概述
Rabbit MQ的使用场景非常多，典型的场景主要分为下面几种：
- 削峰
- 基于
pub/sub模型的事件驱动 - 跨系统的异步通信
下面简要的梳理一下这几种场景。
秒杀订单之削峰
sec-kill-order独立集群的职责有三个：
- 接收所有瞬时涌入的秒杀请求，并以先进先出的方式将请求保存到队列里，将请求排队，起到削峰的作用；
- 提供拉取数据接口，给
秒杀业务处理层使用； - 提供用户秒杀订单查询状态的接口；
而秒杀业务处理层则用于监听后端接口的处理能力并从sec-kill-order里获取请求，并将请求分发到后端服务。
解耦之刷缓存
之前参与过一个电商应用，主要是输出销售商品信息的，由于访问量比较大，使用了Memcache作为中央缓存。后台的业务人员可以手动的改动商品信息，因此需要准实时的将改动的信息同步到缓存里。
当然我们直接在商品后台更新完商品数据后，同步操作操作memcache也是可以的，但是不推荐这么做，理由如下：
操作缓存的应用，最好是离缓存最近的应用，如上面的C端商品服务，像后台服务、定时任务等，最好不要直接操作C端缓存，需要做解耦操作，将刷缓存的逻辑收拢到同一个地方。
订单支付成功之发布订阅
如上图，当订单api收到支付成功的消息后，将订单状态扭转为已支付后，需要发布一条订单已成功支付的消息，有两个应用需要订阅这条消息，一个是pms营销系统，一个是大数据。pms需要订阅订单支付成功的消息的理由有好几个，例如：
- 用户下了一个拼团订单，当订单支付成功后，需要更新团的状态以及已参团人数；
- 用户的订单可能还用了优惠券，订单支付成功后，需要将用户的优惠券状态扭转为已使用；
而大数据侧则可以利用这条消息做一个实时的已支付订单dashboard。当然像WMS侧也是需要感知已支付订单的，用于扣减仓库的库存。