分布式流程恢复
分布式流程恢复结合重试、对账和受控修复。本文负责业务标识、恢复状态和差异处理。
1. 面试核心
先记住这几条，再读正文- 稳定业务标识。 稳定业务 ID 让重试、重放和人工补单识别同一动作。
- 请求意图。 幂等键绑定请求意图，同键异参应返回冲突。卡 · 幂等键的语义与生命周期
- 状态转换。 状态机用条件转换拒绝迟到消息覆盖合法终态。
- 对账发现。 对账比较权威数据与目标结果，发现静默差异。卡 · 综合题
- 受控修复。 人工修复复用业务校验与幂等机制，并保留审计。
2. 稳定业务标识
全局流程 ID、步骤 ID 与支付单号首次创建后保持稳定。事件 ID 标识同一事实的重复投递。重试时使用原 ID，新的业务动作使用新 ID。
本地幂等记录与业务变化共同提交。唯一约束或条件转换限制重复效果。短期缓存标记只覆盖其有效窗口。
2.1 幂等键的语义与生命周期
幂等键应带租户或调用方范围。服务保存请求摘要、处理状态和最终结果。同键同参重复到达时返回原结果。同键异参说明意图冲突，应返回明确错误。
处理中记录可返回处理中，或等待已有执行结果。服务恢复时根据持久状态继续执行。独立外部副作用还需对方的幂等协议。
保留期需要覆盖重试、死信重放和人工补单。过期后若仍接受旧请求，应能从业务唯一记录识别它。否则要拒绝过期请求，并走专门修复流程。
3. 状态机
订单可从 PENDING 进入 PAID 或 CANCELLED。迟到支付通知遇到 CANCELLED 时，应进入核对或退款分支。它只提供支付事实，不直接覆盖订单终态。
SQL 以版本或当前状态作为条件。影响 0 行时，读取状态区分已完成、过期和非法转换。
4. 错误分类与重试
暂时性网络失败和限流可有限退避重试。参数错误、账号冻结或结构不兼容需修复输入。
外部结果未知时，先查询原业务 ID。对方支持幂等重试时，也可沿用原键重试。步骤记录尝试次数、下次时间和最后错误。达到上限后转入明确待处理状态。
5. 对账
对账先明确每类事实的权威来源。支付渠道流水说明外部扣款结果。内部账务说明已登记的资金变化。搜索索引则是数据库的派生结果。
核对使用主键、金额、版本和状态。只比总数会让一条多和一条少相互抵消。关键业务需下钻到具体差异记录。
6. 增量扫描
增量任务记录扫描范围、游标和检查点。按更新时间扫描时，使用时间与主键组成稳定顺序。相同时间戳和延迟提交需通过重叠窗口补查。
重叠窗口仍有范围边界。周期全量核对用于发现长期遗漏。修复任务本身也需幂等，才能安全从检查点恢复。
7. 自动修复
权威记录明确且操作可重放时，可以自动修复。例如数据库版本高于索引版本，可重建该投影。
修复写入需检查目标版本，避免覆盖新的合法变化。金额、数量和范围设定上限。含义不明或存在多种解释的差异进入人工队列。
8. 人工修复
修复工具发送业务命令，记录操作者、原因和工单号。命令复用正式业务的鉴权、状态校验和幂等能力。
高风险操作可使用预览、双人审批和金额上限。每次操作保留不可变审计，并提供结果查询。执行后重新对账。
9. 修复演练
演练注入重复、乱序、丢事件和外部结果未知。验证告警、差异定位、重放和人工入口。
恢复耗时需在接近生产的数据量下测量。发现时间与修复时间都应有目标。
10. 常见问题
10.1 投递保证与业务对账
至少一次投递覆盖定义范围内的消息交付。漏生成事件、错误确认和人工改表仍会造成差异。业务对账从结果检查这些缺口。
10.2 人工修复的边界
人工处理适合事实含混或风险过高的状态。可靠性取决于操作是否受约束、可审计和可验证。可确定的重复问题应逐步自动化。
11 · 面试题卡片
11.1 分布式流程补偿多次失败后，如何发现并安全修复
出现公司：暂无已核验的公开来源（本站自测）
题型：综合题
考察重点
- 稳定 ID、状态机和有限重试。
- 权威数据、增量对账和确定性修复。
- 人工审批、审计和恢复验证。
参考回答
补偿失败需进入持久、可查询的待处理状态。
先按错误类型有限重试，并保持业务 ID 稳定。外部结果未知时核对原请求结果。
对账从权威数据发现差异。只有操作确定、幂等且版本条件有效时，才自动修复。含混冲突交给受控工具处理，并保留审批和审计。修复后重新核对，再验证恢复时间。
11.2 幂等键相同但金额不同，或者去重记录已过期时，应该怎样处理？
出现公司：暂无已核验的公开来源（本站自测）
考察重点：请求意图、保留期与历史重放。
相关内容：幂等键的语义与生命周期。
参考回答
同键异参应返回冲突，避免把两次业务意图当成一次。
去重记录保留期应覆盖允许的重放窗口。记录过期后，可由业务唯一记录继续识别旧动作。缺少这项依据时，应拒绝旧请求并转受控修复。