简介
本文介绍几种MQ（消息队列）的区别，包括：RabbitMQ，RocketMQ，Kafka。
本内容也是Java后端面试中常见的问题。
性能对比
| 项 | RabbitMQ | RocketMQ | kafka |
| 吞吐量 | 万级（5.95w/s） | 10万级（11.6w/s） | 10万级（17.3w/s） |
| 时效性 | 微秒级。 | 毫秒级。 | 毫秒级。 |
| 可用性 | 高。 （主从架构） | 非常高。（主从架构) | 非常高。（主从架构） |
| 消息可靠性 | 优化配置后，可做到0丢失 | 优化配置后，可做到0丢失 | 优化配置后，可做到0丢失 |
| 性能的稳定性 | 消息堆积时：性能下降。 | 队列较多时：性能稳定。 消息堆积时：性能稳定。 | Topic多时分区也多，性能下降。 消息堆积时：性能稳定。 |
功能对比
| 项 | RabbitMQ | RocketMQ | Kafka |
| 使用场景 | 吞吐量中等的应用类业务。 | 吞吐量大的应用类业务。 | 吞吐量大的场景。 比如：日志、大数据量。 |
| 延迟消息 | 支持 | 支持。 5.0之前不能自己指定(只能选) 5.0及之后版本支持指定时间。 | 不支持。 只能手写代码间接支持。 |
| 主从切换 | 自动切换。 | 自动切换。 | 自动切换。 |
| 事务消息 | 支持 | 支持 | 不支持 |
| 顺序消费 | 支持。 | 支持。 在顺序消息场景下，消费失败时消费队列将会暂停 | 支持。 但是一台Broker宕机后，会产生消息乱序 |
| 消费失败重试 | 支持 | 支持。 offset存储在broker中 | 支持。 |
| 消息重新消费 | 支持按照时间来重新消息。 | 支持通过修改offset来重新消费。 | |
| Broker端消息过滤 | 不支持 | 支持 通过tag过滤，类似于子topic | 不支持 |
| 消费并行度 | 可一次抓取多条一起消费。 镜像模式下也是从master消费。 | 顺序消费：消费并行度和分区数一致 乱序消费：消费服务器的消费线程数之和。 | 消费并行数和分区数一致。 |
| 消费方式 | 默认是推。（支持推和拉） | 默认是拉。（支持推和拉） | 默认是拉。（支持推和拉） |
| 批量发送 | 不支持 | 不支持 | 支持 默认生产者缓存、压缩，再批量发送 |
| 消息清理 | 支持。 | 支持。 | 支持。 |
优缺点
| 项 | RabbitMQ | RocketMQ | kafka |
| 优点 | 1、消息延迟最低。 | 1、性能强：吞吐量大，消息堆积或队列很多时性能稳定。单机最高支持5万个队列，复杂不会明显变化。 2、功能强大：多种消费方式、broker消息过滤、消息顺序消费、事务。 | 1、性能强大：吞吐量最大，消息堆积时性能也很好。 |
| 缺点 | 1、吞吐量略差。 2、消息堆积时，性能会明显降低。 3、不支持事务。 | 1、吞吐量低于kafka。（注意：业务系统用足够，阿里都在用。只是不适合日志等大数据场景） | 1、消费集群数目要小于分区数目（只增加消费者无法提高消费速度）。 2、topic多时，性能明显降低。单机超过64个队列(分区)，负载明显升高，且分区越多，发送消息响应时间变长。 3、支持消息顺序，但一台代理宕机后，会产生消息乱序； 4、功能少：不支持事务 、延迟消息 |
运维对比
| 项 | RabbitMQ | RocketMQ | kafka |
| 系统维护 | Erlang语言开发，不利于二开。 | Java语言开发，利于二开。 | Scala语言开发，不利于二开。 |
| 部署依赖 | Erlang环境 | Java环境 | Kafka2.8之前：依赖Zookeeper Kafka2.8及之后：无依赖 |
| 管理后台 | 官方提供rabbitmqadmin | 官方提供，rocketmq-console | 官网不提供，有第三方开源管理工具（Kafka Web Conslole、Kafka Manager） |
请先 ！