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

架构

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

 

rocketmq kafka 技术选型 rocketmq与kafka_rocketmq kafka 技术选型

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

RocketMQ的架构拓扑图

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

 

rocketmq kafka 技术选型 rocketmq与kafka_Java_02

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

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

Master/Slave/Broker概念

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

1 2 3 4 5 6 7 8 9

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

1 2 3 4 5 6 7 8

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

12 3 4 5 6 7 8

这里机器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。

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机制

RocketMQ 创建topic的命令

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

b:

c: //b和c2选1，b是指定topic所在的机器，c是指定topic所在的cluster

topic: //这个是基本参数，没什么好讲的

readQueueNums/writeQueueNums: //队列个数。缺省2者相等，是8。关于这个readQueueNums/writeQueueNums，是RocketMQ特有的概念，后面再来详细分析。此处就认为他们2者相等，是同1个。

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); 。。。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

Kafka创建topic的命令

跟RocketMQ相比，有2个同样的参数：1个是topic，一个是队列数目，也就是这里的–partitions。

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

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支持异步实时刷盘，同步刷盘，同步Replication，异步Replication
Kafka使用异步刷盘方式，异步Replication/同步Replication
总结：RocketMQ的同步刷盘在单机可靠性上比Kafka更高，不会因为操作系统Crash，导致数据丢失。
Kafka同步Replication理论上性能低于RocketMQ的同步Replication，原因是Kafka的数据以分区为单位组织，意味着一个Kafka实例上会有几百个数据分区，RocketMQ一个实例上只有一个数据分区，RocketMQ可以充分利用IO Group Commit机制，批量传输数据，配置同步Replication与异步Replication相比，性能损耗约20%~30%，Kafka没有亲自测试过，但是个人认为理论上会低于RocketMQ。

性能对比

Kafka单机写入TPS约在百万条/秒，消息大小10个字节
RocketMQ单机写入TPS单实例约7万条/秒，单机部署3个Broker，可以跑到最高12万条/秒，消息大小10个字节
总结：Kafka的TPS跑到单机百万，主要是由于Producer端将多个小消息合并，批量发向Broker。

RocketMQ为什么没有这么做？

Producer通常使用Java语言，缓存过多消息，GC是个很严重的问题
Producer调用发送消息接口，消息未发送到Broker，向业务返回成功，此时Producer宕机，会导致消息丢失，业务出错
Producer通常为分布式系统，且每台机器都是多线程发送，我们认为线上的系统单个Producer每秒产生的数据量有限，不可能上万。
缓存的功能完全可以由上层业务完成。

单机支持的队列数

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

单机可以创建更多Topic，因为每个Topic都是由一批队列组成
Consumer的集群规模和队列数成正比，队列越多，Consumer集群可以越大

消息投递实时性

Kafka使用短轮询方式，实时性取决于轮询间隔时间，0.8以后版本支持长轮询。
RocketMQ使用长轮询，同Push方式实时性一致，消息的投递延时通常在几个毫秒。
消费失败重试
Kafka消费失败不支持重试。
RocketMQ消费失败支持定时重试，每次重试间隔时间顺延
总结：例如充值类应用，当前时刻调用运营商网关，充值失败，可能是对方压力过多，稍后再调用就会成功，如支付宝到银行扣款也是类似需求。

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

严格的消息顺序

Kafka支持消息顺序，但是一台Broker宕机后，就会产生消息乱序
RocketMQ支持严格的消息顺序，在顺序消息场景下，一台Broker宕机后，发送消息会失败，但是不会乱序
Mysql Binlog分发需要严格的消息顺序

定时消息

Kafka不支持定时消息
RocketMQ支持两类定时消息
开源版本RocketMQ仅支持定时Level，定时Level用户可定制
阿里云ONS支持定时Level，以及指定的毫秒级别的延时时间
分布式事务消息
Kafka不支持分布式事务消息
阿里云ONS支持分布式定时消息，未来开源版本的RocketMQ也有计划支持分布式事务消息
消息查询
Kafka不支持消息查询
RocketMQ支持根据Message Id查询消息，也支持根据消息内容查询消息（发送消息时指定一个Message Key，任意字符串，例如指定为订单Id）
总结：消息查询对于定位消息丢失问题非常有帮助，例如某个订单处理失败，是消息没收到还是收到处理出错了。

消息回溯

Kafka理论上可以按照Offset来回溯消息
RocketMQ支持按照时间来回溯消息，精度毫秒，例如从一天之前的某时某分某秒开始重新消费消息
总结：典型业务场景如consumer做订单分析，但是由于程序逻辑或者依赖的系统发生故障等原因，导致今天消费的消息全部无效，需要重新从昨天零点开始消费，那么以时间为起点的消息重放功能对于业务非常有帮助。

消费并行度

Kafka的消费并行度依赖Topic配置的分区数，如分区数为10，那么最多10台机器来并行消费（每台机器只能开启一个线程），或者一台机器消费（10个线程并行消费）。即消费并行度和分区数一致。
RocketMQ消费并行度分两种情况
顺序消费方式并行度同Kafka完全一致
乱序方式并行度取决于Consumer的线程数，如Topic配置10个队列，10台机器消费，每台机器100个线程，那么并行度为1000。

消息轨迹

Kafka不支持消息轨迹
阿里云ONS支持消息轨迹

开发语言友好性

Kafka采用Scala编写
RocketMQ采用Java语言编写

Broker端消息过滤

Kafka不支持Broker端的消息过滤
RocketMQ支持两种Broker端消息过滤方式
根据Message Tag来过滤，相当于子topic概念
向服务器上传一段Java代码，可以对消息做任意形式的过滤，甚至可以做Message Body的过滤拆分。

消息堆积能力

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

开源社区活跃度

Kafka社区更新较慢
RocketMQ的github社区有250个个人、公司用户登记了联系方式，QQ群超过1000人。
成熟度
Kafka在日志领域比较成熟
RocketMQ在阿里集团内部有大量的应用在使用，每天都产生海量的消息，并且顺利支持了多次天猫双十一海量消息考验，是数据削峰填谷的利器。
 

参考

RocketMQ与Kafka对比（18项差异）