深入浅出RocketMQ（五）：延时消费源码分析：用户下单锁库存与超时释放

本文探讨了RocketMQ中延时消费的实现原理及其在电商秒杀系统中的应用。通过设置消息延迟级别，RocketMQ能够自动处理超时订单，释放库存，确保资源的有效利用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

前言

今天我们来聊聊RocketMQ中的延时消费，主要在于了解RocketMQ是怎么帮我们实现延时消费以及模拟业务场景下如何使用延时消费实现功能。

1、业务场景

先从一个简单的业务场景入手，假如你在做电商模块的秒杀系统，不考虑风险控制数据统计这些逻辑，那么最简单的流程应该是

        1. 锁定库存
        2. 创建订单
        3. 返回结果
        4. 支付完成
        5. 更新数据

当用户请求进来时我们去查询一次商品库存是否满足需求，如果OK就修改当前商品库存随后创建好订单然后告知用户结果。

至于高并发情况下如何保证商品库存更新这一操作的安全性，我们可以采用乐观锁的形式去修改库存结果，对于失败的情况只要直接告知用户秒杀失败即可，这并不是我们这章需要讨论的。

看起来这个逻辑似乎没有问题，但是我们要考虑一些极端的情况

就比如：A用户下单之后迟迟没有付款，那只要A用户不付款，这个库存就一直属于该用户

这个逻辑很明显是有问题的，而现实生活中也不会出现这种情况，在电商系统中，经常会有一个超时自动释放库存的逻辑。

2、解决方案

12306相信大家都用过，当我们选好票之后会自动跳转到支付页面，并要求我们需要30分钟内完成支付，否则该订单自动取消。

这个逻辑就是我们刚才说的超时自动释放库存（或者是自动取消订单），通过rocketMQ提供的延时消费功能，我们可以很无脑的实现这个逻辑。

为什么说是无脑呢？因为在API使用层面来说实在是太简单了，我们只需要在创建Message之后设置延迟级别，然后就完事了……

message.setDelayTimeLevel(9);

当然，这也是因为RocketMQ只需要保证这个消息的发送能按用户设置的延时级别准时投递给消费者就行了，至于释放库存这一逻辑，那是你业务上的事情。

所以我们要做的事情就是，在消费到延时消息后，检查订单状态是否已经完成，如果用户没有支付的话则将订单设置为超时，然后将库存还回去。

3、实现原理

现在RocketMq并不支持任意时间的延时，需要设置几个固定的延时等级，从1s到2h分别对应着等级1到18 消息消费失败会进入延时消息队列，消息发送时间与设置的延时等级和重试次数有关。

 // 延迟级别
 // 当前支持的延迟时间
 1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h
 //  分别对应级别
 1 2 3....................

当然，我们更关注的是，RocketMQ是怎么实现延时消费的。在RocketMQ GitHub官方文档上面给的解释是这样的：

在这里插入图片描述
官方文档的解释其实已经很清晰了，消费者消费消息是根据其订阅的Topic中有没有消息来决定的，而RocketMQ就是把你需要延时消费的消息暂存在另一个队列，直到时间到了再投递给你想要的Topic去消费。

4、源码分析

光靠我这样说大家可能印象不够深刻，接下来我将通过对RocketMQ4.5.1的源码进行简单解析，让大家对broker是如何处理延时消息有个更加全面的了解。

（插一嘴，因为RocketMQ基于maven，因此构建源码环境很简单，上github clone下来等maven自动构建完就好了，Spring5的源码环境构建实在是让我心累……）

4.1 源码构建

https://github.com/apache/rocketmq/tree/release-4.5.1

通过该链接clone下来之后，直接用IDEA打开，静静等待它自动帮你构建好环境就好了。

有了4.5.1的源码之后，大家看着源码可能会不知所措，这么多的东西该从哪里看起呢？有些初学者阅读源码的方式就是：找到启动类，一行一行阅读下去。

实际上这样是很傻的，不仅效率不高，而且很容易迷失在代码发散的各个分支功能中。真正阅读源码的好习惯是：带着问题去找答案。

4.2 源码分析

就比如我们现在，我们想要知道broker是怎么帮我们解决延时消费问题的，那么我们就直接根据关键字查找即可：

在这里插入图片描述
点进来我们可以看到，这个类是一个内部类，而且还是继承于TimeTask，那么很自然的一个直觉就是，一定有其它地方把它作为一个定时任务来启动。在什么地方启动呢我们待会再看。

先观察一下这个内部类的成员变量和构造器，其实不用我说你们都懂，delayLevel是延时级别，offset是消费偏移量，构造器则是为这两个成员变量设置值。

run方法做的事情我们就不看了，猜测它应该就是根据当前延时级别去把延时队列里的数据投递到对应的Topic里。

在这里插入图片描述
接下来我们看一下这个内部类在哪个地方使用到了，通过查找功能我们很快就能定位到ScheduleMessageService的start()方法里：

public void start() {
        if (started.compareAndSet(false, true)) {
            this.timer = new Timer("ScheduleMessageTimerThread", true);
            for (Map.Entry<Integer, Long> entry : this.delayLevelTable.entrySet()) {
                Integer level = entry.getKey();
                Long timeDelay = entry.getValue();
                Long offset = this.offsetTable.get(level);
                if (null == offset) {
                    offset = 0L;
                }

                if (timeDelay != null) {
                    this.timer.schedule(new DeliverDelayedMessageTimerTask(level, offset), FIRST_DELAY_TIME);
                }
            }
            ...省略其他逻辑
    }

其他逻辑我们统统忽略，最重要的显然是这个for循环：通过遍历delayLevelTable这个Map得到每个消费级别对应的时延以及消费偏移量，然后每个级别启动一个1秒执行一次的定时任务。

结尾

通过查看源码我们可以发现，在BrokerServer上，会有专门的TimeTask去把到达延迟消费时间后的消息投递到对应的Topic上。但是这样其实可能存在一个问题，假如当前延迟时间队列中的内容数量十分多，就有可能会出现投递不及时的情况。因此对于定时调度这一功能实现，使用专门的定时调度中间件或许会更好一点。