实现线性一致系统

实现线性一致系统

线性一致性本质意味着 “表现得好像只有一个数据副本，且其上所有操作都是原子的”，所以最简单方案：真就只用一个数据副本。但无容错性：若持有该副本的节点失效，数据将丢失或无法访问，直到节点重启。

系统容错最常用方案，复制：

• 单主复制（部分支持线性一致）

  单主复制系统中，仅主库承担写，而追随者在其他节点上保留数据副本。若从【主库】或同步更新的【从库】读，则可满足线性一致性 ^iv。但并非每个单主DB都是线性一致，因为它们可能采用快照隔离设计或并发处理上存在bug。

  [iv]  对单主DB分区（分片），使每个分区有一个单独领导者，不会影响线性一致性，因为线性一致性只是对单一对象的保证，而交叉分区事务是不同问题。

  从【主库】读取的前提，你确定知道领导者是谁。某节点可能自认为是领导者，而事实并非如此，若自以为是的领导者继续对外服务，就会违反线性一致性。若使用异步复制，故障切换时甚至可能丢失一些已提交的写入，这同时违反持久性和线性一致性。

• 共识算法（线性一致）

  类似单主复制。但共识协议内置防止脑裂和过期副本的措施。因此，共识算法可安全实现线性一致性存储。如zk、etcd。

• 多主复制（非线性一致）

  多主复制系统通常无法线性一致，因为它们同时在多节点并发写，并将其异步复制到其他节点。因此，可能产生写冲突，正是因为多数据副本引入的结果。

• 无主复制（可能非线性一致）

  无主复制系统，有人认为通过要求法定读写（ w + r > n ）满足即可获得 “强一致性”，但这完全取决于具体quorum配置及强一致性的定义，可能并不保证线性一致。

  如日历时钟的 “最后写入胜利” 冲突解决方法几乎肯定是非线性一致，因为时钟偏差，不能保证时间戳与实际事件顺序一致。不规范的法定人数也破坏线性一致。即使严格的法定人数，非线性一致的行为也是可能的。