复制方式对线性一致性的可达性差异

不同复制架构提供线性一致性的能力天差地别。[[复制的三种主流架构单主多主无主及其复杂度权衡]]中单主复制若从主库读，或从能确认自己仍是主库的同步从库读，理论上可以提供线性一致性；但很多实现为了性能会牺牲这点（例如异步从库读到旧数据、脑裂期间的旧主库仍在应答请求）。共识算法（Raft/Paxos/Zab类）从设计上就保证线性一致。多主复制天然不提供线性一致性，因为多个主库并发处理写入，之后再异步合并，会产生冲突数据。[[无主复制靠读写法定人数在故障中维持可用与新鲜度]]（Dynamo风格）通常也不是线性一致的，即便使用严格法定人数（w+r>n）：因为法定人数读写只保证”读到最新写”在没有并发冲突时成立，一旦读写发生时间上的重叠竞争，不同副本执行写入的先后顺序不同，客户端就可能读到不一致的中间状态——这与”多数投票即等价单副本”的直觉相反，是[[法定人数看似严格保证实则存在边缘陷阱及宽松法定人数的取舍]]的又一个具体表现。

结构图：

flowchart TD
    A[复制架构] --> B[单主复制]
    A --> C[共识算法 Raft/Paxos/Zab]
    A --> D[多主复制]
    A --> E[无主复制 Dynamo风格]
    B -->|从主库/同步从库读且正确检测领导权| F[可提供线性一致性]
    C --> F
    D --> G[天然不提供: 并发写入异步合并冲突]
    E -->|即使 w+r>n 严格法定人数| G