一、数据可靠性

• RocketMQ支持异步实时刷盘，同步刷盘，同步Replication，异步Replication
• Kafka使用异步刷盘方式，异步Replication

总结：RocketMQ的同步刷盘在单机可靠性上比Kafka更高，不会因为操作系统Crash，导致数据丢失。 同时同步Replication也比Kafka异步Replication更可靠，数据完全无单点。 

二、性能对比

• Kafka单机写入TPS约在百万条/秒，消息大小10个字节
• RocketMQ单机写入TPS单实例约7万条/秒，单机部署3个Broker，可以跑到最高12万条/秒，消息大小10个字节

总结：Kafka的TPS跑到单机百万，主要是由于Producer端将多个小消息合并，批量发向Broker。

RocketMQ为什么没有这么做？

1. Producer使用Java语言开发，缓存过多消息，GC是个很严重的问题
2. Producer调用发送消息接口，消息未发送到Broker，向业务返回成功，此时Producer宕机，会导致消息丢失，业务出错。

三、消费失败重试

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

四、分布式事务消息

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

五、Broker端消息过滤(Tag)

• Kafka不支持Broker端的消息过滤
• RocketMQ根据Message Tag来过滤，相当于子topic概念 

六、存储形式

• Kafka采用partition，每个topic的每个partition对应一个文件。顺序写入，定时刷盘。但一旦单个broker的partition过多，则顺序写将退化为随机写，Page Cache脏页过多，频繁触发缺页中断，性能大幅下降。
• RocketMQ采用CommitLog+ConsumeQueue，单个broker所有topic在CommitLog中顺序写，Page Cache只需保持最新的页面即可。同时每个topic下的每个queue都有一个对应的ConsumeQueue文件作为索引。ConsumeQueue占用Page Cache极少，刷盘影响较小。

七、延时消息

• RocketMQ支持固定延时等级的延时消息，等级可配置。
• kfaka不支持延时消息。

八、服务发现

• RocketMQ自己实现了namesrv。
• Kafka使用ZooKeeper。