感覺有必要補充一篇訊息佇列技術的基本概念，無論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技術的一些簡單梳理和歸納，分享給大家，希望對大家有幫助。
訊息佇列二
queue只有maxsize乙個構造引數，用來指定佇列容量，指定為0的時候代表容量無限。主要有以下成員函式 queue.qsize 返回訊息佇列的當前空間。返回的值不一定可靠 queue.empty 判斷訊息佇列是否為空，返回true或false。同樣不可靠 queue.full 類似上邊，判斷訊息...
system v 訊息佇列（二）
1 功能 把一條訊息新增到訊息佇列中 2 原型 intmsgsnd int msqid,const void msgp.size t msgsz,int msg 3 引數 msgqid 由msgget函式返回的訊息佇列標識碼 msgp 是乙個指標，指標指向準備傳送的訊息 msgsz 是msgp指向的...
訊息佇列 訊息佇列
輪詢排程 一次性分發所有訊息，保證訊息平均分配，不管消費者是否能正常消費 訊息應答 保證消費端能確實消費，不丟失 公平 乙個乙個分發所有訊息,在保證分發到的執行緒確認回覆後，才分發下個訊息給下個空閒的消費者，訊息持久化 保證佇列中的訊息不丟失，包括3要素 交換器 訊息佇列 訊息都必須宣告持久化 發布...