4. 回滚保护机制分类

在回滚保护机制设计中，恢复策略的选择直接决定了系统在故障或异常后的行为边界。工程上常见的恢复模式可以归纳为五类：前向恢复、后向恢复、补偿事务、快照回滚和版本回退。它们并非互相替代，而是针对不同的失败语义、数据形态和一致性要求，形成互补的保护体系。理解每种模式的触发条件、恢复方向与代价，是设计回滚保护机制的第一步。

一、五类恢复模式的核心原理

前向恢复（Forward Recovery）假设失败发生在执行中途，但目标状态仍然有效。系统通过重试、重放日志或继续执行剩余步骤，把未完成的操作推进到完成态。它适用于幂等操作、可重入流程以及“失败可重试”的场景，例如消息重投、任务重调度、分布式事务的提交阶段重试。前向恢复的关键前提是：操作必须可重复执行且不会产生副作用叠加。

后向恢复（Backward Recovery）则相反，它承认当前路径已经不可继续，必须撤销未完成或已部分生效的操作，回到之前的稳定状态。典型实现包括 undo 日志、回滚段、事务回滚。后向恢复要求系统保留足够的历史信息，并且撤销操作本身是可靠的。它常用于数据库事务、工作流失败回退、批量任务中断处理。

补偿事务（Compensating Transaction）是后向恢复在分布式场景下的延伸。由于跨服务事务无法依赖本地回滚，系统为每个已提交的正向操作定义一个语义相反的补偿操作，例如“扣款”对应“退款”、“预占库存”对应“释放库存”。补偿事务不保证隔离性，只保证最终一致性，因此需要处理补偿失败、补偿重试和补偿顺序问题。

快照回滚（Snapshot Rollback）面向状态整体性要求高的对象。系统在关键时间点对内存、存储或配置生成快照，失败时直接加载快照，恢复到拍摄时刻的完整状态。它的优势是恢复速度快、状态一致性强；代价是存储开销大、快照频率受限，且快照之后产生的合法数据可能一并丢失。

版本回退（Version Rollback）常见于配置、代码、模型和规则引擎。每次变更生成新版本，失败时把生效指针切回旧版本。版本回退通常不修改历史数据，只改变“当前生效版本”，因此恢复速度快、可审计性强。但它要求版本之间兼容，且回退后可能需要处理新版本产生的数据迁移问题。

二、方法流程：如何选择恢复模式

选择恢复模式时，建议按以下顺序判断：

1. 判断失败是否可继续。如果操作幂等且失败原因可消除，优先前向恢复，避免不必要的回退。
2. 判断是否需要强一致。单库事务、本地状态机优先后向恢复；跨服务、跨存储则考虑补偿事务。
3. 判断状态是否可整体还原。内存缓存、配置中心、模型文件适合快照回滚；数据库全量快照成本高，需谨慎。
4. 判断变更是否以版本为粒度。配置、规则、代码、模型优先版本回退，恢复快且可审计。
5. 组合使用。真实系统往往同时使用多种模式，例如“版本回退 + 快照回滚 + 补偿事务”三层防护。

三、案例场景：订单履约链路的多层回滚

以电商订单履约为例，用户下单后依次触发库存预占、支付扣款、优惠券核销、物流单创建。若物流单创建失败，系统不会简单“全部回滚”，而是分层处理：

• 物流单创建本身可重试，采用前向恢复，重试三次仍失败才进入回退。
• 优惠券核销已提交，采用补偿事务，调用“退券”接口抵消。
• 支付扣款已成功，采用补偿事务，发起退款并记录补偿流水。
• 库存预占采用后向恢复，直接释放预占额度。
• 订单状态机整体采用版本回退，把订单从“履约中”切回“待处理”。

回滚保护配置示例（YAML）
rollback:
  forward:
    retry: 3
    backoff: 200ms
  backward:
    undo_log: enabled
  compensate:
    coupon: releaseCoupon
    payment: refund
    max_retry: 5
  snapshot:
    interval: 5m
    retain: 12
  version:
    pointer: active_version
    fallback: previous_stable

四、误区与复盘

复盘时建议重点检查三点：恢复模式是否与失败语义匹配、补偿操作是否可重试且幂等、版本回退后新旧数据是否兼容。只有把恢复方向、一致性目标和代价三者对齐，回滚保护机制才真正可靠。

五、五类模式对比清单