一、異步處理
秒殺系統需要解決如何利用有限的服務器資源，盡可能多地處理短時間內的海量請求。
處理一個秒殺請求包含步驟：
- 風險控制
- 庫存鎖定
- 生成訂單
- 短信通知
- 更新統計數據
能否決定秒殺成功，實際上只有風險控制和庫存鎖定這兩步，當服務端完成前面2個步驟，確定本次請求的秒殺結果后，就可以馬上給用戶返回響應，然后把請求的數據放入消息隊列中，由消息隊列異步地進行后續的操作。
這樣不僅響應速度更快，並且在秒殺期間，可以把大量的服務器資源用來處理秒殺請求。秒殺結束后再把資源用於處理后面的步驟，充分利用有限的服務器資源處理更多的秒殺請求。
總結：在這個場景中，消息隊列被用於實現服務的異步處理。這樣做可以更快地返回結果，減少等待，自然實現了步驟之間的並發，提升系統總體的性能。
二、流量控制
繼續以秒殺系統為例，一個設計健壯的程序有自我保護的能力，它應該可以在海量的請求下，還能在自身能力范圍內盡可能多地處理請求，拒絕處理不了的請求並且保證自身運行正常。使用消息隊列隔離網關和后端服務，以達到流量控制和保護后端服務的目的。
整個秒殺系統為：
- 網關在收到請求后，將請求放入請求消息隊列。
- 后端服務從請求消息隊列中獲取請求，完成后續秒殺處理過程，然后返回結果
秒殺開始后，短時間大量的秒殺請求到達網關時，不會直接沖擊到后端的秒殺服務，而是先堆積在消息隊列中，后端服務按照自己的最大處理能力，從消息隊列中消息請求進行處理。對於超時的請求直接處理為秒殺失敗，運維人員還可以隨時增加秒殺服務的實例數量進行水平擴展。
這樣做的優點是：能根據下游的處理能力自動調節流量，達到削峰填谷。缺點是：增加了系統調用鏈環節，導致總體的響應時延變長；上下游系統都要將同步改為異步消息，增加了系統的復雜度。
令牌桶流量控制：
令牌桶控制流量的原理是：單位時間內只發送固定數量的令牌到令牌桶中，規定服務在處理請求之前必須從令牌桶中拿出一個令牌，如果令牌桶中沒有令牌，則拒絕請求。這樣就保證單位時間內，能處理的請求不超過發放令牌的數據，起到了流量控制的作用。
令牌桶可以簡單地用一個有固定容量的消息隊列加一個”令牌發生器“來實現：令牌發生器按照預估的處理能力，勻速生產令牌並放入令牌隊列（如果隊列滿了則丟棄令牌），網關在收到請求時去令牌隊列消費一個令牌，獲取到令牌則繼續調用后端秒殺服務，如果獲取不到令牌則直接返回秒殺失敗。
三、服務解耦
當一個新訂單創建時：
- 支付系統需要發起支付流程
- 風控系統需要審核訂單的合法性
- 客服系統需要給用戶發送短信告知用戶
- 經營分析系統需要更新統計數據
- ........
這些訂單下游的系統都需要實時獲得訂單數據。隨着下游系統不斷的增加和變化，並且每個子系統可能只需要訂單數據的一個子集，而訂單服務需要不斷跟着下游系統進行修改，這造成了系統耦合過於緊密的問題。
引入消息隊列，訂單服務在訂單變化時發送一條消息到消息隊列的一個主題Order中，所有下游系統都訂閱主題Order，這樣每個下游系統都可以獲得實時的訂單數據。無論增加、減少下游系統或下游系統需求如何變化，訂單服務都無需做任何更改，實現了訂單服務與下游服務的解耦。
四、其他場景
- 作為發布/訂閱系統實現一個微服務級系統的觀察者模式
- 連接流計算任務和數據
- 用於將消息廣播給大量接受者
消息隊列自身的一些問題和局限性：
- 引入消息隊列帶來的延遲問題
- 增加了系統的復雜性
- 可能產生數據不一致的問題。