企业官网建设流程全解析

超时未支付订单处理，几乎是每个电商系统都绕不开的“日常暗礁”。用户下单不付款，商品库存被锁定，优惠券被占用，如果放任不管，黄牛和恶意占单的人能把你库存掏空，而平台还得背个“虚假繁荣”的KPI。更棘手的是，哪怕你已经按常规节奏写好了定时任务，一旦遇到订单处理组件在凌晨大促高峰期宕机——该关的订单没关掉，库存超卖、对账不平、投诉汹涌，好几套下游系统跟着遭殃。我见过不少团队在这个问题上反复栽跟头，有些甚至把线上事故定义为“系统bug”，但本质上是架构设计时没有把超时处理和组件故障放在一起想。

这篇博文就围绕这两个核心问题展开：超时未支付订单的完整处理方案，以及订单处理链路中组件宕机后的应对策略。我会把方案选型、表结构设计、延迟队列的实现细节、兜底扫描的正确写法、故障恢复流程和排查技巧都过一遍。适合正在做交易系统、订单系统或者中间件平台的后端同学，也适合即将接手电商核心链路、想提前了解坑在哪里的技术负责人。

1. 超时未支付订单处理：先想清楚这不止是一个定时任务的问题

1.1 从业务痛点看超时关单到底解决了什么

表面上，超时关单就是一个规则：订单创建后30分钟未支付，把订单改成已关闭。但落到底层，它牵涉的是库存、优惠、支付渠道额度、财务对账，甚至用户购物体验。库存是有限的，一个订单锁住库存不释放，后面真实想买的用户就买不到，商家眼睁睁看着转化率往下掉。优惠券也是成本，用户领了券下单不支付，券被锁定在订单上，既不能继续发给别人，也不能让用户重新使用，时间久了就是一笔糊涂账。

支付渠道侧同样有隐性成本。很多支付方式在创建支付单后会占住渠道的授权额度，虽然不在交易系统里直接可见，但量一大，支付渠道的可用额度会被无效订单吃掉。对用户来说，如果订单超时处理太激进，比如刚下单几分钟就自动关闭，体验非常差；处理太晚，库存和优惠又一直被无效占用。我在实际项目里看到过一些团队把超时时间调成“用户下单后2小时”，理由是“怕用户还在犹豫”，结果黄牛专门利用这个时间差锁库存，最后导致库存账和实物账对不上。

所以超时关单这件事，核心价值不是“关掉一张订单”，而是 在准确的时间点回收订单占用的所有资源，同时保证整个操作不伤害正常用户的购物流程。这需要一套能精确延迟调度、能在故障时兜底、能在并发下保持幂等的机制。只写一个定时任务扫表，显然不够。

1.2 三种主流实现方案对比，选型不能只看延迟精度

实现超时处理，业界方案大致分三类：定时扫描数据库、延迟消息、基于 Redis ZSet 的延迟队列。每一类都有明确的使用边界，不能只听别人说“推荐方案”就照搬。

定时扫描数据库是很多早期系统的做法。每隔一段时间扫一次订单表，找出超过超时时间且仍未支付的订单进行关闭。优点是实现简单、依赖少，一个 crontab 或一个 xxl-job 就能跑。缺点是延迟不精准，扫描频率越高数据库压力越大，而且订单表一旦上了千万级，SELECT * FROM orders WHERE status = 'PAY_WAITING' AND expire_time < NOW()这种SQL在无合适索引的情况下就是灾难。一般建议扫描频率不超过5分钟一次，且必须配合索引和分批处理。这种方案适合订单量不大、并发不高的内部业务系统。

延迟消息（如 RocketMQ 的定时消息、RabbitMQ 的延迟插件）的延迟精度相对高，消息到期后能较实时地触发处理。RocketMQ 的定时消息可以做到秒级延迟，比如30分钟关单就直接发一条延迟30分钟的消息，消费者收到后检查订单状态再关单。优势是对业务代码侵入少，消息天然带有重试和持久化能力。但需要注意，RocketMQ 的定时消息不能动态调整延迟时间，如果你一个订单支持“用户手动延长支付时间”，消息已经发出去就不好改了，只能靠消费时再判断。

