一、为什要使用MQ
-
（解耦）实现分布式系统之间的解耦调用
业务中有这样的一个场景：
有系统A（订单），系统B（短信），系统C（优惠卷），系统D（库存）
-
商品订单确认，后续需要给客户发送短信，需要扣除优惠卷，需要扣减库存，假设后续需要加一个其他的系统，就需要修改A系统中的代码，删除一个同理，这样非常的麻烦
在这个场景中，A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。A 系统要时时刻刻考虑 BCD 四个系统如果挂了该咋办？要不要重发，要不要把消息存起来？头发都白了啊！
如果可以把系统A所要发送的消息放在一个地方，谁需要谁去拿，比如图书管理员----书架----借阅者
如果使用 MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。
使用场景：
一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦
- （异步）实现异步调用
系统A产生一个消息，然后经过系统B，系统C，系统D，假设每个系统都需要100s，合起来就是400s…
这样非常的消耗时间，使用MQ
这样的话系统A创建消息100S—>发送到MQ100S 200S解决
- （削峰）削峰（队列），解决高并发问题
最好的例子就是：秒杀，秒杀活动，一般会因为流量过大，导致应用挂掉。
10000ops直接请求到数据库，数据库连接异常 GG
加入MQ进行流量削峰
使用 MQ，每秒 1k 个请求写入 MQ，BCD系统每秒钟最多处理 100 个请求，假设 MySQL 每秒钟最多处理 100 个。BCD系统从 MQ 中慢慢拉取请求，每秒钟就拉取 100 个请求，不要超过自己每秒能处理的最大请求数量就 ok，这样下来，哪怕是高峰期的时候，BCD系统也绝对不会挂掉。而 MQ 每秒钟 1k 个请求进来，就 100 个请求出去，结果就导致在中午高峰期（1 个小时），可能有几十万甚至几百万的请求积压在 MQ 中。
这个短暂的高峰期积压是 ok 的，因为高峰期过了之后，每秒钟就 50 个请求进 MQ，但是BCD系统依然会按照每秒 100 个请求的速度在处理。所以说，只要高峰期一过，BCD系统就会快速将积压的消息给解决掉。
中间件模式的的优点：
系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。
二、使用会有什么缺点？
-
系统可用性降低
系统引入的外部依赖越多，越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了，ABCD 四个系统还好好的，没啥问题，你偏加个 MQ 进来，万一 MQ 挂了咋整？MQ 一挂，整套系统崩溃，你不就完了
-
系统复杂度提高
硬生生加个 MQ 进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已
-
一致性问题
A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了