ARC 3理解复制、分区与修复第 10–14 章

第三篇回顾 —— 复制、分区与修复的可观察过程（第 10–14 章）

第三篇把笼统的“网络恢复后会一致”展开为可观察过程：漏失发生在哪一段、由谁检测、如何修复，以及已发生的业务响应为何仍需外部保护。

从成员到收敛的完整过程

成员观察稳定
  → 本地 mutation 产生 delta
  → 在线传播尝试远端应用
  → digest/anti-entropy 发现缺口
  → replay 或 snapshot 修复
  → 再次比较并确认收敛

ChangeStream 是这个过程的观察面之一，但它自己的有界缓冲也可能丢事件。最终判断需要回到集合状态、digest 与业务事实源。

五个边界

边界 常见误解 正确合同
成员 一次 join/leave 就是全局事实 连续稳定视图后再做高风险 quorum 决策
传播 本地成功等于远端已写 分开记录 local commit 与 remote apply
修复 replay/snapshot 越多越安全 不倒退；在可用窗口和成本之间选择
订阅 ChangeStream 是可靠事件日志 有界缓冲、显式 overflow、必要时重读状态
响应 最终一个 winner 撤销 loser 的 OK 事务、幂等、fencing 或补偿保护副作用

本篇如何兑现 DSM 价值

第三篇说明 Runtime 如何处理成员变化、在线 delta、差异检测和副本修复。这些通用机制减少了各业务服务自行编写传播与补差流程的工作。DSM 负责当前协同状态的恢复；调用方仍负责解释局部成功、保护外部副作用，并为 ChangeStream 选择可接受的丢弃或失败策略。

故障到证据的映射

故障 最小证据 仍未证明
成员抖动 稳定轮次重置；Lease 返回 membership-unstable 真实网络阈值合适
在线 delta 漏失 本地先成功；恢复后 repair 追平 exactly-once 历史投递
requester 落后 planner 选择 replay/snapshot；不倒退 大规模最优成本
慢订阅者 四种 overflow 行为与指标 无损业务事件流
网络分区 autonomous/quorum Lease 对照 外部副作用已被保护

评审时的六个问题

  1. 这里使用的是当前可见成员、原始集群规模还是稳定规模？
  2. 本地返回成功时，远端到了哪一个阶段？
  3. 谁会发现在线传播漏掉的 delta？
  4. replay 不可用或更贵时，snapshot 如何安全接管？
  5. 订阅缓冲满时，选择丢、等还是报错，指标是什么？
  6. 分区中的局部成功是否触发了不可撤销业务副作用？

迁移练习

把贯穿案例的 route hint 换成「灰度开关」。分别写出：权威来源、locator、分区期间两个本地 OK 的业务影响、repair 方式、ChangeStream overflow 策略，以及不允许放入 DSM 的开关类型。

下一步

进入第四篇：把集合和失败边界封装为业务端口，接入 Spring Boot，并用两层身份隔离与多层测试证据守住工程边界。