众所周知，在项目中引入中间件会增加项目复杂度和维护成本，那为什么还需要引入RabbitMQ？这里我们就分析一下MQ的使用场景: 1) 服务解耦；2) 异步处理; 3) 流量削峰; 4) 消息广播。
服务解耦
通常情况下，分布式项目中服务之间的通讯一般会选择使用RPC或者Restful接口，这势必会使得服务之间存在强依赖关系，为雪崩效应埋下伏笔。使用MQ作为消息缓冲即可很好解除这种强依赖关系，让上下游服务很清爽地解耦开来，解除雪崩风险。
虽然使用RabbitMQ将服务A和服务B变成弱关联，解除雪崩风险，但是假如下游服务一直不消费或者消费速度缓慢，便会出现背压现象，这需要设计相应的策略应对。
异步处理
在整个服务调用链中，最终响应速度与中间服务处理速度正相关。如果中间某个服务处理比较耗时，并且属于非核心流程，这种情况即可将其剥离为异步处理。如支付结束之后，短信通知用户的场景，由于通知操作一般比较耗时，可将其拆分为支付完成之后，推送通知消息到MQ，由MQ触发通知用户的操作，从而实现通知操作异步处理，以增强核心业务的处理性能。
流量削峰
在秒杀或者促销活动中，通常会在一个时间段流量到达一个高点，远超过应用的处理极限，针对这种情况，当然也可以引入MQ来削峰。处理流程为：上游服务将消息推送到MQ，下游服务按照自己的处理节奏以拉的形式从MQ中消费消息，从而保护底层数据库。
不管是秒杀还是促销的设计，我们的出发点都是保护底层数据库不会因为突发的大流量崩溃。可为消息队列设置请求阈值，超过则抛弃或者跳转到指定路径。
消息广播
在支付通知场景中，如支付完成之后，需要将支付明细短信通知到用户，并且需要将其作为日志备份。对于通知服务和日志备份服务来讲，都需要订阅支付明细信息。这种情况也可以使用MQ来解决。
这种情况中，只要订阅了同一个MQ主题的服务都可以接受到MQ推送的消息(消息将以循环round-robin的方式发送给消费者)，每条消息只会分发给一个订阅的消费者。
