java学习day97--RocketMQ工作原理

目录

RocketMQ 原理

Topic 基本原理

在Rocketmq集群(或单台主机)中新建 Topic1

在管理界面中新建主题Topic1,为了方便观察测试效果,这里把写队列读队列的数量都设置成3。

java学习day97--RocketMQ工作原理

这样,在 broker-a 和 broker-b 上都创建了 Topic1 主题,并各创建了3写3读队列,共6写6读,如下图所示:

java学习day97--RocketMQ工作原理
也可以修改Topic1分别配置 broker-a 和 borker-b 上的队列数量。

perm 参数的含义

perm 参数是设置队列的读写权限,下面表格列出了可配置的值及其含义:

取值 含义
6 同时开启读写
4 禁写
2 禁读

Topic 收发消息原理

java学习day97--RocketMQ工作原理
生产者将消息发送到 Topic1 的其中一个写队列,消费者从对应的一个读队列接收消息。

写队列中的消息会同步到读队列中

生产者的负载均衡

java学习day97--RocketMQ工作原理
生产者以轮询的方式向所有写队列发送消息,这些队列可能会分布在多个broker实例上。

消费者的负载均衡

一个 group 中的多个消费者,可以以负载均衡的方式来接收消息。

读取队列被均匀分配给这些消费者,它们从指定的队列来接收消息。队列的分配可以采用不同的策略,这里简略介绍以下三种策略:

AllocateMessageQueueAveragely 平均分配

这是默认策略,它是这样分配队列的:

java学习day97--RocketMQ工作原理

根据消费者的数量以及队列的数量进行平均分配,这样有可能会导致同一个消费者进行跨服务器消费数据。

AllocateMessageQueueAveragelyByCircle 环形分配

如果使用环形分配,在消费者的代码中需要设置分配策略,代码如下:

consumer.setAllocateMessageQueueStrategy(new AllocateMessageQueueAveragelyByCircle());

java学习day97--RocketMQ工作原理

根据在服务器中队列的索引进行分配,这种分配策略的逻辑很简单,所有0号队列分给0号消费者,所有1号队列分给1号消费者,以此类推。

AllocateMessageQueueConsistentHash 一致性哈希

如果使用一致性哈希算法进行分配,在消费者的代码中需要设置分配策略,代码如下:

consumer.setAllocateMessageQueueStrategy(new AllocateMessageQueueConsistentHash());

这种算法依靠一致性哈希算法,看当前消费者可以落到哪个虚拟节点,该虚拟节点对应哪个队列。

问题

思考一下,如果写队列比读队列多会怎样?反之会怎样?

如果写队列比读队列多的话,那么写队列中的数据就会一直不被消费,直到增加了队列的数量才可以消费

如果读队列比写队列多的话,那么消费者就会一直等待生产者生产数据,浪费资源

NameServer 基本原理

java学习day97--RocketMQ工作原理

NameServer 是 rocketmq 自己开发的一个轻型注册中心,他的作用相当于是 zk、eureka等。

rocketmq 为什么不使用 zk 呢?实际上 rocketmq 的早期版本使用的就是 zookeeper。

而 rocketmq 的架构设计决定了只需要一个轻量级的元数据服务器就足够了。

甚至,NameServer 都不需要有一个集群的管理者。以至于,NameServer 看起来都不像一个集群。事实上,NameServer 本质上来看,也不是一个集群。因为它的各个节点是独立的,不相关的。每个 NameServer 都是独立和 Producer、Consumer打交道。

基本认识

  1. NameServer主要用于存储Topic,Broker关系信息,功能简单,稳定性高。
  2. 各个NameServer节点之间不相关,不需要通信,单台宕机不影响其它节点。
  3. NameServer集群整体宕机不影响已建立关系的Concumer,Producer,Broker。

Broker、Producer、Consumer 与NameServer的通信

  1. 每个Borker和所有NameServer保持长连接,心跳间隔为30秒。每次心跳时还会携带当前的Topic信息。当某个Broker两分钟之内没有心跳,则认为该Broker下线,并调整内存中与该Broker相关的Topic信息。
  2. Consumer 从 NameServer 获得 Topic 的路由信息,与对应的 Broker 建立长连接。间隔30秒发送心跳至Broker。Broker检查若发现某 Consumer 两分钟内无心跳则认为该Consumer下线,并通知该Consumer所有的消费者集群中的其他实例,触发该消费者集群重新负载均衡。
  3. Producer 与消费者一样,也是从 NameServer 获得 Topic 的路由信息,与对应的 Broker 建立长连接,30秒发送一次心跳。Broker 也会认为两分钟内没有心跳的 Producer 下线。
上一篇:centos7搭建最新版RocketMQ(单机)


下一篇:使用yum安装软件时提示 cannot find a valid baseurl for repo:base/7/x86_64