【中间件】RocketMQ与Kafka的异同_rocketmq的offset和kafka的offset的区别

一、相同之处

• 1、两者底层原理有很多相似之处，RocketMQ借鉴了Kafka的设计。
• 2、两者均利用了操作系统Page Cache的机制，同时尽可能通过顺序io降低读写的随机性，将读写集中在很小的范围内，减少缺页中断，进而减少了对磁盘的访问，提高了性能。

二、不同之处

1、存储形式

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

2、存储可靠性

• RocketMQ支持异步刷盘，同步刷盘，同步Replication，异步Replication。
• Kafka使用异步刷盘，异步Replication。

3、顺序消息

• Kafka和RocketMQ都仅支持单topic分区有序。RocketMQ官方虽宣称支持严格有序，但方式为使用单个分区。

4、延时消息

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

5、消息重复

• RocketMQ仅支持At Least Once。
• Kafka支持At Least Once、Exactly Once。

6、消息过滤

• RocketMQ执行过滤是在Broker端，支持tag过滤及自定义过滤逻辑。
• Kafka不支持Broker端的消息过滤，需要在消费端自定义实现。

7、消息失败重试

• RocketMQ支持定时重试，每次重试间隔逐渐增加。
• Kafka不支持重试。

8、DLQ（dead letter queue）

• RocketMQ通过DLQ来记录所有消费失败的消息。
• Kafka无DLQ。Spring等第三方工具有实现，方式为将失败消息写入一个专门的topic。

9、回溯消费

• RocketMQ支持按照时间回溯消费，实现原理与Kafka相同。
• Kafka需要先根据时间戳找到offset，然后从offset开始消费。

10、事务

• RocketMQ支持事务消息，采用二阶段提交+broker定时回查。但也只能保证生产者与broker的一致性，broker与消费者之间只能单向重试。即保证的是最终一致性。
• Kafka从0.11版本开始支持事务消息，除支持最终一致性外，还实现了消息Exactly Once语义（单个partition）。

11、服务发现

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

12、高可用

• RocketMQ在高可用设计上粒度只控制在Broker。其保证高可用是通过master-slave主从复制来解决的。

• Kafka控制高可用的粒度是放在分区上。每个topic的leader分区和replica分区都可以在所有broker上负载均衡的存储。

• Kafka的这种设计相比RocketMQ这种主从复制的设计有以下好处：

• Kafka中不需要设置从broker，所有的broker都可以收发消息。负载均衡也做的更好。

• Kafka的分区选举是自动做的，RocketMQ需要自己指定主从关系。

• Kafka分区的复制份数指定为N，则可以容忍N-1个节点的故障。发生故障只需要分区leader选举下即可，效率很高。

三、参考资料

• MQ初窥门径【面试必看的Kafka和RocketMQ存储区别】
• RocketMQ高性能之底层存储设计
• 【干货】Kafka 事务特性分析
• Kafka设计解析（八）- Exactly Once语义与事务机制原理
• 消息中间件——RocketMQ与Kafka特性对比
• Kafka和RocketMQ的一点对比总结
• RocketMQ之消息中间件需要解决的问题