一個故事告訴你什麼是消息隊列！

案例

有一天，產品跑來講：「咱們要作一個用戶註冊功能，須要在用戶註冊成功後給用戶發一封成功郵件。」

小明（攻城獅）：「好，需求很明確了。」 不就提供一個註冊接口，保存用戶信息，同時發起郵件調用，待郵件發送成功後，返回用戶操做成功。沒一會功夫，代碼就寫完了。驗證功能沒問題後，就發佈上線了。

線上正常運行了一段時間，產品匆匆地跑來講：「你作的功能不行啊，運營反饋註冊操做響應太慢，已經有好多用戶流失了。」

小明聽得一身冷汗，趕忙回去改。他發現，原先的以單線程同步阻塞的方式進行郵件發送，確實存在問題。此次，他利用了 JAVA 多線程的特性，另起線程進行郵件發送，主線程直接返回保存結果。測試經過後，趕忙發佈上線。小明心想，這下總沒問題了吧。

沒過多久，產品又跑來了，他說：「如今，註冊操做響應是快多了。可是又有新的問題了，有用戶反應，郵件收不到。可否在發送郵件時，保存一下發送的結果，對於發送失敗的，進行補發。」

小明一聽，哎，又得熬夜加班了。產品看他一臉苦逼的樣子，忙說：「郵件服務這塊，別的團隊都已經作好了，你不用再本身搞了，直接用他們的服務。」

小明趕忙去和郵件團隊溝通，誰知他們的服務根本就不對外開放。這下小明可開始犯愁了，明知道有這麼一個服務，但是恰恰又調用不了。

郵件團隊的人說，「看你愁的，我給你提供了一個相似郵局信箱的東西，你往這信箱裏寫上你要發送的消息，以及咱們約定的地址。以後你就不用再操心了，咱們天然能從約定的地址中取得消息，進行郵件的相應操做。」

後來，小明才知道，這就是外界廣爲流傳的消息隊列。你不用知道具體的服務在哪，如何調用。你要作的只是將該發送的消息，向大家約定好的地址進行發送，你的任務就完成了。對應的服務天然能監聽到你發送的消息，進行後續的操做。這就是消息隊列最大的特色，將同步操做轉爲異步處理，將多服務共同操做轉爲職責單一的單服務操做，作到了服務間的解耦。

哈哈，這下能高枕無憂了。太年輕，哪有萬無一失的技術啊~

不久的一天，你會發現全部業務都替換了郵件發送的方式，統一使用了消息隊列來進行發送。這下僅僅一個郵件服務模塊，難以承受業務方源源不斷的消息，大量的消息堆積在了隊列中。這就須要更多的消費者（郵件服務）來共同處理隊列中的消息，即所謂的分佈式消息處理。

總結

定義

有了上面的基礎，再看很是官方的解釋應該也能理解了。

消息隊列（英語：Message queue）是一種進程間通訊或同一進程的不一樣線程間的通訊方式，軟件的貯列用來處理一系列的輸入，一般是來自用戶。消息隊列提供了異步的通訊協議，每個貯列中的紀錄包含詳細說明的數據，包含發生的時間，輸入設備的種類，以及特定的輸入參數，也就是說：消息的發送者和接收者不須要同時與消息隊列互交。消息會保存在隊列中，直到接收者取回它。 ——維基百科

名詞解釋

解釋仍是太官方了，咱們來看一個最簡單的架構模型：

• Producer：消息生產者，負責產生和發送消息到 Broker；
• Broker：消息處理中心。負責消息存儲、確認、重試等，通常其中會包含多個 queue；
• Consumer：消息消費者，負責從 Broker 中獲取消息，並進行相應處理；

特性

異步性

將耗時的同步操做，經過以發送消息的方式，進行了異步化處理。減小了同步等待的時間。

鬆耦合

消息隊列減小了服務之間的耦合性，不一樣的服務能夠經過消息隊列進行通訊，而不用關心彼此的實現細節，只要定義好消息的格式就行。

分佈式

經過對消費者的橫向擴展，下降了消息隊列阻塞的風險，以及單個消費者產生單點故障的可能性（固然消息隊列自己也能夠作成分佈式集羣）。

可靠性

消息隊列通常會把接收到的消息存儲到本地硬盤上（當消息被處理完以後，存儲信息根據不一樣的消息隊列實現，有可能將其刪除），這樣即便應用掛掉或者消息隊列自己掛掉，消息也可以從新加載。

來源：https://github.com/jasonGeng88/blog/
近期熱文推薦：

1.Java 15 正式發佈， 14 個新特性，刷新你的認知！！

2.終於靠開源項目弄到 IntelliJ IDEA 激活碼了，真香！

3.我用 Java 8 寫了一段邏輯，同事直呼看不懂，你試試看。。

4.吊打 Tomcat ，Undertow 性能很炸！！

5.《Java開發手冊（嵩山版）》最新發布，速速下載！

以爲不錯，別忘了隨手點贊+轉發哦！