RabbitMQ有什么优缺点？A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是， 要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了， 咋整？你这数据就
不一致了。
所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对 它带来的坏处做各种额外的技术方案和架构来规避掉，做好之后，你会发现，妈 呀，系统复杂度
提升了一个数量级，也许是复杂了 10 倍。但是关键时刻，用， 还是得用的。
这个首先你可以说下你们公司选用的是什么消息中间件，比如用的是 RabbitMQ，然后可以初步给一些你对不同MQ中间件技术的选型分析。
举个例子：比如说ActiveMQ是老牌的消息中间件，国内很多公司过去运用的还 是非常广泛的，功能很强大。
但是问题在于没法确认ActiveMQ可以支撑互联网公司的高并发、高负载以及高 吞吐的复杂场景，在国内互联网公司落地较少。而且使用较多的是一些传统企 业，用ActiveMQ做
异步调用和系统解耦。
然后你可以说说RabbitMQ，他的好处在于可以支撑高并发、高吞吐、性能很 高，同时有非常完善便捷的后台管理界面可以使用。
另外，他还支持集群化、高可用部署架构、消息高可靠支持，功能较为完善。
而且经过调研，国内各大互联网公司落地大规模RabbitMQ集群支撑自身业务的 case较多，国内各种中小型互联网公司使用RabbitMQ的实践也比较多。
除此之外，RabbitMQ的开源社区很活跃，较高频率的迭代版本，来修复发现的 bug以及进行各种优化，因此综合考虑过后，公司采取了RabbitMQ。
但是RabbitMQ也有一点缺陷，就是他自身是基于erlang语言开发的，所以导致 较为难以分析里面的源码，也较难进行深层次的源码定制和改造，毕竟需要较为 扎实的erlang语
言功底才可以。
然后可以聊聊RocketMQ，是阿里开源的，经过阿里的生产环境的超高并发、 高吞吐的考验，性能卓越，同时还支持分布式事务等特殊场景。
而且RocketMQ是基于Java语言开发的，适合深入阅读源码，有需要可以站在 源码层面解决线上生产问题，包括源码的二次开发和改造。
另外就是Kafka。Kafka提供的消息中间件的功能明显较少一些，相对上述几款 MQ中间件要少很多。
但是Kafka的优势在于专为超高吞吐量的实时日志采集、实时数据同步、实时数 据计算等场景来设计。
因此Kafka在大数据领域中配合实时计算技术（比如Spark Streaming、 Storm、Flink）使用的较多。但是在传统的MQ中间件使用场景中较少采用。
ActiveMQ
RabbitMQ
RocketMQ
Kafka
ZeroMQ
单机吞吐
量
比 RabbitM Q低
2.6w/s（
消息做持 久化）
11.6w/s
17.3w/s
29w/s
开发语言
Java
Erlang
Java
Scala/Java
C
主要维护
者
Apache
Mozilla/Spring
Alibaba
Apache
iMatix创
始人已去
世
成熟度
成熟
成熟
开源版本不够成熟
比较成熟
只有C、
PHP等版
本成熟
订阅形式
点对点 (p2p)、广 播（发布
订阅）
提供了4 种： direct,
topic,Headers 和 fanout。
fanout就 是广播模 式
基于 topic/me ssageTag 以及按照消
息类 型、属性 进行正则 匹配的发 布
订阅模 式
基于topic 以及按照 topic进行
正则匹配的发布订 阅模式
点对点
(P2P)
持久化
支持少量 堆积
支持少量 堆积
支持大量 堆积
支持大量 堆积
不支持
顺序消息
不支持
不支持
支持
支持
不支持
性能稳定
性
好
好
一般
较差
很好
集群方式
支持简单 集群模 式，比
如’主备’，对 高级集群 模式
支持 不好。
支持简单 集群，'复 制’模 式，
对高 级集群模 式支持不 好。
常用 多 对’Mast erSlave’ 模 式，开源
版本需手 动切换 Slave变成 Master
天然 的‘Lead erSlave’无 状态集
群，每台 服务器既 是Master
也是Slave
不支持
管理界面
一般
较好
一般
无
无
综上，各种对比之后，有如下建议：
一般的业务系统要引入 MQ，最早大家都用 ActiveMQ，但是现在确实大家用 的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是 算了吧，我个人不
推荐用这个了；
后来大家开始用 RabbitMQ，但是确实 erlang 语言阻止了大量的 Java 工程师 去深入研究和掌控它，对公司而言，几乎处于不可控的状态，但是确实人家是开 源的，比较稳定的
支持，活跃度也高；
不过现在确实越来越多的公司会去用 RocketMQ，确实很不错，毕竟是阿里出 品，但社区可能有突然黄掉的风险（目前 RocketMQ 已捐给 Apache，但 GitHub 上的活跃度其实
不算高）对自己公司技术实力有绝对自信的，推荐用 RocketMQ，否则回去老老实实用 RabbitMQ 吧，人家有活跃的开源社区，绝 对不会黄。
所以中小型公司，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是 不错的选择；大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选 择。
如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝 对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性 规范。