Kafka VS RocketMq

淘宝内部的交易系统使用了淘宝自主研发的Notify消息中间件，使用Mysql作为消息存储媒介，可完全水平扩容，为了进一步降低成本，我们认为存储部分可以进一步优化，2011年初，Linkin开源了Kafka这个优秀的消息中间件，淘宝中间件团队在对Kafka做过充分Review之后，Kafka无限消息堆积，高效的持久化速度吸引了我们，但是同时发现这个消息系统主要定位于日志传输，对于使用在淘宝交易、订单、充值等场景下还有诸多特性不满足，为此我们重新用Java语言编写了RocketMQ，定位于非日志的可靠消息传输（日志场景也OK），目前RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。

一、 数据库可靠性

A：RocketMQ支持异步刷盘，同步刷盘，同步Replication，异步Replication

B：kafka使用异步刷盘方式，异步Replication

备注：RocketMQ的同步刷盘在单机可靠性上比Kafka更高，不会因为操作系统Crash，导致数据丢失。 同时同步Replication也比Kafka异步Replication更可靠，数据完全无单点。另外Kafka的Replication以topic为单位，支持主机宕机，备机自动切换，但是这里有个问题，由于是异步Replication，那么切换后会有数据丢失，同时Leader如果重启后，会与已经存在的Leader产生数据冲突。开源版本的RocketMQ不支持Master宕机，Slave自动切换为Master，阿里云版本的RocketMQ支持自动切换特性。

二、性能（producer生成消息的TPS）

A：Kafka单机写入TPS约在百万条/秒，消息大小10个字节

B：RocketMQ单机写入TPS单实例约7万条/秒，单机部署3个Broker，可以跑到最高12万条/秒，消息大小10个字节

备注：Kafka的TPS跑到单机百万，主要是由于Producer端将多个小消息合并，批量发向Broker。

RocketMQ为什么没有这么做？

Producer通常使用Java语言，缓存过多消息，GC是个很严重的问题

Producer调用发送消息接口，消息未发送到Broker，向业务返回成功，此时Producer宕机，会导致消息丢失，业务出错

Producer通常为分布式系统，且每台机器都是多线程发送，我们认为线上的系统单个Producer每秒产生的数据量有限，不可能上万。

缓存的功能完全可以由上层业务完成。

三、单机支持的队列数（consumer集群的支持）

Kafka单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长

RocketMQ单机支持最高5万个队列，Load不会发生明显变化

队列多有什么好处？

单机可以创建更多Topic，因为每个Topic都是由一批队列组成

Consumer的集群规模和队列数成正比，队列越多，Consumer集群可以越大

四、消息推送时效性

A：Kafka使用短轮询方式，实时性取决于轮询间隔时间

B：RocketMQ使用长轮询，同Push方式实时性一致，消息的投递延时通常在几个毫秒。

五、消息失败重试机制

A：Kafka消费失败不支持重试

B：RocketMQ消费失败支持定时重试，每次重试间隔时间顺延

备注：例如充值类应用，当前时刻调用运营商网关，充值失败，可能是对方压力过多，稍后在调用就会成功，如支付宝到银行扣款也是类似需求。

这里的重试需要可靠的重试，即失败重试的消息不因为Consumer宕机导致丢失。

六、消息推送的顺序

A：Kafka支持消息顺序，但是一台Broker宕机后，就会产生消息乱序

B：RocketMQ支持严格的消息顺序，在顺序消息场景下，一台Broker宕机后，发送消息会失败，但是不会乱序

Mysql Binlog分发需要严格的消息顺序

七、消息定时推送策略

A：Kafka不支持定时消息

B：RocketMQ支持两类定时消息

开源版本RocketMQ仅支持定时Level

阿里云ONS支持定时Level，以及指定的毫秒级别的延时时间

八、分布式事务消息

A：Kafka不支持分布式事务消息

B：阿里云ONS支持分布式定时消息，未来开源版本的RocketMQ也有计划支持分布式事务消息

