Kafka、RabbitMQ、RocketMQ消息中间件的对比

引言

分布式系统中,我们广泛运用消息中间件进行系统间的数据交换,便于异步解耦。现在开源的消息中间件有很多,目前对kafka、rabbitmq、rocketmq这三个消息中间件做下对比分析。

 

-	-	kafka	rocketmq	rabbitmq	数据来源	相关文章
定位	设计定位	系统间的数据流管道，实时数据处理。 例如：常规的消息系统、网站活性跟踪，监控数据，日志收集、处理等	非日志的可靠消息传输。 例如：订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等	可靠消息传输。和rocketmq类似。
基础对比	成熟度	日志领域成熟	成熟	成熟
	所属社区／公司	apache	alibaba开发，已加入到apache下	mozilla public license
	社区活跃度	高	中	高	来源于网络
	api完备性	高	高	高
	文档完备性	高	高	高	来源于网络
	开发语言	scala	java	erlang
	支持协议	一套自行设计的基于tcp的二进制协议	自己定义的一套 (社区提供jms--不成熟)	amqp
	客户端语言	c/c++、python、go、erlang、.net、ruby、node.js、php等	java	java、c、 c++、 python、 php、perl 等
	持久化方式	磁盘文件	磁盘文件	内存、文件
可用性、可靠性比较	部署方式	单机／集群	单机／集群	单机／集群
	集群管理	zookeeper	name server
	选主方式	从isr中自动选举一个leader	不支持自动选主。通过设定brokername、brokerid实现，brokername相同，brokerid=0时为maser，其他为slave	最早加入集群的broker
	可用性	非常高 分布式、主从	非常高 分布式、主从	高 主从，采用镜像模式实现，数据量大时可能产生性能瓶颈	rabbitmq集群部署 http://www.cnblogs.com/knowledgesea/p/6535766.html rabbitmq可用性、可靠性分析 http://blog.csdn.net/cadem/article/details/53422912?utm_source=itdadao&utm_medium=referral
	主从切换	自动切换 n个副本，允许n-1个失效；master失效以后自动从isr中选择一个主；	不支持自动切换 master失效以后不能向master发送信息，consumer大概30s（默认）可以感知此事件，此后从slave消费；如果master无法恢复，异步复制时可能出现部分信息丢失	自动切换 最早加入集群的slave会成为master；因为新加入的slave不同步master之前的数据，所以可能会出现部分数据丢失
	数据可靠性	很好 支持producer单条发送、同步刷盘、同步复制、异步。	很好 producer单条发送，broker端支持同步刷盘、异步刷盘，同步双写，异步复制。	好 producer支持同步／异步ack。支持队列数据持久化，镜像模式中支持主从同步	kafka也同步刷盘，但是效率较低 http://jm.taobao.org/2016/04/28/kafka-vs-rocktemq-4/
	消息写入性能	非常好 每条10个字节测试：百万条/s	很好 每条10个字节测试：单机单broker约7w/s，单机3个broker约12w/s	ram约为rocketmq的1/2， disk的性能约为ram性能的1/3	数据来源于网络 单条消息的数据量越小，性能对比时kafka表现越好	kafka vs rocktmq： https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines kafka vs rocktmq vs rabbitmq  http://www.cnblogs.com/felixzh/p/6198070.html http://ju.outofmemory.cn/entry/177937
	性能的稳定性	队列/分区多时性能不稳定，明显下降。 消息堆积时性能稳定	队列较多、消息堆积时性能稳定	消息堆积时，性能不稳定、明显下降
	单机支持的队列数	单机超过64个队列/分区，load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长	单机支持最高5万个队列，load不会发生明显变化	依赖于内存	数据来源于网络测评 kafka新能降低是因为topic增多时，顺序写变成了随机写	kafka vs rocketmq: topic数量对单机性能的影响 http://jm.taobao.org/2016/04/07/kafka-vs-rocketmq-topic-amout/?utm_source=tuicool&utm_medium=referral
	堆积能力	非常好 消息存储在log中，每个分区由一个或多个segment  log文件	非常好 所有消息存储在同一个commit log中	一般 生产者、消费者正常时，性能表现稳定；消费者不消费时，性能不稳定	http://www.cnblogs.com/purpleraintear/p/6033136.html
	复制备份	消息先写入leader的log，followers从leader中pull数据，pull到数据以后先ack leader，然后写入log中。 isr中维护与leader同步的列表，落后太多的follwer会被删除掉	同步双写 异步复制：slave启动线程从master中拉数据	普通模式下不复制； 镜像模式下：消息先到mster，然后写到slave上。加入集群之前的消息不会被复制到新的slave上。
	消息投递实时性	毫秒级 具体由consumer轮询间隔时间决定	毫秒级 支持pull、push两种模式，延时通常在毫秒级	毫秒级
