概述
Rabbit MQ的使用場景非常多，典型的場景主要分爲下面幾種：
- 削峯
- 基於
pub/sub模型的事件驅動 - 跨系統的異步通信
下面簡要的梳理一下這幾種場景。
秒殺訂單之削峯
sec-kill-order獨立集羣的職責有三個：
- 接收所有瞬時涌入的秒殺請求，並以先進先出的方式將請求保存到隊列裏，將請求排隊，起到削峯的作用；
- 提供拉取數據接口，給
秒殺業務處理層使用； - 提供用戶秒殺訂單查詢狀態的接口；
而秒殺業務處理層則用於監聽後端接口的處理能力並從sec-kill-order裏獲取請求，並將請求分發到後端服務。
解耦之刷緩存
之前參與過一個電商應用，主要是輸出銷售商品信息的，由於訪問量比較大，使用了Memcache作爲中央緩存。後臺的業務人員可以手動的改動商品信息，因此需要準實時的將改動的信息同步到緩存裏。
當然我們直接在商品後臺更新完商品數據後，同步操作操作memcache也是可以的，但是不推薦這麼做，理由如下：
操作緩存的應用，最好是離緩存最近的應用，如上面的C端商品服務，像後臺服務、定時任務等，最好不要直接操作C端緩存，需要做解耦操作，將刷緩存的邏輯收攏到同一個地方。
訂單支付成功之發佈訂閱
如上圖，當訂單api收到支付成功的消息後，將訂單狀態扭轉爲已支付後，需要發佈一條訂單已成功支付的消息，有兩個應用需要訂閱這條消息，一個是pms營銷系統，一個是大數據。pms需要訂閱訂單支付成功的消息的理由有好幾個，例如：
- 用戶下了一個拼團訂單，當訂單支付成功後，需要更新團的狀態以及已參團人數；
- 用戶的訂單可能還用了優惠券，訂單支付成功後，需要將用戶的優惠券狀態扭轉爲已使用；
而大數據側則可以利用這條消息做一個實時的已支付訂單dashboard。當然像WMS側也是需要感知已支付訂單的，用於扣減倉庫的庫存。