第 34 章 分布式理论：CAP、共识与一致性

CAP 与一致性模型给出"能承诺什么"，Raft 给出"怎么做到"，分布式事务、ID、锁、限流与分片则是这套理论在工程里的六张落地账单。

学习目标

读完本章，你应当能够：

1. 用 C/A/P 的准确定义破除"三选二"误读，说出分区发生时真正的二选一，并用 PACELC 给 Cassandra/HBase/MongoDB/MySQL 主从定位；
2. 按强弱排出线性一致、顺序一致、因果一致、最终一致的谱系，并用具体执行历史区分线性一致与顺序一致；
3. 独立推导 Raft 的选举超时随机化、AppendEntries 一致性检查、commitIndex 推进规则，以及为什么不能直接提交旧任期的日志（Figure 8 式反例）；
4. 说出 Paxos 两阶段的活锁成因与 Multi-Paxos 的改进点，并辨析 Raft 与 ZAB 的模型差异；
5. 列出六种分布式事务方案各自的不一致窗口，与六种分布式 ID 方案的失效场景；
6. 说清四种分布式锁各在什么时候不安全，以及 Redlock 争议的结论与 fencing token 的位置；
7. 算出一致性哈希下取模扩容的键迁移比例，说明虚拟节点为什么能消除倾斜。

前置知识检查

34.1 CAP 的准确表述与 PACELC

34.1.1 先把三个字母的定义读准

面试里九个候选人里九个会说"CAP 是三选二"，这是本章第一个要拆掉的错误。CAP 出自 Brewer 的猜想与 Gilbert、Lynch 的证明，三个字母的准确含义是：

• C = 线性一致性（linearizability），不是"数据一致"。它要求整个系统对外表现得像只有一个副本、且每个操作在其调用与返回之间的某一瞬间原子生效。注意这是一个强到苛刻的模型：它同时约束了"所有节点看到同一顺序"和"这个顺序必须与真实时间兼容"。很多系统自称"强一致"，实际只做到顺序一致或读己之写。
• A = 可用性，准确定义是"每一个非故障节点收到的每一个请求，都能在有限时间内返回一个非错误响应"。关键词是"非故障节点"与"非错误响应"：超时不算可用、返回 503 不算可用、返回可能过期的数据算可用。所以 A 不等于"高可用"，它是有界响应性。
• P = 分区容忍，指网络被切成若干互不可达的子集时系统仍能继续运行。这里的"分区"是网络分区（network partition），不是数据分区（sharding）。

34.1.2 “三选二"错在哪

“三选二"隐含一个前提：三者权重相同、可以任意舍弃一个。两个错误：

1. P 不是可选项。只要系统跨网络部署，交换机故障、GC 长暂停、网线被拔都会产生分区。分区不是"要不要"的问题，而是"什么时候发生"的问题。既然 P 必须保留，“三选二"就退化成二选一，且只在分区期间。
2. CA 系统在分布式语境下不存在。单机数据库满足 CA（没有分区可言），但一旦跨机，就必须面对分区。 所以正确表述是：在分布式系统中 P 是前提，真正的选择是"分区发生时，宁可拒绝服务以保证线性一致（CP），还是宁可返回可能陈旧或冲突的数据以保证可用（AP）”。而且这个选择只在分区窗口内生效——没有分区时，CAP 什么都不约束，这正是 PACELC 要补的那一半。

34.1.3 PACELC：没有分区时的另一半账

PACELC（读作 “pass-el-see”）由 Abadi 提出，把 CAP 补全为两段：if Partition then A else L, else C —— 即"分区时在 A 与 C 之间选；否则（Else）在延迟 L 与一致性 C 之间选"。 第二段才是日常态。以三副本为例：MongoDB 的多数派写（w:majority）要等两个副本确认，比 w:1 多出一个跨机房往返；单机房 RTT 约 0.1~0.5 ms，跨可用区往往按毫秒到几十毫秒计，跨大洲约 150 ms。同步复制用延迟买一致性，这就是 C 与 L 的交换。

