【RocketMQ】一、RocketMQ架构与范畴模型

0、MQ类比生存中的例子

以坐火车类比MQ：

安检大厅就像是一个系统的门面，继续来自四周八方且目标地差别的人流，并完成基础的安全校验。人来了，不是直接涌上火车，而是根据所乘坐的车次，到差别的候车厅等着，火车则是消费这些人，现实中是把他们拉到对应的地方，这个候车厅，就像MQ，而差别的车次走向差别的候车厅，则是“主题topic”这个概念的味道。
1、MQ异步通讯

同步通讯下，每个哀求直接从调用方发送到被调用方，且要求被调用方立即返回响应结果给调用方，以便确定本次调用是否乐成。

很显着，同步调用的方式有其毛病，比如网络波动或者下游服务不可用时，就会有问题：

异步通讯下，调用方只需将哀求转换成异步时间（消息）发送给中心代理，发送乐成，即可为该异步链路调用完成。剩下的工作会有中心代理可靠地关照到下游的被调用系统，以确保任务执行完成。

这个中心代理，一样平常就是消息中心件。

MQ的三大好处：

• 解耦
  
• 异步提速
  
• 削峰填谷（留意和限流的区别，别简单理解成限流，准确的说，这里是整流）
  

劣势：

• 系统复杂度提升
  
• 系统可用性低沉（MQ宕机，影响上下游服务）
  
• 一致性问题（A服务通过MQ给B、C、D服务发消息，结果B、C乐成消费消息，但D消费时出现了非常，如何保证数据一致性）
  

2、RocketMQ的背景

RocketMQ是阿里专为万亿级超大规模的消息处理而设计，具有高吞吐、低延迟、海量堆积、次序收发等特点，项目发展：

• 2012年阿里开发Rocket MQ
  
• 2015年庞大特性发布：事件消息、SQL过滤、轨迹追踪、定时消息
  
• 2016年在阿里云托管，并捐赠给Apache
  
• 2017年成为Apache的顶级项目
  

1. // apache的官网apache.org前，加上技术，如rocketmq
2. https://rocketmq.apache.org

复制代码

3、RocketMQ的架构

3.1 RocketMQ4.x版本

•   MQ上下游，分别是消息的生产者、消息的消费者
  
•   Broker，翻译，经纪人，干活儿的，负责盘算和存储
  
•   如果Broker有多个实例，或者部署在多台服务器上时，它们之间如何互相知道对方的存在 ⇒ NameServer
  
•   NameServer，命名服务器，负责Topic 路由注册中心，支持 Topic、Broker 的动态注册与发现
  

   Name Server的作用：
  

• NameServer继续Broker集群的注册信息并且保存下来作为路由信息的基本数据，然后提供心跳检测机制，查抄Broker是否还存活
  
• 每个NameServer将保存关于 Broker 集群的整个路由信息，Producer和Consumer通过Nameserver就可以知道整个Broker集群的路由信息，从而举行消息的投递和消费
  

  

组件或数据流说明Namesrver无状态服务，负责保存Topic路由信息
Topic路由信息=topic-queue-brokerBroker有状态服务，处理盘算和存储
盘算 = 处理生产者哀求，消费者哀求，管理哀求，Broker系统服务（比如索引构建服务，消息过期服务）
存储 = 消息存储，索引存储Broker -> NamesrverBroker定期把Broker信息+当前Broker中的Topic信息上报Namesrver生产者生产消息生产者<-> Namesrver生产者从Namesrver获取Topic路由信息，包罗Broker IP生产者<-> Broker生产者通过Topic路由信息，把消息直接发送给对应的Broker实例
生产者定期和Broker心跳，上报当前生产者实例信息消费者消费消息消费者<-> Namesrver消费者从Namesrver获取Topic路由信息， 包罗Broker IP消费者 <-> Broker消费者通过Topic路由信息，从指定Broker中拉取消息消费
消费者定期和Broker心跳，上报当前消费者实例信息

补充说明：

• NameServer无状态，是指各个NameServer实例之间不需举行通讯，Broker是向每一台Nameserver注册自己的路由信息，即每个NameServer实例上都有一份完备的路由信息，如许，即使某个实例挂了，也不影响生产者或者消费者获取broker路由信息
  
