回到目录

很久就想写一套属于自己的消息队列组件，前段时候看了汤雪华同学的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!

回到目录