【每天5分钟，了解一个知识点】
方案一：定时任务
原理: 使用如Quartz或Spring Schedule等工具，定期查询数据库中处于“未支付”状态且已超过预设支付期限的订单，然后将这些订单的状态更新为“已关闭”。
优点:
实现简单，技术门槛低。
对系统其他部分的影响较小，易于维护和理解。
缺点:
资源效率不高，即使没有需要处理的订单，定时任务也会定期执行，造成不必要的系统开销。
订单关闭不够精确，取决于定时任务的执行频率，可能存在延迟关闭或提前关闭的情况。
方案二：JDK 延迟队列 DelayQueue
原理: 利用Java中的DelayQueue
，每个待处理的订单对象实现Delayed
接口，设定一个延迟时间（即支付超时时间）。当订单放入队列后，只有当其指定的延迟时间到期，该订单才会被处理，进而执行关闭逻辑。
优点:
精确控制订单关闭时间，资源利用率较高。
利用Java标准库，无需引入额外依赖。
缺点:
仅限于单机环境，难以应用于分布式系统。
需要自定义订单对象并实现
Delayed
接口，增加了代码复杂度。
方案三：Redis 过期监听
原理: 将订单信息及过期时间存储在Redis中，利用Redis的键过期事件（KeyExpirationEvent）触发器，当订单过期时，通过订阅者接收事件并执行订单关闭逻辑。
优点:
实现相对简单，利用Redis的特性，能精确控制过期时间。
支持分布式环境，适合现代微服务架构。
缺点:
需要处理Redis订阅/发布机制的可靠性问题。
Redis过期事件可能有延迟，特别是在高负载情况下。
Redis内存满了，也会淘汰有效的数据，需要重复Redis的存储
方案四：Redisson 分布式延迟队列
原理: Redisson是基于Redis的Java客户端，提供了丰富的数据结构和分布式服务。其中的分布式延迟队列功能类似于JDK的DelayQueue
，但支持分布式环境。将订单信息作为任务加入延迟队列，到期后自动执行关闭操作。
优点:
结合了Redis的高性能与分布式特性，同时简化了分布式环境下的延迟队列实现。
提供了丰富的配置选项和高级特性，如重试机制、事务支持等。
缺点:
需要引入Redisson依赖，增加了系统的复杂度。
学习成本相对高于直接使用Redis或JDK原生工具。
方案五：RocketMQ 延迟消息
原理: RocketMQ是一款分布式消息中间件，支持发送延迟消息。创建订单时，向RocketMQ发送一个带有延迟时间的消息，当消息达到指定的延迟时间后，消费者接收到消息并执行订单关闭操作。
优点:
支持灵活的消息延迟等级，满足不同业务场景需求。
解耦了订单系统与其他系统，提高了系统的可扩展性和灵活性。
缺点:
引入了额外的消息中间件组件，增加了系统的运维复杂度。
需要处理消息丢失、重复消费等潜在问题。
以上五种方案各有优缺点，具体选择哪种方案要根据实际业务需求和系统架构来决定。在订单量较小的情况下，可以采用方案一或方案二；在订单量较大且对关单实时性要求较高的情况下，可以考虑方案三、方案四或方案五。
【关联阅读】
