【RocketMQ】一、RocketMQ架构与范畴模型
0、MQ类比生存中的例子以坐火车类比MQ：
https://i-blog.csdnimg.cn/direct/9fd3063841f34033b1c80b8613d40773.png
安检大厅就像是一个系统的门面，继续来自四周八方且目标地差别的人流，并完成基础的安全校验。人来了，不是直接涌上火车，而是根据所乘坐的车次，到差别的候车厅等着，火车则是消费这些人，现实中是把他们拉到对应的地方，这个候车厅，就像MQ，而差别的车次走向差别的候车厅，则是“主题topic”这个概念的味道。
1、MQ异步通讯
https://i-blog.csdnimg.cn/direct/23ef86df1fcb45e5b0c2b855cd990dce.png
同步通讯下，每个哀求直接从调用方发送到被调用方，且要求被调用方立即返回响应结果给调用方，以便确定本次调用是否乐成。
https://i-blog.csdnimg.cn/direct/456e96c149724f7198e6192fb9c5f2ab.png
很显着，同步调用的方式有其毛病，比如网络波动或者下游服务不可用时，就会有问题：
https://i-blog.csdnimg.cn/direct/439a89f8f2c942c28d22d912db73a092.png
异步通讯下，调用方只需将哀求转换成异步时间（消息）发送给中心代理，发送乐成，即可为该异步链路调用完成。剩下的工作会有中心代理可靠地关照到下游的被调用系统，以确保任务执行完成。
https://i-blog.csdnimg.cn/direct/cb850493430949f79c4ddaeda3e6964c.png
这个中心代理，一样平常就是消息中心件。
https://i-blog.csdnimg.cn/direct/4fd6f904ab0040b7b0554f57e9bd5c3e.png
MQ的三大好处：
[*]解耦
[*]异步提速
[*]削峰填谷（留意和限流的区别，别简单理解成限流，准确的说，这里是整流）
劣势：
[*]系统复杂度提升
[*]系统可用性低沉（MQ宕机，影响上下游服务）
[*]一致性问题（A服务通过MQ给B、C、D服务发消息，结果B、C乐成消费消息，但D消费时出现了非常，如何保证数据一致性）
2、RocketMQ的背景
RocketMQ是阿里专为万亿级超大规模的消息处理而设计，具有高吞吐、低延迟、海量堆积、次序收发等特点，项目发展：
[*]2012年阿里开发Rocket MQ
[*]2015年庞大特性发布：事件消息、SQL过滤、轨迹追踪、定时消息
[*]2016年在阿里云托管，并捐赠给Apache
[*]2017年成为Apache的顶级项目
// apache的官网apache.org前，加上技术，如rocketmq
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集群的路由信息，从而举行消息的投递和消费
https://i-blog.csdnimg.cn/direct/3928c6cfaace4157af116bb83ba05ed0.png
组件或数据流说明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心跳，上报当前消费者实例信息 https://i-blog.csdnimg.cn/direct/7feeb3f7082d430cb75b49b907eb7daa.png
补充说明：
[*]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
https://i-blog.csdnimg.cn/direct/3c8d915f86c04e978610b517d9dc30ac.png
组件或数据流说明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 即可
https://i-blog.csdnimg.cn/direct/4c83d942354d49e3b564edec3b058120.png
4、RocketMQ 模型中的概念
消息生产者生产出消息，投递到对应的topic主题下的队列里面（一个topic下，有多个Message Queue），消费者组通过订阅主题，从RocketMQ 服务端中获取消息并消费。
https://i-blog.csdnimg.cn/direct/b6472450fc594b89b94249f4e93c2057.png
4.1 主题
[*]一个主题下有多个队列
[*]消息范例必须一致：比如创建主题时，消息范例为次序消息，却又发送事件消息到该主题，就会返回范例不匹配的非常（每种主题只支持一种消息范例）
[*]主题的拆分，可以根据业务和消息范例这两方面来思量
4.2 队列
[*]主题是一个逻辑概念，队列才是真正存储消息的
[*]所有乐成发送到队列的消息，默认做持久化
[*]生产者指定某个主题，向主题内发送消息，但现实消息发送到该主题下的某个队列中
[*]同一队列间的消息天然存在次序关系，头部最早，尾部最新
[*]消息在队列中的位置和消息之间的次序通过位点（Offset） 举行标志管理
[*]可以从恣意位点读取恣意数量的消息，以此实现类似聚合读取、回溯读取
4.3 消息
[*]默认对消息做持久化
[*]消息对象的属性有两类，生产者自己定义的 + Rocket MQ服务端自己生成并添补的
[*]生产者自己定义的属性有：所要投递到的主题名称、消息范例、消息负载body、索引Key列表、过滤标签tag、定时时间等
[*]Rocket MQ服务端自己生成并添补的属性有：现实存储当前消息的队列、消息位点offset、消息ID、消息重试次数
https://i-blog.csdnimg.cn/direct/cf45850fe10b4667b979ca009c384de5.png
4.4 生产者
https://i-blog.csdnimg.cn/direct/a79e1d7393e7464682252eb352cd3832.png
[*]同一个生产者可以向多个主题发送消息，并不需要创建多个生产者，同一个主题也可以接收多个生产者的消息
[*]生产者发送消息可以选择同步或者异步
[*]生产者可以选择批量发送消息
[*]不要频繁创建和销毁生产者（RocketMQ 的生产者是可以重复利用的底层资源，类似数据库的毗连池）
[*]失败重试和事件控制见后续
// 正确
Producer p = ProducerBuilder.build();
for (int i =0;i<n;i++){
Message m= MessageBuilder.build();
p.send(m);
}
p.shutdown();
// 错误
for (int i =0;i<n;i++){
Producer p = ProducerBuilder.build();
Message m= MessageBuilder.build();
p.send(m);
p.shutdown();
}
4.5 消费者分组
[*]一组消费逻辑一致的消费者
[*]通过消费者分组内初始化多个消费者实现消费性能的水平扩展
[*]Apache RocketMQ 以消费者分组的粒度来管理订阅关系
[*]Apache RocketMQ 的服务端将消息投递给消费者消费时，支持次序投递和并发投递，也是在消费者组中定义
[*]消费者消费消息失败时的重试策略，包罗重试次数、死信队列设置等，也是在消费者分组中定义
4.6 消费者
[*] 消费者必须关联一个指定的消费者分组，以获取分组内统一定义的行为配置和消费状态
[*] 消费者范例有：PushConsumer范例、SimpleConsumer范例、PullConsumer范例（仅推荐流处理场景利用）
[*] RocketMQ 的消费者是可以重复利用的底层资源，类似数据库的毗连池，所以不要频繁创建和销毁消费者
// 正确
Consumer c = ConsumerBuilder.build();
for (int i =0;i<n;i++){
Message m= c.receive();
//process message
}
c.shutdown();
// 错误
for (int i =0;i<n;i++){
Consumer c = ConsumerBuilder.build();
Message m= c.receive();
//process message
c.shutdown();
}
4.7 订阅关系
[*]订阅关系是针对消费者分组和主题来说的，不是单独的一个消费者
[*]如下，两个消费者分组都订阅了主题A，且两个分组要求的数据差别，一个要带Tag a，一个要带Tag b
https://i-blog.csdnimg.cn/direct/21f09ac0f7df41d280e131f2cfd39fd4.png
[*]如下，同一个消费者组，也可以订阅两个差别的主题
https://i-blog.csdnimg.cn/direct/b35efd0131be4557a15e08fb520f8afd.png
5、消息传输模型
5.1 点对点模型
[*]消费者和生产者之间，只认同一个队列
[*]即使消费者有多个，一条消息也只能被唯一一个消费者实例处理
https://i-blog.csdnimg.cn/direct/af09d3c7096e4b36a53407559e9394f3.png
5.2 发布订阅模型
[*]同一个主题内的消息，可以被多个订阅组消费
[*]每个订阅组都可以拿到全量消息
https://i-blog.csdnimg.cn/direct/80b0c047c21e488fbd572fbe2db4f097.png
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]