在电商、支付等系统中，一般都是先创建订单（支付单），再给用户一定的时间进行支付，如果没有按时支付的话，就需要把之前的订单（支付单）取消掉。
这种类似的场景有很多，还有比如到期自动收货、超时自动退款、下单后自动发送短信等等都是类似的业务问题。
在解决这类问题的时候，有一种比较简单的方式，那就是通过业务上的被动方式来进行关单操作。
简单点说，就是订单创建好了之后。我们系统上不做主动关单，什么时候用户来访问这个订单了，再去判断时间是不是超过了过期时间，如果过了时间那就进行关单操作，然后再提示用户。
这种做法是最简单的，基本不需要开发定时关闭的功能，但是他的缺点也很明显，那就是如果用户一直不来查看这个订单，那么就会有很多脏数据冗余在数据库中一直无法被关单。
还有一个缺点，那就是需要在用户的查询过程中进行写的操作，一般写操作都会比读操作耗时更长，而且有失败的可能，一旦关单失败了，就会导致系统处理起来比较复杂。
所以，这种方案只适合于自己学习的时候用，任何商业网站中都不建议使用这种方案来实现订单关闭的功能。
定时任务关闭订单，这是很容易想到的一种方案。
具体实现细节就是我们通过一些调度平台来实现定时执行任务，任务就是去扫描所有到期的订单，然后执行关单动作。
这个方案的优点也是比较简单，实现起来很容易，基于Timer、ScheduledThreadPoolExecutor、或者像 xxl-job 这类调度框架都能实现，但是有以下几个问题：
1、时间不精准。 一般定时任务基于固定的频率、按照时间定时执行的，那么就可能会发生很多订单已经到了超时时间，但是定时任务的调度时间还没到，那么就会导致这些订单的实际关闭时间要比应该关闭的时间晚一些。
2、无法处理大订单量。 定时任务的方式是会把本来比较分散的关闭时间集中到任务调度的那一段时间，如果订单量比较大的话，那么就可能导致任务执行时间很长，整个任务的时间越长，订单被扫描到时间可能就很晚，那么就会导致关闭时间更晚。
3、对数据库造成压力。 定时任务集中扫表，这会使得数据库 IO 在短时间内被大量占用和消耗，如果没有做好隔离，并且业务量比较大的话，就可能会影响到线上的正常业务。
4、分库分表问题。 订单系统，一旦订单量大就可能会考虑分库分表，在分库分表中进行全表扫描，这是一个极不推荐的方案。
所以，定时任务的方案，适合于对时间精确度要求不高、并且业务量不是很大的场景中。如果对时间精度要求比较高，并且业务量很大的话，这种方案不适用。
DelayQueue 是一个无界的 BlockingQueue，用于放置实现了 Delayed 接口的对象，其中的对象只能在其到期时才能从队列中取走
有这样一种方案，他不需要借助任何外部的资源，直接基于应用自身就能实现，那就是基于 JDK 自带的 DelayQueue 来实现。
基于延迟队列，是可以实现订单的延迟关闭的，首先，在用户创建订单的时候，把订单加入到 DelayQueue 中，然后，还需要一个常驻任务不断的从队列中取出那些到了超时时间的订单，然后在把他们进行关单，之后再从队列中删除掉。
这个方案需要有一个线程，不断的从队列中取出需要关单的订单。一般在这个线程中需要加一个 while(true) 循环，这样才能确保任务不断的执行并且能够及时的取出超时订单。
使用 DelayQueue 实现超时关单的方案，实现起来简单，不须要依赖第三方的框架和类库，JDK 原生就支持了。
当然这个方案也不是没有缺点的，首先，基于 DelayQueue 的话，需要把订单放进去，那如果订单量太大的话，可能会导致 OOM 的问题；另外，DelayQueue 是基于 JVM 内存的，一旦机器重启了，里面的数据就都没有了。虽然我们可以配合数据库的持久化一起使用。而且现在很多应用都是集群部署的，那么集群中多个实例上的多个 DelayQueue 如何配合是一个很大的问题。
所以，基于 JDK 的 DelayQueue 方案只适合在单机场景、并且数据量不大的场景中使用，如果涉及到分布式场景，那还是不建议使用。
时间轮可以理解为一种环形结构，像钟表一样被分为多个 slot。每个 slot 代表一个时间段，每个 slot 中可以存放多个任务，使用的是链表结构保存该时间段到期的所有任务。时间轮通过一个时针随着时间一个个 slot 转动，并执行 slot 中的所有到期任务
还有一种方式，和上面我们提到的 JDK 自带的 DelayQueue 类似的方式，那就是基于时间轮实现。
为什么要有时间轮呢？主要是因为 DelayQueue 插入和删除操作的平均时间复杂度——O(nlog(n))，虽然已经挺好的了，但是时间轮的方案可以将插入和删除操作的时间复杂度都降为 O(1)。
基于 Netty 的 HashedWheelTimer 可以帮助我们快速的实现一个时间轮，这种方式和 DelayQueue 类似，缺点都是基于内存、集群扩展麻烦、内存有限制等等。
但是他相比 DelayQueue 的话，效率更高一些，任务触发的延迟更低。代码实现上面也更加精简。
所以，基于 Netty 的时间轮方案比基于 JDK 的 DelayQueue 效率更高，实现起来更简单，但是同样的，只适合在单机场景、并且数据量不大的场景中使用，如果涉及到分布式场景，那还是不建议使用。
既然基于 Netty 的时间轮存在一些问题，那么有没有其他的时间轮的实现呢？
还真有的，那就是 Kafka 的时间轮，Kafka 内部有很多延时性的操作，如延时生产，延时拉取，延时数据删除等，这些延时功能由内部的延时操作管理器来做专门的处理，其底层是采用时间轮实现的。
而且，为了解决有一些时间跨度大的延时任务，Kafka 还引入了层级时间轮，能更好控制时间粒度，可以应对更加复杂的定时任务处理场景；
Kafka 中的时间轮的实现是 TimingWheel 类，位于 kafka.utils.timer 包中。基于 Kafka 的时间轮同样可以得到 O(1) 时间复杂度，性能上还是不错的。
基于 Kafka 的时间轮的实现方式，在实现方式上有点复杂，需要依赖 kafka，但是他的稳定性和性能都要更高一些，而且适合用在分布式场景中。
延迟消息，当消息写入到 Broker 后，不会立刻被消费者消费，需要等待指定的时长后才可被消费处理的消息，称为延时消息。
相比于 Kafka 来说，RocketMQ 中有一个强大的功能，那就是支持延迟消息。
有了延迟消息，我们就可以在订单创建好之后，发送一个延迟消息，比如 20 分钟取消订单，那就发一个延迟 20 分钟的延迟消息，然后在 20 分钟之后，消息就会被消费者消费，消费者在接收到消息之后，去关单就行了。
但是，RocketMQ 的延迟消息并不是支持任意时长的延迟的，它只支持：1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h 这几个时长。（商业版支持任意时长）
可以看到，有了 RocketMQ 延迟消息之后，我们处理上就简单很多，只需要发消息，和接收消息就行了，系统之间完全解耦了。但是因为延迟消息的时长受到了限制，所以并不是很灵活。
如果我们的业务上，关单时长刚好和 RocketMQ 延迟消息支持的时长匹配的话，那么是可以基于 RocketMQ 延迟消息来实现的。否则，这种方式并不是最佳的。
延迟消息不仅在 RocketMQ 中支持，其实在 RabbitMQ 中也是可以实现的，只不过其底层是基于死信队列实现的。
当 RabbitMQ 中的一条正常的消息，因为过了存活时间（TTL 过期）、队列长度超限、被消费者拒绝等原因无法被消费时，就会变成 Dead Message，即死信。
当一个消息变成死信之后，他就能被重新发送到死信队列中（其实是交换机-exchange）。
那么基于这样的机制，就可以实现延迟消息了。那就是我们给一个消息设定TTL，然但是并不消费这个消息，等他过期，过期后就会进入到死信队列，然后我们再监听死信队列的消息消费就行了。
而且，RabbitMQ 中的这个 TTL 是可以设置任意时长的，这就解决了 RocketMQ 的不灵活的问题。
但是，死信队列的实现方式存在一个问题，那就是可能造成队头阻塞，因为队列是先进先出的，而且每次只会判断队头的消息是否过期，那么，如果队头的消息时间很长，一直都不过期，那么就会阻塞整个队列，这时候即使排在他后面的消息过期了，那么也会被一直阻塞。
基于 RabbitMQ 的死信队列，可以实现延迟消息，非常灵活的实现定时关单，并且借助 RabbitMQ 的集群扩展性，可以实现高可用，以及处理大并发量。他的缺点第一是可能存在消息阻塞的问题，还有就是方案比较复杂，不仅要依赖RabbitMQ，而且还需要声明很多队列( exchange )出来，增加系统的复杂度
其实，基于 RabbitMQ 的话，可以不用死信队列也能实现延迟消息，那就是基于 rabbitmq_delayed_message_exchange插件，这种方案能够解决通过死信队列实现延迟消息出现的消息阻塞问题。但是该插件从 RabbitMQ 的 3.6.12 开始支持的，所以对版本有要求。
这个插件是官方出的，可以放心使用，安装并启用这个插件之后，就可以创建x-delayed-message类型的队列了。
前面我们提到的基于私信队列的方式，是消息先会投递到一个正常队列，在TTL过期后进入死信队列。但是基于插件的这种方式，消息并不会立即进入队列，而是先把他们保存在一个基于 Erlang 开发的 Mnesia 数据库中，然后通过一个定时器去查询需要被投递的消息，再把他们投递到 x-delayed-message 队列中。
基于 RabbitMQ 插件的方式可以实现延迟消息，并且不存在消息阻塞的问题，但是因为是基于插件的，而这个插件支持的最大延长时间是(2^32)-1 毫秒，大约 49 天，超过这个时间就会被立即消费。但是他基于 RabbitMQ 实现，所以在可用性、性能方便都很不错
很多用过 Redis 的人都知道，Redis 有一个过期监听的功能，
在 redis.conf 中，加入一条配置 notify-keyspace-events Ex 开启过期监听，然后再代码中实现一个KeyExpirationEventMessageListener，就可以监听 key 的过期消息了。
这样就可以在接收到过期消息的时候，进行订单的关单操作。
这个方案不建议大家使用，是因为 Redis 官网上明确的说过，Redis 并不保证 Key 在过期的时候就能被立即删除，更不保证这个消息能被立即发出。所以，消息延迟是必然存在的，随着数据量越大延迟越长，延迟个几分钟都是常事儿。
而且，在 Redis 5.0 之前，这个消息是通过 PUB/SUB 模式发出的，他不会做持久化，至于你有没有接到，有没有消费成功，他不管。也就是说，如果发消息的时候，你的客户端挂了，之后再恢复的话，这个消息你就彻底丢失了。（在 Redis 5.0 之后，因为引入了 Stream，是可以用来做延迟消息队列的。）
虽然基于 Redis 过期监听的方案并不完美，但是并不是 Redis 实现关单功能就不完美了，还有其他的方案。
我们可以借助 Redis 中的有序集合——zset 来实现这个功能。
zset 是一个有序集合，每一个元素(member)都关联了一个 score，可以通过 score 排序来取集合中的值。
我们将订单超时时间的时间戳（下单时间+超时时长）与订单号分别设置为 score 和 member。这样 redis 会对 zset 按照score 延时时间进行排序。然后我们再开启 redis 扫描任务，获取”当前时间 > score”的延时任务，扫描到之后取出订单号，然后查询到订单进行关单操作即可。
使用 redis zset 来实现订单关闭的功能的优点是可以借助 redis 的持久化、高可用机制。避免数据丢失。但是这个方案也有缺点，那就是在高并发场景中，有可能有多个消费者同时获取到同一个订单号，一般采用加分布式锁解决，但是这样做也会降低吞吐型。
但是，在大多数业务场景下，如果幂等性做得好的，多个消费者取到同一个订单号也无妨。
上面这种方案看上去还不错，但是需要我们自己基于 zset 这种数据结构编写代码，那么有没有什么更加友好的方式？
有的，那就是基于 Redisson。
Redisson 是一个在 Redis 的基础上实现的框架，它不仅提供了一系列的分布式的 Java 常用对象，还提供了许多分布式服务。
Redission 中定义了分布式延迟队列 RDelayedQueue，这是一种基于我们前面介绍过的 zset 结构实现的延时队列，它允许以指定的延迟时长将元素放到目标队列中。
其实就是在 zset 的基础上增加了一个基于内存的延迟队列。当我们要添加一个数据到延迟队列的时候，redission 会把数据+超时时间放到 zset 中，并且起一个延时任务，当任务到期的时候，再去zset中把数据取出来，返回给客户端使用。
大致思路就是这样的，感兴趣的大家可以看一看 RDelayedQueue 的具体实现。
基于 Redisson 的实现方式，是可以解决基于 zset 方案中的并发重复问题的，而且还能实现方式也比较简单，稳定性、性能都比较高。
实现的复杂度上（包含用到的框架的依赖及部署）：
Redission > RabbitMQ 插件 > RabbitMQ 死信队列 > RocketMQ 延迟消息 ≈ Redis 的 zset > Redis 过期监听 ≈ kafka 时间轮 > 定时任务 > Netty 的时间轮 > JDK 自带的 DelayQueue > 被动关闭
方案的完整性：
Redission ≈ RabbitMQ 插件 > kafka 时间轮 > Redis 的 zset ≈ RocketMQ 延迟消息 ≈ RabbitMQ 死信队列 > Redis 过期监听 > 定时任务 > Netty 的时间轮 > JDK 自带的 DelayQueue > 被动关闭
不同的场景中也适合不同的方案：
- 自己玩玩：被动关闭
- 单体应用，业务量不大：Netty 的时间轮、JDK 自带的 DelayQueue、定时任务
- 分布式应用，业务量不大：Redis 过期监听、RabbitMQ 死信队列、Redis 的 zset、定时任务
- 分布式应用，业务量大、并发高：Redission、RabbitMQ 插件、kafka 时间轮、RocketMQ 延迟消息
总体考虑的话，考虑到成本，方案完整性、以及方案的复杂度，还有用到的第三方框架的流行度来说，个人比较建议优先考虑 Redission+Redis、RabbitMQ 插件、Redis 的 zset、RocketMQ 延迟消息等方案。