消息隊列技術之基本概念

最近一直在總結Azure Messaging ServiceBus Messaging相關的技術：消息順序、消息持久化、複雜對象消息的序列化、消息事務、消息回執等機制。

感受有必要補充一篇消息隊列技術的基本概念，不管RabbitMQ、ActiveMQ仍是其餘，都有的一些基本概念、術語、機制，分享給你們，但願你們在搞消息隊列技術的時候可以快速

理解、排上用場。

1. 消息生產者、消息者、隊列、主題

消息生產者Producer：發送消息到消息隊列。

消息消費者Consumer：從消息隊列接收消息。

消息隊列Queue：一個先進先出的消息存儲區域。消息按照順序發送接收，一旦消息被消費處理，該消息將從隊列中刪除。

主題Topic：一種支持消息多個訂閱者的機制。

2. 點對點/Queue消息隊列模型

一個生產者向一個特定的隊列發送消息，一個消費者從該隊列中接收消息；

消息的生產者和消費者能夠不一樣時處於運行狀態。

每個成功處理的消息都由消息消費者簽收確認（Acknowledge）。如圖：

3. 發佈訂閱消息模型Topic

發佈訂閱模型中，支持向一個特定的消息主題Topic發佈消息。0個或多個訂閱者可能對接收來自特定消息主題的消息感興趣。在這種模型下，發佈者和訂閱者彼此不知道對方，這種

模式被歸納爲：

多個消費者能夠得到消息在發佈者和訂閱者之間存在時間依賴性，即必須先訂閱，再發送消息，然後接收訂閱的消息，這個操做順序必須保證。如圖：

4. 消息的順序性保證

基於Queue消息模型，利用FIFO先進先出的特性，能夠保證消息的順序性。

5. 消息的ACK機制

即消息的Ackownledge確認機制，

爲了保證消息不丟失，消息隊列提供了消息Acknowledge機制，即ACK機制，當Consumer確認消息已經被消費處理，發送一個ACK給消息隊列，此時消息隊列即可以刪除這個消

息了。若是Consumer宕機/關閉，沒有發送ACK，消息隊列將認爲這個消息沒有被處理，會將這個消息從新發送給其餘的Consumer從新消費處理。

6. 消息的同步和異步收發

同步：消息的收發支持同步收發的方式。同時還有另外一種同步方式：同步收發場景下，消息生產者和消費者雙向應答模式，例如：張三寫封信送到郵局中轉站，而後李四從中轉站獲

得信，而後在寫一份回執信，放到中轉站，而後張三去取，固然張三寫信的時候就得寫明回信地址。

消息的接收若是以同步的方式(Pull)進行接收，若是隊列中爲空，此時接收將處於同步阻塞狀態，會一直等到消息的到達。

異步：消息的收發一樣支持異步方式：異步發送消息，不須要等待消息隊列的接收確認；異步接收消息，以Push的方式觸發消息消費者接收消息。

7. 消息的事務支持

消息的收發處理支持事務，例如：在任務中心場景中，一次處理可能涉及多個消息的接收、處理，這應該處於同一個事務範圍內，若是一個消息處理失敗，事務回滾，消息從新回到

隊列中。

8. 消息的持久化

消息的持久化，對於一些關鍵的核心業務來講是很是重要的，啓用消息持久化後，消息隊列宕機重啓後，消息能夠從持久化存儲恢復，消息不丟失，能夠繼續消費處理。

9. 消息隊列的高可用性

在實際生產環境中，使用單個實例的消息隊列服務，若是遇到宕機、重啓等系統問題，消息隊列就沒法提供服務了，所以不少場景下，咱們但願消息隊列有高可用性支持，例如

Azure ServiceBus Messaging就有高可用保障機制；RabbitMQ有鏡像+HAProxy的高可用性方案，ActiveMQ也有基於LevelDB+ZooKeeper的高可用性方案。這點你們在

實際技術選型時須要重要考慮，雲端的MQ服務，好比Azure Messaging的SLA就承諾了99.9%, 也是很是推薦的。

以上是最近這一年研究消息隊列MQ技術的一些簡單梳理和概括，分享給你們，但願對你們有幫助。

 

周國慶

2017/4/12