基于 Redis ZSet 的延迟队列是我目前比较推荐的自研方案。把订单号作为 member，把期望执行时间戳作为 score，定时往 ZSet 里塞。消费端用ZRANGEBYSCORE拉取到期的订单，逐个处理。它的好处是延迟精度可以任意控制、支持动态调整超时时间、性能高，坏处是需要自己处理持久化和消息丢失问题，还需要额外脚本维护。这个方案适合订单量大、超时场景复杂、需要随时动态调整的主交易链路。我在后面的实操部分会详细讲这个方案怎么落地。

三类方案没有绝对优劣，关键是业务复杂度、团队维护能力和可用性要求。直接用一张表对比会更直观：

1.3 超时时间该谁定义：参数化和配置化的设计思路

很多系统把超时时间写死在代码里，比如private static final int PAY_TIMEOUT_MINUTES = 30;，这对固定业务的系统没问题，但放在电商里就很尴尬。大促期间，运营想缩短恶意占单者的窗口，把超时时间改短；日常想照顾用户犹豫期，又希望时间长一点；不同品类甚至不同订单来源，规则也不同。如果写死在代码里，每次调整都要发版，等审批流程走完，最佳处理时机早就过了。

这里建议把超时时间做成订单维度的字段：创建订单时根据业务方配置写入orders.expire_time。运营在后台配置的是“普通订单30分钟、秒杀订单5分钟、预售订单24小时”，下单服务在构建订单时按规则算好expire_time并存储。这样做有额外的好处：后续任何场景要判断“这个订单是否超时”，直接拿当前时间和订单上的expire_time做比较即可，不依赖全局配置在某个时间点被修改后的口径不一致问题。配置中心集中管理，实时生效，运营调整完策略，新订单立即按新规则执行。

有人会担心：那存量订单怎么办？比如配置从30分钟改成5分钟，已经创建但还没关闭的订单要不要按新规则处理？我建议不要动态修改已有订单的expire_time，除非是特定风险控制场景。为什么？因为用户在下单时看到的页面承诺是“请于30分钟内完成支付”，平台单方面缩短时间，从产品体验上讲是不合理的。真要处理风险订单，应该通过专门的调度或风控任务去单独关闭，而不是改所有存量的超时时间。

2. 组件宕机应对策略：超时处理链路的脆弱点与高可用改造

2.1 盘点关键路径上的组件，谁挂了影响最大

订单超时处理看似只是“一个任务”，但它在链路中依赖的东西不少。我按依赖顺序梳理一遍：首先是存放订单数据的数据库，其次是负责延迟调度的组件（Redis或MQ），然后是执行关闭动作的应用服务，最后是下游的库存、优惠券、支付通知等系统。这四个环节任意一个出问题，超时关单都会受到影响，但影响程度完全不同。

数据库挂了的场景最悲观。订单状态查询、关闭订单的状态更新都在数据库上，数据库不可用意味着所有关单操作全部失败。而且因为超时关单是“等条件满足才处理”的，一旦数据库恢复，之前积压的库存锁定还会继续持有，恢复期必须处理大量超时订单的积压。Redis 挂掉的影响取决于你拿它做什么——如果延迟队列放在 Redis 里，Redis 不可用地期间新增的超时订单不会有消息触发，但数据库兜底扫描还能继续关单，所以不是完全停摆。MQ 挂掉的影响类似：延迟消息发不出去或消费不了，依赖 MQ 的重试机制暂时失效，需要有其他通道补偿。

应用服务（执行关单的服务）DOWN 了就更有意思。如果这个服务是无状态多副本部署，单副本挂掉，流量由其他副本扛住；如果整个集群都不可用，关单动作停下来，但是查询、下单等主流程不一定受影响。这种情况下，超时订单会“堆积”在等待关闭的状态，恢复后需要清理积压，否则库存释放延迟会直接放大。至于下游的库存服务、优惠券服务，如果它们挂了，关单主流程的数据库状态更新还能做，但“释放库存”这个动作无法成功，如果系统设计成“先关单、再异步释放库存”，就会出现订单已关闭但库存仍被占用的脏数据。

我在设计高可用方案时，一贯思路是：主流程绝对不能因为次要依赖挂掉而不可用，所有非核心操作都要有降级路径。对超时关单而言，“关闭订单状态”是核心，释放库存、退优惠券、发通知都是可以异步补偿的周边动作。明确了这一点，后续的架构决策就清晰很多。

2.2 高可用改造三板斧：冗余、重试、降级

