1.为什么使用消息队列?

核心问题

1. 你知不知道你们系统里为什么要用消息队列这个东西？
2. 你既然用了消息队列这个东西，你知不知道用了有什么好处 & 坏处？
3. 既然你用了 MQ，可能是某一种 MQ，那么你当时做没做过调研？

---

消息队列的好处

1. 解耦
   以前是我挨个通知大家吃饭（点对点调用），现在我在微信群里发消息，谁饿谁来看（MQ 发布订阅）。
   各模块不再直接调用，降低耦合度，提高系统灵活性。

2. 异步
   同步是“亲自送到每家”；异步是“打包交给快递公司处理”，我只管发，快不快你们自己去搞，客户早就满意回家了。
   提升响应速度，改善用户体验。

3. 削峰
   高峰期像大雨，水流太猛容易漫堤；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	社区不活跃，性能不足，技术更新滞后