分布式数据库一致性模型：云镇图书馆的副本与馆规

可视化演示

展示一致性模型谱系（线性→顺序→因果→最终）、CAP定理CP/AP权衡、Google Spanner TrueTime+Multi-Paxos外部一致性实现。

一致性基石：副本从哪来

云镇总馆决定复制母本，原因很朴素：一场大火就能烧掉全部藏书。复制三套到三个分馆，防火能力一下子提升三倍。可代价立刻浮现——总馆改错别字时，得让三套复印件保持一致，否则读者在东城看到《三体》在架，到西城却被告知“已借出”。副本（Replica） 就是同一份数据在多个物理位置存的拷贝，它是分布式系统冗余的根本手段，也是一致性问题的根源。

副本有了，下一个问题是读写流程。云镇的规矩是“写总馆、读分馆”：所有借阅登记只能到总馆办，办完总馆再把更新“通知”到分馆。这在数据库里叫单主复制（Single-Leader Replication）。通知方式也有讲究：总馆可以等所有分馆回电话确认后才告诉读者“办好了”，这叫全量同步；也可以只等多数分馆确认，叫过半确认；还有更偷懒的——通知发出去就不管了，叫异步复制。同步范围越广，读者越不容易看到旧目录，但每次登记的等待时间就越长。

副本书越多，图书馆防灾能力越强，但每次登记的 $T_{\text{prop}}$ 也越难压小。副本是图书馆的安全垫，也是分布式系统所有“不一致烦恼”的起点——后面所有馆规，都是在回答怎么对付这个 $T_{\text{prop}}$。

线性一致性：实时电话方案

总馆曾经试过一种最严格的馆规：每次登记完毕，必须立刻打电话通知三个分馆，分馆必须在电话里复述确认，读者在任何一个分馆看到的目录都跟总馆一模一样。这套方案下，整个图书馆网络表现得像只有一个总馆在运转——你根本感觉不到副本的存在。这就是 线性一致性（Linearizability），别名强一致或原子一致性。

线性一致性的要求非常苛刻：它要求系统存在一个与真实时间对齐的全局顺序。任意两次操作，只要真实世界里先发生，那么在全局顺序里它也必须排在前面，所有读者看到的先后顺序必须一致。换句话说，“先发生”就是“先生效”，没有任何回旋余地。实现它通常需要共识算法（如 Raft 或 Paxos），或者全量同步复制——写请求要等所有副本或至少一个 quorum 确认后才算成功。

实时电话方案的正确性无可挑剔，代价是总馆每次登记都要等最远的分馆回话——写延迟被“最慢的副本”绑架。在分布式世界里，这就是线性一致性的宿命：它用延迟换来了“假装只有一个副本”的完美假象，适合元数据、分布式锁、账户余额这类绝不容错的关键数据。

顺序一致性：编号信件方案

电话方案太费人力，总馆改用了「邮政公告」：每次登记不再是实时电话，而是把变更编上信件序号，按顺序寄往分馆。分馆收到几封信就公布几封，有的分馆邮差跑得快、一口气收到三封，有的还只收到一封——但信件的编号顺序绝不会乱。读者可能看到旧公告，但只要看到的公告序列，编号一定是递增的。这就是 顺序一致性（Sequential Consistency）。

顺序一致性的核心是“进程内有序”：同一个客户端（读者）自己发起的操作，在所有副本上呈现的顺序必须与它发起时一致；但不同客户端的并发操作，谁先谁后，系统可以自由编排，不需要与真实时间对齐。换句话说，它放弃了“绝对实时”，保留了“相对有序”。它比线性一致性更容易实现，因为不需要全局时钟，只要给每个进程的操作按序编号即可。

编号信件方案比电话便宜得多，总馆发完信就不用等回执。读者偶尔看到旧公告，但绝不会看到“先借续集后借第一部”这种逻辑颠倒。顺序一致性适合那些“顺序不错乱即可”的场景——比如日志流水、操作审计导出的快照。

