RocketMQ (三) 基本原理

喜欢ヅ旅行 2023-02-25 02:30 11阅读 0赞

### 文章目录 ###

*  Topic 基本原理
 *   *  在Rocketmq集群中新建 Topic1
     *  perm 参数的含义
     *  Topic 收发消息原理
     *  生产者的负载均衡
     *  消费者的负载均衡
     *   *  AllocateMessageQueueAveragely 平均分配
         *  AllocateMessageQueueAveragelyByCircle 环形分配
         *  AllocateMessageQueueConsistentHash 一致性哈希
     *  问题
 *  NameServer 基本原理
 *   *  基本认识
     *  Broker、Producer、Consumer 与NameServer的通信

# Topic 基本原理 #

## 在Rocketmq集群中新建 Topic1 ##

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

![topic1][]

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

![topic1][topic1 1]  
*你也可以修改Topic1分别配置 broker-a 和 borker-b 上的队列数量。*

## perm 参数的含义 ##

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

<table> 
 <thead> 
  <tr> 
   <th>取值</th> 
   <th>含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>6</td> 
   <td>同时开启读写</td> 
  </tr> 
  <tr> 
   <td>4</td> 
   <td>禁写</td> 
  </tr> 
  <tr> 
   <td>2</td> 
   <td>禁读</td> 
  </tr> 
 </tbody> 
</table>

## Topic 收发消息原理 ##

![topic][]  
生产者将消息发送到 Topic1 的其中一个**写队列**，消费者从对应的一个**读队列**接收消息。

## 生产者的负载均衡 ##

![producer][]  
生产者以**轮询**的方式向所有写队列发送消息，这些队列可能会分布在多个broker实例上。

## 消费者的负载均衡 ##

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

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

### AllocateMessageQueueAveragely 平均分配 ###

这是默认策略，它是这样分配队列的：

![topic][topic 1]

### AllocateMessageQueueAveragelyByCircle 环形分配 ###

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

consumer.setAllocateMessageQueueStrategy(new AllocateMessageQueueAveragelyByCircle());

这种分配策略的逻辑很简单，所有0号队列分给0号消费者，所有1号队列分给1号消费者，以此类推。

![topic][topic 2]

### AllocateMessageQueueConsistentHash 一致性哈希 ###

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

consumer.setAllocateMessageQueueStrategy(new AllocateMessageQueueConsistentHash());

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

## 问题 ##

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

# NameServer 基本原理 #

![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 下线。

[topic1]: /images/20230209/ed0c353988d146ccb3dd971905759b40.png
[topic1 1]: /images/20230209/2c5de0df713144dfb44721078ec3023d.png
[topic]: /images/20230209/28b1d5d1c1a24a078c188dac9bd0a912.png
[producer]: /images/20230209/cc7e58a3c39848b4828e7f24cab9285c.png
[topic 1]: /images/20230209/ad9c0f1ca7314ea98b22d671904bba8c.png
[topic 2]: /images/20230209/b88920def68141be8def9b43a2d28f86.png
[rocketmq]: /images/20230209/c4f488df326946cf880d3b00789254f5.png