很久就想写一套属于自己的消息队列组件，前段时候看了汤雪华同学的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!
本文转自博客园张占岭（仓储大叔）的博客，原文链接：Lind.DDD.LindMQ的一些想法，如需转载请自行联系原博主。
