分布式一致性模型横向对比

可视化演示

展示四种一致性模型强度谱系、读写可见性行为及CAP权衡三角，支持一致性强度调节。

一致性模型概述

周末约火锅的群里，为什么同一时刻四个人看到的聊天记录不一样？因为消息是异步传播的：有人用 4G，有人连 WiFi，有人在地铁里断断续续。计算机世界更夸张，一份数据被复制到不同机房的多台机器上，每台机器之间隔着真实的物理网络，延迟和故障让它们天然“看不同步”。

如果没有额外规则，“从副本 A 读到的数据”和“从副本 B 读到的数据”可能互相矛盾。一致性模型就是约束多副本读操作可见性的规则集合，它回答三个问题：一次写成功后，什么时候能被其他节点看到？以什么顺序看到？各副本呈现的状态是否必须完全相同？我们把副本 i 在时刻 t 的状态记为 $S_i(t)$，一致性模型就是在 $S_1(t), S_2(t), \dots, S_n(t)$ 之间订立契约。

从强到弱，主流模型分为线性一致性、顺序一致性、因果一致性、最终一致性。它们对“写入何时可见、操作如何排序”逐级放宽：强一致要求全局实时对齐；顺序一致只要求存在全局合法顺序；因果一致只约束有因果关系的操作；最终一致只要求最终收敛。就像一群朋友需要约定“以谁的发言为准”，系统也需要规则来管理“多个人看到同一件事”的秩序——这决定了系统是更稳、更快，还是更扛得住故障。

强一致性

如果把一致性比作约火锅，强一致就是“开会表决”式规则：小林宣布“今晚吃海底捞”，必须等四个朋友全部回复“收到”、确认信息已在各自手机里同步，才允许任何人“知道”这个决定。不存在“阿凯知道了、大壮还不知道”的中间时刻——要么大家都没看到，要么同时看到。这种全局同时对外呈现单一视图的性质，在分布式系统里叫线性一致性，工业上通常靠 Raft/Paxos 共识协议或两阶段提交来实现。

形式化地说：任意两个操作 op₁、op₂，如果 op₁ 在实时时间上先于 op₂ 完成，那么在线性化顺序 L 中，op₁ 也必须排在 op₂ 前面。所有操作都像在某个时间点“原子地”生效，读操作永远返回最近一次写入的结果。

代价也很直接：每次写入要等全体副本确认，延迟随副本数量上升；只要一个副本失联，系统就面临阻塞或降级。多副本联合可用性约为单副本可用性的乘积，副本越多，整体越容易“约不成饭”。所以强一致最靠谱，但举手一次要等所有人到齐——正确性换来了延迟和可用性的牺牲。

顺序一致性

另一种规则更像“群聊排序”：不要求大家同时看到消息，但消息必须按发送顺序到达每个人的屏幕。先有小林问“去不去？”，才有大壮答“去！”，任何人的手机上都不许出现“回答”排在“提问”之前。顺序一致性只约束顺序，不约束实时——在顺序一致的系统里，允许某些节点先执行了部分操作，其他节点暂时看到中间状态，只要最终排出的全局顺序合法即可。

形式化定义：存在一个全局操作顺序 L，任意进程 P_i 内先发的操作，在 L 中也保持同样先后。这比线性一致弱，因为不需要与真实时钟对齐——操作不必在某条“实时同步线”上同时生效。

它和线性一致的核心区别在于“时间对齐”：线性一致要求操作必须在调用和返回之间的某个真实时刻生效，读后立刻可见；顺序一致只要求存在一个合法顺序，允许短暂“穿越”。就像微信群按消息序号排序——顺序对了，晚几秒收到完全没关系，但要是“回复”显示在“提问”之前，大家就会觉得系统坏了。

因果一致性

