RocketMQ介绍

 消息队列是分布式系统中重要的组件，使用消息队列主要是为了经过异步处理提升系统性能和削峰、下降系统耦合性。Apache RocketMQ是由阿里巴巴开源的可支撑万亿级数据洪峰的分布式消息和流计算平台，于2016年捐赠给Apache Software Foundation，2017年9月25日成为Apache 顶级项目。因为其高稳定性、低延时、高吞吐量等特色，被大规模应用于金融、互联网、物流公司的核心交易支付、实时位置追踪、大数据分析等场景，同时也被电力、交通、汽车、零售等十几个行业的数万家企业普遍使用，是企业数字化转型的核心基础性软件。​

 网上对RocketMQ的介绍不少，还有中文开发者网站http://rocketmq.cloud/zh-cn/index.html，你们能够自行搜索。本章结合网上的各类介绍（内容均来自网上），只对相关的内容、概念进行说明，为后续文章作准备。

 工做中也比较多的接触RocketMQ，以前看过RocketMQ的源码，梳理过流程，可是没有输出文档。为此，这边将以RocketMQ 4.4.0版本为例，从新整理源码中相应的流程。

1. 整体架构

 以下为RocketMQ的整体架构：

这里涉及到的角色包括：

• NameServer:NameServer是一个很是简单的Topic路由注册中心，其角色相似Dubbo中的zookeeper，支持Broker的动态注册与发现。主要包括两个功能：

  • Broker管理，NameServer接受Broker集群的注册信息而且保存下来做为路由信息的基本数据。而后提供心跳检测机制，检查Broker是否还存活
  • 路由信息管理，每一个NameServer将保存关于Broker集群的整个路由信息和用于客户端查询的队列信息。而后Producer和Conumser经过NameServer就能够知道整个Broker集群的路由信息，从而进行消息的投递和消费。

NameServer一般也是集群的方式部署，各实例间相互不进行信息通信。Broker是向每一台NameServer注册本身的路由信息，因此每个NameServer实例上面都保存一份完整的路由信息。当某个NameServer因某种缘由下线了，Broker仍然能够向其它NameServer同步其路由信息，Producer,Consumer仍然能够动态感知Broker的路由的信息。

• Broker:Broker主要负责消息的存储、投递和查询以及服务高可用保证。Broker部署相对复杂，Broker分为Master与Slave，一个Master能够对应多个Slave，可是一个Slave只能对应一个Master，Master与Slave 的对应关系经过指定相同的BrokerName，不一样的BrokerId 来定义，BrokerId为0表示Master，非0表示Slave。Master也能够部署多个。每一个Broker与NameServer集群中的全部节点创建长链接，定时注册Topic信息到全部NameServer。

• Producer:消息发布的角色，支持分布式集群方式部署。

  • Producer经过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程支持快速失败而且低延迟。
  • Producer与NameServer集群中的其中一个节点（随机选择）创建长链接，按期从NameServer获取Topic路由信息，并向提供Topic 服务的Master创建长链接，且定时向Master发送心跳。Producer彻底无状态，可集群部署。
• Producer Group:一类 Producer 的集合名称，这类 Producer 一般发送一类消息，且消费逻辑一致。

• Consumer:消息消费的角色，支持分布式集群方式部署。支持以push推，pull拉两种模式对消息进行消费。同时也支持集群方式和广播方式的消费，它提供实时消息订阅机制，能够知足大多数用户的需求。

  • Consumer既能够从Master订阅消息，也能够从Slave订阅消息，消费者在向Master拉取消息时，Master服务器会根据拉取偏移量与最大偏移量的距离（判断是否读老消息，产生读I/O），以及从服务器是否可读等因素建议下一次是从Master仍是Slave拉取。
  • Consumer与NameServer集群中的其中一个节点（随机选择）创建长链接，按期从NameServer获取Topic路由信息，并向提供Topic服务的Master、Slave创建长链接，且定时向Master、Slave发送心跳。
• Consumer Group:一类 Consumer 的集合名称，这类 Consumer 一般消费一类消息，且消费逻辑一致。

2. 工做流程

结合部署架构图，描述集群工做流程：

• 启动NameServer，NameServer起来后监听端口，等待Broker、Producer、Consumer连上来，至关于一个路由控制中心。
• Broker启动，跟全部的NameServer保持长链接，定时发送心跳包。心跳包中包含当前Broker信息(IP+端口等)以及存储全部Topic信息。注册成功后，NameServer集群中就有Topic跟Broker的映射关系。
• 收发消息前，先建立Topic，建立Topic时须要指定该Topic要存储在哪些Broker上，也能够在发送消息时自动建立Topic。
• Producer发送消息，启动时先跟NameServer集群中的其中一台创建长链接，并从NameServer中获取当前发送的Topic存在哪些Broker上，轮询从队列列表中选择一个队列，而后与队列所在的Broker创建长链接从而向Broker发消息。
• Consumer跟Producer相似，跟其中一台NameServer创建长链接，获取当前订阅Topic存在哪些Broker上，而后直接跟Broker创建链接通道，开始消费消息。

 以下图示：

 Producer会向一些队列轮流发送消息，这些队列集合称为Topic。Consumer能够作广播消费，也能够作集群消费，若是作广播消费，则一个Consumer实例消费这个Topic对应的全部队列，若是作集群消费，则多个Consumer 实例平均消费这个Topic对应的队列集合。

 Topic是逻辑概念，对于RocketMQ，一个Topic能够分布在各个Broker上，把一个Topic分布在一个Broker上的子集定义为一个Topic分片，其实就是在某一broke上一个topic的部分数据

对应上图，TopicA有3个Topic分片，分布在Broker1,Broker2和Broker3上，TopicB有2个Topic分片，分布在Broker1和Broker2上，TopicC有2个Topic分片，分布在Broker2和Broker3上。

 将Topic分片再切分为若干等分，其中的一份就是一个Queue（队列）。每一个Topic分片等分的Queue的数量能够不一样，由用户在建立Topic时指定。每一个Topic分片等分的Queue的数量能够不一样，由用户在建立Topic时指定, 是消费负载均衡过程当中资源分配的基本单元。须要指出的是，在一个Consumer Group内，Queue和Consumer之间的对应关系是一对多的关系：一个Queue最多只能分配给一个Consumer，一个Cosumer能够分配获得多个Queue。这样的分配规则，每一个Queue只有一个消费者，能够避免消费过程当中的多线程处理和资源锁定，有效提升各Consumer消费的并行度和处理效率。便是负载均衡过程当中资源分配的基本单元，同Kafaka相同。

3. 消息

 消息(Message)是系统所传输信息的物理载体，生产和消费数据的最小单位，每条消息必须属于一个Topic。RocketMQ中每一个消息拥有惟一的Message ID，且能够携带具备业务标识的Key。系统提供了经过Message ID和Key查询消息的功能。

 能够为消息设置标志（Tag），用于同一Topic下区分不一样类型的消息。来自同一业务单元的消息，能够根据不一样业务目的在同一Topic下设置不一样标签。标签可以有效地保持代码的清晰度和连贯性，并优化RocketMQ提供的查询系统。消费者能够根据Tag实现对不一样子主题的不一样消费逻辑，实现更好的扩展性。

 消息的消费能够分为集群消费和广播消费

• 集群消费（Clustering）：集群消费模式下,相同Consumer Group的每一个Consumer实例平均分摊消息。
• 广播消费（Broadcasting）：广播消费模式下，相同Consumer Group的每一个Consumer实例都接收全量的消息。

更多原创内容请搜索微信公众号：啊驼（doubaotaizi）