订单超时自动关闭

一般电商系统订单创建后30分钟未支付，系统会自动关闭订单

方案一

直接用定时任务去扫描订单表，查询有哪些超时的订单

优点

实现简单，例如借助xxl_job，定时去扫描订单表

缺点

性能问题：

• 如果订单量很大，定时任务执行时需要遍历大量订单，可能会对数据库和系统性能造成影响。
• 高峰期订单激增可能导致定时任务的处理时间过长，影响订单及时处理。

实时性不足：

• 定时扫描通常是基于固定间隔时间的检查（比如每隔 10 分钟扫一次），因此订单超时处理并不是实时的，可能存在一定的延迟。

可扩展性：

• 当业务量增大时，需要考虑定时任务的扩展性。单一任务可能无法处理大量数据，因此可能需要划分多个任务或使用分布式任务调度。
• 数据库在处理大规模查询时可能成为瓶颈，影响其他操作的性能。

灵活性：

• 超时时间无法修改，不能灵活配置

方案二

使用延迟消息进行处理，例如RocketMQ延迟消息

优点

实时性较好：

• 延迟消息机制能够在订单超时点精确触发超时处理，避免了定时扫描的批处理延迟和实时性不足。

性能高效：

• 通过消息驱动模式，避免了频繁的数据库扫描，减轻了数据库的负担。
• RocketMQ 能够处理大量消息且支持高并发，适合高流量的电商环境。

系统解耦：

• 生产者（订单创建者）和消费者（处理订单状态更新的服务）解耦，各自关注自身逻辑。
• 支持异步处理，可以有效利用微服务架构特性。

灵活性：

• 延迟时间可以通过延迟消息的级别配置灵活调整，适应不同业务场景。

可靠性：

• RocketMQ 的消息存储机制保证了消息的持久性、可重试和幂等性，增加了系统的可靠性。

缺点

配置复杂性：

• 需要对 RocketMQ 集群进行配置和管理，包括延迟级别的设置和集群的维护。

延迟级别限制：

• 延迟消息只支持有限的延迟级别（如 1s、5s、10s 等），不能精确到任意时间点，需要根据业务需求合理设置。

资源消耗：

• 高流量的订单可能会导致大量延迟消息的积压，需要合理规划 RocketMQ 的集群资源和队列设计。

方案三

主要用延迟消息来实现，配合定时任务扫表。

为什么使用了延迟消息还需要定时任务

• 在出现消息积压的情况下，会导致订单无法及时关闭
• 在处理消息积压时，订单无法及时关闭影响用户体验

所以需要使用定时任务扫表，作为一个兜底的方案

如何解决定时任务扫表带来数据库性能问题

• 定时任务扫描从库的订单表
• 查询超时订单时，可以在30分钟的基础上增加30秒，如果MQ没有关闭订单，定时任务会延迟30秒进行关闭