分享一个c写的开源分布式消息队列equeue.docVIP

前言 本文想介绍一下前段时间在写enode时，顺便实现的一个分布式消息队列equeue。这个消息队列的思想不是我想出来的，而是通过学习阿里的rocketmq后，自己用c#实现了一个轻量级的简单版本。一方面可以通过写这个队列让自己更深入的掌握消息队列的一些常见问题；另一方面也可以用来和enode集成，为enode中的command和domain event的消息传递提供支持。目前在.net平台，比较好用的消息队列，最常见的是微软的MSMQ了吧，还有像rabbitmq也有.net的client端。这些消息队列都很强大和成熟。但当我学习了kafka以及阿里的rocketmq（早期版本叫metaq，自metaq 3.0后改名为rocketmq）后，觉得rocketmq的设计思想深深吸引了我，因为我不仅能理解其思想，还有其完整的源代码可以学习。但是rocketmq是java写的，且目前还没有.net的client端，所以不能直接使用（有兴趣的朋友可以为其写一个.net的client端），所以在学习了rocketmq的设计文档以及大部分代码后，决定自己用c#写一个出来。 项目中包含了队列的全部源代码以及如何使用的示例。也可以在enode项目中看到如何使用。 equeue消息队列中的专业术语 Topic 一个topic就是一个主题。一个系统中，我们可以对消息划分为一些topic，这样我们就能通过topic，将消息发送到不同的queue。 Queue 一个topic下，我们可以设置多个queue，每个queue就是我们平时所说的消息队列；因为queue是完全从属于某个特定的topic的，所以当我们要发送消息时，总是要指定该消息所属的topic是什么。然后equeue就能知道该topic下有几个queue了。但是到底发送到哪个queue呢？比如一个topic下有4个queue，那对于这个topic下的消息，发送时，到底该发送到哪个queue呢？那必定有个消息被路由的过程。目前equeue的做法是在发送一个消息时，需要用户指定这个消息对应的topic以及一个用来路由的一个object类型的参数。equeue会根据topic得到所有的queue，然后根据该object参数通过hash code然后取模queue的个数最后得到要发送的queue的编号，从而知道该发送到哪个queue。这个路由消息的过程是在发送消息的这一方做的，也就是下面要说的producer。之所以不在消息服务器上做是因为这样可以让用户自己决定该如何路由消息，具有更大的灵活性。 Producer 就是消息队列的生产者。我们知道，消息队列的本质就是实现了publish-subscribe的模式，即生产者-消费者模式。生产者生产消息，消费者消费消息。所以这里的Producer就是用来生产和发送消息的。 Consumer 就是消息队列的消费者，一个消息可以有多个消费者。 Consumer Group 消费者分组，这可能对大家来说是一个新概念。之所以要搞出一个消费者分组，是为了实现下面要说的集群消费。一个消费者分组中包含了一些消费者，如果这些消费者是要集群消费，那这些消费者会平均消费该分组中的消息。 Broker equeue中的broker负责消息的中转，即接收producer发送过来的消息，然后持久化消息到磁盘，然后接收consumer发送过来的拉取消息的请求，然后根据请求拉取相应的消息给consumer。所以，broker可以理解为消息队列服务器，www.ipb.cc 提供消息的接收、存储、拉取服务。可见，broker对于equeue来说是核心，它绝对不能挂，一旦挂了，那producer，consumer就无法实现publish-subscribe了。 集群消费 集群消费是指，一个consumer group下的consumer，平均消费topic下的queue。具体如何平均可以看一下下面的架构图，这里先用文字简单描述一下。假如一个topic下有4个queue，然后当前有一个consumer group，该分组下有4个consumer，那每个consumer就被分配到该topic下的一个queue，这样就达到了平均消费topic下的queue的目的。如果consumer group下只有两个consumer，那每个consumer就消费2个queue。如果有3个consumer，则第一个消费2个queue，后面两个每个消费一个queue，从而达到尽量平均消费。所以，可以看出，我们应该尽量让consumer group下的consumer的数目和topic的queue的数目一致或成倍数关系。这样每个consumer消费的queue的数量总是一样的，这样每个consumer服务器的压力才会