（一）延时任务篇——延时任务的几种实现方式概述

前言

延时任务是我们在项目开发中经常遇到的场景，例如订单超时30分钟自动取消，邮件5分钟后通知等等，对于这样的应用场景，我们又该如何应对呢，尤其是在微服务环境下，如何保证我们的延迟任务并发问题以及数据安全等等问题。本节内容作者会根据以往的项目开发经验，介绍几种延时任务的实现方案。

正文

方案一：定时任务+db数据库

- 方案说明：以订单30分钟超时支付，取消订单为例，用户下单后在db数据库记录订单的下单时间,开启一个定时轮询任务，比如每5分钟扫描一次数据库的数据，查询下单时间加上30分钟小于当前时间并且还未支付的订单数据，根据查询结果，将查询到的数据做关单的处理。

- 需要注意的问题：如果是微服务项目，要使用分布式任务xxl-job等中间件实现定时任务，如果使用的springtask等要加分布式锁，避免任务在多个服务上重复执行；任务执行失败，最好有重试机制，保证成功率。

- 优缺点：优点是实现简单，基本不用引入第三方的中间件。缺点是性能低下，耗费系统资源，没有用来处理的业务数据，定时任务会空跑。

方案二：使用MQ消息中间件

- 方案说明：使用MQ消息中间件实现，目前已知的支持延时任务的消息中间件有rabbitmq、rocketmq等，其底层基本都是通过延时队列实现。需要注意的是rabbitmq的延迟队列需要安装插件支持，rocketmq只支持固定时间等级的延迟任务。只要将延迟消息发送到mq消息中间件中，开启客户端的监听，监听延迟队列的消息，从而消费消息。

- 需要注意的问题：增加消息中间件会增加系统的复杂度，同时要保证消息中间件的高可用。

- 优缺点：天然支持高并发，性能好，实现了业务解耦。缺点是增加了系统的复杂性。

方案三：使用redis实现

- 方式一：使用redis的key过期监听机制

①实现原理：通过开启redis的key过期监听机制，在redis配置文件中设置notify-keyspace-events Ex，开启key过期的事件监听机制，当key过期后，会通过发布订阅机制发布key过期的消息，客户端通过继承实现KeyExpirationEventMessageListener监听器，实现key过期的消息监听。

②实现方案：使用redis的String数据类型，以订单id为key并设置过期时间，当key过期后，通过监听到key的过期事件，然后在处理具体的业务数据。

③问题：官方不推荐使用，安全级别低，可能会存在数据丢失的问题。

- 方式二：使用zset数据结构实现

①实现方案：使用redis的zset数据结构，以订单id为key，score的值为定单过期的时间戳，通过定时任务查询前n条数据，如果数据过期，则处理对应的关单业务，并将处理后的key删除。

②优缺点：读取缓存数据，性能优秀，虽然也存在资源的浪费。增加了系统的复杂性。

- 方式三：使用redisson的延迟队列实现

①通过redisson的延迟队列RDelayedQueue实现，其底层也主要是通过redis的zset数据结构加redis的订阅发布机制实现，集成更加方便，使用简单，是redis方式实现延迟队列的最佳实践。