关闭

RocketMQ概念模型

标签: 消息队列RocketMQ
2298人阅读 评论(0) 收藏 举报

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上的分片等分为指定份数后的其中一份,是负载均衡过程中资源分配的基本单元。

 

1
0
查看评论

Rocketmq-Topic

rocket-topic 创建
  • adaihao_
  • adaihao_
  • 2017-01-16 23:35
  • 4315

rocketmq问题汇总-一个consumerGroup只对应一个topic

1 同一个订阅组内不同Consumer实例订阅不同topic消费混乱问题调查 图1: 背景说明: 如图1左半部分,假设目前的关系如下: broker: 两个,broker_a和broker_b topic:两个,topic1和topic2,每个topic在每个broker上分...
  • a417930422
  • a417930422
  • 2016-02-14 17:32
  • 17215

阿里RocketMQ Quick Start

部署 首先使用dos2unix命令将alibaba-rocketmq/bin目录下的文件都转化为
  • a19881029
  • a19881029
  • 2014-06-26 15:04
  • 161080

分布式消息队列RocketMQ源码分析之1 -- Topic路由数据结构解析 -- topicRoute与topicPublishInfo与queueId

在前1篇RokcetMQ与Kafka架构差异一文中,我们已经讨论了2者在Topic的路由结构,也即topic/partition与物理机器的映射关系上的巨大差异。这个差异也是2者在架构上的一个巨大差异点,也是导致RocketMQ可以去除ZK依赖的一个重要原因。本篇将接着这个话题,进一步从源码角度深度...
  • chunlongyu
  • chunlongyu
  • 2017-01-12 12:55
  • 2949

RocketMQ原理解读 NameServer篇(broker节点治理)

序言在来阿里实习之前,就对消息队列非常感兴趣,当时就翻看了RocketMQ的使用指南并在本地搭建环境跑了些demo。如今项目压力不太大,就准备趁着实习期间来细看RocketMQ的原理和源码实现.NameServer作用nameServer顾名思义,在系统中肯定是做命名服务,服务治理方面的工作,功能应...
  • mr253727942
  • mr253727942
  • 2016-09-23 12:58
  • 4423

1.偏头痛杨的rocketmq4.x入门之基础概念扫盲篇

前戏 阅读本文之前,读者必须自己清楚什么是消息队列,以及消息队列的一些基本概念,例如:消息、生产者、消费者等。 我们如果需要玩异步、分布式事务、代码物理解耦、削峰平谷、发布订阅等等,可以使用消息队列中间件, 那么阿里的rocketmq是一款比较中意的产品,既有开源版又有商业版(阿里云的mq有点贵,谁...
  • piantoutongyang
  • piantoutongyang
  • 2017-09-28 15:29
  • 1326

RocketMQ管理命令说明

1.1.  控制台使用 RocketMQ提供有控制台及一系列控制台命令,用于管理员对主题,集群,broker等信息的管理; l  登录控制台: 首先进入RocketMQ工程,进入/RocketMQ/bin 在该目录下有个mqadmin脚本 l  查看帮助: ...
  • tianwei7518
  • tianwei7518
  • 2014-11-09 17:21
  • 14089

RocketMQ入门(2.快速入门)

本文档主要包含以下内容: 如何开通 MQ 服务如何申请 MQ 资源如何通过 MQ 进行消息收发 MQ 快速接入流程图: 1.开通MQ服务 在阿里云官方网站开通MQ服务。 2.申请MQ资源 在 MQ 消息系统中,消息发布者将消息发送到某个指定的消息主题(Topic) ,而消息订阅者则...
  • onlyyjco
  • onlyyjco
  • 2016-08-01 21:56
  • 2007

rocketmq3.26研究之四DefaultMQProducer

DefaultMQProducer 作为rocketmq生产者的默认实现,其实它并没有做任何实现,其内部引用一个DefaultMQProducerImpl实例进行具体消息发送。 它有一些基础配置,比如多长时间内消息发送多少次还是没成功则放弃(默认为4秒内发送3次,每次发消息默认超时间...
  • a417930422
  • a417930422
  • 2016-02-18 18:38
  • 4798

《RocketMq》四、Producer生产者

Producer的用途大家都很清楚,主要就是生产消息,那么分布式模式下与单队列模式不一样,如何能够充分利用分布式的优势,将生产的消息分布到不同的队列下呢?Rocket-MQ提供了3种不同模式的Producer: 1. NormalProducer 2. OrderProducer 3. Transa...
  • xxxxxx91116
  • xxxxxx91116
  • 2015-12-22 12:53
  • 5940
    个人资料
    • 访问:4036次
    • 积分:82
    • 等级:
    • 排名:千里之外
    • 原创:4篇
    • 转载:0篇
    • 译文:0篇
    • 评论:0条
    文章分类
    文章存档