如何實現Rocketmq集群消費測試

小編給大家分享一下如何實現Rocketmq集群消費測試，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

一 機器部署

1、機器組成

7臺機器，均為16G內存

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

2、運行環境配置

3、刷盤方式

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

二 性能評測

1、評測目的

   測試consumer端的集群模式消費。

2、評測指標

    （1）topic關聯的readQueueNums讀隊列數值

    （2）屬于同一個consumerGroup的consumer個數

    （3）所有consumer消費消息的總條數

    （4）每個consumer消費消息，讀取的隊列Id

    （5）部署集群中的master機器臺數

3、評測邏輯

  如果有 5 個隊列，2 個 consumer，那么第一個 Consumer 消費 3 個隊列，第二 consumer 消費 2 個隊列。

    如果Consumer 超過隊列數量，那么多余的Consumer 將不能消費消息。

    隊列數量、Consumer數量、Replance結果如下表

4、評測過程

       （1）發送消息前，查看服務端的topic關聯的隊列個數。

       （2）producer端向topic名稱為“clusterTopicTest”隊列發送消息，定為20條，發送消息后并記錄每條消息的msgId、queueId、offset等基本信息。

    （3）配置consumer端，日志記錄每個consumer端的instanceName、消息的offset、所消費隊列queueId、消息的body、消息msgId，以及每個consumer消費消息的總條數。

    （4）每次消費完之后，統計所有consumer端消費消息的總數，判斷消息是否有丟失。

    （5）每次消費完之后，分析每個consumer消費隊列的queueId，判斷隊列是否達到了負載均衡。

    （6）記topic的隊列數為A，記consumer個數為B，做如下調整：

    第一組：保持A不變，增加B，使得A > B，然后重復步驟1-5。

    第二組：保持A不變，增加B，使得A = B，然后重復步驟1-5。

    第三組：保持A不變，增加B，使得A = 2 * B，然后重復步驟1-5。

    第三組：增加A，保持B不變，使得2 * A = B，然后重復步驟1-5。

    第五組：減少A，保持B不變，使得2 * A < B，然后重復步驟1-5。

    （7）注意：需要先啟動所有consumer端，在啟動producer端發送消息，這樣才能在每個consumer端同時看到消息的消費情況，因為消息被消費的速率是很快的。

    （8）注意：master機器個數，每臺master機器上指定topic的隊列數，兩數值相乘，才是最終的rocketmq做負載均衡的隊列個數。 （步驟6的master機器個數為2）

    第一組，總發送條數20條

    3個consumer消費消息總條數：8+3+3+3+3 = 20條

    2臺master機器，每個topic有8個隊列， 期望的隊列個數 2*8=16個，實際的隊列個數 4+3+3+3+3 = 16個，可以看出期望、實際的queue分布是相同的結果。

    producer的發送記錄：

    consumer1的消費記錄：

    consumer2的消費記錄：

    consumer3的消費記錄：

    consumer4的消費記錄：

    consumer5的消費記錄：

    第二組，總發送條數20條

    8個consumer消費消息總條數：8+3+3+3+3 = 20條

    2臺master機器，每個topic有8個隊列， 期望的隊列個數 2*8=16個，實際的隊列個數 2+2+2+2+2+2+2+2 = 16個，可以看出期望、實際的queue分布是相同的結果。

    8個consumer消費消息總條數：4+2+2+2+2+2+4+2+2 = 20條

    producer的發送記錄：

    consumer1的消費記錄：

    consumer2的消費記錄：

    consumer3的消費記錄：

    consumer4的消費記錄：

    consumer5的消費記錄：

    consumer6的消費記錄：

    consumer7的消費記錄：

    consumer8的消費記錄：

第三組，總發送條數20條

    8個consumer消費消息總條數：8+3+3+3+3 = 20條

    2臺master機器，每個topic有8個隊列， 期望的隊列個數 2*8=16個，實際的隊列個數 4+4+4+4 = 16個，可以看出期望、實際的queue分布是相同的結果。

    8個consumer消費消息總條數：8+4+4+4 = 20條

    producer的發送記錄：

    consumer1的消費記錄：

    consumer2的消費記錄：

    consumer3的消費記錄：

    consumer4的消費記錄：

第四組，總發送條數20條

    8個consumer消費消息總條數：8+3+3+3+3 = 20條

    2臺master機器，每個topic有8個隊列， 期望的隊列個數 2*4=8個，實際的隊列個數 1+1+1+1+1+1+1+1= 8個，可以看出期望、實際的queue分布是相同的結果。

    8個consumer消費消息總條數：3+3+2+2+2+2+3+3 = 20條

    producer的發送記錄：

    consumer1的消費記錄：

    consumer2的消費記錄：

    consumer3的消費記錄：

    consumer4的消費記錄：

    consumer5的消費記錄：

    consumer6的消費記錄：

    consumer7的消費記錄：

    consumer8的消費記錄：

第五組，總發送條數20條

    8個consumer消費消息總條數：8+3+3+3+3 = 20條

    2臺master機器，每個topic有8個隊列， 期望的隊列個數 2*3=6個，實際的隊列個數 1+1+1+1+1+1+0 = 6個，可以看出期望、實際的queue分布是相同的結果。

    8個consumer消費消息總條數：3+4+3+3+4+3+0 = 20條

    producer的發送記錄：

    consumer1的消費記錄：

    consumer2的消費記錄：

    consumer3的消費記錄：

    consumer4的消費記錄：

    consumer5的消費記錄：

    consumer6的消費記錄：

    consumer7的消費記錄：

二 評測結果

    1、rocketmq集群消費模式，訂閱消息的確達到了隊列負載均衡，與這種負載均衡消費相關的因素有： master機器個數、 特定topic的queue個數，這兩個數值相乘，才是rocketmq最終計算隊列的總數。

    2、rocketmq的集群消費能力，保證消息準確性，完整性，所有被消費的消息總數與producer端發送的消息總數是一致的，不存在消息丟棄的情況。

    3、分析consumer消費日志，說明每條消息在相同consumerGroup組的不同consumer端中僅僅只會被消費一次。

    4、在集群消費模式下，如果consumer的總數，超過了隊列總數，那么多余的consumer端將不能消費消息。

以上是“如何實現Rocketmq集群消費測試”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！