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

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

RocketMQ的存储结构

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的客户端更友好：提供了基于processqueue的方式处理了多线程问题（这里碰到很多实现误区是自实现多线程，处理不好容易丢失数据）。

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