S41：Crash / Resume 与 Exactly-once 的边界
所谓 exactly-once 往往只在特定日志或事务边界内成立；跨外部系统的业务效果通常依靠至少一次投递、幂等、去重和对账实现“有效一次”。
内容类型：预习教材（不代表已完成）
日期：2027-01-02
阶段：P2 · AI Systems Engineering 90
总路线：Day 131 / 360
周次：W6 · Agent Runtime & Durable Workflow
节奏：周六可选探索 / 补学
状态：教材已备；学习未完成
标签：crash-resume、exactly-once、at-least-once、effectively-once、optional
一句话定义
所谓 exactly-once 往往只在特定日志或事务边界内成立；跨外部系统的业务效果通常依靠至少一次投递、幂等、去重和对账实现“有效一次”。
学习目标
- 区分消息投递次数、处理次数、状态提交次数和业务效果次数。
- 能找到 crash/resume 中的原子性缺口。
- 理解 exactly-once 声明必须带作用域、条件和失败假设。
- 可选地做一次最小崩溃推演，不把它变成压力测试。
核心知识
- At-most-once 可能丢失但不重投；at-least-once 不轻易丢失但会重复；exactly-once 需要限定观察边界。
- 某流系统可在自己的日志与状态存储内原子提交 offset 和结果，但调用外部支付 API 后，这个原子边界通常不再覆盖业务效果。
- “Effectively-once” 是工程目标：重复消息到达时，通过稳定 key、幂等消费者、结果缓存和 reconciliation 让可观察业务效果像一次。
- Crash 发生位置决定语义：保存 checkpoint 前、外部效果前、效果后确认前、确认后响应前各不相同。
- 两将军问题等理论提醒我们：网络不可靠时，双方无法凭有限确认获得绝对共同知识。工程上要暴露不确定性而非承诺魔法语义。
机制与推导
假设处理包含 read message → write local state → call external API → ack message。没有分布式事务时，无法让四步天然原子。交换顺序只会移动窗口：先 ack 可能丢业务，后 ack 可能重复。因而设计组合通常是：
durable inbox + business idempotency key
+ transactional local state/outbox
+ idempotent or queryable downstream
+ reconciliation for remaining uncertainty
Exactly-once 评审应问：对哪个实体一次？在哪段时间？谁是权威观察者？故障包括进程、网络分区、存储回滚和人工重发吗？若无法回答，术语本身没有足够信息。
最小练习或观察步骤
- 任选一个无真实副作用的小 workflow，在四个步骤之间标出崩溃点。
- 对每个点写恢复后可能出现丢失、重复还是未知。
- 选择一个稳定业务 key，说明它的作用域与保留期。
- 写一句准确声明，例如“在本地 inbox+state 事务内不重复提交；外部效果依靠下游 key 与对账”。
- 精力不足可完全跳过；不需要实现消息代理或真实故障注入。
常见误区与边界
- 把 Kafka/数据库某一层 exactly-once 直接延伸为端到端业务效果 exactly-once。
- 通过无限保留去重 key 回避生命周期设计。
- 对不可查询下游仍自动重复高风险动作。
- 只测试进程崩溃，不考虑网络迟延、响应丢失与操作员重发。
- 用“理论不可能”作为不做幂等和对账的借口。
- 本日是可选探索，不要求证明形式化正确性。
系统 / 金融 / Web3 场景连接
支付系统不会只靠消息中间件承诺“不重复扣款”，还使用业务流水号、账务幂等和日终对账。Web3 交易以 nonce 防止同账户同序列重复，但替换交易、跨链消息和最终性仍产生新的作用域，不能概括为全链 exactly-once。
自检问题
- 消息 exactly-once 与业务效果 exactly-once 有什么差异？
- 调整 ack 顺序为什么不能消除所有窗口？
- “有效一次”需要哪些机制组合？
- 一个 exactly-once 声明应注明哪些条件？
专业课程对齐
- 阅读 MIT 6.5840 Distributed Systems 的 RPC、fault tolerance、consensus 主题，具体理解失败与网络不确定性怎样限制端到端“一次”保证。
- 阅读 Temporal 官方文档 的 Activity retries 与 durable execution 概览，观察 workflow 确定性并不自动让外部 activity 具备 exactly-once 效果。
- 阅读 CloudEvents 官方站点 的事件标识与 envelope 概念，比较 event identity 与业务效果 identity，避免把去重事件误当业务幂等。
深入学习提示
若继续探索，只做“声明审计”：找一句 exactly-once 宣称，补齐其范围、权威状态、保留期和故障模型。再用一个外部副作用反例检验。无需追求形式化证明；能把含糊承诺改写成受条件约束的保证，就是本日核心能力。
学后填写区
- 今日选择（休息 / 概念回看 / 小推演）：
- 我限定的 exactly-once 作用域：
- 一个无法消除的窗口：
- 可采用的工程组合：
- 未验证部分：