RabbitMQ 簡介

很多剛開始學習Java的小伙伴對RabbitMQ還不是很了解，RabbitMQ是使用Erlang語言開發的開源消息隊列系統，基于AMQP協議來實現。AMQP的主要特征是面向消息、隊列、路由(包括點對點和發布/訂閱)、可靠性、 安全。AMQP協議更多用在企業系統內，對數據一致性、穩定性和可靠性要求很高的場景，對性能和吞吐量的要求還在其次。

MQ全稱為Message Queue, 消息隊列(MQ)是一種應用程序對應用程序的通信方法。應用程序通過讀寫出入隊列的消息(針對應用程序的數據)來通信，而無需專用連接來鏈接它們。消息傳遞指的是程序之間通過在消息中發送數據進行通信，而不是通過直接調用彼此來通信，直接調用通常是用于諸如遠程過程調用的技術。排隊指的是應用程序通過 隊列來通信。隊列的使用除去了接收和發送應用程序同時執行的要求。

解耦

當發送短信執行成功后頁面才執行倒計時60秒，假如在發送短信時網速原因，導致短信一直被阻塞，那么倒計時也會被一直延遲，這樣及其影響用戶體驗感。

這時候就可以使用RabbitMQ了，將發送短信和倒計時解耦，基于消息的模型，關心的是“通知”，而非“處理”。

像下訂單、郵件通知、緩存刷新等操作都可以使用消息隊列進行優化。

異步提升效率

場景說明：用戶需發送短信驗證碼時，點擊發送短信，第三方平臺發送短信至用戶手機成功，執行倒計時60秒。傳統的做法有兩種 1.串行的方式;2.并行方式：

(1)串行方式：將用戶點擊發送短信，第三方平臺發送短信至用戶手機成功，執行倒計時60秒。以上三個任務全部完成后，返回給客戶端(響應150ms)。

(2)并行方式：在用戶點擊發送短信成功后，第三方平臺發送短信的同時，執行倒計時60秒。與串行的差別是，并行的方式可以提高處理的時間(響應100ms)。

(3)引入消息隊列，將不是必須的業務邏輯，異步處理(55ms)。改造后的架構如下：

流量削峰

流量削鋒(流量錯峰)也是消息隊列中的常用場景，一般在秒殺或團搶活動中使用廣泛。

應用場景：系統其他時間A系統每秒請求量就100個，系統可以穩定運行。系統每天晚間八點有秒殺活動，每秒并發請求量增至5000條，但是系統最大的處理能力只能每秒處理2000個請求(因為MySQL每秒只能處理2000個請求，MySQL的缺點：在海量數據處理與熱數據時，效率會顯著變慢)，于是系統崩潰，服務器宕機。

引入RabbitMQ：系統A從RabbitMQ中慢慢拉取請求，每秒就拉取2000個請求，不要超過自己每秒能處理的請求數量即可。RabbitMQ，每秒5000個請求進來，結果只有2000個請求出去，所以在秒殺期間(將近一小時)可能會有幾十萬或者幾百萬的請求積壓在RabbitMQ中。這個短暫的高峰期積壓是沒問題的，因為高峰期過了之后，每秒就只有50個請求進入RabbitMQ了，但是系統還是按照每秒2000個請求的速度在處理，所以說，只要高峰期一過，系統就會快速將積壓的消息消費掉。我們在此計算一下，每秒在RabbitMQ積壓3000條消息，1分鐘會積壓18萬，1小時積壓1000萬條消息，高峰期過后，1個多小時就可以將積壓的1000萬消息消費掉。

以上就是關于“RabbitMQ的使用場景”的介紹，如果您想了解更多相關知識，可以關注一下動力節點的Java在線學習，里面的課程內容豐富，由淺到深，適合沒有基礎的小伙伴學習，希望對大家能夠有所幫助。