大量订单定时退款的场景
我们先考虑一个正常的电商购物流程，一般来说我们作为用户在一个电商APP上都会选择一些商品加入购物车，然后对购物车里选择的一些商品统一下一个订单，此时后台的订单系统必然会在订单数据库中创建一个订单。
但是我们下了一个订单之后，虽然订单数据库里会有一个订单，订单的状态却是“待支付”状态，因为此时你其实还没有支付这个订单，我们的订单系统其实也在等待订单用户完成这个订单的支付。
这里就有两种可能了，一种可能是用户下单之后立马就支付掉了，那么接着订单系统可以走后续的流程，比如通过MQ发送消息通知优惠券系统给用户发优惠券，通知仓储系统进行调度发货，等等。
另外一种可能就是用户下单之后，一直在犹豫，迟迟没有下订单。
因此在实际情况中，其实APP的大量用户每天会下很多订单，但是不少订单可能是一直没有进行支付的，可能他下单之后犹豫了，可能是他忘了支付了！
我们看下图示意，订单数据库中有很多订单是没有支付的。
所以一般订单系统都必须设置一个规则，当一个订单下单之后，超过比如30分钟没有支付，那么就必须订单系统自动关闭这个订单，后续你如果要购买这个订单里的商品，就得重新下订单了。
我们看下图，可能你的订单系统就需要有一个后台线程，不停的扫描订单数据库里所有的未支付状态的订单，看他如果超过30分钟了还没支付，那么就必须自动把订单状态 更新为“已关闭”
但是这里就引入了一个问题，就是订单系统的后台线程必须要不停的扫描各种未支付的订单，这种实现方式实际上并不是很好。
一个原因是未支付状态的订单可能是比较多的，然后你需要不停的扫描他们，可能每个未支付状态的订单要被扫描N多遍，才会发现他已经超过30分钟没支付了。
另外一个是很难去分布式并行扫描你的订单。因为假设你的订单数据量特别的多，然后你要是打算用多台机器部署订单扫描服务，但是每台机器扫描哪些订单？怎么扫描？什么时候扫描？这都是一系列的麻烦问题
延迟消息
因此针对类似这种场景，MQ里的延迟消息往往就会出场了，他是特别适合在这种场景里使用的，而且在实际项目中，MQ的延迟消息使用的往往是很多的。
所谓延迟消息，意思就是说，我们订单系统在创建了一个订单之后，可以发送一条消息到MQ里去，我们指定这条消息是延迟消息，比如要等待30分钟之后，才能被订单扫描服务给消费到
我们如下图所示
这样当订单扫描服务在30分钟后消费到了一条消息之后，就可以针对这条消息的信息，去订单数据库里查询这个订单，看看他在创建过后都过了30分钟了，此时他是否还是未支付状态？
如果此时订单还是未支付状态，那么就可以关闭他，否则订单如果已经支付了，就什么都不用做了，我们看下图
这种方式就比你用后台线程扫描订单的方式要好的多了，一个是对每个订单你只会在他创建30分钟后查询他一次而已，不会反复扫描订单多次。
另外就是如果你的订单数量很多，你完全可以让订单扫描服务多部署几台机器，然后对于MQ中的Topic可以多指定一个
MessageQueue，这样每个订单扫描服务的机器作为一个Consumer都会处理一部分订单的查询任务。所以MQ的延迟消息，是非常常用并且非常有用的一个功能。
延迟消息的代码实现
发送延迟消息的代码示例
上面的代码，其实发送延迟消息的核心，就是设置消息的delayTimeLevel，也就是延迟级别
RocketMQ默认支持一些延迟级别如下：1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h
所以上面代码中设置延迟级别为3，意思就是延迟10s，你发送出去的消息，会过10s被消费者获取到。那么如果是订单延迟扫描场景，
可以设置延迟级别为16，也就是对应上面的30分钟。
接着我们看看一个消费者的代码示例，比如订单扫描服务，正常他会对每个订单创建的消息，在30分钟以后才获取到，然后去查询订单状态，判断如果是未支付的订单，就自动关闭这个订单
