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