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下线。
1万+
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
