如何实现RocketMQ队列queue的偏移量Offset均衡分布测试

141次阅读

没有评论

共计 2155 个字符，预计需要花费 6 分钟才能阅读完成。

这篇文章给大家分享的是有关如何实现 RocketMQ 队列 queue 的偏移量 Offset 均衡分布测试的内容。丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，一起跟随丸趣 TV 小编过来看看吧。

一机器部署

1、机器组成

7 台机器，均为 16G 内存

每台服务器均有 4 个 CPU，2 核

2、运行环境配置

3、刷盘方式

每台机器 master 机器均采用异步刷盘方式

二性能评测

1、评测目的

测试 queue 接受消息负载均衡

2、评测指标

每个 queue 的接受消息后，其偏移量 offset 大致相同

3、评测逻辑

创建 topic，并配置该 topic 下的 queue 数量（3，5，8，16），发送消息后打印该条消息对应的 offset，比对消息 offset 增加量

4、评测过程

（1）在 master 机器上创建名称为“topicQueueOffsetTest”

（2）控制台创建的 topic 配置文件保存在 store 目录，查看 /root/store/config/topic.json 文件，即可找到该 topic 的原始数据

（3）client 端开启 5 个线程，发送不同数量的消息，发送消息后记录消息在各队列 queue 的 offset

queue 配置的是默认值 8，发送的消息条数 5*50=250 条消息

queue 配置的是默认值 8，发送的消息条数 5*400=2000 条消息

客户端设置 queue 队列数为 12，再次发送的消息条数 5*400=2000 条消息，并记录消息的 offset，关键代码如下

此处日志显示的 queueNum=12, 是指的 client 端的 producer 获取的 queue 个数，但此时后续的日志显示，server 端的 queueID 依然是 0 -7，总共 8 个，两种 queue 的个数并不相等。

说明在 producer 发送消息时，对于此前已运行的 borker 服务器，修改配置文件的 defaultTopicQueueNums 属性的值不起作用，需要重启服务才能使得已运行的 topic 的 queue 个数真正生效。

有两种方式，可动态更改 topic 以及 topic 相关的属性，

第一种、编辑 master 机器的 /root/store/config/topic.json 文件，找到 topic 名称为 topicQueueOffsetCheck 的数据，更新其 readQueueNums、writeQueueNums 两个属性，并重启 master 集群和 slave 集群

第二种方式：在 rocketmq 控制台动态更新 topic 相关数据 (此方式更改后，会自动同步 topic 数据到其他 master、其他 slave，可以不用重启 master、slave 服务)，此处我采用的是第二种方式更新。

更新 server 端的 queue 为 12，再次发送 2000 条消息，发现新旧两种队列的消息 offset 基本已达到均衡。

queueId 为 0 - 7 的队列，消息较多，各个队列的消息 offset 几乎相同，消息负载平衡；

queueId 为 8 -11 的队列，消息较少，是为新增的 4 个队列，这四个队列之间的 offset 也基本达到了平衡。

纵观这 12 个队列保存的消息， queueId= 0 的队列，上一次的 offset 偏移量为 508，本次 offset=594，差值 594-508=86，其余 quereId 的消息差异量也基本在 83 左右。说明动态更新 queueNums，水平扩容之后， queue 队列在接受到消息后任能够均衡存储消息。

从此例分析出：queue 收到的消息均衡分布，指的是每个 queue 每次收到消息的增加量能达到均衡；并不是指扩容后新增的 queue 队列的 offset 需要从 0 增加到原有队列的 offset，而原有 queue 需等待直至所有 queue 的消息偏移量 offset 均达到同一水平的情况。