如何實現RocketMQ隊列queue的偏移量Offset均衡分布測試

191次閱讀

沒有評論

共計 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 均達到同一水平的情況。