功能对比	顺序消费	支持顺序消费 但是一台broker宕机后，就会产生消息乱序(来自网上，尚未找到原因）	支持顺序消费 在顺序消息场景下，消费失败时消费队列将会暂停	支持顺序消费
	定时消息	不支持	开源版本仅支持定时level	不支持
	事务消息	不支持	支持	不支持
	broker端消息过滤	不支持	支持 通过tag过滤，类似于子topic	不支持
	消息查询	不支持	支持 根据messageid查询 支持根据messagekey查询消息	不支持
	消费失败重试	不支持失败重试 offset存储在consumer中，无法保证。 0.8.2版本后支持将offset存储在zk中	支持失败重试 offset存储在broker中	支持失败重试
	消息重新消费	支持通过修改offset来重新消费	支持按照时间来重新消息
	发送端负载均衡	可*指定	可*指定	需要单独loadbalancer支持
	消费并行度	消费并行度和分区数一致	顺序消费：消费并行度和分区数一致 乱序消费：消费服务器的消费线程数之和	可一次抓取多条一起消费。 镜像模式下其实也是从master消费
	消费方式	consumer pull	consumer pull ／broker push	broker push
	批量发送	支持 默认producer缓存、压缩，然后批量发送	不支持	不支持
	消息清理	指定文件保存时间，过期删除	指定文件保存时间，过期删除	consumer ack以后，消息将被标记为删除 可用内存少于40%（默认），触发gc，gc时找到相邻的两个文件，合并right文件到left。
运维	系统维护	scala语言开发，维护成本高	java语言开发，维护成本低	erlang语言开发，维护成本高
	部署依赖	zookeeper	nameserver	erlang环境
	管理后台	官网不提供，第三方开源管理工具可供使用；不用重新开发	官方提供，rocketmq-console	官方提供rabbitmqadmin	kafka管理后台比较；http://top.jobbole.com/31084/
	管理后台功能	kafka web conslole brokers列表；kafka 集群中 topic列表，及对应的partition、logsize等信息；topic对应的consumer groups、offset、lag等信息； 生产和消费流量图、消息预览 kafkaoffsetmonitor： kafka集群状态；topic、consumer group列表；图形化展示topic和consumer之间的关系；图形化展示consumer的offset、lag等信息 kafka manager 管理几个不同的集群；监控集群的状态(topics, brokers, 副本分布, 分区分布)；产生分区分配(generate partition assignments)基于集群的当前状态；重新分配分区	cluster、topic、connection、nameserv、message、broker、offset、consumer	overview、connections、channels、exchanges、queues、admin
总结	优点	1、在高吞吐、低延迟、高可用、集群热扩展、集群容错上有非常好的表现； 2、producer端提供缓存、压缩功能，可节省性能，提高效率。 3、提供顺序消费能力 4、提供多种客户端语言 5、生态完善，在大数据处理方面有大量配套的设施。	1、在高吞吐、低延迟、高可用上有非常好的表现；消息堆积时，性能也很好。 2、api、系统设计都更加适在业务处理的场景。 3、支持多种消费方式。 4、支持broker消息过滤。 5、支持事务。 6、提供消息顺序消费能力；consumer可以水平扩展，消费能力很强。 7、集群规模在50台左右，单日处理消息上百亿；经历过大数据量的考验，比较稳定可靠。	1、在高吞吐量、高可用上较前两者有所不如。 2、支持多种客户端语言；支持amqp协议。 3、由于erlang语言的特性，性能也比较好; 使用ram模式时，性能很好。 4、管理界面较丰富，在互联网公司也有较大规模的应用;	数据来自网络
	缺点	1、消费集群数目受到分区数目的限制。 2、单机topic多时，性能会明显降低。 3、不支持事务	1、相比于kafka，使用者较少，生态不够完善。消息堆积、吞吐率上也有所不如。 2、不支持主从自动切换，master失效后，消费者需要一定的时间才能感知。 3、客户端只支持java	1、erlang 语言难度较大。集群不支持动态扩展。 2、不支持事务、消息吞吐能力有限 3、消息堆积时，性能会明显降低

 

摘自:https://blog.csdn.net/wuzhengfei1112/article/details/78069645