分布式事务的故障恢复，本质上不是“重试”的问题，而是“精确执行一次”的问题。当一个分布式事务因网络抖动、节点重启或锁冲突而超时，直接发起重试会带来一个致命风险：事务的某些分支可能已经在远端提交成功，只是协调者没收到响应。如果盲目重试，就会导致数据错乱。解决这个问题的核心，在于将“超时检测”与“幂等操作”绑定在一起，形成一套闭环的异常处理机制。

超时的本质：不确定性窗口

在分布式系统中，一次远程调用超时，对调用方而言意味着一个“未知”状态。被调用的节点可能已经完成了持久化，也可能在提交前崩溃了，甚至可能仅仅是网络链路拥堵导致响应报文丢失。这个不确定性窗口，是分布式事务所有复杂性的根源。你不能简单地取消事务，因为可能已经有一部分数据落盘；你也不能简单地重试，因为可能造成重复扣款或重复发货。正确的做法是，将每一次事务分支的调用都设计成幂等操作，让重试变得安全。

幂等设计的三种落地模式

幂等意味着同一个操作执行一次与执行多次，产生的副作用完全相同。在分布式事务场景中，实现幂等通常有三种成熟模式。第一种是“唯一键约束”，这是数据库层面最硬的兜底。以转账为例，事务流水表上对“交易流水号”建立唯一索引。当重复的扣款指令到达时，INSERT操作会因为主键冲突而失败，业务层捕获这个异常后，直接返回成功即可，因为这说明该笔操作已经完成。第二种是“状态机约束”，适用于订单、审批流等长流程事务。订单的状态从“待支付”变为“已支付”是一个单向操作，在UPDATE语句的WHERE条件中带上前置状态，例如 

UPDATE orders SET status = 'paid' WHERE order_id = ? AND status = 'pending'
。如果重试执行这条SQL，由于status已经不再是pending，受影响行数为0，业务层据此判断为重复请求，直接丢弃或返回已有结果。第三种是“Token机制”，适用于插入操作无法通过唯一键约束直接覆盖的场景。调用方在发起事务分支前，先向服务端申请一个全局唯一的Token，服务端将该Token存入Redis并设置与事务超时时间一致的过期窗口。实际执行时，服务端通过原子命令删除该Token，删除成功则执行事务，删除失败（Token不存在）则直接返回成功。这三种模式可以组合使用，唯一键约束作为底层兜底，状态机处理更新操作，Token机制处理无实体键的插入场景。

超时重试的策略与陷阱

有了幂等保障，重试策略才能真正发挥作用。重试绝不是简单的while循环，它需要精心设计退避算法和终止条件。常见的做法是采用指数退避配合随机抖动，避免在服务端刚恢复时造成“惊群效应”。例如，第一次重试等待1秒，第二次等待2秒，第三次等待4秒，同时每次在基础等待时间上增加一个随机毫秒数。但更重要的是，重试必须有明确的截止时间，这个截止时间应小于上层业务调用方的超时时间，防止重试无限递归。一个容易被忽视的陷阱是“重试放大”。如果事务协调者向三个参与者发送指令，其中一个超时，协调者只应重试那个超时的分支，而不是重试整个事务。这就要求协调者记录每个分支的执行状态，做到精细化的失败恢复。另一个陷阱是网络分区下的假活锁。当协调者与参与者之间发生网络分区，参与者实际存活且已提交，但协调者持续重试失败。此时，单纯的重试无法解决问题，需要引入“反查机制”，即协调者通过一条独立的控制通道定期查询参与者的事务状态，一旦确认已提交，立即终止重试并标记事务完成。

事务协调者的状态持久化