34.1.4 BASE 与柔性事务

BASE（Basically Available, Soft state, Eventually consistent）是 AP 路线的工程口号，与 ACID 相对。它的准确落点是放弃"事务边界的原子性由数据库保证”，把原子性移交应用层：允许中间态被外部观察（软状态）、允许读暂时陈旧（最终一致），用柔性事务（flexible transaction）换可用性与吞吐。柔性事务的共同特征是"没有全局锁或全局锁只持有极短时间，一致性由重试、补偿、对账三条路兜住"，具体六种方案见 34.5 节。判断一个方案是刚是柔，只问一句：它有没有在一段时间内让某个资源全局不可用？ 有就是刚性（如 2PC），没有就是柔性。

34.2 一致性模型谱系

一致性模型不是"程度的形容词"，而是一条从强到弱、可用性和延迟逐级改善的谱系。判断一个历史是否合法，看它是否满足对应模型的约束。

34.3 Raft：从选举到提交的完整推导

34.3.1 三种角色、任期与状态

Raft 把节点分为 Leader、Follower、Candidate 三种角色，并把时间切成递增的任期（term）（连续整数）。每个节点持久化 currentTerm 和 votedFor，term 的作用是给所有消息与日志条目打上单调的逻辑时间戳，让节点能一眼判断"这条消息是否过期"。

1
2
3
4
5
6
7
8
9

           选举超时（150~300 ms 随机）
                   ▼
   ┌──────────┐  超时   ┌───────────┐  拿到多数票   ┌────────┐
   │ Follower │────────▶│ Candidate │──────────────▶│ Leader │
   └──────────┘         └───────────┘               └────────┘
        ▲                     │ 发现更大 term /        │
        │                     │ 同 term 已有 Leader    │ 发现更大 term
        └─────────────────────┴────────────────────────┘
   全部角色：收到更大 term 的消息 → 立刻退回 Follower 并更新 currentTerm

每个节点还维护两个易失索引，这是 34.3.3 全部推导的基础：commitIndex（已知被多数派持久化的最高日志下标，可安全应用到状态机）与 lastApplied（已应用到状态机的最高下标）；Leader 额外维护每个 Follower 的 nextIndex（下一条要发的下标）与 matchIndex（已确认复制到的最高下标）。

34.3.2 选举：随机化超时为什么是必需品

Follower 在选举超时内没收到任何 AppendEntries 或投票请求，就自增 currentTerm、投自己一票、转为 Candidate，向所有节点并发发 RequestVote。 RequestVote 的关键参数与投票规则：

• 参数：term（候选人任期）、candidateId、lastLogIndex、lastLogTerm。
• 投票条件（两条都必须满足）：term 不小于自己的 currentTerm，且候选人的日志"至少和我一样新"。日志新旧的比较是：先比最后一条日志的 term，大者更新；term 相同再比 lastLogIndex，大者更新。
• 拿到多数派（N/2 + 1）选票才当选；每个任期每个节点只投一票（votedFor 持久化，防止重启后重复投票）。 为什么要随机化超时？假设所有节点固定在同一个超时时间。它们会几乎同时超时、同时进入 Candidate、同时把票投给自己。N 个节点分成 N 份选票，没有任何人拿到多数派（这是"选票瓜分",split vote），然后所有人同时等待下一个同样的超时，再次同时开选——系统可以无限期无法选出 Leader。

1
2
3
4
5

固定超时（全部 150 ms）          随机超时（150~300 ms）
t=0   所有节点同时超时             最先超时的节点（如 173 ms）率先发 RequestVote
t=0+  各投自己 → 票数 1,1,1,1,1    其余节点还在等待，未投票 → 票全部给它
t=150 同时重来 → 再瓜分            当选，发心跳，其余节点重置计时器
⇒ 可能永远选不出来                 ⇒ 冲突概率被压到很低，且每轮重试都独立

