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, 即更多的消费线程数

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。