• Broker向NameServer注册的Topic路由信息，是Topic- queue- broker三部分，即主题信息、每个topic下的队列的属性信息（比如队列数量）、broker的IP信息
  
• 生产者发消息时，需要知道它这个topic要往哪个broker发，因此，生产者与NameServer 集群的此中一个节点建立长毗连，定期从 NameServer 获取Topic路由信息，并向提供对应Topic 服务的 Broker实例建立长毗连，且定时向该 Broker实例发送心跳
  
• 消费者与NameServer的关系，也是一样
  

3.2 RocketMQ5.0版本

相比4.x，5.0版本：

• 引入了Controller 组件，负责Broker的故障转移（Master选举）
  
• 引入了Proxy组件，无状态服务，充当了客户端与 Broker 之间的中介，处理客户端哀求并转发到相应的 Broker
  

组件或数据流说明Namesrver无状态服务，负责保存Topic路由信息
Topic路由信息=topic-queue-broker
在5.0.0时，Nameserver历程中可以嵌入Controller模块，若设置enableControllerInNamesrv=true，在Nameserver历程中嵌入启动一个Controller实例Broker有状态服务，处理盘算和存储
盘算 = 处理生产者哀求，消费者哀求，管理哀求，Broker系统服务（比如索引构建服务，消息过期服务）
存储 = 消息存储，索引存储

在5.0.0时， Broker支持主从切换，Broker的脚色包罗：master，slave，learner
若设置asyncLearner=true，则Broker为learner，只同步数据， 不到场选举masterBroker -> NamesrverBroker定期把Broker信息+当前Broker中的Topic信息上报NamesrverTCP生产者生产消息TCP生产者<-> Namesrver生产者从Namesrver获取Topic路由信息，包罗Broker IPTCP生产者<-> Broker生产者通过Topic路由信息，把消息直接发送给对应的Broker实例
生产者定期和Broker心跳，上报当前生产者实例信息TCP消费者消费消息TCP消费者<-> Namesrver消费者从Namesrver获取Topic路由信息， 包罗Broker IPTCP消费者 <-> Broker消费者通过Topic路由信息，从指定Broker中拉取消息消费
消费者定期和Broker心跳，上报当前消费者实例信息Controller(控制器)5.0.0新增，负责Broker Master的选举并将结果关照BrokerBroker <-> ControllerBroker定期把Broker信息上报Controller
Controller选举新的Broker Master后，关照全部BrokerProxy5.0.0新增，无状态服务，新客户端通过Grpc接口访问Proxy举行收发消息
Proxy中支持嵌入Broker
若设置proxyMode=LOCAL，则会在Proxy历程中启动一个Broker实例Proxy <-> Broker5.0.0新增，Proxy通过Remoting协议和Broker通讯，可以把Proxy当作一个Remoting的ClientProxy <-> NamesrverProxy 通过 NameServer 获取 Broker 的元数据信息，将哀求路由到适当的 Broker新Client5.0.0新增，新客户端，目前支持Grpc协议新Client <-> Proxy新客户端访问Proxy举行收发消息 补充：

• Proxy用于扩展消息代理服务器的性能和容量， Proxy 可以将消息路由到多个 Broker 上，以实现负载均衡和容错，Proxy 还提供了一些接口，如队列管理、消费者管理、配置管理等，供新的客户端利用
  
• RocketMQ 5.x版本有两种部署模式：
  
• 在 Local 模式下，Broker 和 Proxy 是同历程部署，只是在原有 Broker 的配置基础上新增 Proxy 的浅易配置就可以运行，Local模式下 Broker 和 Proxy之间的通讯属于历程间通讯，性能比力好，响应时间比力短
  
• 在 Cluster 模式下，Broker 和 Proxy 分别部署，即在原有的集群基础上，额外再部署 Proxy 即可
  

4、RocketMQ 模型中的概念

消息生产者生产出消息，投递到对应的topic主题下的队列里面（一个topic下，有多个Message Queue），消费者组通过订阅主题，从RocketMQ 服务端中获取消息并消费。

4.1 主题

