相同之处
- 两者底层原理有很多相似之处，RocketMQ借鉴了Kafka的设计。
- 两者均利用了操作系统Page Cache的机制，同时尽可能通过顺序io降低读写的随机性，将读写集中在很小的范围内，减少缺页中断，进而减少了对磁盘的访问，提高了性能。
不同之处
存储形式
- Kafka采用partition，每个topic的每个partition对应一个文件。顺序写入，定时刷盘。但一旦单个broker的partition过多，则顺序写将退化为随机写，Page Cache脏页过多，频繁触发缺页中断，性能大幅下降。
- RocketMQ采用CommitLog+ConsumeQueue，单个broker所有topic在CommitLog中顺序写，Page Cache只需保持最新的页面即可。同时每个topic下的每个queue都有一个对应的ConsumeQueue文件作为索引。ConsumeQueue占用Page Cache极少，刷盘影响较小。
存储可靠性
- RocketMQ支持异步刷盘，同步刷盘，同步Replication，异步Replication。
- Kafka使用异步刷盘，异步Replication。
顺序消息
Kafka和RocketMQ都仅支持单topic分区有序。RocketMQ官方虽宣称支持严格有序，但方式为使用单个分区。
延时消息
- RocketMQ支持固定延时等级的延时消息，等级可配置。
- kfaka不支持延时消息。
消息重复
- RocketMQ仅支持At Least Once。
- Kafka支持At Least Once、Exactly Once。
消息过滤
- RocketMQ执行过滤是在Broker端，支持tag过滤及自定义过滤逻辑。
- Kafka不支持Broker端的消息过滤，需要在消费端自定义实现。
消息失败重试
- RocketMQ支持定时重试，每次重试间隔逐渐增加。
- Kafka不支持重试。
DLQ（dead letter queue）
- RocketMQ通过DLQ来记录所有消费失败的消息。
- Kafka无DLQ。Spring等第三方工具有实现，方式为将失败消息写入一个专门的topic。
回溯消费
- RocketMQ支持按照时间回溯消费，实现原理与Kafka相同。
- Kafka需要先根据时间戳找到offset，然后从offset开始消费。
事务
- RocketMQ支持事务消息，采用二阶段提交+broker定时回查。但也只能保证生产者与broker的一致性，broker与消费者之间只能单向重试。即保证的是最终一致性。
- Kafka从0.11版本开始支持事务消息，除支持最终一致性外，还实现了消息Exactly Once语义（单个partition）。
服务发现
- RocketMQ自己实现了namesrv。
- Kafka使用ZooKeeper。
高可用
- RocketMQ在高可用设计上粒度只控制在Broker。其保证高可用是通过master-slave主从复制来解决的。
- Kafka控制高可用的粒度是放在分区上。每个topic的leader分区和replica分区都可以在所有broker上负载均衡的存储。
- Kafka的这种设计相比RocketMQ这种主从复制的设计有以下好处：
- Kafka中不需要设置从broker，所有的broker都可以收发消息。负载均衡也做的更好。
- Kafka的分区选举是自动做的，RocketMQ需要自己指定主从关系。
- Kafka分区的复制份数指定为N，则可以容忍N-1个节点的故障。发生故障只需要分区leader选举下即可，效率很高。
