EQueue - 一个纯C#写的分布式消息队列介绍2

一年前，当我第一次开发完EQueue后，写过一篇文章介绍了其整体架构，做这个框架的背景，以及架构中的所有基本概念。通过那篇文章，大家可以对EQueue有一个基本的了解。经过了1年多的完善，EQueue无论是功能上还是成熟性上都完善了不少。所以，希望再写一篇文章，介绍一下EQueue的整体架构和关键特性。

EQueue架构

EQueue是一个分布式的、轻量级、高性能、具有一定可靠性，纯C#编写的消息队列，支持消费者集群消费模式。

主要包括三个部分：producer, broker, consumer。producer就是消息发送者；broker就是消息队列服务器，负责接收producer发送过来的消息，以及持久化消息；consumer就是消息消费者，consumer从broker采用拉模式到broker拉取消息进行消费，具体采用的是long polling（长轮训）的方式。这种方式的最大好处是可以让broker非常简单，不需要主动去推消息给consumer，而是只要负责持久化消息即可，这样就减轻了broker server的负担。同时，consumer由于是自己主动去拉取消息，所以消费速度可以自己控制，不会出现broker给consumer消息推的太快导致consumer来不及消费而挂掉的情况。在消息实时性方面，由于是长轮训的方式，所以消息消费的实时性也可以保证，实时性和推模型基本相当。

EQueue是面向topic的架构，和传统的MSMQ这种面向queue的方式不同。使用EQueue，我们不需要关心queue。producer发送消息时，指定的是消息的topic，而不需要指定具体发送到哪个queue。同样，consumer发送消息也是一样，订阅的是topic，不需要关心自己想从哪个queue接收消息。然后，producer客户端框架内部，会根据当前的topic获取所有可用的queue，然后通过某种queue select strategy选择一个queue，然后把消息发送到该queue；同样，consumer端，也会根据当前订阅的topic，获取其下面的所有的queue，以及当前所有订阅这个topic的consumer，按照平均的方式计算出当前consumer应该分配到哪些queue。这个分配的过程就是消费者负载均衡。

Broker的主要职责是：

发送消息时：负责接收producer的消息，然后持久化消息，然后建立消息索引信息（把消息的全局offset和其在queue中的offset简历映射关系），然后返回结果给producer；

消费消息时：负责根据consumer的pull message request，查询