RocketMQ基于延迟消息机制优化大量订单的定时退款扫描问

　　我们先考虑一个正常的电商购物流程，一般来说我们作为用户在一个点上APP上都会选择一些商品加入购物车，然后对购物车里选择的一些商品统一下一个订单，此时后台的订单系统必然会在订单数据库中创建一个订单。
　　但是我们下了一个订单之后，虽然订单数据库里会有一个订单，订单的状态却是待支付状态，因为此时你还没有支付这个订单，我们的订单系统其实也在等待订单用户完成这个订单的支付。
　　这里就有两种可能了，一种是用户下单之后立马就支付掉了，那么接着订单系统可以走后续的流程，比如通过MQ发送消息通知优惠券系统给用户发放优惠券等等。
　　另外一种可能是用户下单后，一直在犹豫，迟迟没有下订单。
　　因此在实际情况中吗，其实APP的大量用户每天会下很多订单，但是不少订单可能是一直没有进行支付的，可能他下了单之后犹豫了，可能是他忘了支付了。
　　所以一般订单系统都必须设置一个规则，当一个订单下单之后，比如超过30分钟没有支付，那么就必须自动关闭这个订单，后续你如果要购买这个订单里的商品，就要重新下订单了。
　　可能你的订单系统就需要有一个后台线程，不停地扫描订单数据库里所有的未支付状态的订单，看他如果超过30分钟还没支付，就自动把订单状态改成已关闭。
　　但是这里就引入一个问题，就是订单系统的后台线程必须要不停地扫描各种未支付的订单，这种实现方式实际上并不是很好。
　　一个原因是未支付状态的订单可能是比较多，然后你需要不停地扫描他们，可能每个未支付状态的订单要被扫描N多遍，才会发现他已经超过30分钟未支付了。
　　另外一个是很难去分布式并行扫描你的订单，因为假设你的订单数量特别多，然后你要是打算用多台机器部署订单扫描服务，但是每台机器扫描哪些订单？怎么扫描？什么时候扫描？这都是一系列麻烦的问题。
　　因此针对此类场景的问题，MQ里的延迟消息就会出场了，他是特别适合在这种场景里使用的，而且在实际项目中，MQ的延迟消息使用的往往是很多的。
　　所谓延迟消息，意思就是当我们订单系统在创建了一个订单之后，可以发送一条消息到MQ里去，我们指定这条消息是延迟消息，比如要等待30分钟，才能被订单扫描服务给消费到。
　　这样当订单扫描服务在30分钟后消费到了一条消息之后，就可以针对这条消息的信息，去订单数据库里查找这个订单，看看他的状态是否还是未支付状态。如果还是未支付，那么就可以关闭这个订单。
　　这种方式就比用后台线程扫描订单的方式要好得多了，一个是对每个订单你只会在创建30分钟之后查询他一次而已，不会反复扫描订单多次。
　　另外就是如果你的订单数量比较多，你完全可以让订单扫描服务多部署几台服务器，然后对于这个Topic可以多指定一些MessageQueue，这样每个订单扫描服务的机器可以作为一个consumer都会处理一部分订单的查询任务。
　　基于订单定时退款场景，来分析RocketMQ的延迟消息的代码实现publicclassScheduledMessageProducer｛publicstaticvoidmain（String〔〕args）throwsException｛这是订单系统的生产者DefaultMQProducerproducernewDefaultMQProducer（OrderSystemProducerGroup）；producer。start（）；MessagemessagenewMessage（CreateOrderInformTopic，orderInfoJson。getBytes（））；这里设置消息为延迟消息，延迟级别为3message。setDelayTimeLevel（3）；producer。send（message）；｝｝
　　大家看到上面的代码，其实发送延迟消息的核心，就是设置消息的delayTimeLevel，也就是延迟级别，RocketMQ默认支持一些延迟级别如下：1s5s10s30s1m2m3m4m5m6m7m8m9m10m20m30m1h2h
　　所以上面的代码中设置延迟级别为3，也就是延迟10s，如果是订单延迟扫描场景，可以设置延迟级别为16，也就是对应上面的30分钟。