马克社区,马克吐温社区,马克java社区Java秒杀系统(十一)：定时任务补充处理超时未支付的订单

Java秒杀系统(十一)：定时任务补充处理超时未支付的订单

作者：修罗debug
版权声明：本文为博主原创文章，遵循 CC 4.0 by-sa 版权协议，转载请附上原文出处链接和本声明。

摘要：本篇博文是“Java秒杀系统实战系列文章”的第十一篇，本篇博文我们将借助定时任务调度组件来辅助“失效超时未支付的订单记录”的处理，用以解决上篇博文中采用“RabbitMQ死信队列失效处理超时未支付的订单”的瑕疵！

内容：上篇文章我们介绍了如何采用消息中间件RabbitMQ的死信队列失效处理超时未支付的订单，实战完毕之后，相信各位小伙伴对死信队列应该有了一个初步的认识以及使用。在该业务场景中，虽然死信队列可以“近乎完美”地解决那样的需求，但是却仍然存在着一点瑕疵，即 “当许多订单记录恰好在某个TTL集中失效，准备交由RabbitMQ的死信队列进行处理时，此时恰好RabbitMQ的服务挂掉了。。。”

RabbitMQ的服务突然挂掉，将意味着在那个时候那些本该被失效处理的订单记录却迟迟没有得到处理（因为RabbitMQ已经不提供服务了！），虽然后面重启了RabbitMQ服务，消息也重新进行了处理，但是却有可能在这段时间内用户“重新下不了单”或者其他一些意想不到的问题！

各位小伙伴看到这里，估计应该明白个大概了！虽然会抱怨“他娘的，无缘无故，RabbitMQ的服务咋会挂掉”！抱怨归抱怨，现实却仍旧是现实，隐患仍然是存在的，那既然存在隐患，那就得找寻一些方法来解决。

本篇博文我们将采用“定时器”或者叫“定时任务调度”的方式来辅助处理，即我们会设定一下Cron时间，定时在数据库中轮询获取status = 0（即状态为未支付）的订单，并更新失效掉那些时间已经超过了TTL的订单！（set status = -1）。下面我们进入代码实战环节：

(1) 定时器的实现我们暂且采用一个比较简单的方式，即@Scheduled注解来实现，我们将所有的简单定时器的实现都放在SchedulerService服务类中，其完整源代码如下所示：

@Service
public class SchedulerService {
    private static final Logger log= LoggerFactory.getLogger(SchedulerService.class);

    @Autowired
    private ItemKillSuccessMapper itemKillSuccessMapper;

    @Autowired
    private Environment env;

    //定时获取status=0的订单并判断是否超过TTL，然后进行失效
    @Scheduled(cron = "0 0/30 * * * ?")
    public void schedulerExpireOrders(){
        try {
            List<ItemKillSuccess> list=itemKillSuccessMapper.selectExpireOrders();
            if (list!=null && !list.isEmpty()){
                //java8的写法
                list.stream().forEach(i -> {
                    if (i!=null && i.getDiffTime() > env.getProperty("scheduler.expire.orders.time",Integer.class)){
                        itemKillSuccessMapper.expireOrder(i.getCode());
                    }
                });
            }
        }catch (Exception e){
            log.error("定时获取status=0的订单并判断是否超过TTL，然后进行失效-发生异常：",e.fillInStackTrace());
        }
    }
}

其中的遍历，Debug是采用了Java8的Steam API。上述这种定时任务调度的写法简单粗暴，而且还快！（世上武功无坚不摧、无快不破！）但是，快归快，在这里还是需要提一点注意的地方。

(2) 即如果在该项目有多个这样的定时任务，那么有一点值得注意的是：多个定时任务的执行时间Cron如果挨得很近，那么效率一定是瓶颈，这是因为如果只是上面那样写，那么始终只会有一个、单一的线程在执行上面的定时任务！

试想一下，如果有定时任务A、B、C都是每隔5分钟执行一次，那么很明显，将会有一些定时任务处于阻塞的状态而迟迟不能在规定的时间内执行完！

因此，为了解决此种“痛点”，我们需要加入一些自定义的配置，即针对“定时任务调度”我们加入“线程池”的配置，其完整的源代码如下所示，各位小伙伴可以写多几个定时器，然后观察控制台的输出信息，即可看到每个不同的定时任务采用了不同的线程执行。

/**
 * 定时任务多线程处理的通用化配置
 * @Author:debug (SteadyJack)
 * @Date: 2019/6/29 21:45
 **/
@Configuration
public class SchedulerConfig implements SchedulingConfigurer{
	//针对定时任务调度-配置多线程（线程池）
    @Override
    public void configureTasks(ScheduledTaskRegistrar taskRegistrar) {
        taskRegistrar.setScheduler(Executors.newScheduledThreadPool(10));
    }
}

(3) 至此，关于定时任务辅助失效处理秒杀系统中“超时未支付的订单记录”的代码已经实战完毕了！可以调整一下Cron的取值，然后将整个系统运行在外置的Tomcat服务器，稍等片刻即可看到定时任务的执行了，在这里就不贴图了！

补充：

1、目前，这一秒杀系统的整体构建与代码实战已经全部完成了，该秒杀系统对应的视频教程的链接地址为：https://www.fightjava.com/web/index/course/detail/6，可以点击链接进行试看以及学习，实战期间有任何问题都可以留言或者与Debug联系、交流！

2、另外，Debug也开源了该秒杀系统对应的完整的源代码以及数据库，其地址可以来这里下载：https://gitee.com/steadyjack/SpringBoot-SecondKill 记得Fork跟Star啊！！！

3、最后，不要忘记了关注一下Debug的技术微信公众号：

原文链接：https://fightjava.com/web/index/blog/article/23

后端高级