Kafka 和 RocketMQ 之性能对比

点击上方“中间件兴趣圈”，选择“设为星标”算法

作积极的人，越努力越幸运！缓存

在双十一过程当中投入一样的硬件资源，Kafka 搭建的日志集群单个Topic能够达到几百万的TPS，而使用RocketMQ组件的核心业务集群，集群TPS只能达到几十万TPS，这样的现象激发了我对二者性能方面的思考。
微信

舒适提示：TPS只是众多性能指标中的一个，咱们在作技术选型方面要从多方面考虑，本文并不打算就消息中间件选型方面投入太多笔墨，重点想尝试剖析二者在性能方面的设计思想。网络

一、文件布局

1.1 Kafka 文件布局

Kafka 文件在宏观上的布局以下图所示：
架构

文件的组织以 topic + 分区进行组织，每个 topic 能够建立多个分区，每个分区包含单独的文件夹，而且是多副本机制，即 topic 的每个分区会有 Leader 与 Follow，而且 Kafka 内部有机制保证 topic 的某一个分区的 Leader 与 follow 不会存在在同一台机器，而且每一台 broker 会尽可能均衡的承担各个分区的 Leader，固然在运行过程当中若是不均衡，能够执行命令进行手动重平衡。Leader 节点承担一个分区的读写，follow 节点只负责数据备份。并发

Kafka 的负载均衡主要依靠分区 Leader 节点的分布状况。负载均衡

分区的 Leader 节点负责读写，而从节点负责数据同步，若是Leader分区所在的Broker节点发生宕机，会触发主从节点的切换，会在剩下的 follow 节点中选举一个新的 Leader 节点，其数据的流入流程以下图所示：
运维

ack = 0异步
不等broker端确认就直接返回，即客户端将消息发送到网络中就返回发送成功。分布式
ack = 1
Leader 节点接受并存储后向客户端返回成功。
ack = -1
Leader节点和全部的Follow节点接受并成功存储再向客户端返回成功。

1.2 RocketMQ 文件布局

RocketMQ 的文件布局以下图所示：

1.3 文件布局对比

Kafka 中文件的布局是以 Topic/partition ，每个分区一个物理文件夹，在分区文件级别实现文件顺序写，若是一个Kafka集群中拥有成百上千个主题，每个主题拥有上百个分区，消息在高并发写入时，其IO操做就会显得零散，其操做至关于随机IO，即 Kafka 在消息写入时的IO性能会随着 topic 、分区数量的增加，其写入性能会先上升，而后降低。

而 RocketMQ在消息写入时追求极致的顺序写，全部的消息不分主题一概顺序写入 commitlog 文件，并不会随着 topic 和分区数量的增长而影响其顺序性。但经过笔者的实践来看一台物理机并使用SSD盘，但一个文件没法充分利用磁盘IO的性能。

二者文件组织方式，除了在磁盘的顺序写方面有所区别后，因为其粒度的问题，Kafka 的 topic 扩容分区会涉及分区在各个 Broker 的移动，其扩容操做比较重，而 RocketMQ 数据存储是基于 commitlog 文件的，扩容时不会产生数据移动，只会对新的数据产生影响，RocketMQ 的运维成本对 Kafka 更低。

最后 Kafka 的 ack 参数能够类比 RocketMQ 的同步复制、异步复制。

Kafka 的 ack 参数为 1 时，对比 RocketMQ 的异步复制；-1 对标 RocketMQ 的同步复制，而 -1 则对标 RocketMQ 消息发送方式的 oneway 模式。

二、数据写入方式

2.1 Kafka 消息写入方式

Kafka 的消息写入使用的是 FileChannel，其代码截图以下：

而且在消息写入时使用了 transferTo 方法，根据网上的资料说 NIO 中网络读写真正是零拷贝的就是须要调用 FileChannel 的 transferTo或者 transferFrom 方法，其内部机制是利用了 sendfile 系统调用。

