分布式存储：数据一致性保证

可视化演示

展示主从复制写入传播、强一致与最终一致性对比、Quorum共识投票流程，交互切换查看分布式存储一致性核心机制。

一致性基础

把招牌菜谱抄成七份，分别放在主厨和六位帮厨手边，这就是“副本”。顾客从不同灶台点同一道菜，如果都能吃到一模一样的味道，我们说菜谱一致；如果有一位帮厨偷偷加辣而其他人不知道，出菜就出现了“不一致”。分布式存储的一致性，问的正是：同一份数据复制到多台机器后，从不同机器读出来是否相同、以谁为准。

存储系统会给出不同强度的“承诺”，也就是一致性模型。强一致性承诺：一次写入一旦成功，之后任意副本上的读取都立刻能看到新值。弱一致性只承诺某个不确定的时刻之后能读到新值。最终一致性放松到“如果停止写入，所有副本最终会收敛到同一版本”。读写一致性则承诺：写者本人下一次读，一定能读到自己刚写的内容。

选哪种模型，不是选择题里选“正确”或“错误”，而是在延迟、可用性、实现复杂度之间权衡。强一致性常用 Quorum 或 Raft 实现，适合账务、元数据；最终一致性常用于缓存、对象存储、CDN。最终一致性的收敛过程可以用极限来表达：

就像餐厅会对顾客承诺：你刚下单改了辣度，你下一口吃到的一定是改过的味道；至于角落里的装饰摆盘，可以晚一点统一。明确承诺什么，客人投诉时你才知道该赔哪道菜。

副本复制策略

后厨要同步菜谱，首先得定下“谁来改、谁来抄”。最简单的方案是主从复制：只有主厨能改菜谱，其他帮厨只许照着抄。这样不容易出错，但主厨一旦休假，大家就得等待。如果几家分店各有主厨都能改，就成了多主复制，可用性更高，但两个人同时改同一道菜时，就会产生冲突。

在分布式存储里，主从复制（单主复制）是默认选择：客户端把写请求发到主节点，主节点把操作追加到日志，再异步或同步地发给从节点。多主复制多见于多数据中心，代价是需要解决并发写冲突。同步与异步的关键区别是：写请求何时算成功？同步复制要求等待若干副本确认后再返回；异步复制只要主节点确认就返回，副本慢慢追赶。

同步复制越“安全”，延迟就越明显。如果要求包括主副本在内的 k 个副本都确认写入，响应时间可以粗略写成：

同步复制像请帮厨当场复述菜谱，异步复制则像先把纸条塞进抽屉，晚点再誊抄。你要上菜快，就不能等所有人；你要绝对一致，就得忍受慢一点。

共识算法

主厨不在时，帮厨们必须商量出由谁临时做主。最自然的办法是“超过半数点头”：只要超过一半的人同意同一个决定，这个决定就生效。分布式系统也采用类似思想，这就是共识算法。它解决的问题是：在部分机器可能宕机或网络异常时，让所有正常机器对“谁是主、日志顺序是什么”达成一致。

Quorum（法定人数）是共识中最基础的概念。在一个有 N 个副本的组里，多数派大小为：

同时，为了让读取一定能拿到最新提交的数据，读写 Quorum 需要满足 $W + R > N$。Raft 算法把共识拆成选主、日志复制、安全性三个子问题：先选出一个主节点，所有写日志都从主节点发给从节点，超过半数确认后提交。Paxos 则更抽象，用 Prepare 和 Accept 两阶段让多个提案者竞争达成一致。

超过半数的帮厨点头才算数，即使有两三个人缺席，决定依然有效。共识算法就是这种“开小会机制”的形式化：不追求所有人都同意，但追求不会被两拨人做出相反决定。

CAP定理

现在假设后厨突然被一堵隔板分成两半，左边帮厨看不到右边新改的菜谱。如果两半都继续接单，左边按旧菜谱做，右边按新菜谱做，味道就不一致；如果坚持两边必须一致，就只能让其中一半停止接单，等隔板撤走。这个两难困境，就是分布式系统中的 CAP 定理。

C 是一致性（Consistency），A 是可用性（Availability），P 是分区容错（Partition Tolerance）。CAP 说的是：当网络分区真实发生时，你无法同时保证强一致性和完全可用性。形式化表达为：

隔板不是你想不想面对的问题，而是后厨迟早会遇到的问题。真实系统通常把请求分类：关键元数据走 CP，高并发读走 AP，用“分场景选择”代替“一套方案走天下”。

