摘要：消息隊列中間件是分布式系統中重要的組件，主要解決應用耦合，異步消息，流量削鋒等問題。實現高性能，高可用，可伸縮和最終一致性架構。是大型分布式系統不可缺少的中間件。
目前在生產環境，使用較多的消息隊列有ActiveMQ，RabbitMQ，Kafka等。
消息隊列應用場景
以下介紹消息隊列在實際應用中常用的使用場景。異步處理，應用解耦，流量削鋒和消息通訊四個場景。
1.異步處理
場景說明：用戶注冊后，需要發注冊郵件和注冊短信。傳統的做法有兩種1.串行的方式；2.並行方式。
（1）串行方式：將注冊信息持久化后，發送注冊郵件，再發送注冊短信。三個業務全部完成后，返回給客戶端。
（2）並行方式：將注冊信息持久化后，發送注冊郵件的同時，發送注冊短信。三個業務全部完成后，返回給客戶端。與串行的差別是，並行的方式可以提高處理的時間。
假設三個業務節點每個使用100毫秒鍾，不考慮其他開銷，則串行方式的時間是300ms，並行的時間可能是200毫秒。則串行的方式1秒內可處理3次請求，並行方式1秒內可處理5次請求，綜上所述，傳統的方式系統的性能（並發量，吞吐量，響應時間）會有瓶頸。如何解決這個問題呢？
引入消息隊列，將不是必須的業務邏輯，異步處理。如下圖所示
按照上圖，用戶的響應時間相當於是注冊信息寫入數據庫的時間和將消息插入消息隊列，也就是105毫秒。注冊郵件，發送短信消息寫入隊列后，直接返回。如此消息隊列異步處理后，1秒內可處理9次請求。大大提高了系統的性能
2.應用解耦
場景說明：后台發貨系統，發貨后快遞發貨系統需要通知訂單系統，該訂單已發貨。如果我們用傳統的做法是，快遞發貨系統調用訂單系統的接口，更新訂單為已發貨。如下圖
傳統模式的缺點：
1） 假如訂單系統無法訪問，則訂單更新為已發貨失敗，從而導致發貨失敗；
2） 發貨系統與訂單系統耦合；
如何解決以上問題呢？引入應用消息隊列后的方案，如下圖：
發貨系統：發貨后，發貨系統完成持久化處理，將消息寫入消息隊列，返回發貨成功。
訂單系統：訂閱發貨的消息，獲取發貨信息，訂單系統根據信息，進行更新操作。
如上，發貨系統在發貨的時候不用關心后續操作了，如果訂單系統不能正常使用。也不影響正常發貨，實現訂單系統與發貨系統的應用解耦。
3.流量削鋒
流量削鋒也是消息隊列中的常用場景，一般在秒殺或搶夠活動中使用廣泛。
應用場景：秒殺活動，一般會因為流量過大，應用系統配置承載不了這股瞬間流量，導致系統直接掛掉，即傳說中的“宕機”現象。為解決這個問題，我們會將那股巨大的流量拒在系統的上層，即將其轉移至 MQ 而不直接涌入我們的接口，此時MQ起到了緩沖作用。
4.消息通訊
消息通訊是指，消息隊列一般都內置了高效的通信機制，因此也可以用在實現消息通訊。如點對點消息隊列，或者聊天室等。
點對點通訊：客戶端A和客戶端B使用同一隊列，進行消息通訊。
聊天室通訊：客戶端A，客戶端B 訂閱同一主題，進行消息發布和接收。
以上實際是消息隊列的兩種消息模式，點對點或發布訂閱模式。