最近一直在總結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