1.前话
这个系列打算深入研究的是RocketMq
和Spring
集成开发时的一些原理,目的是为了后续在Spring
框架内如何更合理方便的使用RocketMq
,以达到后续可以为Spring
程序定制RocketMq
使用方法。
本系列只站在Producer
和Consumer
的角度来分析(可以简单理解成客户端交互)其与Spring
的开发原理和更合理的搭配Spring
使用,关于Broker
和NameServer
那些便不做过多的分析。
本文章主要介绍的是RocketMq
的一些基本概念,如消费者生产者和Broker
这些的含义,并且会介绍部署时每个角色的启动交互逻辑,看完这篇文章将会对NameServer
、BrokerServer
、Producer
和Consumer
这四个主要角色之间的通信数据交互关系有个大概的了解。
2.基本概念
- 消息生产者
Producer
:负责生产消息,一个消息生产者会把应用系统里产生的消息发送到broker
服务器。RocketMQ
提供多种发送方式,同步发送、异步发送、顺序发送、单向发送。同步和异步方式均需要Broker
返回确认信息,单向发送不需要; - 消息消费者
Consumer
:负责消费消息,一个消息消费者会从Broker
服务器拉取消息、并将其提供给应用程序。RocketMq
提供了两种消费形式:拉取式消费、推动式消费; - 主题
Topic
:表示一类消息的集合,每个主题包含若干条消息,每条消息只能属于一个主题,是RocketMQ
进行消息订阅的基本单位; - 标签
Tag
:为消息设置的标志,用于同一Topic
主题下区分不同类型的消息。 来自同一业务单元的消息,可以根据不同业务目的在同一主题下设置不同标签。 标签能够有效地优化RocketMQ
提供的查询系统; - 代理服务器
BrokerServer
:消息中转角色,负责存储消息、转发消息。代理服务器在RocketMQ
系统中负责接收从生产者发送来的消息并存储、同时为消费者的拉取请求作准备。代理服务器也存储消息相关的元数据,包括消费者组、消费进度偏移和主题和队列消息等; - 名字服务
NameServer
:名称服务充当路由消息的提供者。生产者或消费者能够通过名字服务查找各主题相应的Broker IP
列表。多个NameServer
实例组成集群,集群间相互独立,没有信息交换。
3.RocketMq架构
3.1 基本架构
既然要了解客户端如何使用,那么了解RocketMq
的的整体架构是必不可少的。技术架构图如下:
RocketMq
的架构角色分为四个部分:
Producer
:消息发布角色,支持分布式集群方式部署。Producer
通过MQ的负载均衡模块选择相应的Broker
集群队列进行消息投递,投递的过程支持快速失败并且低延迟;Consumer
:消息消费角色,支持分布式集群方式部署。支持以push
推,pull
拉两种模式对消息进行消费。同时也支持集群方式
和广播方式
的消费,它提供实时消息订阅机制,可以满足大多数用户的需求;NameServer
:一个非常简单的Topic
路由注册中心,其角色类似Dubbo
中的zookeeper
,支持Broker
的动态注册与发现。主要包括两个功能:Broker
管理,NameServer
接受Broker
集群的注册信息并且保存下来作为路由信息
的基本数据。然后提供心跳检测机制,检查Broker
是否还存活;路由信息
管理,每个NameServer
将保存关于Broker
集群的整个路由信息和用于客户端查询的队列信息。然后Producer
和Conumser
通过NameServer
就可以知道整个Broker
集群的路由信息,从而进行消息的投递和消费。
BrokerServer
:Broker
主要负责消息的存储、投递和查询以及服务高可用保证,为了实现这些功能,Broker
包含了以下几个重要子模块Remoting Module
:整个Broker
的实体,负责处理来自clients
端的请求;Client Manager
:负责管理客户端(Producer/Consumer
)和维护Consumer
的Topic
订阅信息;Store Service
:提供方便简单的API接口处理消息存储到物理硬盘和查询功能;HA Service
:高可用服务,提供Master Broker
和Slave Broker
之间的数据同步功能;Index Service
:根据特定的Message key
对投递到Broker的消息进行索引服务,以提供消息的快速查询。
具体Broker
模块图如下:
需要注意的是NameServer
通常也是集群的方式部署,各实例间相互不进行信息通讯。Broker
是向每一台NameServer
注册自己的路由信息,所以每一个NameServer
实例上面都保存一份完整的路由信息。当某个NameServer
因某种原因下线了,Broker
仍然可以向其它NameServer
同步其路由信息,Producer
,Consumer
仍然可以动态感知Broker
的路由的信息。
3.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
建立连接通道,开始消费消息。
RocketMq
网络部署特点:
NameServer
是一个几乎无状态节点,可集群部署,节点之间无任何信息同步;Broker
分为Master
与Slave
,一个Master
可以对应多个Slave
,但是一个Slave
只能对应一个Master
,Master
与Slave
的对应关系通过指定相同的BrokerName
,不同的BrokerId
来定义,BrokerId
为0表示Master
,非0表示Slave
。Master
也可以部署多个。每个Broker
与NameServer
集群中的所有节点建立长连接
,定时注册Topic
信息到所有NameServer
。 注:只有BrokerId=1的从服务器才会参与消息的读负载;Producer
与NameServer
集群中的其中一个节点(随机选择)建立长连接,定期从NameServer
获取Topic
路由信息,并向提供Topic
服务的Master
建立长连接,且定时向Master
发送心跳。Producer
完全无状态,可集群部署;Consumer
与NameServer
集群中的其中一个节点(随机选择)建立长连接,定期从NameServer
获取Topic
路由信息,并向提供Topic
服务的Master
、Slave
建立长连接,且定时向Master
、Slave
发送心跳。Consumer
既可以从Master
订阅消息,也可以从Slave
订阅消息,消费者在向Master
拉取消息时,Master
服务器会根据拉取偏移量与最大偏移量的距离(判断是否读老消息,产生读I/O),以及从服务器是否可读等因素建议下一次是从Master
还是Slave
拉取。
本文章取自RocketMq官方github中文文档Apache RocketMq中文文档。