消息中间件选型

序：

本文介绍几种MQ（消息队列）的区别，包括：RabbitMQ，RocketMQ，Kafka。

本内容也是Java后端面试中常见的问题。

性能

选型	RabbitMQ	RocketMQ	kafka
吞吐量	万级（5.95w/s） 为保证消息可靠性在吞吐量上做了取舍。	10万级（11w/s）	10万级（17w/s）
时效性	微秒级。 RabbitMQ的一大特点，延迟最低。	毫秒级。	毫秒级。
可用性	高。 基于主从架构实现高可用性	非常高。分布式架构	非常高。 kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性	优化配置后，可做到0丢失	优化配置后，可做到0丢失	优化配置后，可做到0丢失
性能的稳定性	消息堆积时，性能不稳定、明显下降	队列较多、消息堆积时性能稳定	队列/分区多时性能不稳定，明显下降。 消息堆积时性能稳定

部署

选型	RabbitMQ	RocketMQ	kafka
系统维护	Erlang语言开发，维护成本高	java语言开发，维护成本低	Scala语言开发，维护成本高
部署依赖	Erlang环境	nameserver	zookeeper
管理后台	官方提供rabbitmqadmin	官方提供，rocketmq-console	官网不提供，第三方开源管理工具可供使用；不用重新开发

功能

选型	RabbitMQ	RocketMQ	Kafka
使用场景	Rabbitmq适合对可靠性和实时性要求高，对速度要求不高的场景。适合小公司。	适合对可靠性要求很高的场景。适合金融互联网（特别是电商的大量交易涌入，后端无法及时处理的情况）。    在阿里双11已经经历了多次考验。	Kafka主追求高吞吐量、高速度与持久化。主要用于处理活跃的流式数据，大数据量的数据处理上。适合日志采集，数据采集。
延迟消息	支持	支持。 但时间不能自己指定，只能选。最新版本支持指定时间。	不支持。但可以手写代码来间接支持。
主从切换	自动切换。 最早加入集群的slave会成为master；因为新加入的slave不同步master之前的数据，所以可能会出现部分数据丢失	不支持自动切换。 master失效以后不能向master发送信息，consumer大概30s（默认）可以感知此事件，此后从slave消费；如果master无法恢复，异步复制时可能出现部分信息丢失	自动切换。 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、稳定可靠，数据不会丢失。 3、支持多种消费方式、broker消息过滤、消息顺序消费、consumer可水平扩展，消费能力很强。 4、支持事务	1、这些方面表现很好：高吞吐、低延迟、高可用、集群热扩展、集群容错 2、producer端提供缓存、压缩功能，可节省性能，提高效率。 3、提供顺序消费能力 4、生态完善，在大数据处理方面有大量配套的设施。

缺点

选型	RabbitMQ	RocketMQ	kafka
缺点	1、在吞吐量、高可用略差。 2. erlang 语言难度较大。基本只能依赖于开源社区的快速维护和修复bug，不利于做二次开发和维护 3、不支持事务。 4、消息吞吐能力较差，消息堆积时，性能会明显降低。	1、吞吐量不如于kafka。 2、不支持主从自动切换，master失效后，消费者需要一定的时间才能感知。 3、客户端只支持Java 4、生态的支持度不如RabbitMQ和kafka。	1、消费集群数目受到分区数目的限制。 2、单机topic多时，性能会明显降低。单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长 3、不支持事务 4、支持消息顺序，但是一台代理宕机后，就会产生消息乱序； 5、消费失败不支持重试

总结

性能优化就是数据库的优化，但是数据库因为历史原因，横向扩展是一件非常复杂的工程，所有我们一般会尽量把流量都挡在数据库之前。

消息中间件作为提高系统性能首先考虑，消息队列，就是指保存消息的一个容器。阻隔直达数据库的流量，缓存组件和消息组件是两大杀器。