九、消息查询机制

A：Kafka不支持消息查询

B：RocketMQ支持根据Message Id查询消息，也支持根据消息内容查询消息（发送消息时指定一个Message Key，任意字符串，例如指定为订单Id）

备注：消息查询对于定位消息丢失问题非常有帮助，例如某个订单处理失败，是消息没收到还是收到处理出错了。

十、消息回溯

A：Kafka理论上可以按照Offset来回溯消息

B：RocketMQ支持按照时间来回溯消息，精度毫秒，例如从一天之前的某时某分某秒开始重新消费消息

备注：典型业务场景如consumer做订单分析，但是由于程序逻辑或者依赖的系统发生故障等原因，导致今天消费的消息全部无效，需要重新从昨天零点开始消费，那么以时间为起点的消息重放功能对于业务非常有帮助。

十一、消费并行度

A：Kafka的消费并行度依赖Topic配置的分区数，如分区数为10，那么最多10台机器来并行消费（每台机器只能开启一个线程），或者一台机器消费（10个线程并行消费）。即消费并行度和分区数一致。

B：RocketMQ消费并行度分两种情况

顺序消费方式并行度同Kafka完全一致

乱序方式并行度取决于Consumer的线程数，如Topic配置10个队列，10台机器消费，每台机器100个线程，那么并行度为1000。

十二、消息轨迹

A：Kafka不支持消息轨迹

B：阿里云ONS支持消息轨迹

十三、Broker端消息过滤

A：Kafka不支持Broker端的消息过滤

B：RocketMQ支持两种Broker端消息过滤方式

根据Message Tag来过滤，相当于子topic概念

向服务器上传一段Java代码，可以对消息做任意形式的过滤，甚至可以做Message Body的过滤拆分。

消息堆积能力

理论上Kafka要比RocketMQ的堆积能力更强，不过RocketMQ单机也可以支持亿级的消息堆积能力，我们认为这个堆积能力已经完全可以满足业务需求。

后期维护

十四、开源社区活跃度

A：Kafka社区更新较慢

B：RocketMQ的github社区有250个个人、公司用户登记了联系方式，QQ群超过1000人。

十五、商业支持

A：Kafka原开发团队成立新公司，目前暂没有相关产品看到

B：RocketMQ在阿里云上已经开放公测近半年，目前以云服务形式免费供大家商用，并向用户承诺99.99%的可靠性，同时彻底解决了用户自己搭建MQ产品的运维复杂性问题

十六、成熟度

A：Kafka在日志领域比较成熟

B：RocketMQ在阿里集团内部有大量的应用在使用，每天都产生海量的消息，并且顺利支持了多次天猫双十一海量消息考验，是数据削峰填谷的利器。

十七、namesrv VS zk

我们知道，在早期的RocketMQ版本中，是有依赖ZK的。而现在的版本中，是去掉了对ZK的依赖，转而使用自己开发的NameSrv。并且这个NameSrv是无状态的，你可以随意的部署多台，其代码也非常简单，非常轻量。那不禁要问了：ZooKeeper是业界用来管理集群的一个非常常用的中间件，比如Kafka就是依赖的ZK。那为什么RocketMQ要自己造轮子，自己做集群的管理呢？纯粹就是再做一个Zookeeper吗？本篇试图通过一个架构上的巨大差异，来阐述为什么RocketMQ可以去掉ZK。（不需要zk的选举机制，master/salver的角色是固定的）

我们知道，在Kafka中，是1个topic有多个partition，每个partition有1个master + 多个slave。对应如下图所示：

注意：这里只有3台机器(b0,b1,b2)，每台机器既是Master，也是Slave。具体来说，比如机器b0，对于partition0来说，它可能是Master；对应partition1来说，它可能又是Slave。

不同于Kafka，一台机器同时是Master和Slave。在RocketMQ里面，1台机器只能要么是Master，要么是Slave。这个在初始的机器配置里面，就定死了。其架构拓扑图如下：