现实中大多数消息根本不需要全局排序。群聊里“小林问去不去”和“阿凯说去海底捞”有因果关系——后者是对前者的回答，颠倒顺序会闹笑话。但“大壮发了个表情包”和“阿凯说海底捞”毫无关系，谁先谁后没人会注意。因果一致性只约束有因果关系的操作，无因果的并发操作允许以任意顺序出现。

在分布式系统里，用 happened-before 关系（记作 $\to$）表达因果依赖：如果 op_a 可能影响 op_b，则所有副本必须先应用 op_a 再应用 op_b。实现上通常用向量时钟（Vector Clock）追踪每个副本的因果依赖版本，确保“提问”永远不会晚于“回答”被应用。

因果一致比顺序一致更宽松，允许大量并发操作以不同顺序到达不同副本——只要不破坏因果链。购物车里“先加商品 A 再修改数量”必须保序，而“加商品 A”和“加商品 B”互不相干，乱序完全无感。这就是聊天的分寸：对话逻辑不能乱，无关的插科打诨随便穿插。

最终一致性

群主在群里发“周五 7 点海底捞门口集合”，有人秒收，有人地铁里收不到，半小时后才看到。但只要最终所有人都收到这条通知，火锅照约。最终一致性就是“不承诺立刻一致，只承诺过一会儿一致”的规则：系统允许读到旧值，经过一段不可预测的时间后，所有副本最终收敛到相同状态。DNS、DynamoDB、Cassandra 都是这条路线。

它靠异步复制或后台对账实现写扩散，不需要等待所有副本确认即可返回成功。数学上，最终一致保证存在一个收敛时刻：

但“最终一致”不是“没有规则”。系统必须配套冲突处理机制：版本向量（Version Vector）检测并发写、CRDT 自动合并、或 LWW（最后写入者胜）决定谁的覆盖谁。如果每次约火锅都有人迟到半小时，聚会可能取消——最终一致的关键是“最终”是否落在业务可接受的时限内，否则强一致才是更安全的选择。

权衡对比核心

假设朋友们分处两节地铁车厢，突然有人断网，群被切成两个互不相通的小圈子。这时你必须选择：暂停讨论，等断网的人上线再统一结论（一致性）；还是两边各聊各的，事后同步（可用性）。你不可能同时做到“同步讨论”又“不同步交流”。这就是 CAP 定理的核心：当网络分区发生时，一致性与可用性无法同时满足，P 是分布式系统的常态而非异常，所以设计决策本质是“分区时保 C 还是保 A”。

除了可用性，延迟也是关键维度。强一致的写延迟大约等于一次网络往返乘以副本链长度，最终一致只需主副本一次本地确认。再看可用性指标：单个副本可用性为 A 时，n 个副本全部同时可用的概率是：

这个权衡就是“约火锅断网时等不等”的理论版：等，结论最准但可能永远约不成；不等，先吃上但后来的人可能不认账。没有绝对的对错，只有针对业务的选择。

主流系统选型

不同群聊工具选择了不同规则：工作群要求“已读必达”、消息严格不乱序，接近强一致；闲聊群里消息偶尔乱序没人投诉，最终一致足够。分布式系统和数据库也一样，它们的模型选择直接反映了服务的业务属性。

| 系统 | 一致性取向 | 理由 |

| --- | --- | --- |

| ZooKeeper / etcd | 线性一致（Raft/ZAB） | 分布式锁、配置变更必须全局唯一 |

| DynamoDB / Cassandra | 最终一致（可配置） | 海量流量下优先保证可用性 |

| MySQL 主从复制 | 最终一致 + 读己之写 | 多数业务读多写少，容忍短暂延迟 |

| MongoDB | 可配置（主从默认最终一致，可开 majority 读） | 兼顾性能与可调强度 |

| Spanner | 外部一致（TrueTime） | 跨地域金融级数据需要全局时钟 |

为什么 ZooKeeper 必须强一致？因为“分布式锁”的场景中，两个客户端不能同时认为自己拿到了锁——这是共识问题，错了就出事故。而 DynamoDB 面对的是购物车、会话这类高并发数据，短暂读到旧值用户无感，服务不可用才是真正的灾难。MySQL 主从则走中间路线：主库写、从库读，利用半同步复制和路由策略在性能与一致性之间找平衡。

