简介
本文介绍几种MQ（消息队列）的区别，包括：RabbitMQ，RocketMQ，Kafka。
本内容也是Java后端面试中常见的问题。
性能对比
| 项 | RabbitMQ | RocketMQ | kafka |
| 吞吐量 | 万级（5.95w/s） 为保证消息可靠性在吞吐量上做了取舍。 | 10万级（11.6w/s） | 10万级（17.3w/s） |
| 时效性 | 微秒级。 RabbitMQ的一大特点，延迟最低。 | 毫秒级。 | 毫秒级。 |
| 可用性 | 高。 基于主从架构实现高可用性 | 非常高。分布式架构 | 非常高。 kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 |
| 消息可靠性 | 优化配置后，可做到0丢失 | 优化配置后，可做到0丢失 | 优化配置后，可做到0丢失 |
| 性能的稳定性 | 消息堆积时，性能明显下降。 | 队列较多、消息堆积时性能稳定，不下降。 | Topic多时，分区也多，性能明显下降。 消息堆积时性能稳定 |
功能对比
| 项 | RabbitMQ | RocketMQ | Kafka |
| 使用场景 | 适合对可靠性和实时性要求高，对速度要求不高的场景。 适合中小项目。 | 适合对性能、可靠性要求很高的场景。 RocketMQ已经承受住了阿里双11多次考验。 | 适合日志采集，数据采集。 Kafka追求高吞吐量、高速度与持久化。主要用于处理流式数据、大数据量。 |
| 延迟消息 | 支持 | 支持。 但时间不能自己指定，只能选。 5.0及之后版本支持指定时间。 | 不支持。但可以手写代码来间接支持。 |
| 主从切换 | 自动切换。 最早加入集群的slave会成为master；因为新加入的slave不同步master之前的数据，所以可能会出现部分数据丢失 | 自动切换。 master失效后不能向master发送信息，consumer大概30s（默认）可以感知此事件，此后从slave消费；若master无法恢复，异步复制时可能出现部分信息丢失。 5.0后提高了故障切换的速度和可靠性，缩短了切换时间。 | 自动切换。 N个副本，允许N-1个失效；master失效以后自动从isr中选择一个主。 |
| 事务消息 | 支持 | 支持 | 不支持 |
| 顺序消费 | 支持顺序消费。 | 支持。 在顺序消息场景下，消费失败时消费队列将会暂停 | 支持。 但是一台Broker宕机后，就会产生消息乱序 |
| 消费失败重试 | 支持失败重试 | 支持失败重试。 offset存储在broker中 | 不支持失败重试。 offset存储在consumer中，无法保证。 0.8.2版本后支持将offset存储在zk中。 |
| 消息重新消费 | 支持按照时间来重新消息 | 支持通过修改offset来重新消费 | |
| Broker端消息过滤 | 不支持 | 支持 通过tag过滤，类似于子topic | 不支持 |
| 消费并行度 | 可一次抓取多条一起消费。 镜像模式下其实也是从master消费 | 顺序消费：消费并行度和分区数一致 乱序消费：消费服务器的消费线程数之和 | 消费并行度和分区数一致 |
| 消费方式 | broker push | consumer pull 或 broker push | consumer pull |
| 批量发送 | 不支持 | 不支持 | 支持 默认producer缓存、压缩，然后批量发送 |
| 消息清理 | 支持。 | 支持。 | 支持。 |
优缺点
| 项 | RabbitMQ | RocketMQ | kafka |
| 优点 | 1、消息延迟最低。 2、管理界面较丰富 | 1、高吞吐、低延迟、高可用表现很好；消息堆积时，性能也很好。 2、支持多种消费方式、broker消息过滤、消息顺序消费。 3、支持事务 | 1、这些方面表现很好：高吞吐、低延迟、高可用、集群热扩展、集群容错，消息堆积时，性能也很好。 2、producer端提供缓存、压缩功能，可节省性能，提高效率。 3、提供顺序消费能力 4、生态完善，在大数据处理方面有大量配套的设施。 |
| 缺点 | 1、在吞吐量、高可用略差。 2. erlang 语言难度较大。基本只能依赖于开源社区的快速维护和修复bug，不利于做二次开发和维护 3、不支持事务。 4、消息吞吐能力较差，消息堆积时，性能会明显降低。 | 1、吞吐量不如于kafka。 2、不支持主从自动切换，master失效后，消费者需要一定的时间才能感知。 3、客户端只支持Java 4、生态不如RabbitMQ和kafka。 | 1、消费集群数目受到分区数目的限制。 2、单机topic多时，性能明显降低。单机超过64个队列/分区，Load明显升高，且队列越多，发送消息响应时间变长 3、不支持事务 4、支持消息顺序，但一台代理宕机后，会产生消息乱序； 5、不支持延迟消息 |
可用性对比
| 项 | RabbitMQ | RocketMQ | kafka |
| 部署方式 | 单机／集群 | 单机／集群 | 单机／集群 |
| 集群管理 | name server | zookeeper | |
| 选主方式 | 最早加入集群的broker | 不支持自动选主。通过设定brokername、brokerId实现，brokername相同，brokerid=0时为maser，其他为slave | 从ISR中自动选举一个leader |
| 可用性 | 高 主从，采用镜像模式实现，数据量大时可能产生性能瓶颈 | 非常高 分布式、主从 | 非常高 分布式、主从 |
| 主从切换 | 自动切换。 最早加入集群的slave会成为master；因为新加入的slave不同步master之前的数据，所以可能会出现部分数据丢失 | 4.5之前不支持自动切换； 4.5及之后支持自动切换。 master失效后，应用无法向master发送信息，consumer大概30s（默认）可以感知此事件，此后从slave消费；若master无法恢复，异步复制时可能出现部分信息丢失。 | 自动切换。 N个副本，允许N-1个失效；master失效以后自动从isr中选择一个主； |
| 数据可靠性 | 好。 producer支持同步／异步ack。支持队列数据持久化，镜像模式中支持主从同步 | 很好。 producer单条发送，broker端支持同步刷盘、异步刷盘，同步双写，异步复制。 | 很好。 支持producer单条发送、同步刷盘、同步复制、异步。 |
| 消息写入性能 | 一般。 约为RocketMQ的1/2， | 很好。 每条10个字节测试：单机单broker约7w/s，单机3个broker约12w/s | 非常好。 每条10个字节测试：百万条/s |
| 性能的稳定性 | 消息堆积时，性能不稳定、明显下降 | 队列较多、消息堆积时性能稳定 | 队列/分区多时性能不稳定，明显下降。 消息堆积时性能稳定 |
| 单机支持的队列数 | 依赖于内存 | 单机支持最高5万个队列，Load不会发生明显变化 | 单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长 |
| 堆积能力 | 一般。 生产者、消费者正常时，性能表现稳定；消费者不消费时，性能不稳定 | 非常好 所有消息存储在同一个commit log中 | 非常好 消息存储在log中，每个分区由一个或多个segment log文件 |
| 复制备份 | 普通模式下不复制； 镜像模式下：消息先到master，然后写到slave上。加入集群之前的消息不会被复制到新的slave上。 | 同步双写 异步复制：slave启动线程从master中拉数据 | 消息先写入leader的log，followers从leader中pull数据，pull到数据以后先ack leader，然后写入log中。 ISR中维护与leader同步的列表，落后太多的follwer会被删除掉 |
| 消息投递实时性 | 毫秒级 | 毫秒级 支持pull、push两种模式，延时通常在毫秒级 | 毫秒级 具体由consumer轮询间隔时间决定 |
运维对比
| 项 | RabbitMQ | RocketMQ | kafka |
| 系统维护 | Erlang语言开发，维护成本高 | java语言开发，维护成本低 | Scala语言开发，维护成本高 |
| 部署依赖 | Erlang环境 | nameserver | zookeeper |
| 管理后台 | 官方提供rabbitmqadmin | 官方提供，rocketmq-console | 官网不提供，第三方开源管理工具可供使用；不用重新开发 |
| 管理后台功能 | overview、connections、channels、exchanges、queues、admin | Cluster、Topic、Connection、NameServ、Message、Broker、Offset、Consumer | 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)基于集群的当前状态；重新分配分区 |
其他对比
| 项 | RabbitMQ | RocketMQ | kafka |
| 设计定位 | 可靠消息传输。和RocketMQ类似。 | 非日志的可靠消息传输。 例如：订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等 | 系统间的数据流管道，实时数据处理。 例如：常规的消息系统、网站活性跟踪，监控数据，日志收集、处理等 |
| 成熟度 | 成熟 | 成熟 | 日志领域成熟 |
| 所属社区／公司 | Mozilla Public License | Alibaba开发，已加入到Apache下 | Apache |
| 社区活跃度 | 高 | 高 | 高 |
| API完备性 | 高 | 高 | 高 |
| 文档完备性 | 高 | 高 | 高 |
| 开发语言 | Erlang | Java | Scala |
| 支持协议 | AMQP，同时支持MQTT、STOMP等协议。 | 自己定义的JMS协议。 | 一套自行设计的基于TCP的二进制协议。 |
| 客户端语言 | Java、C、 C++、 Python、 PHP、Perl 等 | Java | C/C++、Python、Go、Erlang、.NET、Ruby、Node.js、PHP等 |
| 持久化方式 | 内存、文件 | 磁盘文件 | 磁盘文件 |
请先 ！