• 一个主题下有多个队列
  
• 消息范例必须一致：比如创建主题时，消息范例为次序消息，却又发送事件消息到该主题，就会返回范例不匹配的非常（每种主题只支持一种消息范例）
  
• 主题的拆分，可以根据业务和消息范例这两方面来思量
  

4.2 队列

• 主题是一个逻辑概念，队列才是真正存储消息的
  
• 所有乐成发送到队列的消息，默认做持久化
  
• 生产者指定某个主题，向主题内发送消息，但现实消息发送到该主题下的某个队列中
  
• 同一队列间的消息天然存在次序关系，头部最早，尾部最新
  
• 消息在队列中的位置和消息之间的次序通过位点（Offset） 举行标志管理
  
• 可以从恣意位点读取恣意数量的消息，以此实现类似聚合读取、回溯读取
  

4.3 消息

• 默认对消息做持久化
  
• 消息对象的属性有两类，生产者自己定义的 + Rocket MQ服务端自己生成并添补的
  
• 生产者自己定义的属性有：所要投递到的主题名称、消息范例、消息负载body、索引Key列表、过滤标签tag、定时时间等
  
• Rocket MQ服务端自己生成并添补的属性有：现实存储当前消息的队列、消息位点offset、消息ID、消息重试次数
  

4.4 生产者

• 同一个生产者可以向多个主题发送消息，并不需要创建多个生产者，同一个主题也可以接收多个生产者的消息
  
• 生产者发送消息可以选择同步或者异步
  
• 生产者可以选择批量发送消息
  
• 不要频繁创建和销毁生产者（RocketMQ 的生产者是可以重复利用的底层资源，类似数据库的毗连池）
  
• 失败重试和事件控制见后续
  

1. // 正确
2. Producer p = ProducerBuilder.build();
3. for (int i =0;i<n;i++){
4.     Message m= MessageBuilder.build();
5.     p.send(m);
6. }
7. p.shutdown();
9. // 错误
10. for (int i =0;i<n;i++){
11.     Producer p = ProducerBuilder.build();
12.     Message m= MessageBuilder.build();
13.     p.send(m);
14.     p.shutdown();
15. }

复制代码

4.5 消费者分组

• 一组消费逻辑一致的消费者
  
• 通过消费者分组内初始化多个消费者实现消费性能的水平扩展
  
• Apache RocketMQ 以消费者分组的粒度来管理订阅关系
  
• Apache RocketMQ 的服务端将消息投递给消费者消费时，支持次序投递和并发投递，也是在消费者组中定义
  
• 消费者消费消息失败时的重试策略，包罗重试次数、死信队列设置等，也是在消费者分组中定义
  

4.6 消费者

• 消费者必须关联一个指定的消费者分组，以获取分组内统一定义的行为配置和消费状态
  
• 消费者范例有：PushConsumer范例、SimpleConsumer范例、PullConsumer范例（仅推荐流处理场景利用）
  
• RocketMQ 的消费者是可以重复利用的底层资源，类似数据库的毗连池，所以不要频繁创建和销毁消费者
  

1. // 正确
2. Consumer c = ConsumerBuilder.build();
3. for (int i =0;i<n;i++){
4.       Message m= c.receive();
5.       //process message
6.     }
7. c.shutdown();
9. // 错误
10. for (int i =0;i<n;i++){
11.     Consumer c = ConsumerBuilder.build();
12.     Message m= c.receive();
13.     //process message
14.     c.shutdown();
15. }

复制代码

4.7 订阅关系

• 订阅关系是针对消费者分组和主题来说的，不是单独的一个消费者
  
• 如下，两个消费者分组都订阅了主题A，且两个分组要求的数据差别，一个要带Tag a，一个要带Tag b
  

• 如下，同一个消费者组，也可以订阅两个差别的主题
  

5、消息传输模型

5.1 点对点模型

• 消费者和生产者之间，只认同一个队列
  
• 即使消费者有多个，一条消息也只能被唯一一个消费者实例处理
  
  
  
  

5.2 发布订阅模型

• 同一个主题内的消息，可以被多个订阅组消费
  
• 每个订阅组都可以拿到全量消息
  
  
  
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。