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

前言

    今天我们来聊聊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 消息消费失败会进入延时消息队列，消息发送时间与设置的延时等级和重试次数有关。

 // 延迟级别