| Kafka | RocketMQ | 备注 | |
| 编程语言 | Scalar | Java | |
| 底层通信模块 | JDK NIO | Netty | |
| 组件间通信用自定义基于TCP的二进制协议 | 组件间通信用自定义RemotingCommand协议 | ||
| 服务管理 | zookeeper | Nameserver | Nameserver 组件相关数据都放在内存中（kafka存储在磁盘中），无选举机制，Master挂了，只能手动吧 Slave转换成Master
Nameserver 各个实例之间无交互，其他角色同时向多个实例发状态信息 |
| 概念 | Brocker代表一个服务器的物理机 | Brocker是一个逻辑概念，Master Slave代表物理机 | |
| Partition | MessageQueue | 读队列数量和写队列数量可以不一致：当我们使用updateTopic命令创建topic时，会发现新建的topic下会有默认的8个写对列和8个读对列(依赖于配置)，并且读队列的数量和写队列的数量还可以不一致，这是为什么呢？难道在底层读写队列是在物理上分离的吗？抱着这个问题，我分析了相关的源代码，发现底层代码对于读写队列指的都是同一个队列，其中写队列的数量是针对的producer，读队列的数量针对的是consumer： a.假设写队列有8个、读队列有4个，那么producer产生的消息会按轮训的方式写入到8个队列中，但是consumer却只能消费前4个队列，只有把读队列重新设置为8后，consumer可以继续消费后4个队列的历史消息； b.假设写队列有4个、读队列有8个，那么producer产生的消息会按轮训的方式写入到4个队列中，但是consumer却能消费8个队列，只是后4个队列没有消息可以消费罢了。 | |
| 数据读写 | 异步刷盘 | 同步/异步刷盘 | |
| 异步复制 | 同步/异步复制 | ||
| Partition leader负责读写，Partition Slave只负责同步 | Master负责读写，Slave只能读 | 如果RocketMQ一个topic只有一个Master,这个Master挂掉后，消息不能够写到服务器 | |
| 数据存储 | topic_patition 文件夹，每个数据文件 对应一个index文件 | commitlog：所有topic数据都存入一个commitlog文件中，文件最大1G，追加写 comsumequeue：commitlog的索引，主要存messagequeue 对应的 offset，供commumer消费使用 indexfile：索引文件 可以通过key查找到所有包含这个key的message，主要用于数据搜索 | |
| producer发送数据方式 | 同步/异步 | 同步/异步/oneway | |
| 消费模式 | 多个Consumer放在同一个Group（集群） 多个Consumer每一个放单独的Group（广播） | Consumer都放到一个Group里面，通过设置参数来确定是 广播 还是集群模式 | |
| pull模式 | push/pull 模式 | RocketMQ push 实际是轮询的pull | |
| Consumer Offset 提交策略 | 1、自动提交（poll()方法中提交，判断距上次提交是否超过5s，超过就提交，提交最新获取到的offset。所以部分数据可能还没有消费） 2、手动提交（参数可指定分区和特定offset） （1）同步提交 （2）异步提交 |  | |
| Rebalance机制 | Consumer Leader 统一计算好后，发给服务器，然后服务器再下发给所有Consumer | 每一个Consumer单独计算，彼此不知道对方的计算结果 | RocketMQ在某些特殊情况下（Master挂掉的同事，Comsumer有变动） 会出现 一个MessageQueue被多个Comsumer消费的情况 |
| Rebalance策略 | 1、Range（默认）（每个topic单独计算，如果订阅的topic比较多，会造成比较严重的分配不均） 2、RoundRobin：消费组内所有消费者以及消费者所订阅的所有topic拉通全量计算，可以解决以上问题 |
| |
| 数据可靠性 | 某些情况下能实现 Exactly Once | 只能实现 at least Once | kafka：producer在同一个会话中 会有seq number计数，来保证发送端的幂等性。 RocketMQ在producer发送不成功后有重试，可能发送重复数据 |
1653
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