随机区间通常取 150~300 ms（Raft 论文口径）；网络 RTT 越大、节点越多，区间要相应放宽，但要保证随机上限明显小于"业务可容忍的选举中断时间"，否则每次换主都要停顿几百毫秒。

34.3.3 日志复制：两条索引与一次一致性检查

Leader 收到客户端请求后，先追加到本地日志，再向所有 Follower 并发发 AppendEntries，携带新条目以及两个"锚点"：prevLogIndex（紧邻新条目之前的日志下标）与 prevLogTerm（该条目的任期）。

1
2
3
4
5
6

Leader (term=5) 日志：[1:1][2:1][3:2][4:3][5:5]   Follower A 日志：[1:1][2:1][3:2][4:3]
                        ▲                              ▲
                  nextIndex[A]=5                  matchIndex[A]=4
   AppendEntries(term=5, prevLogIndex=4, prevLogTerm=3, entries=[idx5,term5])
   Follower 检查：自己 idx4 的 term 是 3 == prevLogTerm 3  → 接受，追加 idx5
   → Leader 收到成功：matchIndex[A]=5，nextIndex[A]=6

Follower 的两条规则：prevLogIndex 处的条目必须存在且 term 等于 prevLogTerm，否则拒绝（并可直接带上自己冲突位置的提示以加速回退）；接受后若新条目与已有条目冲突，删除从冲突点开始的全部后续条目再追加。 拒绝时 Leader 的处理是回退重试：把该 Follower 的 nextIndex 减一，重新发上一轮的 AppendEntries，直到找到双方一致的那个点。这是一次"二分式的逐条回退"，最坏要退到 nextIndex=1。优化手段是让 Follower 在拒绝响应里直接回报冲突条目的 term 与该 term 的首个下标，Leader 一次跳过整个冲突任期，把 O(日志长度) 次往返降到 O(冲突任期数) 次。

34.3.4 commitIndex 的推进规则与"不能提交旧任期日志"

Leader 的提交规则有两条，缺一不可：

1. 只有当前任期的日志条目才能通过"计数多数派"直接提交；
2. 一旦当前任期的某条目被提交，它之前的所有条目（含旧任期的）也被连带提交——因为被提交的条目在所有日志中都位于更早的位置，Followers 的日志按 Raft 日志匹配性质与 Leader 一致。 为什么不能直接提交旧任期日志？用 Figure 8 式反例逐步推。设 5 个节点 S1~S5，多数派 = 3。

1
2
3
4
5
6
7
8

时刻①  任期2，Leader=S1。追加了 idx2=term2 的条目，只复制到 S1、S2（未过半数）→ 不可提交
        S1:[1:1][2:2]   S2:[1:1][2:2]   S3:[1:1]   S4:[1:1]   S5:[1:1]

时刻②  S1 宕机。S5 在任期3 当选（S3、S4、S5 投票），追加 idx2=term3 的条目，未提交
        S1:--宕机--     S2:[1:1][2:2]   S3:[1:1][2:3]  S4:[1:1][2:3]  S5:[1:1][2:3]

时刻③  S5 与 S3、S4 相继宕机；S1 重启并在任期4 当选（S1、S2 投票，S3/S4/S5 不在）
        S1 把 idx2=term2 复制给 S3、S4、S5，此时 idx2=term2 已在 {S1,S2,S3,S4,S5} 多数派上

此刻如果 Raft 允许"只要某条旧任期日志落在多数派上就提交它"，则 idx2=term2 被提交，进而 idx2=term3（S5 那条）也被连带提交。但时刻③ 之后 S5 若再次当选并能复制日志，它会把 idx2=term2 覆盖掉——一条已提交的条目被覆盖，状态机安全性直接破裂。 根因是：旧任期条目"看起来在多数派上"这件事不代表它现在还安全，因为那条目所在位置的多数派可能已被后来的任期内选举换掉。反过来，只要当前任期的条目提交了，旧任期条目就必然安全：当前任期条目能过多数派，说明多数派的日志已经包含了它之前的所有条目（prevLogIndex/prevLogTerm 检查保证了这一点），而任何未来 Leader 都必须从这个多数派里产生，必然带有这些条目。所以规则 1 是安全性的充分条件，规则 2 是它的副产品。

