https://www.cnblogs.com/qinghe123/p/13201713.html
（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来简化系统实现的例子。