Chapter 9 Official Docs Note

第 9 章 Temporal 文档

第 9 章把前面所有机制放到同一场事故里：先把症状映射回机制，再按现实伤害和恢复风险排序处理。

官方锚点

本章必须带走的事实

先分类症状

多症状事故不能用一个旋钮处理，应该先识别每个症状属于哪条 Temporal 机制或运行层。

现实伤害优先

重复发放、重复扣费等副作用正在扩大时，应优先止血并设计补救。

幂等和补救处理副作用

RetryPolicy 导致的重复外部动作要回到 Activity 幂等性和 Compensation 设计。

版本兼容处理 replay 裂缝

旧执行的 Event History 需要新代码继续理解，因此版本兼容和 patching 是部署问题的修复层。

Query 和 Visibility 要平衡

可见性不能关闭，但 Query 返回过重 payload 会让观察本身变成压力源。

最佳实践来自复盘

综合事故的价值在于把机制、症状和修复优先级沉淀成下一次可执行的标准。

本章对应的执行链

  1. 河湾重复发放归到 Retry、Idempotency 和 Compensation。
  2. 旧矿 replay 裂缝归到 Versioning、Patching 和安全部署。
  3. 北坡慢查询归到 Query、Visibility 和 payload。
  4. 先处理正在制造现实伤害的重复副作用。
  5. 再修旧历史兼容和读取负载。
  6. 最后把多症状诊断方法写成可复用值班规则。

结尾自检

  1. 为什么综合事故不能先统一调大所有 Timeout？
  2. 现实伤害、replay 兼容、观察负载三者如何排序？
  3. 为什么慢 Query 不是关闭 Visibility 的理由？
  4. 怎样把一次事故映射回 Temporal 机制，而不是硬套最熟悉的概念？