核心问题
你知不知道你们系统里为什么要用消息队列这个东西？
你既然用了消息队列这个东西，你知不知道用了有什么好处 & 坏处？
既然你用了 MQ，可能是某一种 MQ，那么你当时做没做过调研？
消息队列的好处
解耦
以前是我挨个通知大家吃饭（点对点调用），现在我在微信群里发消息，谁饿谁来看（MQ 发布订阅）。
各模块不再直接调用，降低耦合度，提高系统灵活性。
异步
同步是“亲自送到每家”；异步是“打包交给快递公司处理”，我只管发，快不快你们自己去搞，客户早就满意回家了。
提升响应速度，改善用户体验。
削峰
高峰期像大雨，水流太猛容易漫堤；MQ 就是水库，把水暂时蓄起来，慢慢放出去，保证下游河道不被冲垮。
平滑流量，保障系统稳定。
消息队列的缺点
系统可用性降低
系统越复杂，越容易崩溃，MQ 成为系统中新的单点故障风险。
系统复杂度提高
需要额外搭建、维护 MQ 服务，增加整体架构复杂度。
一致性挑战
异步消息导致数据一致性难以保证，需要设计额外机制确保消息不丢失、不重复、幂等处理(幂等指的是多次执行同一操作，结果和执行一次的结果是一样的)。
常见消息队列对比表格
特性
ActiveMQ
RabbitMQ
RocketMQ
Kafka
单机吞吐量
万级，低于 RocketMQ、Kafka
同 ActiveMQ
10 万级，支持高吞吐
10 万级，高吞吐，适合大数据实时计算和日志采集
Topic 数量对吞吐量影响
无明显数据
无明显数据
支持几百到几千个 topic，吞吐量仅小幅下降
topic 数量从几十到几百时吞吐量大幅下降，需要更多资源支持
时效性
毫秒级
微秒级，延迟最低
毫秒级
毫秒级以内
可用性
高，可主从架构实现高可用
同 ActiveMQ
非常高，分布式架构
非常高，分布式，数据多副本，少数节点宕机不影响整体可用
消息可靠性
低概率丢失
基本不丢失
参数优化后可做到零丢失
同 RocketMQ
功能支持
MQ 功能完备
基于 Erlang，性能优异，延迟低
功能完善，分布式，扩展性强
功能相对简单，主要支持大数据实时计算和日志采集
社区活跃度
较低
较高
中等，Apache 维护，社区活跃度一般
高，尤其在大数据生态中广泛应用
技术门槛
低
Erlang 语言限制，Java 团队掌控难度较大
Java 生态，技术门槛中等
Java/Scala 生态，门槛适中
适用场景
一般业务，老系统
中小型业务系统
大型分布式系统，高吞吐量场景
大数据实时处理、日志采集及流式计算
选型建议
场景类型
推荐 MQ
理由
中小型公司
RabbitMQ
稳定，社区活跃，性能良好
大型公司
RocketMQ
功能全面，扩展性强，适合高吞吐量场景
大数据相关场景
Kafka
优秀的吞吐与扩展能力，适合流数据处理
老旧系统
不推荐 ActiveMQ
社区不活跃，性能不足，技术更新滞后