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
总结	优势	一、在高吞吐、低延迟、高可用、集群热扩展、集群容错上有很是好的表现； 二、producer端提供缓存、压缩功能，可节省性能，提升效率。 三、提供顺序消费能力 四、提供多种客户端语言 五、生态完善，在大数据处理方面有大量配套的设施。	一、在高吞吐、低延迟、高可用上有很是好的表现；消息堆积时，性能也很好。 二、api、系统设计都更加适在业务处理的场景。 三、支持多种消费方式。 四、支持broker消息过滤。 五、支持事务。 六、提供消息顺序消费能力；consumer能够水平扩展，消费能力很强。 七、集群规模在50台左右，单日处理消息上百亿；经历过大数据量的考验，比较稳定可靠。	一、在高吞吐量、高可用上较前二者有所不如。 二、支持多种客户端语言；支持amqp协议。 三、因为erlang语言的特性，性能也比较好; 使用RAM模式时，性能很好。 四、管理界面较丰富，在互联网公司也有较大规模的应用;	数据来自网络
	缺点	一、消费集群数目受到分区数目的限制。 二、单机topic多时，性能会明显下降。 三、不支持事务	一、相比于kafka，使用者较少，生态不够完善。消息堆积、吞吐率上也有所不如。 二、不支持主从自动切换，master失效后，消费者须要必定的时间才能感知。 三、客户端只支持Java	一、erlang 语言难度较大。集群不支持动态扩展。 二、不支持事务、消息吞吐能力有限 三、消息堆积时，性能会明显下降

 

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