Chapter 3 Official Docs Note

第 3 章 Temporal 文档

第 3 章把重试的危险放到现实层：Temporal 能重试外部动作，但业务系统必须让重复请求安全，或准备明确补救。

官方锚点

本章必须带走的事实

Retry 会再次触碰外部世界

重试 Activity 可能再次执行外部写入、登记、扣费或发货。

官方建议 Activity 幂等

Activity 可以非确定性，但推荐设计成 idempotent，让重复执行仍落回同一业务结果。

稳定业务键很关键

幂等通常需要外部系统能识别同一业务请求，而不是每次重试都生成全新身份。

Event History 记录已知事实

隐藏外部结果不会让副作用消失，只会让恢复时缺少事实。

补救是显式动作

Compensation 不是回滚时间，而是设计新的 Activity 去修正已经发生的副作用。

禁用重试不是通用答案

完全禁用重试会放弃恢复短暂故障的能力；问题在于副作用语义是否安全。

本章对应的执行链

  1. 第一次车行登记请求在边界前没有收到回声。
  2. Retry Policy 安排第二次尝试并成功返回。
  3. 第一次请求其实已经在外部系统落笔，于是出现重复配送。
  4. 稳定业务键把重复执行识别成同一业务意图。
  5. Workflow 调度补救 Activity 撤回重复结果。
  6. Event History 记录补救路径，后续恢复可以理解已经发生的修正。

结尾自检

  1. 为什么重试前必须先问 Activity 是否幂等？
  2. 为什么每次重试生成新编号会伪装成多次业务请求？
  3. Compensation 和重跑整个 Workflow 有什么区别？
  4. 禁用所有重试会失去什么能力？