技术选型：RocketMQ or Kafka

当业务需要系统间调用解耦时，MQ 是一个很好的方案，目前选择最多的当属Kafka和阿里的RocketMQ, 两种中间件都可以使用，都是备选方案，摆在面前，怎么选择？

1. 方法论-评估和选择备选方案的方法

按优先级选择，即架构师综合当前的业务发展情况、团队人员规模和技能、业务发展预测等因素，将质量属性按照优先级排序，首先挑选满足第一优先级的，如果方案都满足，那就再看第二优先级……以此类推。

2. RocketMQ 和 Kafka 到底有什么区别？

（1） 适用场景

Kafka适合日志处理；

RocketMQ适合业务处理。

结论：平手，根据具体业务定夺。

（2） 性能

Kafka单机写入 TPS 号称在百万条/秒；

RocketMQ 大约在10万条/秒。

结论：追求性能的话，Kafka单机性能更高。

（3） 可靠性

RocketMQ支持异步/同步刷盘;异步/同步Replication；

Kafka使用异步刷盘方式，异步Replication。

结论：RocketMQ所支持的同步方式提升了数据的可靠性。

（4） 实时性

均支持pull长轮询，RocketMQ消息实时性更好

结论：RocketMQ 胜出。

（5） 支持的队列数

Kafka单机超过64个队列/分区，消息发送性能降低严重；

RocketMQ 单机支持最高5万个队列，性能稳定

结论：长远来看，RocketMQ 胜出，这也是适合业务处理的原因之一

（6） 消息顺序性

Kafka 某些配置下，支持消息顺序，但是一台Broker宕机后，就会产生消息乱序；

RocketMQ支持严格的消息顺序，在顺序消息场景下，一台Broker宕机后，

发送消息会失败，但是不会乱序；

结论：RocketMQ 胜出

（7）消费失败重试机制

Kafka消费失败不支持重试

RocketMQ消费失败支持定时重试，每次重试间隔时间顺延。

（8）定时/延时消息

Kafka不支持定时消息；

RocketMQ支持定时消息

（9）分布式事务消息

Kafka不支持分布式事务消息；

阿里云ONS支持分布式定时消息，未来开源版本的RocketMQ也有计划支持分布式事务消息

（10）消息查询机制

Kafka不支持消息查询

RocketMQ支持根据Message Id查询消息，也支持根据消息内容查询消息

（11）消息回溯

Kafka理论上可以按照Offset来回溯消息

RocketMQ支持按照时间来回溯消息，精度毫秒，例如从一天之前的某时某分某秒开始重新消费消息

3. 为什么阿里会自研RocketMQ？

（1）Kafka的业务应用场景主要定位于日志传输；对于复杂业务支持不够

（2）阿里很多业务场景对数据可靠性、数据实时性、消息队列的个数等方面的要求很高。

kafka针对海量数据，但是对数据的正确度要求不是十分严格。而阿里巴巴中用于交易相关的事情较多，对数据的正确性要求极高，Kafka不合适

（3）当业务成长到一定规模，采用开源方案的技术成本会变高.

开源方案无法满足业务的需要；旧版本、自开发代码与新版本的兼容都可能是问题；运维角度，Kafka使用 scala 编写，而阿里是java系。Kafka 的后续维护是个问题。

（4）阿里在团队、成本、资源投入等方面约束性条件几乎没有.

综上，阿里选择自己开发RocketMQ更多是业务的驱动，当业务更多的需要以下功能的支持时，kafka 不能满足或者 ActiveMQ 等其他消息中间件不能满足，财大气粗能力又强业务还复杂，所以就自己开发了。

4. 其他

另外认为kafka是用于日志传输，所以不适合系统的业务事件是个更大的误区，Kafka本身在最早实现时的确是为了传输日志，但后来经过多年发展，其适用范围早不限于日志，并且很多采取Kafka的公司并非用它来处理日志，kafka背后的 Confluence公司提供了很多基于kafka来简化系统实现的例子。

大家都在发展，功能的差异会很快抹平的。

RocketMQ 可以理解为是Java版 的kafka。

更多的性能对比可以参考阿里中间件团队的报告。

转载于:https://juejin.im/post/5cac5abde51d456e5633dda7