操作型 CRDT 的因果交付

“我删除了刚才看到的添加”包含一条语义依赖：远端若还没见 add，就无法正确解释 remove 指向哪次添加。因果交付让效果算子在其前提已成立后运行。并发 add 没有被 remove 观察到，不属于前提，因而可以在 remove 前后任意出现并按冲突规则保留。

依赖摘要像一张待办清单，而非物理时间戳。向量分量说明每个来源至少应交付到哪一序号；本地缺一项就等待或拉取。墙钟即使完全同步，也不能仅凭时间判断某操作是否真的观察过另一操作。

因果交付会形成 head-of-line blocking：一个丢失前驱可挡住后继。实现要补发依赖、限制缓冲并处理永久故障，但不能为降低延迟直接跳过前驱后仍声称相同语义。

A 执行 $\mathrm{add}(x)$，产生 dot $(A,1)$。B 收到后执行 $\mathrm{remove}(x,\{(A,1)\})$，所以

C 若先执行 remove，而本地尚无 $(A,1)$，朴素删除看似无事发生；随后 add 到达，$x$ 被错误复活。因果交付迫使 C 缓冲 remove，先加入 dot，再删除它，最终 $x$ 不存在。

与此同时 D 未见 A 的 add，独立产生 $\mathrm{add}(x,(D,1))$。该事件与 B 的 remove 并发。C 可以先执行 D 的 add，也可以在 remove 后执行；只要 remove 的 effector 精确列出 $\{(A,1)\}$，$(D,1)$ 均不会被删，add-wins 结果都含 $x$。

若网络把 B 的 remove 重复两次，删除同一 dot 的集合操作是幂等的；若消息是整数 increment，重复便不安全。这个差异来自 effector 代数，不来自因果时钟。若 add 永久丢失，remove 会一直缓冲；严格保持顺序没有满足 eventual delivery，系统需重传前驱或明确宣布源故障后的处理规则。

因果交付可由发送方附完整 vector、稀疏 dependency set 或按会话维护的 causal token 实现。压缩摘要若遗漏真实依赖，会导致安全违规；保守地多报依赖只会增加等待，却可能造成可用性问题。交付完成最好指 effector 已进入可恢复状态，而非只从网络队列取出。

RGA 等序列 CRDT 借它确保 insert 的 anchor 在子节点之前存在；pure op-based CRDT 还可用因果稳定性判断某事件不会再遇到并发前驱。跨数据中心部署必须说明成员变化如何映射时钟分量，否则重用 actor ID 会让新事件被误判为旧前驱。缓冲上限若会丢弃依赖消息，也必须有状态修复路径。