34.3.5 网络分区下的两个 Leader

5 节点被切成 {S1,S2} 与 {S3,S4,S5}：

• 多数派侧 {S3,S4,S5}：能选出 Leader、能提交日志、正常对外服务。
• 少数派侧 {S1,S2}：原 Leader 若在其中，它仍然认为自己是 Leader（它没有全局视野），但任何 AppendEntries 都拿不到多数派确认，所以 commitIndex 无法推进，一条日志都提交不了，客户端写入全部超时。
• 分区恢复：少数派侧 Leader 收到更大 term 的心跳就退回 Follower，其本地未提交的日志被多数派侧的日志覆盖回滚；lastApplied 之后的条目要回退到提交点重新应用。 这个"双主"是良性的，前提正是 34.3.4 的规则：少数派侧的"主"没有提交能力。如果它也能提交，就会出现两个状态机各自前进并永久分叉。

34.3.6 成员变更：为什么不能一次换掉一半

集群配置（membership）本身也是一份需要共识的数据。如果直接把 {A,B,C} 改成 {A,B,C,D,E} 并让两边各自独立选主，可能出现 {A,B,C} 选出 L1、{A,B,C,D,E} 选出 L2 的局面，两个多数派互不重叠，安全性破裂。

• 单节点变更（one server at a time）：一次只增删一个节点。任意两步配置的多数派必然相交，因此不会出现两个不相交的多数派。实现简单，但是串行的，扩容 10 个节点要 10 轮。
• 联合共识（joint consensus）：先切到 C_old,new（提交需要两个配置各自的多数派都同意），再切到 C_new。任意时刻最多只有一个配置的多数派能独立工作。代价是实现复杂、需要额外的中间态处理。

34.4 Paxos、ZAB 与 Raft 的关系

Paxos 解决的最小问题是"一组进程对单个值达成共识"（Basic Paxos），两阶段：

1
2
3
4

