一 机器部署

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、针对过多的消息堆积，可以选择丢弃不重要的消息，即仅仅记录日志，而不真正消费，以此保证消息的完整性，以此来特殊处理消息的堆积情况。