Rocket MQ存储与Kafka存储对比分析

Kafka单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长。Kafka分区数无法过多的问题，RocketMQ单机支持最高5万个队列，负载不会发生明显变化。

本文简单分析一下产生这种问题的原因及因此产生的其他问题。

Rocket MQ的存储结构

RocketMQ的存储结构如下：

RocketMQ在同一个broker上， 所有topic（及topic的queue）的数据都存储在同一个文件中（CommitLog），对每个queue有独立的文件（ConsumeQueue）记录queue相关的数据在commit中的位置，一般ConsumeQueue都可在内存中缓存。

Kafka的存储结构

Kafka的存储结构如下：

Kafka的存储是每个机器上topic的partition（Rocketmq中的queue）的数据独立存储：每个partition对应自己的数据文件。

差异对比

1. 性能差异

这种存储上的差别导致如果单台机器上的partition（queue）数量太多， 对RocketMq来讲， 数据存储的IO可以合并并写到同一个文件， 因此性能不会下降太多。 但对Kafka，随着partition的增多， 会发生多个文件同时IO的情况， 如果这些文件在同一个磁盘上， 就会引起IO写竞争， 因此性能会大幅下降。可通过将partition分散在不同磁盘环境这种竞争。

一般一个broker会由多个topic共享， 因此这种差异可作为选择消息系统的一个重要参考。

2. 同构系统和异构系统的区别

同构系统和异构系统的区别如下：

同构系统：

主从机器上的内容完全一样

主从间数据复制的效率高

异构系统：

异构系统各个机器上的内容不同

充分利用各个机器的资源， 每台机器都可作为写机器（目前绝大多数系统都是仅主可写）从RocketMQ和Kafka的架构上可知， RocketMQ是同构系统， Kafka是异构系统， RocketMQ不可能是异步系统， 因为对同一个queue， 其offset在主从上需要保持一致。3. topic设置差别因为RocketMQ的数据在同一个文件， 因此设置只能是broker维度的设置， 不能精细到topic级别， 比如： 数据存储时间， 刷盘策略， 主从同步策略等。

Kafka支持topic级别的设定，灵活性上Kafka更好。

其他

MQ使用

在应用中， 如果能使用MQ的场景个人比较倾向于使用MQ， 因为本身引入MQ的技术和运维成本并不高，并能解决可靠性和数据分布式问题。

2. MQ的选择

主要根据业务场景， 但如果业务场景没有明显特点， 个人倾向选择RocketMQ， 主要两点理由：

RocketMQ的功能更丰富： 延迟队列， 基于key的消息查询， 事务，tag过滤等。

RocketMQ的客户端更友好： 提供了基于process queue的方式处理了多线程问题（这里碰到很多实现误区是自实现多线程， 处理不好容易丢失数据）。

当然Kafka也有其自身优势， 比如客户端支持更丰富， 社区更成熟， 流处理支持更好等。
责任编辑人：CC