READ · UNDERSTAND · TRANSFER
阅读理解，按需巩固
先沿着原理、问答和迁移案例阅读。需要检查理解时，再切换巩固练习或展开个人记录。
核心知识 · Saga 中已发生事实与条件补偿
先理解核心原理
先备概念：跨服务事务、结果未知与对账、业务授权
补偿是另一个可能收费、失败或不可逆的业务动作，不是抹掉历史。先确认正向结果，再按条款、依赖和授权决定是否补偿，补偿自身也要可恢复。
本地失败不意味着外部未完成
订机票超时可能已出票，酒店也已经真实预订。把本地状态回到 initial 只会丢掉事实，不会取消订单。先以稳定订单身份确认成功、失败或未知，未知不直接触发撤销，否则可能把完整行程拆坏。
补偿恢复业务可接受性
数据库回滚撤销未提交的写入，Saga 补偿面对已提交的多个系统事实。退款不一定退手续费，删报告不能撤回读者已看内容。为每步记录成功回执、补偿动作、条件、截止时间和不可补偿原因。补偿顺序由依赖决定，通常反向处理相关步骤，但独立资源可以并行，特定业务还需先做保护动作。
补偿也存在未知和竞态
取消请求超时可能已成功，下一次沿同一 compensation_id 对账或幂等重试。补偿与正向操作各有身份，不用一个状态覆盖两种结果。并发补偿或用户手工改订单时需要业务版本检查。AWS Saga 文档强调参与者幂等，也指出缺少事务隔离，编排器不能凭自己的旧记录替代当前业务状态。
故障收尾必须可解释
状态显示已订、待确认、正在补偿、已补偿或需人工处理，而不是统一“已回滚”。涉及费用与披露要在原批准范围内，范围不够则给用户具体选项。验收覆盖机票确认失败、机票未知后来成功、酒店不可取消、取消响应丢失和过期；案例只是设计练习，实际条款与效果需对目标系统验证。
回到问题：怎样回答？
先确认用户授权、酒店取消条款和失败是否确定，不能把补偿理解为数据库回滚。每步记录业务回执、补偿条件和截止时间；需要补偿时也使用幂等操作并保存结果。若机票结果未知，先核对而非立即撤销酒店；若补偿有费用或不可逆，应按原授权范围处理或等待确认，并向用户说明当前真实状态。
实现与取舍
先判断失败还是未知
机票接口超时可能已经出票，直接取消酒店会制造不一致。用订单号查询机票状态，将未执行、已执行和未知分开。跨系统没有单一数据库事务时，应按业务流程管理已提交事实；任何本地状态回退都不能抹掉酒店订单。
设计补偿动作
步骤定义正向动作、成功回执、补偿动作、补偿前提和不可补偿原因。退款、取消预订或发布更正都不是原动作的精确逆操作，可能有手续费或外部通知。补偿按依赖关系安排，独立步骤可以并行，强依赖步骤需按业务顺序；不能无条件对所有步骤倒序调用删除。
补偿也会失败
补偿请求需要自己的 operation_id 和回执核对，重试仍受预算与截止时间约束。状态可区分 compensating、compensated、compensation_failed 和 manual_review。让人工看到已完成哪些动作、哪些失败、下一步可选方案，而不是统一显示“任务失败”。
通过故障矩阵验证
测试酒店成功机票失败、机票超时后确认成功、酒店不可取消、补偿请求响应丢失以及用户中途撤销。验收既看最终业务状态，也看是否发生未授权费用和重复补偿。框架的 Saga 模式提供编排思路，补偿的合法性与经济损失仍由业务规则决定。
工程推演
- 场景
- 面试假设：行程 Agent 预订酒店后，机票调用超时。
- 设计决策
- 先查机票订单，再按取消条款和用户授权决定补偿。
- 验证目标
- 用户看到真实预订状态，补偿失败可人工接管。
- 适用边界
- 这是流程设计题，实际费用与取消规则由供应商决定。
连续追问与解答
沿着问题的前提和约束继续向下读。先理解参考解答，再尝试收起答案，用自己的话解释因果和取舍。
第 1 层取消酒店要扣款，原批准覆盖吗？
从是否补偿进入补偿动作自身的授权与经济条件。
参考解答
只有原批准明确包含对应取消条件和费用上限时才可能覆盖，不能由“同意预订”推断“同意损失费用”。重新核对当前取消条款、金额与期限，超范围则暂停并展示具体代价供确认。也要避免等待导致费用变化，向用户说明截止时间。
第 1 层补偿请求也超时怎么办？
正向未知之外，补偿也有远端成功本地未确认窗口。
参考解答
记录补偿结果 unknown，以同一 compensation_id 或订单号查状态；已取消就确认回执，不重复创建退款等动作。若目标支持幂等可沿同键重试，仍受截止时间与预算；无法查询就转人工核实，不能宣称已回滚。
沿着这个回答继续深入
第 2 层查询显示仍有效，就立即再次取消可以吗？
父问对账后，查询一致性与异步状态让结论仍可能未知。
参考解答
先了解状态查询是否强一致以及取消是否异步。旧视图“有效”可能对应取消处理中，重试沿同补偿身份而非创建新动作；等待约定可见性窗口并检查处理中回执。仅凭一次查询未变化，不能证明上次取消失败。
沿着这个回答继续深入
第 3 层取消截止时间马上到，仍查不清，自动重试还是等人工？
不确定结果叠加时间压力，要求业务策略提前定义而非故障时臆断。
参考解答
按预先定义的授权与风险策略决定：目标支持幂等且费用在范围内，可有限沿键重试；不支持且重复费用风险不可控则暂停、告警并提供状态。不能临时用模型猜风险偏好。记录截止时点和已尝试动作，让人工有具体事实可判断。
第 1 层是否所有补偿都必须倒序？
补偿机制进一步要求理解依赖而非栈操作。
参考解答
不必须机械倒序。根据业务依赖图安排，先撤销依赖下游以避免孤立资源；独立步骤可并行，有些保护动作应先执行。补偿可能无法还原原状，设计时写清每步前提与顺序理由，不把“最后做的先删”当通用证明。
举一反三：条件变了，怎样推导？
先找出改变的条件，再判断原方案中哪些前提仍成立。下面的案例是教学推演，便于将原理迁移到新问题。
已公开发布报告
改变的条件：动作影响到第三方读者
延伸问题：删除文件就是完整补偿吗？
推导与参考解答
不是，读者可能已经下载或基于报告行动。可以撤下入口、发布更正、通知受影响者，但各动作有自己的授权与回执，无法恢复到从未发布。状态应说明哪些影响可处理、哪些不可逆，不能显示“事务已回滚”。
保持不变的原理：补偿改善当前业务状态，不抹除已经发生的信息传播。
库存已扣但支付未知
改变的条件：资金与库存两个事实未同时确定
延伸问题：能立刻补回库存吗？
推导与参考解答
先查询支付结果；若支付成功但库存已补回，可能造成付费无货。采用保留状态和超时规则，在未知期间暂不重复出售该库存，按权威支付回执决定履约或退款。不同业务可选择风险策略，但必须明确资金与库存的一致性窗口。
保持不变的原理：补偿需要已确认的事实与依赖条件，超时不自动触发逆动作。
易错点
- 超时直接当失败
- 所有动作都假设可撤销
- 补偿失败仍显示已回滚
参考资料
依据公开技术资料设计；参考资料支持技术机制，场景与评分标准为本站设计，不代表某公司面试原题。 新增问答与迁移案例用于原理讲解，来源核查与案例运行验证分别记录。
检查自己理解到哪一步
读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评；需要进一步验证时，再完成下方小任务。
- 基础达标
- 能区分不可抹除的外部事实与业务允许的补偿动作。
- 中高级信号
- 设计回执核对、补偿前提与逐步状态。
- 资深信号
- 能处理补偿失败、费用授权和人工收尾。
巩固练习 按需完成 · 建议 15 分钟
为酒店和机票两步流程列出失败矩阵及允许的补偿动作。
展开验收要求与检查点
- 未知结果先核验
- 费用动作重新检查授权
- 补偿失败不伪装成功
重点检查
- 不把补偿视为数据库回滚
- 先核对未知结果
- 补偿有授权、幂等和失败状态