RocketMQ中怎么判斷消息堆積

這期內容當中小編將會給大家帶來有關RocketMQ中怎么判斷消息堆積，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

一 機器部署

1、機器組成

7臺機器，均為16G內存  

每臺服務器均有4個CPU，2核

2、運行環境配置

3、刷盤方式

每臺機器master機器均采用異步刷盤方式

二 性能評測

1、評測目的

   測試rocketmq是否存在消息堆積場景。

2、評測指標

    producer發送消息的maxOffset與consumer消費消息的currOffset的差異值

    給定的常量消息堆積數值。

3、評測邏輯

  若消息offset的差異值 大于 常量堆積數值，則認為存在消息堆積的情況。

    反之則不存在消息堆積。

4、評測過程

       （1）producer端向topic名稱為“orderTopicTest”的隊列發送海量消息，定為40000條。

    （2）consumer端訂閱特定名稱的topic，并進行消費。每次消費消息，記錄當前消息的Offset；并根據“MAX_OFFSET”關鍵字，從當前消息對象獲取消息最大偏移量的屬性值，然后計算偏移量MAX_OFFSET與offset的差異值。關鍵代碼如下：

（3）發送消息，記錄發送的消息及其相關日志。

      如果消息偏移量offset的差異值 大于 給定的消息堆積個數值，則記錄日志，說明存在消息堆積的情況。反之則不存在消息堆積。產生的日志如下

   （4）消息堆積處理

    從日志看出，因producer端先運行了好一會兒，已經產生了741個消息擠壓；

    隨著consumer消費服務開啟，消息一邊產生，一邊消費，整體來說消息消費的速率高于消息產生的速率，所以消息offset的差異值在不斷的減少，故第二個截圖的情況存在：消息offset的差異值小于閾值100，所以存在正常消費與消息堆積的混合情況。

    consumer繼續消費消息，producer產生消息的速率跟不上consumer的消費速率，故第三圖就已經是正常消息消費了，即此時的消息堆積的那一部分消息已被消費。

    （5）注意事項

    rocketmq官網文檔指出，集群在有Slave情況下，Master一旦發現Consumer訪問堆積在磁盤的數據時，訪問堆積在磁盤的數據時，回向consumer下達一個指令，命令consumer從slave拉取數據，這樣使得正常發消息的consumer與正常消費消息的consumer都不會收到影響。

   此種情況前提：

    A）集群存在salve機器

    B）consumer存在消息堆積

    C）consumer因某種原因訪問磁盤數據（而非訪問pageCache等內存數據）

    這種情況的場景要求苛刻，需要在高并發的場景下才可能出現；此外，生產環境的集群配置，出現消息堆積的情況，還有可能是受到磁盤大小、網絡因素等等原因，本次測試并未深入到此場景，留待后續進一步測試。

二 評測結果

     1、消息堆積是一個相對值，針對consumer消費消息，某個topic隊列中最大的maxOffset與當前消費消息的currOffset的差異值，大于某個特定的閾值，才會出現消息堆積。

    2、當發送消息高于消息消費的速率，則可能出現消息堆積。

    3、其他條件保存正常水平，存在消息堆積的那一部分消息會隨著時間不斷減少直至消息被消費。

    4、針對過多的消息堆積，可以選擇丟棄不重要的消息，即僅僅記錄日志，而不真正消費，以此保證消息的完整性，以此來特殊處理消息的堆積情況。

上述就是小編為大家分享的RocketMQ中怎么判斷消息堆積了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。