重试能够正确执行的前提，是协调者自身不能丢失事务上下文。如果协调者重启后忘记了曾经发起过哪些事务，那么即使参与者具备幂等能力，协调者也无法发起重试，事务将永远悬挂。因此，协调者必须将事务日志持久化到磁盘，通常采用WAL（预写日志）机制。在发起任何RPC调用之前，先将事务的全局ID、各个分支的调用参数、当前状态写入日志并刷盘。当协调者崩溃恢复后，首先重放日志，对于状态为“处理中”的事务，根据其分支状态决定是重试提交还是回滚。这种设计将分布式事务的恢复问题，转化为了一个本地状态机的重放问题，大大简化了系统复杂度。

回滚的幂等性同样重要

讨论幂等设计时，人们往往聚焦于正向操作的“提交”，而忽略了反向操作的“回滚”。如果回滚操作不具备幂等性，同样会造成灾难。例如，一笔转账的正向操作是A扣款、B入账，回滚操作是A入账、B扣款。如果回滚指令因超时而重试，可能导致A被重复入账。回滚操作的幂等设计通常依赖于“补偿流水”表。每执行一次回滚，都先尝试插入一条补偿记录，利用唯一键约束保证一次回滚只生效一次。同时，回滚逻辑需要识别“空回滚”的情况，即正向操作根本没有到达参与者，此时回滚请求到来，参与者应直接返回成功，而不是报错。这要求参与者在收到回滚请求时，先去查询是否存在对应的正向流水，若不存在则记录一条“已回滚”的占位标记，防止后续迟到的正向操作被执行。

超时时间的动态调整

静态的超时时间无法适应生产环境的波动。一个固定3秒的超时设置，在业务高峰期可能因数据库连接池耗尽而导致大量事务超时，触发海量重试，进而加剧系统负载，形成雪崩。更合理的做法是引入自适应超时机制。协调者可以持续采集每个参与者接口的P99响应时间，将超时阈值动态设置为P99的1.5倍到2倍。当检测到连续超时发生时，协调者应主动降低重试频率，甚至进入熔断状态，快速失败并向上层返回明确错误，而不是继续积压重试任务。这种机制要求重试框架与熔断器紧密结合，将“重试”视为一种对下游的请求，同样受到熔断状态的约束。

实际落地中的架构取舍

在工程实践中，并非所有场景都需要完整的分布式事务框架。如果业务能接受最终一致性，那么将同步的重试转变为异步的消息投递，是更优的选择。利用本地事务表与消息队列的组合，将事务分支的调用转化为一条待发送的消息，由后台Job定时扫描并发送。这种模式下，超时与重试的复杂度被消息中间件的可靠性投递机制所接管，业务层只需保证消息消费的幂等性即可。但对于需要强一致、同步返回结果的场景，TCC（Try-Confirm-Cancel）模式仍是主流。在TCC中，Try阶段负责资源预留，Confirm阶段负责确认提交，Cancel阶段负责释放资源。超时重试主要发生在Confirm和Cancel阶段，因为Try阶段已经通过资源预留锁定了关键数据。Confirm和Cancel操作必须是纯粹的幂等操作，通常通过业务主键加状态位来实现。一个关键细节是，TCC的协调者在发起Confirm之前，必须确保所有参与者的Try都成功，任何Try失败都会导致全局Cancel，这种“一票否决”机制避免了部分提交的尴尬局面。

监控与可观测性

没有度量的重试是盲目的。必须为分布式事务的每一次重试埋点，记录事务全局ID、当前重试次数、耗时、最终状态。当重试次数分布出现异常峰值，或某个参与者的重试比例突然升高，通常意味着底层基础设施出现问题。通过将这些指标接入告警系统，可以在用户感知到数据不一致之前，就介入处理悬挂事务。同时，所有因幂等校验而拦截的重复请求，都应记录为INFO级别日志而非ERROR，避免干扰正常的告警阈值。这些日志是排查数据一致性问题的第一手资料，需要包含完整的调用链上下文。

分布式事务的超时重试与幂等设计，本质上是在不确定性中构建确定性。通过唯一键、状态机、Token机制保证操作的可重复执行，通过协调者日志保证恢复能力，通过动态超时与熔断保证系统的韧性，这套组合拳才能让分布式事务在不可靠的网络之上，提供可靠的业务语义。