消息队列的使用场景有哪些？

## 消息队列的使用场景 1. **异步通信**：有些业务不需要立即处理消息。消息队列提供了异步处理机制，允许用户将消息放入队列，而不必立即处理它们。可以在需要时再处理这些消息。 2. **解耦**：降低工程间的强依赖程度，适用于异构系统适配。消息系统在处理过程中插入一个隐含的、基于数据的接口层，两边的处理过程都需实现这一接口。当应用发生变化时，可以独立扩展或修改两边的处理过程，只需确保它们遵守同样的接口约束。 3. **冗余**：处理数据的过程可能会失败，除非数据被持久化，否则将丢失。消息队列将数据持久化，直到它们被完全处理，规避数据丢失风险。采用“插入-获取-删除”范式，在删除消息前，需要处理系统明确指出消息已被处理完毕。 4. **扩展性**：消息队列解耦了处理过程，增加消息入队和处理频率很容易，只需增加处理过程即可，不需要改变代码或调整参数，便于分布式扩容。 5. **过载保护**：在访问量剧增时，应用需继续发挥作用，但突发流量无法预知。为了应对突发峰值访问，投入资源待命无疑是浪费。使用消息队列能使关键组件顶住突发访问压力，不会因超负荷请求而崩溃。 6. **可恢复性**：系统部分组件失效时，不会影响整个系统。消息队列降低了进程间耦合度，即使处理消息的进程挂掉，队列中的消息仍可在系统恢复后被处理。 7. **顺序保证**：在大多数使用场景下，数据处理顺序很重要。大部分消息队列是有序的，能保证数据按特定顺序处理。 8. **缓冲**：系统中有需要不同处理时间的元素。消息队列通过缓冲层帮助任务高效执行，控制和优化数据流经过系统的速度，调节系统响应时间。 9. **数据流处理**：分布式系统产生的海量数据流（如业务日志、监控数据、用户行为等），通过消息队列进行实时或批量采集汇总，然后进行大数据分析是当前互联网的必备技术。 ## 消息队列的缺点 1. **系统可用性降低**：系统引入的外部依赖越多，越容易出问题。如果 MQ 挂了，整套系统可能崩溃。因此，需要保证消息队列的高可用。 2. **系统复杂度提高**：引入 MQ 后，需要解决消息重复消费、消息丢失、消息传递顺序性等问题，增加了系统的复杂性。 3. **一致性问题**：如 A 系统处理完返回成功，但 BCD 系统中 BD 两个系统写库成功，C 系统写库失败，数据就会不一致。