RocketMQ与kafka的区别

一、前言

淘宝内部的交易系统使用了淘宝自主研发的Notify消息中间件，使用MySQL作为消息存储媒介，支持水平扩容。为了进一步降低成本，阿里中间件团队认为Notify可进一步优化。

2011年初，Linkedin开源了kafka, 阿里中间件团队在对kafka做了充分的review之后，被kafka的无限消息堆积能力、高效的持久化速度深深吸引，但同时发现kafka主要定位于日志传输，对于使用在淘宝交易、订单、充值等场景下，还有若干特性不满足。因此，阿里中间件团队基于Java重新编写了RocketMQ，定位于不仅限于日志场景的可靠消息传输。

目前，RocketMQ在阿里集团被广泛应用于订单、充值、交易、流计算、消息推送、日志流式处理、binlog分发等场景。

二、RocketMQ与kafka的不同

1、数据可靠性

RocketMQ：支持异步实时刷盘、同步刷盘、同步复制、异步复制。
kafka：使用异步刷盘方式，异步复制/同步复制。

总结：
1、RocketMQ支持kafka所不具备的“同步刷盘”功能，在单机可靠性上比kafka更高，不会因为操作系统Crash而导致数据丢失。
2、kafka的同步replication理论上性能低于RocketMQ的replication，这是因为kafka的数据以partition为单位，这样一个kafka实例上可能多上百个partition。而一个RocketMQ实例上只有一个partition，RocketMQ可以充分利用IO组的commit机制，批量传输数据。同步replication与异步replication相比，同步replication性能上损耗约20%-30%。

一句话概括：RocketMQ新增了同步刷盘机制，保证了可靠性；一个RocketMQ实例只有一个partition, 在replication时性能更好。

2、性能对比

1、kafka单机写入TPS月在百万条/秒，消息大小为10个字节。
2、RocketMQ单机写入TPS单实例约7万条/秒，若单机部署3个broker，可以跑到最高12万条/秒，消息大小为10个字节。

总结：
kafka的单机TPS能跑到每秒上百万，是因为Producer端将多个小消息合并，批量发向broker。

那么RocketMQ为什么没有这样做呢？

• 发送消息的Producer通常是用Java语言，缓存过多消息，GC是个很严重的问题。（问题：难道kafka用scala不需要GC？）
• Producer发送消息到broker, 若消息发送出去后，未达到broker，就通知业务消息发送成功，若此时Broker宕机，则会导致消息丢失，从而导致业务出错。
• Producer通常为分布式系统，且每台机器都是多线程发送，通常来说线上单Producer产生的消息数量不会过万。
• 消息合并功能完全可由上层业务来做。

一句话概括：RocketMQ写入性能上不如kafka, 主要因为kafka主要应用于日志场景，而RocketMQ应用于业务场景，为了保证消息必达牺牲了性能，且基于线上真实场景没有在RocketMQ层做消息合并，推荐在业务层自己做。

3、单机支持的队列数

1、kafka单机若超过了64个partition/队列，CPU load会发生明显飙高，partition越多，CPU load越高，发消息的响应时间变长。
2、RocketMQ单机支持最高5万个队列，CPU load不会发生明显变化。

队列多有什么好处呢？
1、单机可以创建更多个topic, 因为每个topic都是有一组队列组成。
2、消费者的集群规模和队列数成正比，队列越多，消费类集群可以越大。

一句话概括：RocketMQ支持的队列数远高于kafka支持的partition数，这样RocketMQ可以支持更多的consumer集群。

4、消息投递的实时性

1、kafka采用短轮询的方式，实时性取决于轮询时间间隔，0.8以后版本支持长轮询。
2、RocketMQ使用长轮询，同Push实时性一致，消息投递的延迟通常在几毫秒内，

一句话：kafka与RocketMQ都支持长轮询，消息投递的延迟在几毫秒内。

5、消费失败重试

1、kafka不支持消费失败重试。
2、RocketMQ消费失败支持定时重试，每次重试间隔时间顺延。

总结：以充值类应用为例，若当前时刻调用运营商网管失败，可能运营商网关此时压力过大，稍后再调用就会成功。这里的重试指可靠的重试，即失败重试的消息不是因为consumer宕机而导致的消息丢失。

