F33｜重试、幂等和事务：为什么超时不是失败证明

从具体对象与小例子开始，理解计算过程与适用条件。

先看最危险的一条时间线

宿主发出“修改文件”→执行器成功写入→返回成功的网络响应丢失→宿主等待超时。如果此时直接重试，可能重复修改；若直接回滚，也可能覆盖后来变化。

所以除了成功与失败，还需要unknown（结果未知）。它描述观察者缺少确认，不是说外部世界处于一种神秘状态。真实动作可能已成功，也可能未发生，需要核验。

幂等不是“重试时最好别出错”

幂等idempotent表示在指定语义下重复相同操作，与执行一次产生相同预期效果。把值设置成10通常比“加10”容易幂等；发邮件通常会造成重复发送，除非服务端另有去重机制。

幂等键idempotency key标识同一逻辑操作意图。重试同一意图复用同一键；两个不同意图不应因为参数偶然相同而被当成一个操作。

服务端需在合适边界持久化键、请求意义与结果，并处理并发、有效期和冲突。客户端自己存一张表，不能自动保证远端动作恰好执行一次。

数据库事务保证到哪里

事务transaction将一组数据库操作作为受控单元处理，常讨论原子性、一致性、隔离性和持久性。这里的“原子”是外部观察者不看到这组操作的半完成状态，具体保证取决于数据库与隔离等级。

数据库提交了记录，不代表同一时刻外部文件或邮件系统也一起提交。两个系统没有共享事务边界时，需要额外协议、核验或补偿，而不是把它们放在同一个函数里就获得原子性。

CAS怎样避免覆盖新版本

CAS（compare-and-swap，比较后交换）表达“只有当前状态仍与我读到的一样，才写入新状态”。例如读取文件版本7，准备补丁；提交前发现已变8，就拒绝覆盖并重新检查。

比较必须与更新在相应边界上受保护。普通代码先检查再写，中间若允许别人修改，仍可能发生TOCTOU（检查到使用之间的竞态）。

原子替换能做什么，不能做什么

本地文件常见方法是写临时文件，再在支持的条件下原子重命名替换目标，避免读者看到半截文件。但持久化到磁盘、跨文件系统、符号链接及与数据库状态同步都有额外条件。

“原子替换”不是“任何断电都绝无丢失”，也不等于多个文件与远端API一起形成事务。需要明确具体平台保证。

重试、恢复、重放和补偿

Retry再尝试某操作；Resume从已保存进展继续；Replay根据事件重建或重新执行；Compensation用另外的动作抵消先前效果。

补偿不一定能真正还原：已发邮件不能让收件人没看过。因此高风险不可逆动作应更谨慎地确认和核验，不能把“出错再回滚”当作通用安全方案。

最小可用恢复记录

至少知道逻辑操作身份、目标、预期版本、当前已知执行状态、结果或核验方式。重启后先确认unknown动作，再决定继续；不要仅凭模型摘要“上次似乎做过”行动。

这类机制的复杂度要与副作用相称。只读搜索通常无需完整事务设计；生产部署、发送、删除和跨系统写入则不能仅靠Prompt保证。

课后自检

机制依据：[IDEMPOTENT][SQLITE]。本节数值与情景除另注外均为原创教学示例；来源不代替中文讲解。