1.Topic
基本原理
1.1 在Rocketmq
集群中新建 Topic1
在管理界面中新建主题Topic1
,为了方便观察测试效果,这里把写队列和读队列的数量都设置成3
。
这样,在 broker-a
和 broker-b
上都创建了 Topic1
主题,并各创建了3
写3
读队列,共6
写6
读,如下图所示:
你也可以修改Topic1
分别配置 broker-a
和 borker-b
上的队列数量。
1.2 perm
参数的含义
perm
参数是设置队列的读写权限,下面表格列出了可配置的值及其含义:
取值 | 含义 |
---|---|
6 | 同时开启读写 |
4 | 禁写 |
2 | 禁读 |
1.3 Topic
收发消息原理
生产者将消息发送到 Topic1
的其中一个写队列,消费者从对应的一个读队列接收消息。
1.4 生产者的负载均衡
生产者以轮询的方式向所有写队列发送消息,这些队列可能会分布在多个broker
实例上。并且读写队列是一一对应的,写队列1只会发消息给读队列1,而不是给其他读队列;
1.5 消费者的负载均衡
一个 group
中的多个消费者,可以以负载均衡的方式来接收消息。
读取队列被均匀分配给这些消费者,它们从指定的队列来接收消息。队列的分配可以采用不同的策略,这里简略介绍以下三种策略:
2. AllocateMessageQueueAveragely 策略
2.1 AllocateMessageQueueAveragely 平均分配
平均分配是Topic的默认策略,在俩台服务器中,各有三个写队列,3个读队列,共6个读写队列,平均分配策略在消息发送到Topic时,会轮询给6个读写队列发送消息,Topic接收消息后,也会已轮询的方式平均发送给3个消费者;
但是如果消息共发送了7条,共6个读写队列,那么Topic1的队列1会接收到2条消息,而其他队列都只接收到1条消息,并且消费者1接收到了3条消息,其他消费者只接收了2条消息,所以其平均分配也只是相对来说;
但是其也有一个弊端,如果broker-b宕机,那么相对应的消息也全都会丢失,并不会转发到broker-a去进行转发;
2.2 AllocateMessageQueueAveragelyByCircle 环形分配
如果使用环形分配,需要调用consumer
对象,在消费者的代码中需要设置分配策略,代码如下:
consumer.setAllocateMessageQueueStrategy(new AllocateMessageQueueAveragelyByCircle());
这种分配策略的逻辑很简单,其通过下标进行分配;所有0号队列分给0号消费者,所有1号队列分给1号消费者,以此类推。
此时当有服务器宕机的话,就不会存在消费者收不到消息的情况,还会有其他服务器给相应的消费者发送消息;但是如果一个Topic只有3个队列时,如果有4个消费者,那么第4个消费者并不会接收到任何消息,三个队列都有自己固定的消费者,此时需要增加一个队列,才可以让第4个消费者接收到消息;
2.3 AllocateMessageQueueConsistentHash 一致性哈希
如果使用一致性哈希算法进行分配,需要调用consumer
对象,在消费者的代码中需要设置分配策略,代码如下:
consumer.setAllocateMessageQueueStrategy(new AllocateMessageQueueConsistentHash());
这种算法依靠一致性哈希算法,看当前消费者可以落到哪个虚拟节点,该虚拟节点对应哪个队列。
2.4 问题
思考一下,如果写队列比读队列多会怎样?反之会怎样?
3.NameServer
基本原理
NameServer
是 rocketmq
自己开发的一个轻型注册中心,他的作用相当于是 zk
、eureka
等。
rocketmq
为什么不使用 zk
呢?实际上 rocketmq
的早期版本使用的就是 zookeeper`。
而 rocketmq
的架构设计决定了只需要一个轻量级的元数据服务器就足够了。杀鸡焉用牛刀?小区里,搞个货架就行了,建个仓库,又占地方,维护成本又高。
甚至,NameServer
都不需要有一个集群的管理者。以至于,NameServer
看起来都不像一个集群。事实上,NameServer
本质上来看,也不是一个集群。因为它的各个节点是独立的,不相关的。每个 NameServer
都是独立和 Producer
、Consumer
打交道。
3.1 基本认识
NameServer
主要用于存储Topic
,Broker
关系信息,功能简单,稳定性高。- 各个
NameServer
节点之间不相关,不需要通信,单台宕机不影响其它节点。 NameServer
集群整体宕机不影响已建立关系的Concumer
,Producer
,Broker
。
3.2 Broker
、Producer
、Consumer
与NameServer
的通信
- 每个
Borker
和所有NameServer
保持长连接,心跳间隔为30秒
。每次心跳时还会携带当前的Topic信息
。当某个Broker
两分钟之内没有心跳,则认为该Broker下线
,并调整内存中与该Broker
相关的Topic信息
。 Consumer
从NameServer
获得Topic
的路由信息,与对应的Broker
建立长连接。间隔30秒
发送心跳至Broker
。Broker
检查若发现某Consumer
两分钟
内无心跳则认为该Consumer下线
,并通知该Consumer
所有的消费者集群中的其他实例,触发该消费者集群重新负载均衡。Producer
与消费者一样,也是从NameServer
获得Topic
的路由信息,与对应的Broker
建立长连接,30秒
发送一次心跳。Broker
也会认为两分钟内
没有心跳的Producer
下线。