回到目錄

很久就想寫一套屬於自己的訊息佇列元件，前段時候看了湯雪華同學的EQueue，感覺還是不錯的，他也是看了rabbitMQ之後寫的Equeue，在設計上與前者有類似的地方，而大叔這次準備寫一個LindMQ，當前整體架構都差不多，無非是生產者，管道，消費者三個角色，而核心部分就是管道Broker這個東西了，為生產者提供了push操作；而為消費者又提供了Pull操作；為了解耦考慮，他們之前沒有直接的引用關係，通訊採用tcp的方式，Broken的訊息儲存介質我們使用redis，生產者和消費者與Broker的通訊我們採用FastSocket這個元件。

LindMQ設計架構圖

關於MQ系統的三大物件

以下三大物件其實都有各自的實現，各自的平臺，各自也都需要一個宿主！

Producer

生產者，用來將訊息從源平臺傳送到目標佇列中，目標佇列用到儲存訊息，這裡一般指Broker，它可以是一種叢集環境,它會封裝對儲存訊息介質的入隊與出隊的基本操作，而對於真實的儲存介質，生產者是不需要知道的！

Broker

訊息處理者，用來處理訊息，加工訊息，儲存訊息等，它會公開基本的推訊息介面和拉訊息介面！

Consumer

消費者，用來處理Broker裡的訊息，它一般通過長連線，定時向Broker里拉訊息的方法實現，基於實時性考慮，又出現了pub/sub這種釋出與訂閱模式，當消費方訂閱了某種訊息主題（topic）之後，有這種訊息產生時，broker會把訊息自動推到訊息方！

關於訊息的上下文

訊息上下文，我們可以把它看成是承載訊息的物件，它會有topic主題，queueId訊息佇列索引，queueOffset內容索引，body訊息體組成，它相關於是producer,broker和consumer之間定義的一種資料協議，他們之間通訊使用這種公開的協議，在LinqQueue裡面訊息協議我們稱為LindMQ，下面看一下協議的內容

    /// <summary>
    /// 訊息協議
    /// </summary>
    [Serializable]
    public class LindMQ
    {
        /// <summary>
 

        /// 訊息所屬Topic，每種Topic有一種型別的Body
        /// </summary>
        public string Topic { get; set; }
        /// <summary>
        /// 訊息內容，Redis裡儲存為Json
        /// </summary>
        public string Body { get; set; }
        /// <summary>
        /// 訊息所屬的佇列ID
        /// </summary>
        public int QueueId { get; internal set; }
        /// <summary>
        /// 訊息在所屬佇列的序號
        /// </summary>
        public long QueueOffset { get; internal set; }
        /// <summary>
        /// 訊息的儲存時間
        /// </summary>
        internal DateTime CreateTime { get; set; }
        /// <summary>
        /// 將訊息物件序列化成字元
        /// </summary>
        /// <returns></returns>
        public override string ToString()
        {
            return Utils.SerializeMemoryHelper.SerializeToJson<LindMQ>(this);
        }
    }

通過上面程式碼我們可以看到，Topic,QueueId,QueueOffset,Body等欄位，這也是一個訊息協議也需要的主要資訊了，Topic是訊息主題，我們可以這樣認為，一種主題就是一類訊息，QueueId它位於Topic訊息主題下面，一個topic可以包括多個queue，而QueueOffset是每個queue裡的訊息索引，類似你的訊息在訊息佇列裡排在第幾位；而body就是我們的訊息體了，它使用二時制流表示，這樣有利於網路傳輸！

好了，今天主要是對LinqQueue做一個簡單的介紹，下次我再繼續介紹LindQueue!

回到目錄