在这里，RocketMQ里面queue这个概念，就对应Kafka里面partition。

有3个Master, 6个Slave，那对应到物理上面，就是3+6，得9台机器！！！而不是上面像Kafka一样，3台机器。

Master/Slave/Broker概念上的差异

通过上面2张图，我们已经可以直观看出2者的巨大差异。反映到概念上，虽然2者都有Master/Slave/Broker这3个概念，但其含义是不一样的。

Master/Slave概念差异

Kafka: Master/Slave是个相对概念，1台机器，可能同时具有Master角色和Slave角色。
RocketMQ: Master/Slave是个绝对概念，1台机器，只能是Master或者Slave。在集群初始配置的时候，指定死的。其中Master的broker id = 0，Slave的broker id > 0。

Broker概念差异

Kafka: Broker是个物理概念，1个broker就对应1台机器。
RocketMQ：Broker是个逻辑概念，1个broker = 1个master + 多个slave。所以才有master broker, slave broker这样的概念。

那这里，master和slave是如何配对的呢？ 答案是通过broker name。具有同1个broker name的master和slave进行配对。

具体到配置里面，如下：

//机器1的配置
brokerClusterName=DefaultCluster
brokerName=broker-a
brokerId=0
deleteWhen=04
fileReservedTime=48
brokerRole=ASYNC_MASTER
flushDiskType=ASYNC_FLUSH

//机器2的配置
brokerClusterName=DefaultCluster
brokerName=broker-a
brokerId=1
deleteWhen=04
fileReservedTime=48
brokerRole=SLAVE
flushDiskType=ASYNC_FLUSH

//机器3的配置
brokerClusterName=DefaultCluster
brokerName=broker-a
brokerId=2
deleteWhen=04
fileReservedTime=48
brokerRole=SLAVE
flushDiskType=ASYNC_FLUSH

 这里机器1和机器2，机器3具有相同的brokerName（broker-a)，一个brokerId = 0，另2个brokerId > 0。所以机器1是Master，机器2, 3是Slave。

所以这里可以看出：RokcetMQ和Kafka关于这2对概念的定义，刚好是反过来的！Kafka是先有Broker，然后产生出Master/Slave；RokcetMQ是先定义Master/Slave，然后组合出Broker。

为什么可以去ZK?

从上面对比可以看出，Kafka和RocketMQ在Master/Slave/Broker这个3个概念上的差异。

这个差异，也就影响到topic, partition这种逻辑概念和Master/Slave/Broker这些物理概念上的映射关系。具体来讲就是：

在Kafka里面，Maser/Slave是选举出来的，RocketMQ不需要选举 。

具体来说，在Kafka里面，Master/Slave的选举，有2步：第1步，先通过ZK在所有机器中，选举出一个KafkaController；第2步，再由这个Controller，决定每个partition的Master是谁，Slave是谁。

这里的Master/Slave是动态的，也就是说：当Master挂了之后，会有1个Slave切换成Master。

而在RocketMQ中，不需要选举，Master/Slave的角色也是固定的。当一个Master挂了之后，你可以写到其他Master上，但不会说一个Slave切换成Master。

这种简化，使得RocketMQ可以不依赖ZK就很好的管理Topic/queue和物理机器的映射关系了，也实现了高可用。

在Kafka里面，一个partition必须与1个Master有严格映射关系，这个Master挂了，就要从其他Slave里面选举出一个Master；而在RocketMQ里面，这个限制放开了，一个queue对应的Master挂了，它会切到其他Master，而不是非要选举出来一个。

说到这，答案基本就知道了：RocketMQ不需要像Kafka那样有很重的选举逻辑，它把这个问题简化了。剩下的就是topic/queue的路由信息，那用个简单的NameServer就搞定了，很轻量，还无状态，可靠性也能得到很好保证。

Topic的创建过程

下面从使用的角度，看看Kafka和RocketMQ在创建topic的时候，分别都需要指定什么参数？