选系统之前先想清楚：你的“群友”最在乎什么？是怕消息错乱（强一致），还是怕群聊卡死（可用性），还是怕每句话都排得严丝合缝却没有性能（顺序一致的代价）？

实际选型决策

手术室的远程会诊系统不容许数据迟疑一秒，朋友圈点个赞晚三分钟显示没人记得。一致性选型，本质是回答一个问题：“如果我的数据出现短暂的旧视图，业务会不会出人命、会不会丢钱、会不会掉用户。”评估顺序像一个漏斗：先看业务容忍度，再看 SLA 延迟与可用性指标，然后估算实现成本，最后用评分模型量化比较。

最终落地的组合通常有规律：支付、库存、分布式锁选线性一致；IM 聊天、评论回复选因果或顺序一致；Feed 流、点赞计数、日志收集选最终一致。常见的坑有两个：一是无脑强一致，把金融级的成本背到所有业务上；二是选了最终一致却不配冲突处理机制，数据冲突后无人裁决。最好的一致性不是最强的，而是最匹配业务的——就像最合适的群聊规则，是让所有人舒服地吃上那顿火锅的规则。

AI 应用场景

Python 演示

import time  class Replica:    """模拟一个带版本号的数据副本"""     def __init__(self, name):        self.name = name        self.version = 0        self.data = {}     def write(self, key, value, version):        self.data[key] = value        self.version = version     def read(self, key):        return self.data.get(key)  class StrongStore:    """强一致存储：所有副本同步写入成功后，调用方才能收到确认"""     def __init__(self, replicas):        self.replicas = replicas     def write(self, key, value):        version = self.replicas[0].version + 1        for r in self.replicas:     # 全量同步，一个副本失败整体失败            r.write(key, value, version)        return version     def read(self, key):        return self.replicas[0].read(key)  class EventualStore:    """最终一致存储：主副本确认即可，后台异步同步"""     def __init__(self, replicas):        self.replicas = replicas        self.pending = []     def write(self, key, value):        version = self.replicas[0].version + 1        self.replicas[0].write(key, value, version)        self.pending.append((key, value, version))        return version     def read(self, key, idx):        return self.replicas[idx].read(key)     def sync(self):        for key, value, version in self.pending:            for r in self.replicas:                if r.version < version:                    r.write(key, value, version)        self.pending.clear()  def main():    r1, r2, r3 = Replica("上海"), Replica("北京"), Replica("深圳")     strong = StrongStore([r1, r2, r3])    strong.write("stock", 100)    print("强一致写入完成")    print("上海副本:", strong.read("stock"))    print("北京副本:", strong.read("stock"))    print("深圳副本:", strong.read("stock"))     r1, r2, r3 = Replica("上海"), Replica("北京"), Replica("深圳")    final = EventualStore([r1, r2, r3])    final.write("stock", 500)    print("\n最终一致写入完成（仅主副本确认）")    print("上海副本:", final.read("stock", 0))    print("北京副本:", final.read("stock", 1))    time.sleep(0.1)    final.sync()    print("后台同步完成后")    print("北京副本:", final.read("stock", 1))    print("深圳副本:", final.read("stock", 2))  if __name__ == "__main__":    main()

1. r.write(key, value, version)每个副本都记录同一版本的数据，版本号用来判断新旧。
2. for r in self.replicas:强一致必须同步所有副本，一个也不许落下。
3. version = self.replicas[0].version + 1每次写入版本号递增，保证后写覆盖先写。
4. self.pending.append((key, value, version))最终一致先把写入动作记入待同步队列。
5. if r.version < version:只同步比当前副本更新的版本，避免旧数据覆盖新数据。
6. if __name__ == "__main__":独立运行时才执行演示，方便被其他模块导入。

常见误区

面试题