版本与冲突解决

当两个帮厨都往各自手抄菜谱上加了新菜，两本菜谱就都成了“最新”。为了让合并时不盲目覆盖，需要在菜谱末尾记录改动历史：谁在什么时候改过几次。这个记录在分布式存储里就是版本向量（Version Vector）。

版本向量本质上是一组计数器，每个副本对应一个计数。每当某个副本完成一次本地写，它就把自己的计数器加 1。两个版本比较时，如果 A 的所有计数都不大于 B，且至少有一个严格小于，说明 B 包含了 A 的全部历史；如果两者各有更大的计数，就说明它们是并发冲突，不能简单覆盖。

版本向量只能告诉我们“哪些更新是并发的”，不能替业务决定到底保留谁。于是工程上常用 LWW（最后写入胜）直接选时间戳大的值，或用 CRDT 这类可交换合并的数据结构，在满足特定约束时自动合并。如同两本菜谱都写了新菜，看到两边都动过笔，才知道需要把两道菜都留下，而不是用后写的把前写的整页撕掉。

AI训练存储实践

回到 AI 算力集群，分布式存储像一家中央菜谱库，成百上千张 GPU“灶台”需要读同一份模型权重。训练过程中，模型权重、优化器状态、数据集分片都会写入存储；如果每个 Worker 读到的版本不一致，梯度更新就会互相覆盖，训练过程便不可复现。

因此，AI 基础设施里最常见的做法是保存“检查点”（Checkpoint）：每隔固定步数，把完整训练状态做成一个一致快照。为了避免快照来自不同时刻，分布式快照需要同步屏障：所有 Worker 在同一训练步先把状态落盘，再统一切换版本。每个检查点可以表示成：

训练中断后，调度器不能让新 Worker 随便找一份旧副本恢复，而是要回到这个“盖了章的合影菜谱”——所有 GPU 从同一版本、同一哈希的检查点重启，训练结果才能接续上。

工程优化与监控

再好的后厨也要有 SOP：菜谱多久同步一次、同步几份、主厨失联后怎么切换、怎么抽查口味。分布式存储同样需要一套工程化手段，把一致性从理论变成可运维的系统。

首先是一致性配置：不同数据选择不同模型。关键元数据用强一致，模型检查点用同步 Quorum，数据集镜像可以放宽到最终一致。其次是性能权衡：W 和 R 越大，越安全，但延迟越高；W=1 时写入最快，W=N 时只要一个副本故障就无法写入。故障恢复时，要尽快识别主副本失联，触发 Raft 或 Paxos 的重新选主。

监控是最后一道防线。复制延迟是最直观的指标，第 i 个副本的落后程度可以写成：

帮厨多久没抄写菜谱、有没有串味，都要有温度计和抽检。一致性系统也一样：没有监控的“强一致”只是纸上承诺，有了延迟、版本差、哈希校验，才能在日常运行中提前发现问题。

---

AI 应用场景

Python 演示

class Replica:    def __init__(self, name):        self.name = name        self.store = {}     def write(self, key, value, version):        self.store[key] = (value, version)     def read(self, key):        return self.store.get(key, (None, -1))  class QuorumKV:    def __init__(self, replica_names, W, R):        self.replicas = [Replica(n) for n in replica_names]        self.n = len(self.replicas)        self.w = W        self.r = R        self.clock = 0        if self.w + self.r <= self.n:            raise ValueError("W + R must exceed N")     def put(self, key, value):        self.clock += 1        version = self.clock        for i in range(self.w):            self.replicas[i].write(key, value, version)        return version     def get(self, key):        best_version = -1        best_value = None        for i in range(self.r):            version, value = self.replicas[i].read(key)            if version > best_version:                best_version = version                best_value = value        return best_value  def main():    kv = QuorumKV(["r1", "r2", "r3"], W=2, R=2)    print("write version:", kv.put("model_weight", "v_001"))    print("read value:", kv.get("model_weight"))  if __name__ == "__main__":    main()

1. class QuorumKV:定义一个 Quorum 键值存储类，核心是控制写入和读取的副本个数。
2. if self.w + self.r <= self.n:如果不满足 W+R>N，读写副本集合不可能相交，也就无法保证读到最新值。
3. for i in range(self.w):写入时只写 W 个副本，不必等所有副本都成功。
4. for i in range(self.r):读取时只读 R 个副本，降低延迟但又能拿到足够信息。
5. if version > best_version:在多个副本返回值中挑选版本号最大的值，作为最新结果返回。

常见误区

面试题