消息队列-优缺点

优点：

(1)解耦

传统模式的缺点：系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！（若多个应用使用A系统的东西，但是根据业务的需求，可能进行更改，那么就需要频繁的修改代码）

中间件模式：将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。（A只需要把东西放在消息队列中，谁要用不关乎它的事情）

(2)异步

传统模式缺点：一些非必要的业务逻辑以同步的方式运行，太耗时间。（一个业务涉及了多个操作，有些是非必要的业务。那么若直接同步进行，耗时太长。例如：下单，要付款，去除优惠卷，付款完要计算积分，计算完积分要发短信，那么用户下完单只需要知道是否完成了付款，关于优惠劵与积分等业务逻辑没必要同步进行，耗时。当链路过长就需要用异步来解决）

中间件模式：将消息写入消息队列，非必要的业务逻辑以异步的方式运行，以加快响应速度

(3)削峰

传统模式缺点：并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常。（秒杀这种活动的时候，所有的请求一起来队缓存或者数据库的时候，当它们承受不了压力的时候，就可能会崩盘。）

中间件模式：系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。

缺点

（1）系统可用性降低

​ 系统引入的外部依赖越多，越容易挂掉，当加了消息中间件MQ，那么如果MQ挂了，整套系统关于消费者无法进行消费，会导致系统不可用。

（2）系统复杂性提高

​ 硬生生加个 MQ 进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？所以需要对MQ进行维护，导致了系统的复杂性提高了。

（3）一致性问题

​ ABCD是一整个业务，例如A是付钱，B是扣除优惠券，C是增加积分，D是发送成功短信，那么，A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，这数据就不一致了。