Phase 1  Prepare(n)          →  Proposal 编号 n（全局唯一、单调递增）
         Promise(n, v')      →  承诺不再接受编号 < n 的 Proposal，并回报已接受的最高编号值 v'
Phase 2  Accept(n, v)        →  v 取"回报值中编号最大的那个"，没有回报值才用自己提议的值
         Accepted(n, v)      →  多数派接受即选定

两个必须点破的地方：其一，提案编号必须全局唯一且单调（用 <序号, proposerId> 保证）；其二，Phase 2 的值不是提议人自由选的——若多数派中有节点已接受过某值，提议人必须采用"最高编号对应的那个值"，这正是"已选定的值不会被推翻"的原因。 Basic Paxos 的活锁：P1 发 Prepare(1)，P2 发 Prepare(2)，各自在对方 Accept 前用更大编号抢占，然后互相不断加号——没有人能完成 Phase 2，谁也不违反安全性，但永远达不成决议。Multi-Paxos 的改进是：选出一个稳定的 Leader（distinguished proposer）由它串行提出后续所有 Proposal，并把 Phase 1 一次性对所有日志槽位做完（后续只跑 Phase 2），把每轮 2 个 RTT 降到稳态约 1 个 RTT。 Raft 的定位是为可理解性而设计的 Multi-Paxos 变体：它做了三件 Paxos 没规定的事——强 Leader（日志只能从 Leader 单向流向 Follower，Paxos 允许任何提议人）、连续的日志槽位与 prevLogIndex/prevLogTerm 检查（Paxos 的 slot 是独立的）、把成员变更写进协议。两者共享的核心约束完全相同：多数派交集保证任意两个已选定的决议不会冲突，编号/任期单调保证旧消息被识别并丢弃。

34.5 分布式事务六种方案对比

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// Try：只做资源预留，绝不产生"最终账"——否则 Cancel 无法真正撤销
boolean tryFreeze(String orderId, long amount) {
    // 唯一索引 + 幂等表：Try 可能被重复执行（网络超时后重试），必须靠 orderId 去重
    return accountMapper.freeze(orderId, amount); // 影响行数 0 表示已被冻结过
}
// Cancel：必须幂等，且必须处理"Try 从未执行"的空回滚
boolean cancelFreeze(String orderId) {
    // 空回滚 = Cancel 先于 Try 到达（Try 请求超时但实际未写入），此时没有冻结记录
    // 只返回 true 会让悬挂风险成立，所以要先插一条"防悬挂"标记记录
    if (freezeMapper.exists(orderId)) return accountMapper.unfreeze(orderId);
    return hangGuardMapper.insert(orderId); // 写下防悬挂标记，拒绝其后到达的 Try
}

TCC 三大坑：空回滚（Try 未到、Cancel 先到，不能报错也不能什么都不做，要落防悬挂标记）、幂等（Try/Confirm/Cancel 都可能重试）、悬挂（Cancel 先到并释放了资源，Try 随后才到并真的冻结，资源被永久占用——防悬挂标记就是为它存在的）。这三个坑在面试里几乎是 TCC 的必问项。

34.6 分布式 ID 的六种方案与取舍

1
2
3
4

 0 | 41 bit 毫秒时间戳 | 10 bit 机器 ID | 12 bit 序列号
 ▲        ▲                  ▲              ▲
符号位     可用 2⁴¹ ms ≈ 69.7 年   最多 1024 台    同毫秒内最多 4096 个
（恒为 0）  起点为自定义纪元(epoch)，因此 41 位约 69 年才耗尽

10 bit 常拆成 5 bit 数据中心 + 5 bit 机器（各 32）。4096 × 1000 = 4,096,000/s，这是单机理论上限。 时钟回拨是 Snowflake 唯一的致命伤，因为算法假设"时间戳单调不减"，回拨后同一毫秒会重复生成 ID。四种处理方式与各自代价：

34.7 分布式锁：四种实现与各自不安全的时刻

本节只做理论对比与缺陷判定；Redis 锁的命令写法、看门狗与主从切换细节见第 27 章 27.11 节。

实现	互斥来源	自动释放	性能量级	什么时候不安全
数据库唯一索引	唯一约束 INSERT 冲突	无（必须显式 DELETE，进程崩溃即死锁）	一次写入约 1~10 ms 量级	进程崩溃后锁永久残留；DELETE 语句本身可能超时；无超时机制时依赖人工清理
Redis	SET NX PX 的原子写入	有（PX 过期）	一次往返约 0.1~0.5 ms（同机房）	主从异步复制：主库写入成功未同步即宕机，从库升主后另一客户端也能加锁成功，互斥破裂
ZooKeeper	临时顺序节点 + Watch	有（会话超时即删临时节点）	一次操作约 1~5 ms 量级	会话超时抖动导致误判持锁方已死；羊群效应（若都用 Watch 同一节点，释放时惊群）——用顺序节点各自 Watch 前一个解决
etcd	租约 Lease + 事务 Txn	有（租约到期）	与 ZK 同量级	本质同 ZK：租约到期与"旧持有者仍在写"之间的窗口依然存在（GC 长暂停会放大它）
Redis 与 ZK/etcd 的根本差别是一致性模型的差别：Redis 主从异步复制走的是 AP 路线，“加锁成功"这个事实在故障切换时可能丢失；ZK/etcd 基于共识协议走 CP，“加锁成功"必然是多数派已持久化的事实，所以它在切换后不会丢。这就是同一把锁在两种底座上"安全性不同"的根源，而不是命令写得对不对。
Redlock 想用"向 N 个（通常 5 个）相互独立的 Redis 实例依次加锁，多数派成功且在总耗时小于锁有效期内才算成功"来绕开单主从的复制丢失问题。Kleppmann 提出两条质疑：其一，它依赖时钟假设——锁的有效性靠各实例的过期时间推算，而这些进程的时钟可能发生跳变（NTP 校时、虚拟机迁移、GC 暂停都可能导致本地时间"快进”），续期与过期判断因此在理论上不可靠；其二，它没有 fencing token——一个进程在 GC 长暂停后恢复，它不知道自己已经不再持锁，仍会向共享资源发起写操作，而资源侧无法识别这是过期持有者。Antirez 的回应是：不依赖时钟的严格方案需要额外机制，而 Redlock 的时钟误差假设（各实例时钟漂移远小于锁有效期）在其设计边界内是可以接受的工程近似。
结论（本节的加分点）：Redlock 争议的真正价值不在于判谁赢，而在于它揭示了一条工程准则——锁的正确性不应被用来保护数据一致性，除非配合 fencing token。若锁只是"减少重复计算”（如避免缓存击穿时的重复回填），出错的代价只是多做一次；若锁保护的是数据一致性（如"同一订单只能被处理一次"），必须让下游资源能拒绝过期锁的写入：持锁方从锁服务拿到单调递增的版本号，写请求带上它；资源侧（数据库、存储）记录已见到的最大版本号，拒绝任何版本号更小的写入。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

      客户端                锁服务                资源（DB/存储）
        │  acquire ──────────▶│
        │  ◀──── token = 33 ──│            （每个锁请求返回比上次更大的 token）
        │                                          │
        │  ── 此处发生 GC 长暂停 / 网络分区 ──      │
        │                                          │
        │  锁过期，客户端 B 拿到 token = 34 ────────▶│  write(token=34) ✔ 记录 max_token=34
        │                                          │
        │  客户端 A 恢复，仍以为持锁 ───────────────▶│  write(token=33) ✘ 33 < max_token → 拒绝
                                                   ⇒ 即使锁语义被破坏，数据也不会被旧持有者污染

34.8 限流算法与一致性哈希

34.8.1 四种限流算法

34.8.2 一致性哈希、虚拟节点与 Redis Cluster 的分片

普通取模扩容的代价可以精确量化。 用 hash(key) mod N 分片，从 N 个节点扩到 N+1 个节点时，某个键仍落在同一节点，当且仅当 hash(key) mod N == hash(key) mod (N+1)。在哈希均匀的近似下，这个比例约为 1/(N+1)，因此需要迁移的键的比例约为 N/(N+1)：

• N=3 → 4：迁移 3/4 = 75%；
• N=9 → 10：迁移 9/10 = 90%；
• N=99 → 100：迁移 99/100 = 99%。 也就是说，节点越多，扩一个节点几乎要搬全量数据（N 取 100 时是 99%），这是"取模分片不能平滑扩容"的量化结论。 一致性哈希（consistent hashing） 把哈希空间组织成一个 0 ~ 2³² − 1 的环，节点与键都哈希到环上，键归属顺时针方向第一个节点。增删一个节点时，只有该节点逆时针到前一个节点之间的那一段键需要迁移，期望迁移比例是 1/(N+1)（加一个节点时约分走 1/(N+1) 的键）。

1
2
3
4
5
6
7
8
9

                    hash ring:  0 ──────────────────────▶ 2³²−1
                         ┌──────── N1 ────────┐
                    K3   │                    │  N3
              ┌──────────┤                    ├────────┐
              │          │      K1  K2        │        │
              │  N2      └────────────────────┘        │
              └───────────────────────────────────────┘
   顺时针：K1 → N3（顺时针第一个节点）；K2 → N3；K3 → N1
   加节点 N4 落在 K1 与 N3 之间 ⇒ 只有原本归 N3 且位于 N4 逆时针区间内的键改归 N4

一致性哈希的问题是数据倾斜：节点数少时，节点在环上分布不均，可能出现一个节点承担 50% 以上的键（“一个节点管半个环”）。极端情况下两个节点哈希得很近，其中一个几乎分不到数据。 虚拟节点（virtual node） 解决它：每个物理节点映射为 V 个虚拟节点（V 通常取 100~1000，工程上常用 150 或 160），虚拟节点散布在环上，键先落到虚拟节点再映射回物理节点。V 越大，各物理节点承载的键比例越接近 1/N——这是"用更多哈希点逼近均匀分布"的做法。代价是每个物理节点的信息要存 V 份（N 个节点 V=160 时是 160N 个环上条目），路由表内存与查找成本随之上升；Ketama 算法就是在这一层做优化的经典实现（它把每个物理节点的虚拟节点数固定为 160，并用一个有序结构做二分查找来定位顺时针第一个节点）。

本章小结

自测题

Q1（辨析）有人说"我们的系统选择了 AP，所以不需要线性一致，只要最终一致"。这句话在 CAP 的语境下错在哪？

Q2（推导）5 节点 Raft 集群，Leader S1 在任期 2 追加了 idx2=term2，只复制到 S2。随后 S1 宕机，S5 在任期 3 当选并追加 idx2=term3，只复制到 S3、S4，然后 S5、S3、S4 全部宕机。S1 重启后在任期 4 再次当选并把 idx2=term2 复制到全部 5 个节点。此时能否说"idx2=term2 已在多数派上，可以提交"？为什么？

Q3（计算）某服务用 hash(key) mod N 分 8 个库。现在要扩到 9 个库，问：(1) 约多少比例的键需要迁移？(2) 若改用一致性哈希（无虚拟节点），加第 9 个节点时期望迁移比例是多少？(3) 如果一致性哈希出现严重倾斜，加虚拟节点后迁移比例会怎么变？

Q4（设计）一个跨服务的订单扣库存场景，要求"同一订单绝不重复扣减"。团队打算用 Redis 分布式锁（SET NX PX + Lua 释放）保护扣减逻辑，你如何评价这个方案？如果一定要用锁，怎么补齐它的短板？

Q5（辨析）Paxos 的 Basic 版本既然能保证安全性，为什么工程上几乎所有系统都用 Raft 或 Multi-Paxos 而不是 Basic Paxos？请给出两个以上的具体原因。

面试高频问题与陷阱

延伸阅读

• In Search of an Understandable Consensus Algorithm（Raft 论文，Ongaro & Ousterhout）：34.3 全节的原始依据，Figure 8 是 34.3.4 反例的来源。
• Paxos Made Simple（Lamport）：34.4 节两阶段的原始表述。
• Zab: High-performance broadcast for primary-backup systems：34.4 节 ZAB 与 Raft 差异的依据。
• Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services（Gilbert & Lynch）：34.1 节 CAP 的形式化证明。
• Consistency Tradeoffs in Modern Distributed Database System Design（Abadi，PACELC 的提出）：34.1.3 节。
• How to do distributed locking（Kleppmann）与 Is Redlock safe?（Antirez）：34.7 节 Redlock 争议的正反两方原文。
• Redis Cluster Specification：34.8.2 节 16384 槽与位图开销、按槽迁移的官方依据。
• Apache Seata 官方文档（AT/TCC/Saga 模式与全局锁、undo_log）：34.5 节。
• 见第 21 章 21.5 节（两阶段提交的崩溃点恢复）、第 22 章 22.1 节（ACID 的实现依赖）、第 23 章 23.2 节（随机主键导致页分裂）、第 26 章 26.1 节（复制模式与丢数据窗口）、第 27 章 27.11 节（Redis 锁的命令实现与看门狗）、第 33 章 33.4 节（重复消费与幂等原语）、第 35 章（接口幂等落地与熔断三态）。