共计 2149 个字符，预计需要花费 6 分钟才能阅读完成。
Broker 差别
主从差别: kafka 的 master/slave 是基于 partition 维度的，而 rocketmq 是基于 broker 维度的；kafka 的 master/slave 是能够切换的，而 rocketmq 不行，当 rocketmq 的 master 宕机时，读能被路由到 slave 上，但写会被路由到此 topic 的其余 broker 上。
刷盘：rocketmq 反对同步刷盘，也就是每次音讯都等刷入磁盘后再返回，保障音讯不失落，但对吞吐量稍有影响。个别在主从构造下，抉择异步双写策略是比拟牢靠的抉择。
音讯查问：rocketmq 反对音讯查问，除了 queue 的 offset 外，还反对自定义 key。rocketmq 对 offset 和 key 都做了索引，均是独立的索引文件。
生产失败重试与提早生产：rocketmq 针对每个 topic 都定义了提早队列，当音讯生产失败时，会发回给 broker 存入提早队列中，每个消费者在启动时默认订阅提早队列，这样生产失败的音讯在一段时候后又可能从新生产。延迟时间适宜提早级别一一对应的，延迟时间是随失败次数逐步减少的，最初一次距离 2 小时。
当然发送音讯是也能够指定提早级别，这样就能被动设置提早生产，在一些特定场景下还是有作用的。
数据写入：kafka 每个 partition 独占一个目录，每个 partition 均有各自的数据文件.log；而 rocketmq 是每个 topic 共享一个数据文件 commitlog 因为 kafka 的 topic 个别有多个 partition，所以 kafka 的数据写入熟读比 rocketmq 高出一个量级。但超过肯定数量的文件同时写入，会导致原先的程序写转为随机写，性能急剧下降，所以 kafka 的分区数量是有限度的。
服务治理：kafka 用 zookeeper 来做服务发现和治理，broker 和 consumer 都会向其注册本身信息，同时订阅相应的 znode，这样当有 broker 或者 consumer 宕机时能立即感知，做相应的调整；而 rocketmq 用自定义的 nameServer 做服务发现和治理，其实时性差点，比方如果 broker 宕机，producer 和 consumer 不会实时感知到，须要等到下次更新 broker 集群时 (最长 30S) 能力做相应调整，服务有个不可用的窗口期，但数据不会失落，且能保障一致性。然而某个 consumer 宕机，broker 会实时反馈给其余 consumer，立刻触发负载平衡，这样能肯定水平上保障音讯生产的实时性。
Producer 差别
发送形式：kafka 默认应用异步发送的模式，有一个 memory buffer 暂存音讯，大数据培训同时会将多个音讯整合成一个数据包发送，这样能进步吞吐量，但对音讯的实效有些影响；rocketmq 可抉择应用同步或者异步发送。
发送响应：kafka 的发送 ack 反对三种设置：音讯存进 memory buffer 就返回；等到 leader 收到音讯返回，等到 leader 和 isr 的 follower 都收到音讯返回，当然 kafka 都是异步刷盘。rocketmq 都须要等 broker 的响应确认，有同步刷盘，异步刷盘，同步双写，异步双写等策略，相比于 kafka 多了一个同步刷盘。
Consumer 差别
音讯过滤: rocketmq 的 queue 和 kafka 的 partition 对应，但 rocketmq 的 topic 还能更加细分，可对音讯加 tag，同时订阅时也可指定特定的 tag 来对音讯做更进一步的过滤。或者向服务器上传一段 Java 代码，能够对音讯做任意模式的过滤，甚至能够做 Message Body 的过滤拆分。
有序音讯：rocketmq 反对全局有序和部分有序，kafka 也反对有序音讯，然而如果某个 broker 宕机了，就不能在保障有序了。
生产确认：rocketmq 仅反对手动确认，也就是生产完一条音讯 ack+1，会定期向 broker 同步生产进度，或者在下一次 pull 时附带上 offset。kafka 反对定时确认，拉取到音讯主动确认和手动确认，offset 存在 zookeeper 上。
生产并行度：kafka 的消费者默认是单线程的，一个 Consumer 能够订阅一个或者多个 Partition，一个 Partition 同一时间只能被一个消费者生产，也就是有多少个 Partition 就最多有多少个线程同时生产。
rocketmq 消费者分有序生产模式和并发生产模式，有序模式下，一个消费者也只存在一个线程生产；并发模式下，每次拉取的音讯按 consumeMessageBatchMaxSize(默认 1)拆分后调配给消费者线程池，消费者线程池 min=20,max=64。也就是每个 queue 的并罚度在 20-64 之间，一个 topic 有多个 queue 就相乘。所以 rocketmq 的并发度比 Kafka 高出一个量级。
事务音讯：rocketmq 指定肯定水平上的事务音讯，以后开源版本删除了事务音讯回查性能，事务机制略微变得没有这么牢靠了，不过阿里云的 rocketmq 反对牢靠的事务音讯；kafka 不反对分布式事务音讯。
生产实时性:kafka 是通过短轮训模式拉取音讯，生产实时性取决于轮训距离；rocketmq 是通过长连贯模式拉取音讯，当有新音讯时会立刻登程拉取，只有生产能力足够，实时性比价牢靠。
