RocketMQ消息堆积判断

 

一 机器部署

1、机器组成

7台机器,均为16G内存  

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

25155619_aMyu.jpg

 

2、运行环境配置

25155619_z4uN.jpg

3、刷盘方式

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

25155619_RDy9.jpg

 

25155619_g5Cg.jpg

 

 

 

二 性能评测

1、评测目的

   测试rocketmq是否存在消息堆积场景。

  

2、评测指标

    producer发送消息的maxOffset与consumer消费消息的currOffset的差异值

    给定的常量消息堆积数值。

   

3、评测逻辑

  若消息offset的差异值 大于 常量堆积数值,则认为存在消息堆积的情况。

    反之则不存在消息堆积。

  

  

4、评测过程

       (1)producer端向topic名称为“orderTopicTest”的队列发送海量消息,定为40000条。

    (2)consumer端订阅特定名称的topic,并进行消费。每次消费消息,记录当前消息的Offset;并根据“MAX_OFFSET”关键字,从当前消息对象获取消息最大偏移量的属性值,然后计算偏移量MAX_OFFSET与offset的差异值。关键代码如下:

25155620_GtRI.jpg

 

(3)发送消息,记录发送的消息及其相关日志。

      如果消息偏移量offset的差异值 大于 给定的消息堆积个数值,则记录日志,说明存在消息堆积的情况。反之则不存在消息堆积。产生的日志如下

25155620_yjBL.jpg

 

25155620_1A5V.jpg

 

25155620_yWUp.jpg

 

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

转载于:https://my.oschina.net/tantexian/blog/703800

<think>好的,我需要回答用户关于RocketMQ延时消息实现机制的问题。根据用户提供的引用资料,我需要整理出相关的原理和方法,并确保符合格式要求。 首先,用户提供的四个引用都提到了RocketMQ的延时消息实现。引用[4]提到RocketMQ将不同延迟时间的消息存放到特定队列,并通过Timer定时轮询。引用[3]指出RocketMQ使用多级时间轮,而引用[4]和引用[2]提到了固定延时等级和消息重试时的延迟机制。引用[1]和[3]比较了其他消息中间件的实现方式,如RabbitMQ的死信队列和Kafka的外部调度。 接下来,我需要将这些信息整合成一个结构清晰的回答。根据系统指令,使用行内数学表达式时要用$...$,但这里可能不太需要数学公式,但要注意格式。独立公式可能需要用$$...$$,但同样可能不适用。需要检查LaTeX语法正确,用中文回答,生成相关问题,并在引用处添加标识。 回答的结构可能需要包括原理概述、具体实现步骤、与其他MQ的对比、常见问题和优化方法。需要确保每个部分都有对应的引用支持。例如,延时等级和Timer定时器在引用[4]和[3]中提到,消息重试的延迟机制在引用[2]中,多级时间轮在引用[3]和[4]中。 需要注意用户的问题是关于实现机制,所以重点应放在RocketMQ如何处理延时消息,包括存储、调度和投递过程。同时,对比其他MQ的特性可以帮助用户理解RocketMQ的优势和限制,这部分引用[3]的表格。 可能还需要提到消息取消的问题,引用[3]指出RocketMQ不支持取消延时消息,而Kafka和RabbitMQ的情况不同。此外,性能分析如延时消息堆积的查看方法在引用[3]中有提到,可以通过mqadmin命令。 在生成相关问题部分,需要考虑用户可能感兴趣的后续问题,如性能优化、应用场景、与其他MQ的对比等。需要确保问题与回答内容相关,并且答案中已有部分信息可以支持这些问题的解答。 最后,要确保所有引用正确标注,例如延时等级和定时器轮询来自引用[4],多级时间轮来自引用[3]和[4],消息重试机制来自引用[2],与其他MQ的对比来自引用[3],消息取消的问题来自引用[3]。 现在需要将这些信息组织成一个连贯的回答,符合用户要求的格式,并确保引用正确,结构清晰。同时,生成的相关问题需要覆盖实现原理、优化、对比、应用场景等。</think>### RocketMQ延时消息实现机制分步解析 #### 一、核心原理 RocketMQ通过**多级时间轮算法**实现延时消息,具体流程如下: 1. **固定延时等级**:提供18个预设延迟时间(如1s/5s/10s等),消息发送时需指定等级而非具体时间[^3][^4] 2. **队列映射机制**:每个延时等级对应独立队列(SCHEDULE_TOPIC_XXXX),消息按等级存入对应队列[^4] 3. **定时扫描机制**:后台线程每秒扫描队列,将到期消息转移到目标Topic $$延迟时间计算公式:T_{实际}=T_{基准} \times 等级系数$$ 例如等级3对应$10s=1s \times 10$[^3] #### 二、具体实现步骤 1. **消息存储** - 发送延时消息时,Topic被临时改为`SCHEDULE_TOPIC_XXXX` - 根据延时等级存入对应队列(QueueId=等级-1)[^4] 2. **调度检测** - Timer每秒遍历所有延时队列 - 通过`offset`判断消息是否到期(队列内按时间有序排列)[^4] 3. **消息投递** - 到期消息恢复原始Topic - 写入CommitLog后进入正常消费流程[^4] ```java // 伪代码示例:消息等级处理 public void transformDelayLevel(Message msg) { int level = msg.getDelayLevel(); String topic = "SCHEDULE_TOPIC_" + level; msg.setTopic(topic); msg.setQueueId(level - 1); } ``` #### 三、关键技术特性对比 | 特性 | RocketMQ | Kafka | RabbitMQ | |--------------|-----------------|-----------------|------------------| | 实现方式 | 多级时间轮 | 外部调度 | 死信队列+TTL | | 最大延迟 | 2小时(开源版) | 无限制 | 无限制 | | 精度 | 秒级 | 依赖实现 | 毫秒级 | | 消息可取消 | 不支持 | 支持 | 不支持 | [数据来源:引用[3]] #### 四、生产环境注意事项 1. **堆积监控** 使用`mqadmin statsAll`命令查看SCHEDULE_TOPIC各队列堆积情况[^3] 2. **等级配置调整** 修改配置文件`messageDelayLevel`可自定义延时等级[^4] 3. **商业版增强** 阿里云商业版支持最大40天延迟,采用更高精度时间轮[^3]
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值