消息中间件中的一些概念

接上一篇的《什么是分布式消息中间件？》，这一篇来介绍一下消息中间件中的一些概念。

Topic

主题，从逻辑上讲一个Topic就是一个Queue，即一个队列；从存储上讲，一个Topic存储了一类相同的消息，是一类消息的集合。比如一个名称为trade.order.queue的Topic里面存的都是订单相关的消息。

Partition

分区。分区是存在于服务端，内部保持顺序、且顺序不可变更的一个队列，用于存储消息。分区可能不应该出现在消息领域内，在使用消息中间件发送和消费时，实际上用户是感受不到分区这个概念的。下面这幅图便于大家去理解分区：

一个Topic存储消息时会分为多个Partition，每个Partition内消息是有顺序的。至于为什么需要将Topic划分成按照Partition存储，在以后设计和实现部分会解释。

Producer

生产者，消息的生产方，一般由业务系统负责产生消息。

Producer负责决定将消息发送到哪个Topic的那个Partition。

Consumer

消费者，消息的消费方，一般是后台系统负责异步消费消息。

Consumer订阅Topic，消费Topic内部的消息。

Broker

消息的存储者，一般也称为Server，在JMS中叫Provider，在RocketMQ（阿里开源的消息中间件）中叫Broker。

NameServer

NameServer其实不是消息中间件的概念了，一般在分布式系统中都会有一个角色作为NameServer用于服务发现，在Kafka中使用ZooKeeper来实现，在RocketMQ中单独写了NameServer服务。

Group

Group用于标志Consumer的身份，拥有相同Group名称的Consumer一般消费一类消息，且消费逻辑是相同的。

RocketMQ中Producer也需要Group标志身份，但是实际上Producer是不需要的。因为Producer之间是不相关的，Consumer之间是需要协同工作的。

这里多解释一下为什么Consumer之间是需要协同工作的。

比如启动了两个Consumer来消费订单消息，然后调用物流系统进行发货。那么在产生一条订单消息后，只能让两个Consumer中的一个来处理消息（否者就发货两次了）所以需要一个标识将这两个Consumer标记为行为一致的。另一个场景是如果一个Consumer实例宕机了，这个时候需要有行为相同的Consumer去接管它的消费任务，那么就需要一个标识来标识行为相同的Consumer。

那是不是只要行为相同的Consumer只存在一个就好了呢？是的，如果只有行为一致的Consumer，那么就不存在协同工作，也可以不需要Group，每个Consumer拥有独立的ID即可。但是实际系统是不可能的，从系统可用性和性能上都不可能（单个Consumer就有单点问题，也有性能问题，毕竟我们谈的是分布式系统）。

集群消费

集群消费的含义是说一类Consumer（即Group相同的Consumer的集合）共同完成对一个Topic的消费。其实上面说明Consumer需要协同工作时举例中就默认是集群消费了，这也是现实业务中95%以上需求的消费方式。

具体来看集群消费模式如下：

Consumer0和Consumer1属于同一个Group，假设Topic中有0~5共6条消息，Consumer0消费到0~2，Consumer1消费到3~5，它们共同完成了Topic中消息的消费。

这存在于大量的无状态的后台系统中，就如上面说的消费订单消息进行发货的例子。

广播消费

广播消费的含义是Topic中的每一条消息都会被一类Consumer（属于同一个Group的多个Consumer）中的每个Consumer实例消费。

如下图，Topic总的0~5共6条消费，Consumer0会消费到0~5完整的6条消息，Consumer1也会消费到0~5的6条消息。

这种消费往往应用在有状态的服务，比如缓存服务器去消费消息更新自己的缓存数据，那么每一台缓存服务器都需要拿到消息。

结语

了解什么是分布式消息中间件和消息中间件的一些概念之后，下一篇计划谈一谈分布式消息中间件的需求，毕竟要有的放矢，明确需求才能知道要做什么，怎么做才合适。

欢迎关注此公众号，将长期发布和分布式消息中间件相关的技术内容。当然如果需要私下交流，也可以加通过留言或信息的方式加作者微信。

PS：为什么本文开头会用一张Kafka的Logo呢？因为Kafka真的是一个非常优秀的软件，文中一些概念也来源于Kafka（如果对消息中间件有兴趣，强烈建议去看看Kafka的文档和实现）。