从这些参数也可以看出，2者的topic, partition这种逻辑概念和物理机器之间的映射关系，有很大不同。

RocketMQ 创建topic的命令

下面代码来自UpdateTopicSubCommand这个类，也就是RocketMq创建topic时，调用的类。这里有几个关键参数：    

 Option opt = new Option("b", "brokerAddr", true, "create topic to which broker");
        opt.setRequired(false);
        options.addOption(opt);

        opt = new Option("c", "clusterName", true, "create topic to which cluster");
        opt.setRequired(false);
        options.addOption(opt);

        opt = new Option("t", "topic", true, "topic name");
        opt.setRequired(true);
        options.addOption(opt);

        opt = new Option("r", "readQueueNums", true, "set read queue nums");
        opt.setRequired(false);
        options.addOption(opt);

        opt = new Option("w", "writeQueueNums", true, "set write queue nums");
        opt.setRequired(false);
        options.addOption(opt);

  
Kafka创建topic的命令

跟RocketMQ相比，有2个同样的参数：

1个是topic，一个是队列数目，也就是这里的–partitions。

bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 3 --partitions 1 --topic my-replicated-topic

2者在创建topic时一个显著的不同

Kafka有一个参数replication-factor，也就是指定给1个Master配几个Slave?

RocketMQ有一个参数c，也就是clusterName，来指定这个cluster里面，所有的Master和Slave的配对（多个master, 多个slave) 对应同1个topic，缺省情况下，所有的Master和Slave属于同1个集群，也就是上面的3台机器配置中的第1个参数brokerClusterName=DefaultCluster。

结合上面的架构拓扑图，我们就可以看出：
对于kafka来说，你指定topic，它的partition个数，它的master/slave配比，然后系统自动从所有机器中，为每个topic_partition分配1个master + 多个slave；

对于RokcetMQ来说，你指定topic，它的queue个数，它对应的cluster。然后系统自动建立这个cluster(多个master + 多个slave) 和你的topic之间的映射关系。

十八、存储上的巨大差异

RocketMQ和Kafka在架构上面的一个巨大差异：Kafka是每个partition对应一个文件，而RocketMQ是把所有topic的所有queue的消息存储在一个文件里面，然后再分发给ConsumeQueue。

Kafka的存储

下图展示了Kafka的存储结构: 其中每个topic_partition对应一个日志文件，Producer对该日志文件进行“顺序写”，Consumer对该文件进行“顺序读”。这种存储方式，对于每个文件来说是顺序IO，但是当并发的读写多个partition的时候，对应多个文件的顺序IO，表现在文件系统的磁盘层面，还是随机IO。因此出现了当partition或者topic个数过多时，Kafka的性能急剧下降。

RocketMQ的存储

为了解决上述问题，RocketMQ采用了单一的日志文件，即把同1台机器上面所有topic的所有queue的消息，存放在一个文件里面，从而避免了随机的磁盘写入。其存储结构如下：

如上图所示，所有消息都存在一个单一的CommitLog文件里面，然后有后台线程异步的同步到ConsumeQueue，再由Consumer进行消费。

关键性差异

上面的存储差异，说的明显一点，就是：Kafka针对Producer和Consumer使用了同1份存储结构，而RocketMQ却为Producer和Consumer分别设计了不同的存储结构，Producer对应CommitLog, Consumer对应ConsumeQueue。

这里之所以可以用“异步线程”，也是因为消息队列天生就是用来“缓冲消息”的。只要消息到了CommitLog，发送的消息也就不会丢。只要消息不丢，那就有了“充足的回旋余地”，用一个后台线程慢慢同步到ConsumeQueue，再由Consumer消费。

可以说，这也是在消息队列内部的一个典型的“最终一致性”的案例：Producer发了消息，进了CommitLog，此时Consumer并不可见。但没关系，只要消息不丢，消息最终肯定会进入ConsumeQueue，让Consumer可见。