Quorum 读写机制
DynamoDB 的设计文档里有这么一句话:
"Dynamo uses a Quorum-like protocol and a decentralized replica synchronization protocol to ensure data consistency."
但很多工程师只知道 DynamoDB 叫"最终一致",不知道它的 Quorum 机制是怎么工作的。
今天,我们把 Quorum 读写机制从理论到实现彻底讲透。
一、Quorum 的核心思想
1.1 什么是 Quorum?
Quorum(法定人数)是一种广泛应用于分布式系统的投票机制。它的核心思想是:
只有当多数派节点确认了一个操作,这个操作才算成功。
1.2 Quorum 的三剑客:N、R、W
1.3 一致性公式
💡
DynamoDB 的默认配置是 N=3, R=2, W=2,即"两个节点确认才算写入成功,两个节点返回才算读取成功"。这意味着读取一定能读到最近一次写入(因为写入的节点和读取的节点必然有交集)。
二、Quorum 的读写流程
2.1 写入流程
2.2 读取流程
2.3 冲突解决(Conflict Resolution)
Quorum 读写最大的问题是:当 W < N 时,写入可能成功但不是所有节点都写入了。
三、生产事故:Quorum 踩坑实录
3.1 事故一:W 设置过低导致数据丢失
⚠️
Quorum 的 W 和 R 设置必须和副本数 N 配合。如果 N=5 但 W=2,意味着写入只需要 40% 的节点确认。一旦有节点故障,可能只有 3 个节点有数据(N - 2 = 3)。此时如果读取 R=3,可能刚好读到 3 个有数据的节点——但如果其中有节点损坏,读到的数据就不完整。
3.2 事故二:读修复延迟导致短暂不一致
Dynamo 的解决方案是 Read Repair:
3.3 事故三:网络分区期间的 Quorum 行为
四、Quorum vs Raft:两种共识的对比
4.1 核心区别
4.2 DynamoDB 的 Quorum vs etcd 的 Raft
【架构权衡】
Quorum 和 Raft 是互补的选择:
- Quorum(N/R/W):适合"我要高可用和最终一致,允许冲突" 的场景,如 DynamoDB、Cassandra 的写路径
- Raft:适合"我要强一致,允许短暂不可用" 的场景,如 etcd、ZooKeeper(写路径)
五、Quorum 参数调优
5.1 调优公式
5.2 场景化配置
六、生产避坑
6.1 坑一:节点数变化时 Quorum 计算错误
6.2 坑二:超时设置不当导致假失败
七、工程代价评估
【架构权衡】
Quorum 参数没有最优解,只有最适合业务的解。记住三个原则:
- R+W > N = 强一致,代价是延迟
- R+W
<N = 弱一致,好处是延迟低 - W 越高 = 写入越慢 = 数据越安全
- R 越高 = 读取越慢 = 读到正确数据的概率越高
大多数互联网场景选 R=2, W=2, N=3(DynamoDB 默认)是最务实的选择。