RocketMQ概念模型

RocketMQ概念模型

一 前言

  对于任何一款中间件产品而言,清晰的概念模型是帮助用户正确理解使用它的关键。由于RocketMQ并没有遵循业界现有的JMS或AMQP规范,而且功能集比后两者更加丰富,描述该中间件产品的概念模型是一项比较有挑战的任务。RocketMQ的官方文档《RocketMQ 原理简介》对产品的概念模型给出了比较简洁而清晰的介绍。

  本文将针对用户在使用RocketMQ过程中需要重点理解的一些概念进行归纳总结和补充说明。

二 概念模型

1 Topic

  首先需要提到的概念是Topic。Topic是RocketMQ中的一个重要概念,RocketMQ的各组件都是围绕着Topic建立起对应关系的。

  在RocketMQ官方文档和本文中, Topic在不同的语境下被赋予了两种不同的语义:

  1)    消息的Topic属性值

    在描述Consumer的订阅设置信息或消息的属性时。

  2)    Topic属性为某个值的消息(单个消息或消息集合)

    在描述Broker,Producer和Consumer的对应关系,Queue以及负载均衡策略时。


2 Broker,Producer和Consumer

  如果不考虑负载均衡和高可用,最简单的Broker,Producer和Consumer之间的关系如下图所示:

 

 

 

  为了实现消息队列的水平扩展和高可用,RocketMQ引入了Producer Group, Consumer Group, Master/Slave Broker和BrokerCluster概念。它们之间的关系进一步演化为:

 


  其中,Broker Group是为了方便指代一个Master Broker及其Slave Broker组成的集合,本文引入的一个新概念,类似于MongoDB中的复制集(Replica Set)概念。Brokr Group的定义是:Broker名相同的一组Master/Slave Broker,其中包含一个Master Broker(Broker Id为0)和0~N个Slave Broker(Broker Id不为0)。

  在上图中我们可以看出,Producer Group、Consumer Group和Topic之间的关系的被强调了:Producer Group生产消息,Consumer Group消费消息。实际的生产和消费行为是组内的各Producer和Consumer按照一致的生产或消费逻辑负责进行的。之所以强调ProducerGroup、Consumer Group和Topic之间的关系,是因为在《RocketMQ用户指南》中,对Consumer Group或Producer Group的说明还不能引起用户对使用规则的足够重视。例如,对ConsumerGroup的说明为:“Consumer 组名,多个Consumer如果属于一个应用,订阅同样的消息,且消费逻辑一致,则应该将它们归为同一组”。而背后的含义其实是:如果一个Consumer Group内的两个Consumer订阅不相同的Topic,会导致各Consumer只消费到一部分Topic。

   另外,在上图中Broker Cluster和Broker Group之间的关系定义成1:N的关系,是为了表明两者之间存在包含关系。在RocketMQ的代码中并没有限制一个Broker Group必须从属于一个Broker Cluster。

   各概念之间的主要对应关系为:

  1)   ProducerGroup和Topic之间的关系是多对多的关系

    一个Producer Group内的Producer可以生产多个不同Topic的消息;

    一个Topic的消息也可以由多个Producer Group内的Producer生产。

  2)   BrokerGroup和Topic之间的关系是多对多的关系

    一个Broker Group可以为多个Topic提供服务;

    一个Topic可以由一个或多个Broker Group提供服务。

    一个Topic由多个Broker Group提供服务即《RocketMQ用户指南》中提到的多Master,或多Master多Slave模式。

    一个Topic由一个Broker Group提供服务即《RocketMQ用户指南》中提到的单Master模式(包含Slave或不包含Slave)。

  3)   ConsumerGroup和Topic之间的关系是多对多的关系

    一个Consumer Group内的Consumer可以消费多个Topic的消息;

    一个Topic的消息也可以由多个Consumer Group内的Consumer消费。

  在集群消费模式下,一个Topic的消息被多个Consumer Group消费的行为比较特殊,在JMS标准中没有与其对应的消费模式。可以描述为:每个Consumer Group会分别将该Topic的消息消费一遍;在每一个Consumer Group内,各Consumer通过负载均衡的方式消费该Topic的消息。下面的例子可以说明这种消费模式的应用场景:

  基于微服务架构的拼车出行应用中,用户完成一次拼车行为后系统需要完成两个动作:扣款和增加用户的积分。拼车管理,支付管理和积分管理被解耦为三个独立的微服务。

  应用为支付管理模块和积分管理模块分别指定一个Consumer Group,两个Consumer Group都订阅“拼车结束”对应Topic的消息。拼车结束后,拼车管理模块只需要发出一个“拼车结束”消息就能够驱动另外的两个业务模块分别完成后续的工作。

  将一个Consumer Group对应业务系统中的一个独立的业务模块,是一个比较值得推荐的ConsuerGroup划分方法。