因果与读己之写：两条人性化规定

云镇的馆规继续演化，新增两条人性化规定。第一条：读者借《射雕》第三册之前，必须先能看到馆藏里有第二册。如果两条登记之间存在“依赖关系”（第二册的入库依赖第一册已有），那么所有分馆公布这两条信息的顺序必须一致——这叫因果一致性（Causal Consistency）。第二条：读者小明上午在总馆还了一本书，下午到南城分馆想再借同一本，南城分馆必须先知道“小明已还书”，否则会闹出“你自己还的书自己都借不到”的笑话，这叫读己之写（Read-your-writes）。

因果一致性只对“有因果关系”的操作强约束顺序，对并发无依赖的操作网开一面；读己之写则把“自己写自己读”绑定为最小承诺，是会话一致性（Session Consistency） 的一部分——同一个会话内，读必须看到之前的写。工程实现上常用版本向量（Version Vector）或客户端携带“上次看到的水位”来达成。

因果一致性比顺序一致性更宽松，比最终一致性更严谨——它不管并发操作谁先谁后，只管“有因才有果”。读己之写则是所有社交产品、内容平台的隐形地基：发帖者永远第一个看到自己的帖子。这两条馆规合在一起，构成了大多数“轻强一致”应用的默认选择。

CAP权衡：洪水断桥的抉择

云镇遇上百年一遇的洪水，总馆到东城分馆的桥被冲断（网络分区）。这时东城读者来问：“最新目录里有这本书吗？”东城管理员只有两个选择：如实说“我这边跟总馆失联，无法确认，不能借”，这保住了“任何分馆对外说法必须一致”的规矩；或者“凭我手头这份旧目录先借给你，等桥修好了再补登记”，这保住了“读者任何时候都能借到书”。两条路必选其一，没有第三条。

这就是 CAP 定理 的核心：$P$（网络分区）是分布式系统的物理现实，不是可以勾掉的设计选项——P 是前提，分区发生后，$C$（强一致性）和 $A$（可用性）只能二选一。选择 $C$ 的系统（如 etcd、ZooKeeper）在分区时拒绝写入，宁可暂停服务也要保证读到的都是权威数据；选择 $A$ 的系统（如 Cassandra、Dynamo）在分区时继续服务，接受返回旧数据、等恢复后慢慢补对账。此外还有 Quorum 折中：让读副本数 $R$ 与写副本数 $W$ 满足 $R + W > N$，读写集合必相交，可以在不强求全量同步的情况下降低延迟。

洪水期间，东城分馆选择“先借出去，回头再补账”就是 AP 派；总馆选择“查不到就是没有”就是 CP 派。CAP 没有善恶，只有业务取舍：银行转账怕错不怕慢，选 CP；抢购秒杀怕等不怕旧，选 AP。

延迟与可用性：馆规的成本账本

东城分馆在桥修好后复盘发现：馆规越严格，读者等待时间越长；馆规越宽松，借书成功率越高。于是它按书品类定了阶梯馆规——新出版的畅销书执行实时电话确认（线性一致），普通小说半小时同步一次（读己之写），十年以上的旧书每天晚上批量同步（最终一致）。这个阶梯背后，是一条清晰的成本光谱。

从线性到最终，一致性强度递减，写延迟通常从“等待全部副本确认”降到“本地写完即返回”，可用性则从“分区时直接拒绝”升到“分区时继续服务”。这个交换关系可以形式化：可用性等于 1 减去“需要跨分区协调的操作比例”，跨分区协调越频繁，可用性越低，延迟越高。而最终一致性模型的独特魅力在于，在没有新写入的静默期，副本状态最终会收敛到一致：

没有免费的馆规：越严格，读者等待越久、分区时越容易吃闭门羹；越宽松，借书越快但越容易借到过期信息。现代系统的一个重要实践是混合模型——同一套数据库里，热数据走强一致，冷数据走弱一致，把这条光谱变成按行或按表配置的“可调一致性”。

主流数据库选型：各家馆规一览

