第 11 章 —— 一次写入的远端传播路径

本章目标： 本章完成后，开发者能够把本地提交、delta 编码、传输、远端校验与应用分开观察，并知道在线传播为什么不能替代 repair。

学习目标

1. 跟踪 Register 更新从本地 mutation 到远端应用的五个阶段。
2. 解释 collection locator、schema 与 delta envelope 的作用。
3. 区分控制面消息和数据面传输。
4. 为传播链路上的漏失设计可修复边界。

前置条件

• 已完成第 5 章 Register 操作。
• 能区分第 10 章的成员视图与数据内容。
• 接受本地 put 成功不包含远端确认。

案例进度

Route Publisher 在 node-a 把 payment 的健康路由更新为 10.0.0.8。API 立即看到本地值，但 node-b 仍短暂保留旧地址。团队沿传播链路逐段定位，而不是把整个现象笼统称为「同步慢」。

五个阶段，五个观察点

1. 本地提交：集合完成 resolver/metadata 处理，当前节点可读。
2. 集合定位：变更携带 tenant、application、collection 身份，不能只靠 Java 类型猜目标。
3. 封装编码：delta 与 schema/capability 信息进入 wire envelope。
4. 数据通道：发送、分帧、重试或丢失发生在传输边界。
5. 远端应用：远端校验目标与能力，再把 REMOTE_DELTA 应用到对应集合。

这条链最重要的结论是：第 1 步完成就可以返回本地成功，而第 5 步可能更晚，甚至在在线路径上永远没有发生。

身份比载荷更先决定正确性

两个集合都保存 RouteHint，不代表它们能互相接收 delta。RuntimePlatformSyncService 按集合 route/locator 寻址，并在能力协商后路由 Register、Lease 或 CRDT 的同步消息。

传播契约至少要回答：

• 这是哪个逻辑服务发来的消息？
• 目标 collection locator 是什么？
• 载荷属于 Register、Lease 还是 CRDT？
• schema/codec 是否兼容？
• 这是在线 delta、replay 还是 snapshot 片段？

任何一项含糊，都可能把「消息送到了」误写成「状态正确应用了」。

在线 delta 的边界

在线 delta 优化正常情况下的低延迟传播。它不是可靠业务事件日志：

因此，ChangeStream 消费者不能假设事件历史完整。它用于观察集合变化，不提供消息队列式的审计日志。

反例与故障注入

将 node-a 到 node-b 的数据丢弃，再执行本地 put：

• node-a.get(key) 返回新路由；
• node-b.get(key) 仍是旧路由；
• 本地成功并没有被撤销；
• 网络恢复后，repair 才补齐缺口。

若测试只断言 node-a，它只能证明集合的本地语义。若只等待 node-b 结果却不记录 origin，也无法区分在线 delta 与后来 repair 的结果。

实验

运行两节点传播与故障恢复测试：

cd submodule/dsm
mvn -q -pl dsm-integration-test -am \
  -Dtest=TwoNodeIntegrationTest,ChaosIntegrationTest \
  -Dsurefire.failIfNoSpecifiedTests=false test

再打开 delta-trace.json，检查每个阶段都有输入、输出、可观察信号和失败后的接续动作。

实验验收卡

回顾

• 本地提交和远端可见是两个不同完成点。
• locator、集合类型和 schema 共同约束远端应用目标。
• 在线 delta 面向低延迟，不保证完整历史。
• 漏失是设计输入，repair 提供持续的差异检测与修复过程。

下一步

第 12 章让迟到的 node-b 主动比较 digest，并在 replay 与 snapshot 之间做可解释选择。

证据链接

• RuntimePlatformSyncService
• RegisterCollectionRoute
• TwoNodeIntegrationTest
• ChaosIntegrationTest