3 Topic,Topic分片和Queue

  Queue是RocketMQ中的另一个重要概念。在对该概念进行分析介绍前,我们先来看一张图:


  为了简化分析过程,在这张图中没有包含Slave Broker。Broker1,Broker2和Broker3都是Master Broker。如果各Master Broker有Slave Broker,Slave Broker中的结构和其对应的Master Broker完全相同。

  从本质上来说,RocketMQ中的Queue是数据分片的产物。为了更好地理解Queue的定义,我们还需要引入一个新的概念:Topic分片。在分布式数据库和分布式缓存领域,分片概念已经有了清晰的定义。同理,对于RocketMQ,一个Topic可以分布在各个Broker上,我们可以把一个Topic分布在一个Broker上的子集定义为一个Topic分片。对应上图,TopicA有3个Topic分片,分布在Broker1,Broker2和Broker3上,TopicB有2个Topic分片,分布在Broker1和Broker2上,TopicC有2个Topic分片,分布在Broker2和Broker3上。

  将Topic分片再切分为若干等分,其中的一份就是一个Queue。每个Topic分片等分的Queue的数量可以不同,由用户在创建Topic时指定。

  我们知道,数据分片的主要目的是突破单点的资源(网络带宽,CPU,内存或文件存储)限制从而实现水平扩展。RocketMQ 在进行Topic分片以后,已经达到水平扩展的目的了,为什么还需要进一步切分为Queue呢?

  解答这个问题还需要从负载均衡说起。以消息消费为例,借用Rocket MQ官方文档中的Consumer负载均衡示意图来说明:


  如图所示,TOPIC_A在一个Broker上的Topic分片有5个Queue,一个Consumer Group内有2个Consumer按照集群消费的方式消费消息,按照平均分配策略进行负载均衡得到的结果是:第一个 Consumer 消费3个Queue,第二个Consumer 消费2个Queue。如果增加Consumer,每个Consumer分配到的Queue会相应减少。Rocket MQ的负载均衡策略规定:Consumer数量应该小于等于Queue数量,如果Consumer超过Queue数量,那么多余的Consumer 将不能消费消息。

  在一个Consumer Group内,Queue和Consumer之间的对应关系是一对多的关系:一个Queue最多只能分配给一个Consumer,一个Cosumer可以分配得到多个Queue。这样的分配规则,每个Queue只有一个消费者,可以避免消费过程中的多线程处理和资源锁定,有效提高各Consumer消费的并行度和处理效率。

  由此,我们可以给出Queue的定义:

    Queue是Topic在一个Broker上的分片等分为指定份数后的其中一份,是负载均衡过程中资源分配的基本单元。

 

阅读更多
文章标签: 消息队列 RocketMQ
博主设置当前文章不允许评论。

Rocketmq-Topic

rocket-topic 创建

adaihao_ adaihao_

2017-01-16 23:35:36

阅读数:5870

没有更多推荐了,返回首页

不良信息举报

RocketMQ概念模型

最多只允许输入30个字

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