一句话概括：RocketMQ支持消费失败重试功能，主要用于第一次调用不成功，后面可调用成功的场景。而kafka不支持消费失败重试。

6、严格保证消息有序

1、kafka可保证同一个partition上的消息有序，但一旦broker宕机，就会产生消息乱序。
2、Rocket支持严格的消息顺序，一台broker宕机，发送消息会失败，但不会乱序。举例：MySQL的二进制日志分发需要保证严格的顺序。

一句话概括：kafka不保证消息有序，RocketMQ可保证严格的消息顺序，即使单台Broker宕机，仅会造成消息发送失败，但不会消息乱序。

7、定时消息

1、kafka不支持定时消息
2、开源版本的RocketMQ仅支持定时级别，定时级别用户可定制

8、分布式事务消息

1、kafka不支持分布式事务消息
2、RocketMQ支持分布式事务消息。

9、消息查询

1、kafka不支持消息查询
2、RocketMQ支持根据消息标识（发送消息时指定一个消息key, 任意字符串，如指定为订单编号）查询消息，也支持根据消息内容查询消息。

总结：消息查询功能对于定位消息丢失问题非常有用，例如某个订单处理失败，可用此功能查询是消息没收到，还是收到了但处理出错了。

一句话概括：RocketMQ支持按消息标识或消息内容查询消息，用于排查消息丢失问题；kafka不支持消息查询。

10、消息回溯

1、kafka可按照消息的offset来回溯消息
2、RocketMQ支持按照时间来回溯消息，精度到毫秒，例如从一天的几点几分几秒几毫秒来重新消费消息。

总结：RocketMQ按时间做回溯消息的典型应用场景为，consumer做订单分析，但是由于程序逻辑或依赖的系统发生故障等原因，导致今天处理
的消息全部无效，需要从昨天的零点重新处理。

11、消息并行度

1、kafka的消息并行度，依赖于topic里配置的partition数，如果partition数为10，那么最多10台机器来消费，每台机器只能开启一个线程；或者一台机器消费，最多开启10个线程。消费的并行度与partition个数一致。
2、RocketMQ并行消费分两种情况：
1）顺序消费方式的并行度与kafka一致。
2）乱序消费方式的并行度取决于consumer的线程数，如topic配置10个队列，10台机器消费，每台机器100个线程，那么并行度为1000。

一句话概括：kafka的消费并行度等于partition数；RocketMQ的消费并行度等于消费的线程数，不受队列数限制。

12、开发语言

1、kafka采用scala开发
2、RocketMQ采用Java开发

13、消息堆积能力

kafka比RocketMQ的消息堆积能力更强，不过RocketMQ单机也可支持亿级的消息积压能力，这个堆积能力也能够完全满足业务需求。

14、开源社区活跃度

1、kafka社区更新较慢
2、RocketMQ的Github社区有250人，公司用户登记了联系方式，QQ群超过1000人，
3、kafka原开发团队成立了新公司，暂时未看到相关产品。
4、RocketMQ已在阿里云商业化，目前以云服务形式供外部商用，并向用户承诺99.99%的可靠性，同时彻底解决了用户自己搭建MQ产品的运维复杂性问题。

15、应用领域成熟度

1、kafka在日志领域比较成熟
2、RocketMQ在阿里集团内部有大量的应用在使用，并顺利支持了多次天猫双十一的考验。

三、总结

kafka和RocketMQ的总体区别是，kafka设计初衷是用于日志传输，而RocketMQ的设计用于解决各类应用可靠的消息传输，阿里云官网承诺RocketMQ数据可靠性为10个9，服务可靠性为99.95%。

kafka相比RocketMQ的优势

1、单机吞吐量TPS可上百万，远高于RocketMQ的TPS7万每秒，适用于日志类消息。
2、kafka支持多语言的客户端

RocketMQ相比kafka的优势

**1、保证消息不丢（ 数据可靠性达10个9）
2、可严格保证消息有序
3、支持分布式事务消息
4、支持按时间做消息回溯（可精确到毫秒级）
5、支持按标识和内容查询消息，用于排查丢消息
6、支持消费失败重试
7、可支持更多的partition, 即更多的消费线程数