第一板斧是冗余。所有无状态服务至少双副本，多可用区部署。数据库做主从+自动切换，Redis 用哨兵或集群模式，MQ 用主从同步。冗余不能只停留在“部署了”，要定期做故障演练，从真实的宕机事件中检验切换时间。我见过不止一次，主库宕了，从库能顶上，但切换脚本里的 IP 写死，导致应用连不上新主库——这就是只做了冗余没做验证的后果。

第二板斧是重试。重试的核心原则是：只在确定性失败上重试，且要带退避，无脑重试会把一个故障放大成雪崩。对超时处理而言，如果关单时下游库存释放失败，我们要判断是网络超时还是业务失败。网络超时可以做限次重试，比如3次、每次间隔指数增长；业务失败（比如订单本身已取消、库存记录不存在）则不该重试，直接记录日志。重试还必须有上限，超过上限进入死信或延迟队列，等人工介入。如果不设上限，每次扫描或消息触发都重复打在下一个故障服务上，后果很难看。

第三板斧是降级。超时关单的降级主要体现在“关单大动作”的拆解上。完整流程包括：校验订单状态、更新状态、释放库存、回退优惠券、解冻支付额度、发通知。如果下游库存系统异常，可以选择先完成数据库状态更新，把释放库存的消息发到 MQ 里，等库存系统恢复后消费；如果 MQ 也异常，直接落库一张“待补偿任务表”，由补偿任务轮询处理。降级的目的不是“什么都做不了”，而是在能力不全的情况下保住最核心的数据一致性。哪怕关单动作只完成了第一步，也比所有步骤都卡死强得多。

3. 实操落地：一个通用的超时订单处理实现参考

3.1 数据模型与关键字段设计

先说订单表里的核心字段。除了常规的订单号、用户ID、金额、状态之外，超时关单场景必须关心这几个字段：status（当前状态，比如 PAY_WAITING / PAID / CLOSED / CANCELED）、expire_time（订单过期时间）、closed_reason（关闭原因，区分超时关闭、手动取消、风控关闭）、version（乐观锁版本号）、close_time（实际关闭时间）。其中expire_time是核心，所有超时判断都以它为准；version是并发安全的基石，后面讲幂等时会详细说。

如果走 Redis ZSet 延迟队列，我建议在订单表之外再建一张轻量的“超时处理任务表”，字段包括：order_no、expected_execute_time、status（PENDING / PROCESSING / DONE / FAILED）、retry_count、last_execute_time。这张表的作用是作为延迟队列的可靠补充：每次把任务塞进 Redis 时，同时在这张表记录一条待处理任务；消费端拿到 Redis 任务后，先去这张表把任务状态改成 PROCESSING，处理完再改成 DONE。这样即使 Redis 数据丢了，这张表也能告诉我“哪些超时的单子还没有被处理完”，用于兜底扫描和故障恢复。

有人可能会说，建这张表又要多维护一套数据，多一次写库，值不值？我的回答是：在主交易链路上，延迟调度的每一条任务都应该有“最终会被执行”的保证，这张表实际上是任务台账。纯靠 Redis 不可靠，纯靠数据库扫描又太低效，两者互补才是成本与可靠性的平衡点。数据量也完全没问题，每条任务就几百字节，一天几百万订单，这张表也就百万级记录，加好索引后完全扛得住。

3.2 基于 Redis ZSet 的延迟队列实现细节

延迟队列的写入逻辑很简单：订单创建成功后，ZADD delay_queue {expire_timestamp} {order_no}。score 存的是到期时间戳，比如当前时间加30分钟。消费端则有讲究，伪代码如下：

