无冲突复制数据类型

传统复制把并发冲突推给两种昂贵机制：要么用共识预先统一操作顺序，要么留给人或应用事后仲裁。CRDT 走第三条路——把冲突解决编译进数据类型的代数结构。状态型的合并满足结合、交换、幂等，因此消息乱序、重复、经由不同路径多次传播都不影响终态；操作型并非让一切顺序都无关，而是保留必要的因果顺序，并让并发操作可交换。可以把状态想成只会向上生长的信息，合并是取两份信息的并；任何两个副本无论经历怎样的交错，只要吸收了同样的信息就站在同一点上。这个视角也标出了方法的天然边界：并非所有语义都能被塞进"单调生长"的模子；若要求各副本在分区期间也立即、不可撤销地选出唯一赢家，就仍旧躲不开协调。

最小的正例是 Grow-only Set：状态为集合，更新是加元素，merge 取并集。副本甲加入 $a$、副本乙并发加入 $b$，交换状态后两边都计算 $\{a\}\cup \{b\}=\{a,b\}$；交换顺序颠倒、状态重复送达，结果不变——结合、交换、幂等三条性质逐一兑现。稍复杂的 G-Counter 让每个副本维护自己的分量，merge 取逐分量最大值，读数取分量之和，同样满足格结构，说明"计数"也能表达为单调膨胀。

边界情形有三。其一，"最后写入胜"（LWW）寄存器常被当作 CRDT 使用，它的合并确实可交换，但语义全押在时间戳上：物理时钟偏斜可能让"较早"的写入胜出，叫作 CRDT 并不解决时钟语义问题。其二，删除比添加难：从只增集合里删元素会破坏单调性，实际设计需引入 tombstone、因果上下文或 observed-remove 规则，并带来元数据回收的难题。其三，CRDT 的收敛性质本身不自动保证跨对象或全局不变量——两个副本并发扣款可以各自合法、合并后余额为负。能否无协调地维护约束，取决于任意可接受的并发更新在合并后是否仍满足它（即"不变量汇合"）：预分配额度（escrow/rights allocation）能让部分约束在无共识下成立；不具备这种性质的约束才需要同步协调，在容错复制系统中常由共识公理库分布式共识Distributed consensus · Consensus problem多个进程在可能故障和通信延迟下对一个值达成一致的任务。实现。

CRDT 是CAP 定理公理库CAP 定理CAP theorem网络分区期间，系统不能同时保证所有请求可用与线性一致性。中选择可用性一侧后的系统性答案：分区期间各副本继续服务，靠代数性质而非拒绝写入来保证愈合后一致，是最终一致性公理库最终一致性Eventual consistency停止更新后，所有副本最终收敛到一致状态的弱一致性保证。从口号变成可证明规格（强最终一致性）的关键一步。它支撑离线编辑、协作软件、地理复制数据库与边缘计算中的共享状态。

工程选型围绕两类设计的权衡展开：状态型依靠半格 join，对乱序和重复更宽容但状态可能庞大；操作型消息较小，却常依赖去重与因果交付公理库因果广播Causal broadcast保证所有进程按因果先后顺序交付消息的广播抽象。保证。存储服务还可向客户端提供因果一致性公理库因果一致性Causal consistency · Causal memory要求每个观察者的读写可见顺序都扩展程序顺序与读来源所生成因果偏序的一致性模型。，但那是版本可见性合同；CRDT 的收敛结论始终绑定各自的传播与执行条件，不能从数据类型的合并代数直接推出完整会话语义。两类设计的元数据与垃圾回收成本都需单独评估。