訊息佇列技術之基本概念

無論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%, 也是非常推薦的。

**:

訊息佇列技術之基本概念

最近一直在總結azure messaging servicebus messaging相關的技術 訊息順序 訊息持久化 複雜物件訊息的序列化 訊息事務 訊息回執等機制。感覺有必要補充一篇訊息佇列技術的基本概念，無論rabbitmq activemq還是其他，都有的一些基本概念 術語 機制，分享給大家...

訊息佇列（Message Queue）基本概念

之前做日誌收集模組時，用到flume。另外也有的方案，整合kafaka來提公升系統可擴充套件性，其中涉及到訊息佇列當時自己並不清楚為什麼要使用訊息佇列。而在我自己提出的原始日誌採集方案中不適用訊息佇列時，有幾個基本問題 1.日誌檔案上傳過程，有個基本的生產者 消費者問題 2.另外系統崩潰時，資料丟失...

OC之訊息基本概念

要說清楚訊息這個話題,我們必須先來了解三個概念 class,sel,imp,它們在 objc objc.h 中定義 typedef struct objc class class typedef struct objc object id typedef struct objc selector s...