2.2 RocketMQ 消息写入方式

RocketMQ 的消息写入支持内存映射与 FileChannel 写入两种方式，示例以下图所示：

2.3 消息写入方式对比

尽管 RocketMQ 与 Kafka 都支持 FileChannel 方式写入，但 RocketMQ 基于 FileChannel 写入时调用的 API 却并非 transferTo，而是先调用 writer，而后定时 flush 刷写到磁盘，其代码截图以下：

为何 RocketMQ 不调用 transerTo 方法呢，我的以为和 RocketMQ 须要在 Broker 组装 MQ 消息格式有关，须要从网络中解码请求，传输到堆内存，而后对消息进行加工，最终持久化到磁盘相关。

从网上查询资料中大概倾向于这样一个观点：sendfile 系统调用相比内存映射多了一次从用户缓存区拷贝到内核缓存区，但对于超过64K的内存写入时每每 sendfile 的性能更高，多是因为 sendfile 是基于块内存的。

三、消息发送方式

3.1 Kafka 消息发送机制

Kafka 在消息发送客户端采用了一个双端队列，引入了批处理思想，其消息发送机制以下图所示：

为了提升 kafka 消息发送的高吞吐量，即控制在缓存区中未积满 batch.size 时来控制消息发送线程的行为，是当即发送仍是等待必定时间，若是linger.ms 设置为 0表示当即发送，若是设置为大于0，则消息发送线程会等待这个值后才会向broker发送。linger.ms 参数者会增长响应时间，但有利于增长吞吐量。有点相似于 TCP 领域的 Nagle 算法。

Kafka 的消息发送，在写入 ProducerBatch 时会按照消息存储协议组织好数据，在服务端能够直接写入到文件中。

3.2 RocketMQ 消息发送机制

RocketMQ 消息发送在客户端主要是根据路由选择算法选择一个队列，而后将消息发送到服务端，消息会在服务端按照消息的存储格式进行组织，而后进行持久化等操做。

3.3 消息发送对比

Kafka 在消息发送方面比 RokcetMQ 有一个显著的优点就是消息格式的组织是发生在客户端，这样会有一个大的优点节约了 Broker 端的CPU压力，客户端“分布式”的承接了其优点，其架构方式有点相似 shardingjdbc 与 MyCat 的区别。

Kafka 在消息发送端另一个特色是引入了双端缓存队列，Kafka 无处不在追求批处理，这样显著的特色是能提升消息发送的吞吐量，但与之带来的是增大消息的响应时间，而且带来了消息丢失的可能性，由于 Kafka 追加到消息缓存后会返回成功，若是消息发送方异常退出，会带来消息丢失。

Kafka 中的 linger.ms = 0 可类比 RocketMQ 消息发送的效果。

但 Kafka 经过提供 batch.size 与 linger.ms 两个参数按照场景进行定制化，比 RocketMQ 灵活。

例如日志集群，一般会调大 batch.size 与 linger.ms 参数，重复发挥消息批量发送机制，提升其吞吐量；但若是对一些响应时间比较敏感的话，能够适当减小 linger.ms 的值。

四、总结

从上面的对比来看，Kafka 在性能上综合表现确实要比 RocketMQ 更加的优秀，但在消息选型过程当中，咱们不只仅要参考其性能，还有从功能性上来考虑，例如 RocketMQ 提供了丰富的消息检索功能、事务消息、消息消费重试、定时消息等。

笔者我的认为一般在大数据、流式处理场景基本选用 Kafka，业务处理相关选择 RocketMQ。

欢迎加入个人知识星球，一块儿交流源码，探讨架构，揭秘亿级订单的架构设计与实践经验，打造高质量的技术交流圈，为广大星友提供高质量问答服务，长按以下二维码加入。

本文分享自微信公众号 - 中间件兴趣圈（dingwpmz_zjj）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。