public void processExpiredOrders() { long now = System.currentTimeMillis(); Set<String> orderNos = redis.zrangeByScore(DELAY_QUEUE_KEY, 0, now, 0, BATCH_SIZE); if (orderNos == null || orderNos.isEmpty()) { return; } for (String orderNo : orderNos) { // 先移除，再处理，防止多线程并发消费同一订单 Long removed = redis.zrem(DELAY_QUEUE_KEY, orderNo); if (removed != null && removed > 0) { try { closeExpiredOrder(orderNo); } catch (Exception e) { // 处理失败，重新入队或落入失败任务表 delayRetry(orderNo); } } } }

这里有个关键点：必须是ZRANGEBYSCORE拿到候选任务后ZREM成功再处理，而不是先处理再移除。原因很简单，如果先处理再移除，在并发场景下两个消费者可能同时拿到同一个订单，都去执行关单，就会产生重复操作；先 ZREM 再处理，虽然不能100%避免重复（任务处理中宕机，任务已经移除，恢复后不知道谁处理过），但至少把并发重复的可能性降到最低。

再强调一点：ZRANGEBYSCORE每次拉取的批次大小要控制。一次拉几千个，线程池又开50个并发去处理，瞬时对数据库的冲击非常大。我建议 batch size 控制在 100 ~ 200 之间，单次处理完再去取下一批，保证消费速度平滑。系统处理能力不够时，宁可积压一点，也不要打爆数据库。

超时时间动态调整怎么支持？如果用户主动选择了“延长支付时间”，直接把这条任务的 score 重新 ZADD 为新过期时间即可。ZSet 的 member 是唯一的，重复 ZADD 会覆盖 score，天然支持更新延迟时间。这一点比延迟消息方案灵活很多，也是我推荐自研延迟队列的一个重要理由。

3.3 定时扫描兜底任务的正确写法

前面说了，延迟队列再快、再准，也有消息丢失和延迟的可能。Redis 持久化策略如果配置不当（比如只配置了 RDB），宕机后可能丢几十秒到几分钟的数据。所以一个可靠的超时处理体系里，兜底扫描任务必须有，而且要在设计上刻意让它“低频率、小范围、可扩展”。

我的做法是：每5分钟跑一次扫描，只捞“理论上早就该被关闭但还没关闭”的订单。SQL 类似：

SELECT order_no, version FROM orders WHERE status = 'PAY_WAITING' AND expire_time < ? AND expire_time > DATE_SUB(NOW(), INTERVAL 30 MINUTE) LIMIT 200;

?参数是当前时间，DATE_SUB(NOW(), INTERVAL 30 MINUTE)是往前推30分钟作为下界。为什么要有下界？因为正常情况下，超时5分钟内的订单应该已经被延迟队列处理掉了；如果扫到超过30分钟还没关的订单，说明这些订单大概率是延迟队列漏掉的，需要立即处理。这样每次扫描的数据量很小，索引也能高效命中，对主库的压力非常有限。

扫描到了订单之后，不能直接“一次性批量关闭”。200条订单要一条条读、一条条处理，每处理完一条就更新数据库。这样既避免了长事务持有锁，又能保证某条订单下游处理失败时，其他订单不受影响。扫描任务本身要做成分布式锁互斥的，只在集群中的一台机器执行，避免每台机器都去扫描一遍造成重复。这个锁可以用 Redis SETNX 实现，带过期时间，比如超过10分钟自动释放。

兜底扫描和延迟队列的关系是“互补”而不是“重复”：延迟队列处理准时到期的绝大多数订单，兜底扫描只捞异常漏掉的订单，两者最终目的都是保证超时订单最终被关闭。我见过一种错误设计：延迟队列处理一轮，扫描任务又马上把同样的订单捞出来再关一轮，导致下游库存接口被重复调用。避免方式很简单——乐观锁更新，只有status='PAY_WAITING'的订单能被关闭，一旦关闭成功，其他进程再执行UPDATE时影响行数为0，相当于天然过滤掉了重复任务。

3.4 关闭订单的完整动作：释放库存、退券、通知一个都不能少

超时关单不是改一个字段就完事。订单状态从PAY_WAITING变成CLOSED之后，至少要联动这些动作：释放预占库存，恢复商品可售数量；退回用户下单时使用的优惠券，让用户能在其他订单重新使用；释放支付渠道的支付额度；给用户发送“订单已超时关闭”的通知。每一步都依赖外部系统或中间件，意味着每一步都可能失败。

我推荐的做法是把“状态更新”和“外部资源释放”拆开。先做状态机更新，再发释放动作。状态机的更新 SQL 长这样：

UPDATE orders SET status = 'CLOSED', close_time = NOW(), version = version + 1 WHERE order_no = ? AND status = 'PAY_WAITING';

如果影响行数为1，说明关单成功，继续执行后续的释放库存、退券、发通知；如果影响行数为0，说明订单已经被其他请求改过状态（比如用户刚完成了支付），就不能再执行关单动作，直接结束。这样既保证了并发安全，又避免了“用户支付和系统关单同时发生”时，系统把已支付订单错关掉的严重事故。

后续的释放动作不一定都要同步执行。库存释放和优惠券退回，建议走 MQ 异步处理，因为这两个动作有独立的业务系统，强依赖它们会让关单的 RT 变得不可控。通知类任务更不需要同步，发个消息给消息中心就行。真正需要同步的只有数据库状态更新——这是关单的“落账”动作，必须确定成功。如果你承担不起“关单成功但库存没释放”的后果，那么异步失败的任务必须落到一张失败任务表，由定时补偿任务反复重试，直到成功。比如库存释放的任务表可以这么设计：id, order_no, task_type(INVENTORY/COUPON/NOTICE), status(INIT/SUCCESS/FAIL), retry_count, next_retry_time。补偿任务扫描status='FAIL' AND next_retry_time < NOW()的记录，重新执行，重试超过5次后进入人工处理队列。

4. 组件宕机后的恢复与容错：我经历过的一次真实故障复盘

4.1 宕机发生时，线上到底会出现哪些异常

去年大促备战期间，我们线上遇到过一次 Redis 集群异常，恰好发生在晚上10点到11点的下单高峰期。Redis 是超时延迟队列的存储，它挂了之后，新创建的订单照样正常写库，也能正常支付，但“超时关单”这条链路直接失去触发源。因为延迟队列的消费者无法从 Redis 拉取到期订单，原本30分钟自动关闭的订单，在故障期间全部停留在PAY_WAITING状态。这不是最糟的，因为我们有兜底扫描，每5分钟还能捞一批超时订单。但兜底扫描捞的是“已经超时超过一段时间”的订单，Redis 挂掉的前几分钟内到期的订单会晚一会儿才被扫到，痛感不明显。

比较明显的异常出现在库存侧。部分商品明明有库存，用户下单时却提示库存不足。查了下原因：一些恶意用户利用超时关单失效的时间窗口下了大量订单并锁住库存，正常用户自然买不到。这就是为什么我说“超时关单是交易链路里的定时炸弹”而不是“后台小任务”——它的失效不会立刻让你看到系统报错，但会以业务数据异常的方式慢慢体现出来。

更隐蔽的是对账问题。交易系统和财务系统每天凌晨对账，如果超时关单在当天某个时段停摆，部分订单状态停留在等待支付，而财务侧已经按“锁定资金”处理，两边数字就对不上。这时候你收到告警短信，说对账差异超过阈值，排查时才发现源头是 Redis 故障导致的关单积压。所以组件宕机的排查不能只看表面报错，要主动关联业务指标的变化，特别是订单状态分布、库存变化、对账差异这几类指标。

4.2 恢复流程与自愈机制：先保基础组件，再清积压

Redis 恢复后，第一件事不是立刻把消费进程全速跑起来，而是先评估积压量。如果故障了30分钟，延迟队列里可能有十几万到几十万条到期任务未消费。消费者进程如果全速拉取并执行关单，数据库瞬间会被打满，可能引发新的数据库故障。正确做法是把消费速度限住，比如先按正常速率的50%处理，观察数据库和下游库存系统的负载，稳定后再逐步调满。

清理积压的顺序也很有讲究。延迟队列只存储了超时订单的触发信号，真正要处理的是数据库里的订单状态。所以我会先跑一轮兜底扫描，把故障期间“早就该关的单子”捞出来按批次关掉；等数据库侧积压降下去后，再放开延迟队列消费者，让它处理新产生的到期任务。这样做的原因是：扫描任务捞单子逻辑简单、压力可控，而延迟队列消费者一旦全速跑，会同时处理大量不同时间点的到期任务，容易把下游库存和优惠券服务瞬间打爆。

自愈机制需要在日常就准备好。我的做法是给所有订单状态流转增加“对账告警”：每分钟统计一次PAY_WAITING且expire_time超过当前时间10分钟以上的订单数量，这个数字持续大于某个阈值就告警。有了这个监控，故障发生时不需要靠用户投诉才能发现，告警会比业务损失更早一步拉响。恢复流程也要演练过，比如每个季度做一次“模拟 Redis 不可用30分钟”的预案演练，团队里每个人都清楚：第一步看监控、第二步确认基础组件恢复、第三步限速消费、第四步核对对账差异。

4.3 T+1对账与人工补偿：数据最终一致性的最后一道防线

即使有延迟队列和兜底扫描，分布式环境下仍然存在某条订单既没被延迟队列处理、也没有被扫描捞出来的“永远漏网”的可能。比如延迟队列消息丢失，同时订单表索引异常导致扫描没捞到。这种极端情况，只能靠对账机制兜底。我实现的是一套T+1对账任务：每天凌晨，扫描订单表里status='PAY_WAITING'且expire_time已超过24小时的所有订单，把它们整理成清单推送给运营和研发。正常情况下这个清单应该是空的，一旦出现数据，就意味着线上存在漏关单，需要走人工处理流程。

人工处理的第一步，是把这些订单单独捞出来确认原因。大部分情况是延迟队列和扫描都处理过，但有一条订单在下游库存释放时失败并进入了死信队列，还没有被补偿任务捡起来。少部分是订单状态被其他事务锁住，扫描一直没成功更新状态。针对这些问题，会先手动执行一次补偿：更新订单状态、释放库存、退券。如果个别订单下游依赖还是异常，就先标记为“特殊处理”，由业务方决定是否补偿用户。

这里我要特别提醒一点：对账清单的处理过程一定要留痕。谁处理的、处理了哪些订单、每一步变更了什么，都要有记录。超时关单看起来简单，但它是交易状态机的一部分，任何人工改动都可能引发资金、库存、优惠的连锁反应。留痕不是为了追责，是为了下次出现问题时有据可循。我在这块踩过坑：人工在数据库里把订单状态从 PAY_WAITING 改成 CLOSED，但没有调用库存释放接口，结果库存在系统里“消失”了整整7天才被盘点发现。

5. 常见问题与排查技巧：超时关单场景的避坑指南

5.1 并发下重复关单，幂等设计怎么负责

很多第一次写超时关单的同学，代码逻辑是“查出订单 -> 判断状态 -> 更新状态”。这在并发下是有问题的。假设两个线程同时查到订单状态是 PAY_WAITING，都判断可以关单，先后执行更新，订单就被关闭了两次。如果更新逻辑里还有“释放库存”的操作，库存就会被释放两次，产生负数库存或重复发放记录。

正确的设计是【状态机+乐观锁】。更新时必须携带期望的状态条件，还是上面那段SQL：UPDATE orders SET status='CLOSED' WHERE order_no=? AND status='PAY_WAITING'。影响行数为1，说明这次关单“赢”了；行数为0说明订单状态已经不是 PAY_WAITING，要么已经关了，要么用户已经支付了。这样，线程A成功更新后，线程B执行同样的更新会被拦截，后续释放库存的操作就不会重复执行。而且这套逻辑不管是在延迟队列处理，还是兜底扫描处理，还是人工手工补偿，都能适用——只要严格执行状态条件，就不会出现重复关单。

还有一个容易忽略的细节：关闭订单和支付到达之间是有天然竞争关系的。用户在第29分59秒点击支付，支付系统正在回调更新订单为 PAID，同时超时任务恰好执行，两个操作同时发生。如果支付回调先更新成功，超时任务再执行 UPDATE，status='PAY_WAITING' 条件不满足，任务失败且不能关单——这是正确行为。如果超时任务先更新成 CLOSED，支付回调才来，怎么办？这时支付回调也要检查状态：不能把已关闭的订单再更新为 PAID。要么提示用户“订单已关闭，请重新下单”，要么在支付成功后立即检查订单状态并触发退款。这个分支必须在支付回调代码里处理，否则会出现“钱扣了、订单关闭”的恶劣事故。

5.2 延迟队列消息丢失了，如何发现和补救

Redis ZSet 持久化如果不当，消息丢失在故障场景下是大概率事件。Redis 的持久化有 RDB 和 AOF 两种。RDB 是快照，默认可能几分钟才做一次，宕机时丢失的是最近几分钟的写入；AOF 是追加日志，可以配置appendfsync everysec，最多丢1秒的数据。对延迟队列来说，丢1秒甚至几秒数据都可以接受，因为有兜底扫描，最后都能补上。但如果配置成appendfsync no或者连 AOF 都没开，宕机恢复后队列数据可能大量丢失，进一步拉长超时订单的处理延迟。

发现消息丢失不能靠“看 Redis 里还有多少任务”，而要靠“业务侧闭环”：关注超时未关单数量。我会在监控面板上放一个趋势图：每分钟PAY_WAITING且expire_time已超过15分钟的订单数。正常情况下这个数字趋近于0；如果出现持续增长，基本可以断定延迟队列出了问题（消费者卡住、消息丢失或 Redis 不可达）。此时立刻看兜底扫描任务是否在正常执行——如果扫描任务也停了，就是双链路同时故障，必须人工介入。

补救手段分两级：第一级，恢复 Redis 并启动消费者，处理积压任务；第二级，如果 Redis 数据确实丢了部分任务，直接靠兜底扫描把“漏网之鱼”捞回来。兜底扫描是定海神针，任何时候都不能停，而且要保证它有独立于 Redis、MQ 之外的资源和监控。我在项目里是把扫描任务单独部署在一组小规格实例上，杜绝“所有任务都跑在同一台机器、同一个故障域”的配置。

5.3 必须盯住的监控指标与告警阈值

超时关单的监控不能只看“任务有没有执行”，要看结果。我通常分成四大类指标：

• 延迟指标：expire_time超过当前时间 5 分钟、10 分钟、30 分钟仍未关闭的订单数量。这是最直接可感的健康度指标，单独看每个区间，可以快速定位处理能力的瓶颈。
• 吞吐指标：每分钟成功关闭的订单数、失败订单数、处理耗时P99。P99 如果持续超过 200ms，就要怀疑数据库慢查询或下游接口超时。
• 组件指标：Redis 队列积压数量、MQ 消费积压数量、扫描任务最近一次执行时间。扫描任务“最近5分钟没有执行”就要告警，这类任务不能依赖日志文件判断死活。
• 数据一致性指标：T+1 对账差异单数、手动补偿单数、失败任务表中的积压数量。

告警阈值建议分三级：一是黄色告警，超时未关订单数超过1000且持续5分钟，说明有轻微积压；二是橙色告警，超过5000且持续10分钟，需要立即查看消费进程；三是红色告警，超过10000或扫描任务超过15分钟未执行，必须拉群处理。阈值要根据日常订单量动态调整，比如大促期间阈值要放大，否则大促流量稍微一高，告警就开始轰炸，大家会逐渐麻木忽视告警，真正出事时反而没人响应。

5.4 大促前如何压测和评估容量

大促前对超时关单链路做容量评估是必须的。很多人只评估下单、支付、库存这几条主链路，把超时关单当做“后台任务”忽略掉，这是大忌。大促流量一定是平时的几倍甚至几十倍，下单量翻倍后，30分钟后需要关单的订单数量同步翻倍，延迟队列的消费压力、数据库的更新压力都会放大。

我用过一套相对简单的估算方法：假设大促峰值每秒下单量是 N，超时时间是 T 分钟，积压在队列中的订单总数约为N * T * 60。比如 N=500单/秒、T=30分钟，那么延迟队列里预计有90万个待处理任务。消费者每秒能处理1000条（含关单和释放库存），处理完全部90万个任务需要900秒，即15分钟。如果下游库存系统每秒只能承受200次释放请求，那么关单服务每秒也只能放行200，90万个任务需要75分钟才能处理完，这就是明显的瓶颈。容量规划就是顺着这个链条去算：下单峰值是多少，超时队列积压多少，消费能力、下游承受能力分别在哪里，哪一个最弱就提前扩容或限流。

压测时还要关注一个细节：延迟队列消费者线程池大小和数据库连接池大小要匹配。线程池开100个线程，数据库连接池只有50个，多余的线程都在等待连接，反而增加了线程切换开销。我一般先把数据库连接池设成消费线程数的两倍左右，再逐步压测调整。另外，压测一定要开监控面板盯着，不能只用压测工具看吞吐，要让实际的监控数据告诉你瓶颈在哪。我在一次压测中就发现，订单状态更新并不慢，慢的是释放库存时调用的一个外部接口，P99达到800ms，最后对该接口做异步批处理才解决。

我个人在实际操作中的体会是，超时关单的代码逻辑并不复杂，真正难的是把“可靠”“可控”“可观测”这三个词落到每一个环节。延迟队列、兜底扫描、状态机更新、失败重试、对账补偿，这套组合下来，订单超时处理才能算一个能让人睡得着觉的系统。最后再分享一个小技巧：任何一次订单状态变更，都建议在变更表里留一条变更记录，带上新旧状态、操作来源、操作时间。平时它只是多写一条数据，但遇到纠纷、对账差异、用户投诉，它就是还原真相最快的线索。