MQ的使用场景

• 异步化缓冲（最终一致性，柔性事务）

服务解耦

假设A系统发送数据到B、C、D三个系统，如果是选择接口调用发送

• 若E系统也要这个数据
• C系统现在不要了
• 现在A系统又要发送第二种数据了

A系统负责人头秃中。。。A系统还要时刻考虑B、C、D、E四个系统若挂了咋办？我要不要重发？我要不要把消息存起来？

你的业务是否有有类似场景呢？

一个系统或模块，调用了多个系统或模块，互相调用很复杂，维护繁琐。 但其实这个调用是不需要直接同步调用接口的，若用MQ，可以考虑在你的项目里，使用MQ将其异步化解耦。

甚至 redis 也可以

异步

削峰

每天3点到9点，A系统风平浪静，每秒并发请求数量就100。结果每次一到11点~3点，每秒并发请求数量突然会暴增到1w。但系统最大处理能力就只能是每秒处理1000个请求。

MQ的优缺点

系统可用性降低

系统引入的外部依赖越多，越容易挂掉，本来你就是A系统调用B、C、D三个系统的接口就好了，ABCD四个系统好好的，没啥问题

你加个MQ进来，万一MQ挂了咋整？MQ挂了，整套系统崩溃了，不就完了。

系统复杂性提高

硬生生加个MQ进来

• 你怎么保证消息没有重复消费？
• 怎么处理消息丢失的情况？
• 怎么保证消息传递的顺序性？

一致性问题：A系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是BCD三个系统那里，BD两个系统写库成功了，结果C系统写库失败了，咋整？你这数据就不一致了。

所以MQ实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，最好之后，你会发现，妈呀，系统复杂度提升了一个数量级。但关键时刻，用还是得用。