『』注意了！Kafka与RabbitMQ千万不要乱用…( 五 )
优先选择 RabbitMQ 的条件：
高级灵活的路由规则
消息时序控制(控制消息过期或者消息延迟)
高级的容错处理能力 ， 在消费者更有可能处理消息不成功的情景中(瞬时或者持久)
更简单的消费者实现
优先选择 Kafka 的条件：
严格的消息顺序
延长消息留存时间 ， 包括过去消息重放的可能
传统解决方案无法满足的高伸缩能力
大部分情况下这两个消息平台都可以满足我们的要求 。但是 ， 它取决于我们的架构师 ， 他们会选择最合适的工具 。
当做决策的时候 ， 我们需要考虑上面着重强调的功能性差异和非功能性限制 。
这些限制如下：
当前开发者对这两个消息平台的了解
托管云解决方案的可用性(如果适用)
每种解决方案的运营成本
适用于我们目标栈的 SDK 的可用性
当开发复杂的软件系统时 ， 我们可能被诱导使用同一个消息平台去实现所有必须的消息用例 。
但是 ， 从我的经验看 ， 通常同时使用这两个消息平台能够带来更多的好处 。
例如 ， 在一个事件驱动的架构系统中 ， 我们可以使用 RabbitMQ 在服务之间发送命令 ， 并且使用 Kafka 实现业务事件通知 。
原因是事件通知常常用于事件溯源 ， 批量操作(ETL 风格) ， 或者审计目的 ， 因此 Kafka 的消息留存能力就显得很有价值 。
相反 ， 命令一般需要在消费者端做额外处理 ， 并且处理可以失败 ， 所以需要高级的容错处理能力 。
这里 ， RabbitMQ 在功能上有很多闪光点 。以后我可能会写一篇详细的文章来介绍 ， 但是你必须记住：你的里程(mileage)可能会变化 ， 因为适合性取决于你的特定需求 。
总结
写这两篇文章是由于我观察到许多开发者把这 RabbitMQ 和 Kafka 作为等价来看待 。
我希望通过这两篇文章的帮助能够让你获得对这两种技术实现的深刻理解以及它们之间的技术差异 。
反过来通过它们之间的差异来影响这两个平台去给用例提供更好的服务 。这两个消息平台都很棒 ， 并且都能够给多个用例提供很好的服务 。
但是 ， 作为解决方案架构师 ， 取决于我们对每一个用例需求的理解 ， 以及优化 ， 然后选择最合适的解决方案 。
作者：王欢编译
推荐阅读
- 超声波■工业熔喷布用超声波清洗机的构造及注意事项
- 「封号」原创 微信用户注意，这3个“雷区”别踩，否则可能直接封号处理
- 『小张侃数码』选择手机时注意以下几点，帮你选择最合适的5G手机
- 人人都是产品经理：商品详情页改版，这6个关键优化点要注意
- 【】微信用户注意！这4个“功能”要关闭，否则个人隐私全泄露了
- [软件]iPhone用户注意！App Store出现新型诈骗软件，350万人已中枪
- 忻州：各位车主注意！忻州城区这样停车扣分、罚款
- 『中国质量万里行』微信用户注意！这4个“功能”要关闭，否则个人隐私全泄露了
- 搜狐：企业建站如何选择平台？这几点需要注意
- 「万象科技大爆料」手机运行内存的4GB，6GB和8GB到底有什么区别？选手机时该注意！