在公衆號回覆課程,免費獲取JAVA全棧課程
做者 | 顏 羣java
公衆號 | 大數據和人工智能技術web
消息隊列，Message queue，簡稱MQ。面試
顧名思義，消息隊列就是一個 存放「消息」的「隊列」，有着 FIFO 的特性。這裏的「消息」實際就是「數據」的意思，所以消息隊列自己就是一個簡單的數據結構——隊列。數據庫
在設計模式上，消息隊列是「生產者-消費者」模式的一個經典實現。編程
通常而言，用戶就是請求的「生產者」，然後臺服務就是請求的「消費者」。設計模式
用戶只須要向MQ中生產請求，無需關心是誰來消費；後臺服務也只須要從MQ中獲取並消費請求，無需關心是哪一個用戶在生產請求。所以，在使用了MQ後，生產者和消費者就沒有了直接引用的關係；也就是說，MQ能夠實現生產者與消費者的解耦，如圖所示。服務器
更進一步，爲了不高併發帶來的延遲，生產者能夠將下單請求以「異步消息」的形式發送MQ中，從而快速響應用戶，提升用戶體驗。微信
MQ的一個重要做用就是：限流。網絡
本文主要介紹：使用MQ進行限流的核心手段——削峯填谷數據結構
MQ能夠把海量的請求延遲轉發給各個後臺服務器。
能夠這樣理解「削峯填谷」：若是沒有MQ，海量請求將直奔服務器；但有了MQ後，海量請求會先暫存到MQ中（海量請求同時抵達時就是流量的「峯」值），以後服務器再將MQ中的海量請求逐步拉取過來並處理，即用「峯」值填補服務器在以後一段時間的「谷」值（若是不從MQ中拉取請求，服務器在沒有數據處理時，併發量的監控線就像山谷同樣處在低位）。
削峯填谷的具體實現方法以下：
在高併發場景下，能夠把海量的用戶請求當作「消息」存儲到消息隊列之中，以後秒殺系統的各個子系統就能夠根據自身的性能，從消息隊列中平穩的拉取固定數目的請求數，如圖所示。
舉個例子，假設某一時刻秒殺的併發請求量是 10 萬，「子系統-A「的處理極限是 2 萬、「子系統-B「是 3 萬、「子系統-C「是 4 萬，顯然 A、B、C 三個子系統是沒法同時承受 10 萬的請求量。此時，就能夠先將 10 萬個請求存儲到消息隊列中（即入隊），而後A、B、C子系統根據自身的能力，選擇性的從消息隊列中拉取必定數額的請求（即出隊），具體就是「子系統-A」僅從消息隊列中拉取 2 萬個請求並處理、「子系統-B」拉取 3 萬條、「子系統-C」拉取 4 萬條，而後將剩餘的 1 萬條請求直接拒絕，或者等待A、B、C的第二輪出隊操做。這樣一來，各個子系統既能夠充分的發揮本身的性能，也能防止因爲超負荷的併發量形成的系統崩潰。
思考：在發送消息的過程當中，如何避免消息丟失、消息被重複消費，如何處理消息積壓問題？
這些問題會在下篇文章中作解答，感謝閱讀。
- 完 -
推薦閱讀
▲
在「大數據和人工智能技術」聊天對話框回覆如下關鍵詞，可得到相關信息喲
回覆【資料】獲取JAVA全棧視頻的配套資料
回覆【最新課程】獲取一門還沒有公開的高級課程（不按期更換）
回覆【提問】獲取免費答疑方式
回覆【課程】獲取JAVA全棧視頻教程 + 配套資料
回覆【軟件】獲取經常使用的開發軟件（逐步完善）
回覆【億級源碼】獲取本號做者出版的《億級流量Java高併發與網絡編程實戰》一書配套源碼
回覆【javase】獲取JAVA視頻教程
回覆【數據庫】獲取數據庫視頻教程
更多課程，逐步開放...
本文分享自微信公衆號 - 大數據和人工智能技術（Big_Data-AI）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。