Kafka 与 RocketMQ 性能对比

Kafka 与 RocketMQ 性能对比

一:文件存储

1、Kafka:
Kafka 与 RocketMQ 性能对比_第1张图片

  • 文件以 topic和分区进行存储,每一个 topic 可以创建多个分区,每一个分区包含单独的文件夹,并且是多副本机制。
  • topic 的每一个分区会有 Leader 与 Follow,并且 Kafka 内部有机制保证 topic 的某一个分区的 Leader 与 follow 不会存在在同一台机器,并且每一台 broker 会尽量均衡的承担各个分区的 Leader,当然在运行过程中如果不均衡,可以执行命令进行手动重平衡。
  • Leader 节点承担一个分区的读写,follow 节点只负责数据同步(数据备份)。
  • 如果Leader分区所在的Broker节点发生宕机,会触发主从节点的切换,会在剩下的 follow 节点中选举一个新的 Leader 节点

分区 Leader 收到客户端的消息发送请求时,什么时候返回发送成功,会直接影响消息发送端的时延,Kafka 提供了 ack 这个参数来进行策略选择:

  • ack = 0
    不等broker端确认就直接返回,即客户端将消息发送到网络中就返回发送成功。
  • ack = 1
    Leader 节点接受并存储后向客户端返回成功。
  • ack = -1
    Leader节点和所有的Follow节点接受并成功存储再向客户端返回成功。

2、RocketMQ
Kafka 与 RocketMQ 性能对比_第2张图片

  • RocketMQ 所有topic的消息都会写入到 commitlog 文件中,然后基于 commitlog文件构建消息消费队列文件(Consumequeue),消息消费队列的组织结构按照 /topic/{queue} 进行组织。
  • RocketMQ 默认采取的是主从同步+异步刷盘、多副本机制,但其副本的粒度为 Commitlog 文件,上图中不同 master 节点之间的数据完成不一样(数据分片),而主从节点节点数据一致。

同样RocketMQ发送也有三种类型

  • 1、同步(syncSend方法),会在broker发回响应之后才发下一个msg。适用于msg很重要对响应时间不敏感的场景
  • 2、异步(asyncSend方法),发送之后不等broker响应,接着发下一个msg,需要实现异步发送回调的接口SendCallback,通过回调接口接收服务器的响应,并对响应结果进行处理,适用于msg很重要且对响应时间非常敏感的场景
  • 3、单向(sendOneWay方法),只负责发消息,不等服务器响应也没有回调,适用于对可靠性要求不高的场景比如日志收集

3、存储方式总结:

  • 1、Kafka 中是以 Topic/partition,每一个分区一个物理文件夹,在分区文件级别实现文件顺序写,如果分区过多上千个,消息在高并发写入时会变成随机IO。即 Kafka 在消息写入时的IO性能会随着 topic 、分区数量的增长,其写入性能会先上升,然后下降。而 RocketMQ则追求极致的顺序写所有的消息不分主题一律顺序写入 commitlog 文件,并不会随着 topic 和 分区数量的增加而影响其顺序性。

  • 2、Kafka 的 topic 扩容分区会涉及分区在各个 Broker 的移动,其扩容操作比较重,而 RocketMQ 数据存储是基于 commitlog 文件的,扩容时不会产生数据移动,只会对新的数据产生影响,所以RocketMQ 的运维成本比Kafka 更低

  • 3、Kafka 的 ack 参数可以类比 RocketMQ 的同步复制、异步复制,

    • Kafka 的 ack 参数为 1 时,对比 RocketMQ 的异步复制;

    • -1 对标 RocketMQ 的 同步复制;

    • 0 则对标 RocketMQ 消息发送方式的 oneway 模式。

二:消息写入

Kafka 消息写入时的零拷贝使用了FileChannel 的 transferTo 方法, 其内部机制是 sendfile 系统调用。
RocketMQ 的消息写入的零拷贝方式是内存映射, 其内部机制是 mmap

其实在RocketMQ 也是支持 FileChannel 方式写入,只不过写入时调用的 API 却并不是 transferTo,而是先调用 writer,然后定时 flush 刷写到磁盘。个人觉得 不直接调用 transerTo 方法是因为RocketMQ 需要在 Broker 对消息(顺序消息、延迟消息、事务消息)进行加工,然后持久化到磁盘。

三:消息发送

1、kafka

消息发送者发送消息时,消息会首先存入到一个双端队列中,双端队列中单个元素为 ProducerBatch,表示一个发送批次,其最大大小受参数 batch.size 控制,默认为 16K。然后会单独开一个 Send 线程,从双端队列中获取一个发送批次,将消息按批发送到 Kafka集群中,这里引入了 linger.ms 参数来控制 Send 线程的发送行为。如果linger.ms 设置为 0表示立即发送,。linger.ms>0 会增加响应时间,但有利于增加吞吐量。

Kafka 的消息发送,在写入 ProducerBatch 时会按照消息存储协议组织好数据(客户端),在服务端可以直接写入到文件中。

2、RocketMQ

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

3、消息发送总结

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

Kafka 通过提供 batch.size 与 linger.ms 两个参数按照场景进行定制化,比 RocketMQ 灵活,linger.ms = 0 就是RocketMQ 消息发送的效果。

四:性能对比总结

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

个人认为通常在大数据、流式处理场景基本选用 Kafka,业务处理相关选择 RocketMQ。

你可能感兴趣的:(kafka,个人开发,开发语言,RocketMQ)