消息隊列

概念

例子

有一天，產品跑來說：“我們要做一個用戶註冊功能，需要在用戶註冊成功後給用戶發一封成功郵件。”

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

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

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

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

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

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

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

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

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

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

百度百科

在消息傳遞機制中，有兩個比較重要的概念。一個是消息，一個是隊列。消息是由通信的雙方所需要傳遞的信息，它可以是各式各樣的媒體，如文本、聲音、圖象等等。消息最終的理解方式，為消息傳遞的雙方事先商定，這樣做的好處是，一是相當於對數據進行了簡單的加密，二則采用自己定義的格式可以節省通信的傳遞量。消息可以含有發送和接收者的標識，這樣只有指定的用戶才能看到只傳遞給他的信息和返回是否操作成功的回執。消息也可以含有時間戳，以便於接收方對某些與時間相關的應用進行處理。消息還可以含有到期時間，它表明如果在指定時間內消息還未到達則作廢，這主要應用與時間性關聯較為緊密的應用。

消息隊列是發送和接收消息的公用存儲空間，它可以存在於內存中或者是物理文件中。消息可以以兩種方式發送，即快遞方式(express)和可恢復模式(recoverable)，它們的區別在於，快遞方式為了消息的快速傳遞，把消息放置於內存中，而不放於物理磁盤上，以獲取較高的處理能力；可恢復模式在傳送過程的每一步驟中，都把消息寫入物理磁盤中，以得到較好的故障恢復能力。消息隊列可以放置在發送方、接收方所在的機器上，也可以單獨放置在另外一臺機器上。正是由於消息隊列在放置方式上的靈活性，形成了消息傳送機制的可靠性。當保存消息隊列的機器發生故障而重新啟動以後，以可恢復模式發送的消息可以恢復到故障發生之前的狀態，而以快遞方式發送的消息則丟失了。另一方面，采用消息傳遞機制，發送方不必要再擔心接收方是否啟動、是否發生故障等等非必要因素，只要消息成功發送出去，就可以認為處理完成，而實際上對方可能甚至未曾開機，或者實際完成交易時可能已經是第二天了。

維基百科

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

說明

結構

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

特性

• 異步性
  將耗時的同步操作，通過以發送消息的方式，進行了異步化處理。減少了同步等待的時間。

• 松耦合
  消息隊列減少了服務之間的耦合性，不同的服務可以通過消息隊列進行通信，而不用關心彼此的實現細節，只要定義好消息的格式就行。

• 分布式
  通過對消費者的橫向擴展，降低了消息隊列阻塞的風險，以及單個消費者產生單點故障的可能性（當然消息隊列本身也可以做成分布式集群）。

• 可靠性
  消息隊列一般會把接收到的消息存儲到本地硬盤上（當消息被處理完之後，存儲信息根據不同的消息隊列實現，有可能將其刪除），這樣即使應用掛掉或者消息隊列本身掛掉，消息也能夠重新加載

【消息隊列】-簡單了解