ARC 1先看见共享状态第 1–4 章
第一篇回顾 —— 先看见共享状态（第 1–4 章）
第一篇从业务责任边界推进到双节点可见，尚未覆盖并发冲突、repair 或生产网络。
本篇形成的认识
- 第 1 章先把订单、支付和事件历史留在各自事实源，只把可修复协同状态交给 DSM。
- 第 2 章建立 Runtime 生命周期，并把本地
put成功限定为本地提交。 - 第 3 章用 locator、entry key、entity、metadata、codec 和 schema 建立稳定身份。
- 第 4 章观察在线 delta，让节点 B 在本地提交之后最终读到节点 A 的 RouteHint。
可验证的学习结果
- 判断一个状态是否具备「可从同伴修复或从权威源重建」的前提。
- 构建单节点 Runtime，注册并关闭集合。
- 为 RouteHint 选择稳定 key 和明确 schema。
- 用条件等待和
REMOTE_DELTA证明受控双节点传播。
本篇如何兑现 DSM 价值
第一篇把“共享状态”落实为可检查的责任边界、稳定身份、Runtime 生命周期和远端可见性。业务服务可以复用集合注册、状态编码和基础传播入口，同时仍需决定哪些状态适合共享，以及本地成功后何时可以依赖远端结果。
四个容易混淆的时刻
| 时刻 | 已经证明 | 还没有证明 |
|---|---|---|
runtime.start() 返回 |
本地 Runtime 进入运行生命周期 | peer 已发现、集合已同步 |
register.put() 返回 |
本地接受变更 | 任一远端已应用 |
节点 B get() 命中 |
B 当前可见该值 | 所有节点相同、不会再冲突 |
| 双节点测试通过 | 固定源码在受控 fake membership 下满足断言 | 真实网络、生产容量、故障修复 |
常见错误
| 错误 | 纠正 |
|---|---|
| 把 DSM 当事务数据库 | 从不可撤销业务承诺和审计责任重新分类 |
| 每次发布用新 entry key | 用稳定业务身份，让 Register 更新同一逻辑条目 |
用 sleep 验证复制 |
等待目标条件并设置明确超时 |
| 测试通过就宣称生产可用 | 写出测试拓扑、通信实现和未覆盖边界 |
迁移练习
给「临时功能开关」写两份设计：一份有权威配置中心，DSM 只保存可重建 hint；另一份没有权威源、开关直接控制资金动作。解释为什么前者可能进入 DSM，而后者需要更强的事实与审计系统。
下一步
进入第二篇，用 Register、Lease 和 CRDT 分别回答当前值、所有权和可合并更新。