云镇图书馆的七种馆规，最终沉淀为每家分馆门前的门牌。这些门牌，就是现实中主流数据库的一致性选择。读懂门牌，才能给业务配上合适的馆。

总馆挂的牌子写着“实时电话方案”——etcd 与 ZooKeeper 采用共识算法（Raft/Paxos）提供线性一致性，是分布式锁、Leader 选举、配置中心的标准选择，宁可分区时停止服务，也绝不让两个节点同时当主。东城分馆挂的牌子是“主馆登记、分馆异步公布”——PostgreSQL 主从复制 默认异步，从库可能滞后，想要读己之写就得把“自己刚写的数据”的读请求路由到主库，或开启同步提交。南城分馆挂的是“周末大同步”——Cassandra 默认最终一致，但提供可调一致性级别：把读写级别都调到 QUORUM 就能获得较强一致，调到 ALL 则接近线性一致。而新建的云山分馆用“卫星对时 + 过半确认”——TiDB 与 Spanner 通过 Raft/Paxos 多副本 + 精确时钟（Spanner 用 TrueTime），实现了跨数据中心的分布式线性一致。

各家馆规没有对错，只有“适不适合自己的读者”。给元数据选 Cassandra 默认级别会出乱子，给排行榜选 etcd 的线性一致则纯属杀鸡用牛刀。选型的关键，是看清业务到底怕“旧”还是怕“等”。

AI 应用场景

Python 演示

import random  class Replica:    """单个副本：保存数据字典和版本号"""     def __init__(self, name):        self.name = name        self.data = {}        self.version = 0  class Cluster:    """模拟多副本数据库集群，支持三种同步模式"""     def __init__(self, mode, replica_count=5):        self.replicas = [Replica("r%d" % i) for i in range(replica_count)]        self.leader = self.replicas[0]        self.mode = mode        self.write_count = 0        self.quorum = replica_count // 2 + 1     def write(self, key, value):        self.write_count += 1        self.leader.data[key] = value        self.leader.version = self.write_count        if self.mode == "sync":            for rep in self.replicas[1:]:                rep.data[key] = value                rep.version = self.write_count        elif self.mode == "quorum":            for rep in self.replicas[1:self.quorum]:                rep.data[key] = value                rep.version = self.write_count     def propagate(self):        """异步模式下，把 leader 最新数据随机传给一个落后副本"""        laggards = [r for r in self.replicas[1:]                    if r.version < self.leader.version]        if laggards:            rep = random.choice(laggards)            rep.data = dict(self.leader.data)            rep.version = self.leader.version     def read(self, replica_index, key):        rep = self.replicas[replica_index]        return rep.data.get(key), rep.version  def simulate(mode, rounds=2000):    cluster = Cluster(mode)    stale = 0    for i in range(rounds):        cluster.write("k", i)        if mode == "async" and random.random() < 0.3:            cluster.propagate()        _, version = cluster.read(random.randrange(len(cluster.replicas)), "k")        if version < cluster.write_count:            stale += 1    return 1.0 * stale / rounds  if __name__ == "__main__":    for mode in ("sync", "quorum", "async"):        print("%-8s 读到旧值比例: %.2f%%" % (mode, simulate(mode) * 100))

1. self.replicas = [Replica("r%d" % i) for i in range(replica_count)]创建 5 个副本节点，replica 0 充当主副本（leader）
2. cluster.write("k", i)每轮模拟一次写请求，主副本版本号递增并写入新值
3. if self.mode == "sync":全同步模式：写请求必须立刻复制到所有副本，读者永远不会读到旧值
4. elif self.mode == "quorum":过半模式：只复制到前 3 个副本（5 个副本的多数派），未覆盖的副本存在旧数据
5. if version < cluster.write_count:读者拿到的版本落后于主副本最新版本，即视为一次“不一致读”
6. random.random() < 0.3异步模式每秒只随机补一次传播，模拟网络传播速度跟不上写入速度的现实

常见误区

面试题