RocketMQ与Kafka对比（18项差别）评价版

此文是rocketmq做者vintage.wang所写，对于每项对比，后面都增长了个人观点，有不对的地方，请各位指出。

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

 

为了方便你们选型，整理一份RocketMQ与Kafka的对比文档，文中若有错误之处，欢迎来函指正。vintage.wang@gmail.com

 

数据可靠性

·RocketMQ支持异步实时刷盘，同步刷盘，同步Replication，异步Replication

·Kafka使用异步刷盘方式，异步Replication

王启军评：这个地方描述有问题，kafka没法设置同步刷盘，可是能够设置同步Replication，使用request.required.acks=-1，全部的replicas接收才返回ack。

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

王启军评：首先明确第一个问题，就算异步刷盘，当broker挂掉时，数据是不会丢失的，只有系统crash才会形成丢失，前面指出，虽然kafka是异步落盘，可是在集群模式下，能够设置同步replication，若是是同步replication，复制因子为N，容许N-1个服务所在的系统crash，而不会丢失数据，也就不存在切换后的问题。

 

性能对比

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

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

总结：Kafka的TPS跑到单机百万，主要是因为Producer端将多个小消息合并，批量发向Broker。

王启军评：这个地方kafka也是能够设置是否进行批量发送的。

 

RocketMQ为何没有这么作？

1.Producer一般使用Java语言，缓存过多消息，GC是个很严重的问题

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

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

4.缓存的功能彻底能够由上层业务完成。

单机支持的队列数

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

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

队列多有什么好处？

1.单机能够建立更多Topic，由于每一个Topic都是由一批队列组成

2.Consumer的集群规模和队列数成正比，队列越多，Consumer集群能够越大

消息投递实时性

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

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

王启军评：0.8版本已经有长轮询实现了

消费失败重试

·Kafka消费失败不支持重试

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

王启军评：kafka也支持，能够经过下面两个参数设置

message.send.max.retries=100

retry.backoff.ms=5000

不过这个重试时间是固定的，一般但愿有个倍数。消息不丢失主要依赖ack机制，可是可能会形成重复，这个消息中间件一般但愿经过业务来解决，最简单的办法，表中设置一个惟一键，或者写业务数据的同时，增长一张日志表，保证惟一。

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

 

这里的重试须要可靠的重试，即失败重试的消息不由于Consumer宕机致使丢失。

 

严格的消息顺序

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

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

王启军评：不知道这个问题从何而来，不知道具体场景。

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

 

定时消息

·Kafka不支持定时消息

·RocketMQ支持两类定时消息

o开源版本RocketMQ仅支持定时Level

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

王启军评：此功能仍是很是有用的，可是不知道支持的数据数量级有没有限制

分布式事务消息

·Kafka不支持分布式事务消息

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

王启军评：虽然kafka不支持分布式事务，可是大多互联网应用采用分布式事务的不多，主要是由于：一、缺少大规模应用的成功案例

二、死锁风险，特别是在大并发量下，如今大可能是以客户端做为协调者，而客户端一般部署在虚拟机或者docker这种容器中，一旦挂掉，数据库只能等客户端恢复解锁。

通常使用rocketmq或者kafka的对并发量要求都比较高，使用分布式事务是一个须要考虑的问题。

Kafka有两个等级的api，大多使用highLevel的，还有一个simple Api，能够本身控制offset的存储，这样就能够变向实现分布式事务了。

消息查询

·Kafka不支持消息查询

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

总结：消息查询对于定位消息丢失问题很是有帮助，例如某个订单处理失败，是消息没收到仍是收处处理出错了。

王启军评：此功能很是棒，比较实用。

消息回溯

·Kafka理论上能够按照Offset来回溯消息

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

总结：典型业务场景如consumer作订单分析，可是因为程序逻辑或者依赖的系统发生故障等缘由，致使今天消费的消息所有无效，须要从新从昨天零点开始消费，那么以时间为起点的消息重放功能对于业务很是有帮助。

 

消费并行度

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

·RocketMQ消费并行度分两种状况

o顺序消费方式并行度同Kafka彻底一致

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

王启军评：这个须要根据具体的业务场景，一般状况下，mq的处理能力已经足够快，瓶颈一般在业务处理上。

消息轨迹

·Kafka不支持消息轨迹

·阿里云ONS支持消息轨迹

开发语言友好性

·Kafka采用Scala编写

·RocketMQ采用Java语言编写

Broker端消息过滤

·Kafka不支持Broker端的消息过滤

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

o根据Message Tag来过滤，至关于子topic概念

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

王启军评：这个功能很是好，实用。

消息堆积能力

 

理论上Kafka要比RocketMQ的堆积能力更强，不过RocketMQ单机也能够支持亿级的消息堆积能力，咱们认为这个堆积能力已经彻底能够知足业务需求。

 

开源社区活跃度

·Kafka社区更新较慢

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

商业支持

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

·RocketMQ在阿里云上已经开放公测近半年，目前以云服务形式免费供你们商用，并向用户承诺99.99%的可靠性，同时完全解决了用户本身搭建MQ产品的运维复杂性问题

成熟度

·Kafka在日志领域比较成熟

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

 

王启军评：kafka的确是在日志领域应用比较普遍的，新版本逐步开始完善，可靠性方面有了很大提高，可是rocketmq一开始就是以电商为背景的，因此不少功能值得确定，从长期来看，若是公司有能力的话，应该以rocketmq为基础，在上面投入人力进行扩展研发。短时间看rocketmq有待完善，客户端不够全，只有java，文档偏少，配置不友好。两个mq都很是优秀，不管选择哪一个都很是不错，能够根据自身实力和业务场景灵活取舍。使用开源，若是要想不出错，研究源码很是必要。