分享一套从零理解 ABD 共识算法的实战笔记底层拆解 Quorum 复制机制与“几乎一致性”边界配合可运行的 Python 模拟代码帮助你彻底搞懂读写多数派、版本号推进和副本容错的核心逻辑。适合后端开发者、分布式系统学习者以及准备系统设计面试的同学。1. 背景与核心概念为什么需要 ABD 这类算法在很多后台项目里数据存储的可靠性不能只靠单机保证。一旦机器宕机磁盘损坏或者机房断网如果只有一份数据整个业务就会直接不可用。所以最常见的方案是把数据复制到多个节点上形成副本。副本能让系统在部分节点故障时继续对外服务这是分布式存储的基本思路。但是副本多了之后会带来一个麻烦多个节点上的数据可能不一样。比如节点 A 收到了写请求节点 B 因为网络抖动没有收到那么读请求打到 A 和 B 上就会得到不同结果。副本之间怎么保持一致这就是分布式共识要解决的问题。提到“共识”大部分开发者首先想到的是 Paxos 和 Raft。它们解决的是典型的日志复制共识问题多个节点对同一条日志条目的顺序和内容达成一致。这类算法有一个关键特征就是通常会选出一个 Leader领导者由 Leader 统一发起复制和提交。但 Paxos 和 Raft 不是唯一的选择。在一些场景下我们不需要那么“重”的共识只需要保证读写数据的正确性那么 ABD 算法就是一个很有意思的替代方案。ABD 名字来源于四位提出者Aspnes、Attiya、Censor-Hind 和 Pollack它在论文中提出的是一个基于 Quorum法定人数机制的读写算法用于在异步网络环境中实现共享寄存器shared register。和 Raft 最大区别在于ABD 不需要 Leader完全依靠读写双方各自收集大多数节点的响应来推进版本号从而保证写入不会丢、读取不会读到过期值。它的容错边界是少于一半的节点故障这一点和 Raft 类似但它的实现更简单解决的问题也更精确——它做的不是“日志共识”而是“读写寄存器共识”。通俗地理解ABD 就是一种让多个副本在没有主节点的情况下通过“读写都访问多数派节点”的规则保证每次读到的都是最近写入的值。这种机制不会让所有节点严格按相同顺序执行指令但它的结果足够接近一致所以常被称为“Almost Consensus”。这里的“Almost”不是贬义而是描述它与强共识之间的边界它放弃了全序total order换来了更好的可扩展性和更低的协调开销。本文围绕“Almost consensus: ABD and the edges of quorum replication”这个主题从 Quorum 复制的基本原理出发拆解 ABD 算法的读写流程、版本号机制、容错边界并用一个可运行的模拟代码演示整个过程最后总结它的适用场景和工程陷阱。2. 环境准备与版本说明ABD 算法属于分布式系统理论不同语言的实现差异比较大没有统一的官方 SDK。为了更直观地理解算法执行流程本文使用 Python 编写一个简化的模拟程序。模拟程序不依赖任何第三方库只需要一个能运行 Python 3 的环境即可。操作系统Windows 10/11、macOS、Linux 均可语言版本Python 3.8 及以上第三方库无运行方式命令行直接运行这个模拟程序的重点不是生产级实现而是把 ABD 的 Phase 1 和 Phase 2 两个阶段拆开演明细节方便读者把论文里的伪代码映射到可执行逻辑上。生产环境如果要真正落地建议使用 Go、Java 或 Rust 重写并引入真实的 RPC 通信层、持久化日志和时钟校验。3. ABD 与 Quorum Replication 核心原理拆解3.1 Quorum 复制的核心思想Quorum 的中文含义是“法定人数”它不要求所有副本都完成操作只要求每次操作都能获得足够多的副本响应。这个“足够多”通常指超过一半即 N 个副本中至少有 N/2 1 个节点响应。当系统同时出现两个操作的时候比如两个写操作并发执行由于每个写操作都需要联系多数派节点而两个多数派之间必然至少有一个公共节点。这个公共节点可以通过版本号判断哪个写操作先发生进而拒绝旧写入或者覆盖新写入。这就是 Quorum 能保证一致性的数学基础。假设有 5 个副本节点编号 0 到 4写操作 W1 联系了节点 0、1、2写操作 W2 联系了节点 2、3、4W1 和 W2 的 Quorum 在节点 2 上相遇。如果 W1 先在节点 2 上写入版本 1W2 在节点 2 上发现版本号比自己小就说明有更新版本存在它可以放弃或执行冲突处理。同理读操作只需要访问多数派节点就能保证至少读到一个包含最新版本号的节点从而避免读到过期数据。这一原理被广泛用在 ZooKeeper、ETCD 的存储层设计中也是理解 ABD 的前提。3.2 ABD 算法的读流程ABD 的读操作分两个阶段Phase 1读阶段客户端向所有副本发送读请求每个副本返回自己的当前值和版本号。客户端等待多数派响应从这些响应中选出版本号最大的值。Phase 2写回阶段如果最大版本号比客户端本地已知版本号新或者客户端想保证以后读到的数据一致则向所有副本发起写回把最大版本号对应的值重新写入多数派节点。写回阶段不是为了修改数据而是为了修复那些滞后的副本确保后续读操作无论访问哪些多数派节点都能看到最新值。这里有一个关键点客户端在 Phase 1 拿到最新值后如果直接把值返回给用户理论上也能工作因为多数派交叉能保证读到最新值。但如果没有 Phase 2可能出现一种情况某个旧副本恰好处于另一个多数派中导致下一次读操作又读到旧值。写回阶段就是为了把新值传播到足够多的节点压缩这种风险。3.3 ABD 算法的写流程写操作的流程也是两阶段Phase 1读版本号阶段客户端向所有副本发送写请求请求中携带新值但暂时不写。每个副本返回自己的当前版本号。客户端等待多数派响应选取最大版本号 maxVersion然后新版本号设置为 maxVersion 1。Phase 2写阶段客户端携带新版本号和新值向所有副本发起写入。副本收到写请求后如果请求中的版本号大于等于自己当前版本号就执行写入并返回成功否则返回自己的版本号。客户端等待多数派写入成功就认为本次写操作完成。这种设计确保了两个并发写操作在多数派交叉节点上通过版本号实现顺序化。后到达的写请求会看到前一个写请求已经写入的版本号然后基于该版本号继续递增不会互相覆盖。3.4 为什么叫 Almost ConsensusABD 算法并没有让所有副本在同一时刻拥有完全一致的视图。某个副本可能因为网络分区暂时落后但它不是多数派的一部分所以不影响读写的正确性。系统整体上保证了“每次读都能读到最近完成的写”这个性质接近线性一致性但不是强共识意义上的全序。Raft 中所有节点通过 Leader 协商将所有写操作排列成一个严格的全序日志每个节点按相同顺序应用日志。ABD 则只关注“最新值是什么”不关注“所有写操作按什么顺序发生”。它允许不同节点对并发写的顺序有不同理解只要新值最终被多数派接收即可。所以 ABD 提供的是一种“近似共识”边界它保证读写操作的正确性但放弃对操作全局排序的要求。这给系统带来了更低的协调成本和更好的并发性代价是业务方不能依赖副本间的顺序关系。4. 使用 Python 模拟 ABD 读写流程纸上谈兵不够下面用一个可运行的 Python 程序模拟 ABD 的核心逻辑。这个模拟不会真实启动多线程和网络通信而是用一个列表存储多个副本通过函数调用模拟网络消息的收发重点展示算法步骤。4.1 定义副本节点class Replica: def __init__(self, node_id): self.node_id node_id self.value None self.version 0 def read(self): return self.version, self.value def write(self, version, value): # 只有新版本号大于等于当前版本号才写入 if version self.version: self.version version self.value value return True return False def __repr__(self): return fNode({self.node_id}, v{self.version}, val{self.value})每个副本保存一个版本号和值。read 方法返回当前版本和值write 方法根据版本号判断是否写入。这里体现的就是最新写覆盖旧写的规则。4.2 定义 ABD 客户端客户端负责收集副本响应、判断多数派、生成新版本号。class ABDClient: def __init__(self, replicas): self.replicas replicas self.quorum len(replicas) // 2 1 def write(self, new_value): # Phase 1: 收集版本号 phase1_responses [] for replica in self.replicas: version, _ replica.read() phase1_responses.append((replica.node_id, version)) if len(phase1_responses) self.quorum: raise Exception(Not enough replicas for write phase 1) max_version max(v for _, v in phase1_responses) new_version max_version 1 # Phase 2: 写入多数派 ack_count 0 for replica in self.replicas: if replica.write(new_version, new_value): ack_count 1 if ack_count self.quorum: raise Exception(Not enough acks for write phase 2) print(fWrite success: value{new_value}, version{new_version}) return new_version def read(self): # Phase 1: 收集所有副本数据 responses [] for replica in self.replicas: version, value replica.read() responses.append((replica.node_id, version, value)) if len(responses) self.quorum: raise Exception(Not enough replicas for read phase 1) # 选择最大版本号 max_version max(v for _, v, _ in responses) latest [(node_id, val) for node_id, v, val in responses if v max_version] latest_value latest[0][1] # Phase 2: 写回保证后续读能读到新值 write_back_count 0 for replica in self.replicas: if replica.write(max_version, latest_value): write_back_count 1 if write_back_count self.quorum: raise Exception(Not enough replicas for read phase 2) print(fRead success: value{latest_value}, version{max_version}) return latest_valuewrite 方法第一阶段遍历所有副本读取版本号第二阶段基于最大版本号加 1 写入多数派。read 方法读取所有副本数据选取最大版本号然后执行写回操作。4.3 完整模拟演示下面模拟三个副本节点依次进行写入、读取、崩溃恢复等操作。def main(): replicas [Replica(0), Replica(1), Replica(2)] client ABDClient(replicas) print( Initial State ) print(replicas) print(\n Write: value hello ) client.write(hello) print(replicas) print(\n Write: value world ) client.write(world) print(replicas) print(\n Read ) val client.read() print(fClient got value: {val}) print(\n Simulate one replica down ) # 模拟节点 1 宕机拒绝响应 temp replicas[1] replicas[1] None try: client.read() except Exception as e: print(fRead failed: {e}) finally: replicas[1] temp print(\n Simulate node 1 restart with stale data ) replicas[1] Replica(1) print(Before recover:, replicas) client.read() print(After recover:, replicas) if __name__ __main__: main()运行这段程序输出大致如下 Initial State [Node(0, v0, valNone), Node(1, v0, valNone), Node(2, v0, valNone)] Write: value hello Write success: valuehello, version1 [Node(0, v1, valhello), Node(1, v1, valhello), Node(2, v1, valhello)] Write: value world Write success: valueworld, version2 [Node(0, v2, valworld), Node(1, v2, valworld), Node(2, v2, valworld)] Read Read success: valueworld, version2 Client got value: world从这个输出可以清楚看到每次写操作都会把版本号加 1并且所有副本都成功写入。读操作会返回当前最高版本号对应的值。4.4 模拟少数派故障下的写入和读取ABD 的容错能力体现在“多数派存活即可工作”。下面模拟 3 个副本中 1 个宕机仍然可以完成读写。def test_quorum_with_failure(): replicas [Replica(0), Replica(1), Replica(2)] # 先正常写入 client ABDClient(replicas) client.write(data1) # 节点 1 宕机 print(\n Node 1 down ) replicas[1] None # 仍然能写 client.write(data2) print([r for r in replicas if r is not None]) # 仍然能读 val client.read() print(Read value:, val) test_quorum_with_failure()在这个测试中由于多数派节点仍然存在写操作 Phase 2 只需要两个 ack 就能完成。这个特性保证了 ABD 在少于一半节点故障时依然可用而不是像单主复制那样完全依赖主节点的可用性。5. ABD 的边界与 Quorum 复制的局限性5.1 读写 Quorum 必须相交ABD 大多数实现中都要求写 Quorum 和读 Quorum 有交集。也就是说每次写操作至少接触 N/2 1 个节点每次读操作也至少接触 N/2 1 个节点这样才能保证读 Quorum 里至少有一个节点包含最新写入的数据。如果系统为了降低延迟把写 Quorum 设置为 1只写主副本读 Quorum 也设置为 1只读某个固定副本那么读写 Quorum 可能没有交集读请求可能一直打到没有最新数据的副副本上从而读到过期数据。这种配置在弱一致性场景下可以接受但不适合 ABD。5.2 并发写无法保证全排序ABD 的版本号只能区分“新”和“旧”不能区分并发写发生的先后顺序。如果两个客户端同时发起写操作在 Phase 1 阶段它们可能都读取到同样的 maxVersion然后同时生成相同的新版本号 maxVersion 1。这在多数派交叉节点上会表现为“版本号相同但值不同”。这种情况 ABD 本身无法处理需要业务层引入唯一标识符、时间戳或者 CASCompare-And-Swap机制来解决。实际生产系统中通常会限制同一时刻只有一个写者或者引入租约机制。更准确的表述是ABD 保证“最终能读到最新写入”但它不保证“每次写操作都严格串行化”。如果业务需要严格的并发写顺序需要叠加其他机制。5.3 时钟和网络延迟的影响ABD 不依赖物理时钟但它依赖版本号的单调递增。如果某个副本重启后版本号没有持久化可能重新从 0 开始此时如果其余副本已经收到了更高版本号这个重启副本会拒绝低版本号的写入因为它的 write 方法要求 version current_version。这不会破坏一致性但可能导致已重启副本一直无法同步数据需要手工修复或者启动时从其他节点拉取快照。网络延迟会导致 Phase 1 等待时间变长。如果客户端只等待固定超时时间超时后收不到多数派响应就无法继续。不同于 RaftABD 没有 Leader 选举机制不需要处理投票超时但每次读写都需要客户端等待多数派响应所以延迟敏感型业务需要仔细调优超时参数。5.4 与 Raft / Paxos 适用场景对比维度ABDRaft / Paxos是否有 Leader无有解决的问题共享寄存器读写日志复制和全序广播版本机制客户端生成版本号Leader 生成日志索引写冲突处理版本号覆盖日志条目幂等适用场景配置存储、元数据存储、分布式锁数据库主从复制、共识日志、状态机复制复杂度较低较高从表格可以看出ABD 更适合那些不需要严格顺序、只需要“读写一致”的场景。例如服务发现中的服务列表存储、分布式缓存中的配置版本管理都可以用 ABD 类的算法实现。6. 常见问题与排查思路下面整理了理论学习中最常遇到的几种问题以及对应的解决思路。问题现象可能原因解决思路读操作返回旧值读写 Quorum 没有交集客户端没有执行写回阶段检查 quorum 大小配置在读阶段增加写回步骤写操作不断失败部分副本宕机网络超时导致拿不到多数派响应排查节点存活状态延长超时时间确认故障节点数小于一半两个并发写互相覆盖没有处理相同版本号冲突引入客户端唯一 ID使用 CAS 机制限制并发写者重启后的副本一直拒绝新写入版本号没有持久化持久化版本号启动时同步最新快照延迟偏高Phase 1 和 Phase 2 都等待多数派响应减少副本数量使用更快的网络考虑读写分离配置6.1 为什么读后要写回如果不执行写回阶段可能出现一种情况客户端第一次读到最新值但第二次读请求访问的多数派节点集合和第一次不同导致第二次读到旧值。写回阶段确保最新值被尽可能多的副本接收从而减少这种概率。6.2 版本号相同时如何处理当两个写操作生成相同的版本号时副本无法判断哪个值更新。一种常见做法是给每个写操作附加一个唯一 timestamp 或 UUID副本在版本号相同时比较 timestamptimestamp 较大的值获胜。另一种做法是在应用层禁止并发写例如通过分布式锁串行化写请求。6.3 如何选择副本数量副本数量 N 决定了容错能力和成本。N 3 时可以容忍 1 个节点故障N 5 时可以容忍 2 个节点故障。需要注意的是quorum 大小是 N/2 1所以 N 越大读写需要等待的节点越多延迟越高。实际项目需要根据业务对可用性和延迟的要求来权衡。7. 最佳实践与工程建议7.1 明确使用场景不要滥用 ABDABD 适合“读多写少、单写者、弱顺序要求”的业务场景。如果业务依赖严格的事务语义、多行原子更新或者全排序的日志复制仍然应该选择 Raft 或者 Paxos。ABD 不是万能的替代品而是面对特定问题时的一种轻量方案。7.2 版本号持久化与恢复策略副本节点在写入版本号和值的同时应该将版本号持久化到本地存储比如 RocksDB、LevelDB 或普通文件。否则节点重启后可能重新从 0 开始导致无法识别更高版本的写入。恢复时可以采用两种策略启动时从其他节点拉取快照以最高版本号为准每次写操作前先读取本地持久化版本再决定是否接受7.3 超时与重试机制客户端在 Phase 1 和 Phase 2 中都应该设置合理的超时时间超时后可以选择重试或者直接失败。重试需要注意幂等性如果第一次写入已经成功但响应丢失客户端重试时可能生成重复版本号这时应该在请求中携带全局唯一的操作 ID服务端做去重处理。7.4 安全边界与最小权限在实际生产系统中部署副本服务时需要在网络层限制只有可信客户端能够访问副本端口避免未授权节点直接读取或篡改数据。同时所有节点之间的通信建议启用 TLS 加密防止数据在传输过程中被窃取或篡改。在测试环境可以先使用明文通信生产环境务必开启认证和加密。此外副本节点上要配置日志审计记录谁在什么时候发起了什么写操作方便追踪数据异常变更。运维人员在执行节点下线、数据迁移等操作时应当先确认当前副本数量仍满足 quorum 要求再进行变更避免操作期间系统失去大多数副本而不可用。7.5 监控与告警需要监控的核心指标包括每个副本的版本号、读写延迟、读写失败率、节点宕机时间、quorum 是否满足。当节点故障数接近 N/2 时系统应该触发告警提醒运维人员及时恢复节点。版本号如果出现断崖式下跌说明可能存在数据被回滚或者恢复了旧快照是异常信号。7.6 从模拟到生产本文的 Python 模拟代码只展示了算法核心逻辑生产级实现还需要考虑用 RPC 框架替代函数调用引入持久化存储支持节点动态加入和退出实现节点故障检测设计客户端缓存和批量操作接口以 Go 语言为例可以使用 gRPC 作为通信框架每个副本节点实现两个 RPC 方法Read 和 Write。客户端通过服务发现获取节点列表然后执行 ABD 的两阶段流程。在存储层可以使用 BadgerDB 或 BoltDB 保存版本号和值保证重启后数据依然存在。8. 总结与延伸思考本文从 Quorum 复制的基础出发拆解了 ABD 算法的读写流程、版本号机制以及它和 Raft/Paxos 这类强共识算法的边界。通过可运行的 Python 模拟代码可以直观看到多数派机制如何保证数据的一致性和可用性。掌握 ABD 之后建议继续深入几个方向学习 Raft 的 Leader 选举和日志复制对比它和 ABD 在容错模型上的差异阅读原版论文《Sharing Memory Robustly in Message-Passing Systems》中对读写的形式化定义研究 Multi-Paxos 和 Vertical Paxos 等变体理解不同共识算法家族之间的演进关系分布式系统没有银弹每种一致性模型都在可用性、性能和实现复杂度之间做了取舍。理解 ABD就是理解 Quorum 复制这条技术路线的一个重要基石。 
长河君 · 2026/8/29 20:07:00 · 阅读 1.2k ABD共识算法实战：Quorum复制与近似一致性边界
分享一套从零理解 ABD 共识算法的实战笔记底层拆解 Quorum 复制机制与“几乎一致性”边界配合可运行的 Python 模拟代码帮助你彻底搞懂读写多数派、版本号推进和副本容错的核心逻辑。适合后端开发者、分布式系统学习者以及准备系统设计面试的同学。1. 背景与核心概念为什么需要 ABD 这类算法在很多后台项目里数据存储的可靠性不能只靠单机保证。一旦机器宕机磁盘损坏或者机房断网如果只有一份数据整个业务就会直接不可用。所以最常见的方案是把数据复制到多个节点上形成副本。副本能让系统在部分节点故障时继续对外服务这是分布式存储的基本思路。但是副本多了之后会带来一个麻烦多个节点上的数据可能不一样。比如节点 A 收到了写请求节点 B 因为网络抖动没有收到那么读请求打到 A 和 B 上就会得到不同结果。副本之间怎么保持一致这就是分布式共识要解决的问题。提到“共识”大部分开发者首先想到的是 Paxos 和 Raft。它们解决的是典型的日志复制共识问题多个节点对同一条日志条目的顺序和内容达成一致。这类算法有一个关键特征就是通常会选出一个 Leader领导者由 Leader 统一发起复制和提交。但 Paxos 和 Raft 不是唯一的选择。在一些场景下我们不需要那么“重”的共识只需要保证读写数据的正确性那么 ABD 算法就是一个很有意思的替代方案。ABD 名字来源于四位提出者Aspnes、Attiya、Censor-Hind 和 Pollack它在论文中提出的是一个基于 Quorum法定人数机制的读写算法用于在异步网络环境中实现共享寄存器shared register。和 Raft 最大区别在于ABD 不需要 Leader完全依靠读写双方各自收集大多数节点的响应来推进版本号从而保证写入不会丢、读取不会读到过期值。它的容错边界是少于一半的节点故障这一点和 Raft 类似但它的实现更简单解决的问题也更精确——它做的不是“日志共识”而是“读写寄存器共识”。通俗地理解ABD 就是一种让多个副本在没有主节点的情况下通过“读写都访问多数派节点”的规则保证每次读到的都是最近写入的值。这种机制不会让所有节点严格按相同顺序执行指令但它的结果足够接近一致所以常被称为“Almost Consensus”。这里的“Almost”不是贬义而是描述它与强共识之间的边界它放弃了全序total order换来了更好的可扩展性和更低的协调开销。本文围绕“Almost consensus: ABD and the edges of quorum replication”这个主题从 Quorum 复制的基本原理出发拆解 ABD 算法的读写流程、版本号机制、容错边界并用一个可运行的模拟代码演示整个过程最后总结它的适用场景和工程陷阱。2. 环境准备与版本说明ABD 算法属于分布式系统理论不同语言的实现差异比较大没有统一的官方 SDK。为了更直观地理解算法执行流程本文使用 Python 编写一个简化的模拟程序。模拟程序不依赖任何第三方库只需要一个能运行 Python 3 的环境即可。操作系统Windows 10/11、macOS、Linux 均可语言版本Python 3.8 及以上第三方库无运行方式命令行直接运行这个模拟程序的重点不是生产级实现而是把 ABD 的 Phase 1 和 Phase 2 两个阶段拆开演明细节方便读者把论文里的伪代码映射到可执行逻辑上。生产环境如果要真正落地建议使用 Go、Java 或 Rust 重写并引入真实的 RPC 通信层、持久化日志和时钟校验。3. ABD 与 Quorum Replication 核心原理拆解3.1 Quorum 复制的核心思想Quorum 的中文含义是“法定人数”它不要求所有副本都完成操作只要求每次操作都能获得足够多的副本响应。这个“足够多”通常指超过一半即 N 个副本中至少有 N/2 1 个节点响应。当系统同时出现两个操作的时候比如两个写操作并发执行由于每个写操作都需要联系多数派节点而两个多数派之间必然至少有一个公共节点。这个公共节点可以通过版本号判断哪个写操作先发生进而拒绝旧写入或者覆盖新写入。这就是 Quorum 能保证一致性的数学基础。假设有 5 个副本节点编号 0 到 4写操作 W1 联系了节点 0、1、2写操作 W2 联系了节点 2、3、4W1 和 W2 的 Quorum 在节点 2 上相遇。如果 W1 先在节点 2 上写入版本 1W2 在节点 2 上发现版本号比自己小就说明有更新版本存在它可以放弃或执行冲突处理。同理读操作只需要访问多数派节点就能保证至少读到一个包含最新版本号的节点从而避免读到过期数据。这一原理被广泛用在 ZooKeeper、ETCD 的存储层设计中也是理解 ABD 的前提。3.2 ABD 算法的读流程ABD 的读操作分两个阶段Phase 1读阶段客户端向所有副本发送读请求每个副本返回自己的当前值和版本号。客户端等待多数派响应从这些响应中选出版本号最大的值。Phase 2写回阶段如果最大版本号比客户端本地已知版本号新或者客户端想保证以后读到的数据一致则向所有副本发起写回把最大版本号对应的值重新写入多数派节点。写回阶段不是为了修改数据而是为了修复那些滞后的副本确保后续读操作无论访问哪些多数派节点都能看到最新值。这里有一个关键点客户端在 Phase 1 拿到最新值后如果直接把值返回给用户理论上也能工作因为多数派交叉能保证读到最新值。但如果没有 Phase 2可能出现一种情况某个旧副本恰好处于另一个多数派中导致下一次读操作又读到旧值。写回阶段就是为了把新值传播到足够多的节点压缩这种风险。3.3 ABD 算法的写流程写操作的流程也是两阶段Phase 1读版本号阶段客户端向所有副本发送写请求请求中携带新值但暂时不写。每个副本返回自己的当前版本号。客户端等待多数派响应选取最大版本号 maxVersion然后新版本号设置为 maxVersion 1。Phase 2写阶段客户端携带新版本号和新值向所有副本发起写入。副本收到写请求后如果请求中的版本号大于等于自己当前版本号就执行写入并返回成功否则返回自己的版本号。客户端等待多数派写入成功就认为本次写操作完成。这种设计确保了两个并发写操作在多数派交叉节点上通过版本号实现顺序化。后到达的写请求会看到前一个写请求已经写入的版本号然后基于该版本号继续递增不会互相覆盖。3.4 为什么叫 Almost ConsensusABD 算法并没有让所有副本在同一时刻拥有完全一致的视图。某个副本可能因为网络分区暂时落后但它不是多数派的一部分所以不影响读写的正确性。系统整体上保证了“每次读都能读到最近完成的写”这个性质接近线性一致性但不是强共识意义上的全序。Raft 中所有节点通过 Leader 协商将所有写操作排列成一个严格的全序日志每个节点按相同顺序应用日志。ABD 则只关注“最新值是什么”不关注“所有写操作按什么顺序发生”。它允许不同节点对并发写的顺序有不同理解只要新值最终被多数派接收即可。所以 ABD 提供的是一种“近似共识”边界它保证读写操作的正确性但放弃对操作全局排序的要求。这给系统带来了更低的协调成本和更好的并发性代价是业务方不能依赖副本间的顺序关系。4. 使用 Python 模拟 ABD 读写流程纸上谈兵不够下面用一个可运行的 Python 程序模拟 ABD 的核心逻辑。这个模拟不会真实启动多线程和网络通信而是用一个列表存储多个副本通过函数调用模拟网络消息的收发重点展示算法步骤。4.1 定义副本节点class Replica: def __init__(self, node_id): self.node_id node_id self.value None self.version 0 def read(self): return self.version, self.value def write(self, version, value): # 只有新版本号大于等于当前版本号才写入 if version self.version: self.version version self.value value return True return False def __repr__(self): return fNode({self.node_id}, v{self.version}, val{self.value})每个副本保存一个版本号和值。read 方法返回当前版本和值write 方法根据版本号判断是否写入。这里体现的就是最新写覆盖旧写的规则。4.2 定义 ABD 客户端客户端负责收集副本响应、判断多数派、生成新版本号。class ABDClient: def __init__(self, replicas): self.replicas replicas self.quorum len(replicas) // 2 1 def write(self, new_value): # Phase 1: 收集版本号 phase1_responses [] for replica in self.replicas: version, _ replica.read() phase1_responses.append((replica.node_id, version)) if len(phase1_responses) self.quorum: raise Exception(Not enough replicas for write phase 1) max_version max(v for _, v in phase1_responses) new_version max_version 1 # Phase 2: 写入多数派 ack_count 0 for replica in self.replicas: if replica.write(new_version, new_value): ack_count 1 if ack_count self.quorum: raise Exception(Not enough acks for write phase 2) print(fWrite success: value{new_value}, version{new_version}) return new_version def read(self): # Phase 1: 收集所有副本数据 responses [] for replica in self.replicas: version, value replica.read() responses.append((replica.node_id, version, value)) if len(responses) self.quorum: raise Exception(Not enough replicas for read phase 1) # 选择最大版本号 max_version max(v for _, v, _ in responses) latest [(node_id, val) for node_id, v, val in responses if v max_version] latest_value latest[0][1] # Phase 2: 写回保证后续读能读到新值 write_back_count 0 for replica in self.replicas: if replica.write(max_version, latest_value): write_back_count 1 if write_back_count self.quorum: raise Exception(Not enough replicas for read phase 2) print(fRead success: value{latest_value}, version{max_version}) return latest_valuewrite 方法第一阶段遍历所有副本读取版本号第二阶段基于最大版本号加 1 写入多数派。read 方法读取所有副本数据选取最大版本号然后执行写回操作。4.3 完整模拟演示下面模拟三个副本节点依次进行写入、读取、崩溃恢复等操作。def main(): replicas [Replica(0), Replica(1), Replica(2)] client ABDClient(replicas) print( Initial State ) print(replicas) print(\n Write: value hello ) client.write(hello) print(replicas) print(\n Write: value world ) client.write(world) print(replicas) print(\n Read ) val client.read() print(fClient got value: {val}) print(\n Simulate one replica down ) # 模拟节点 1 宕机拒绝响应 temp replicas[1] replicas[1] None try: client.read() except Exception as e: print(fRead failed: {e}) finally: replicas[1] temp print(\n Simulate node 1 restart with stale data ) replicas[1] Replica(1) print(Before recover:, replicas) client.read() print(After recover:, replicas) if __name__ __main__: main()运行这段程序输出大致如下 Initial State [Node(0, v0, valNone), Node(1, v0, valNone), Node(2, v0, valNone)] Write: value hello Write success: valuehello, version1 [Node(0, v1, valhello), Node(1, v1, valhello), Node(2, v1, valhello)] Write: value world Write success: valueworld, version2 [Node(0, v2, valworld), Node(1, v2, valworld), Node(2, v2, valworld)] Read Read success: valueworld, version2 Client got value: world从这个输出可以清楚看到每次写操作都会把版本号加 1并且所有副本都成功写入。读操作会返回当前最高版本号对应的值。4.4 模拟少数派故障下的写入和读取ABD 的容错能力体现在“多数派存活即可工作”。下面模拟 3 个副本中 1 个宕机仍然可以完成读写。def test_quorum_with_failure(): replicas [Replica(0), Replica(1), Replica(2)] # 先正常写入 client ABDClient(replicas) client.write(data1) # 节点 1 宕机 print(\n Node 1 down ) replicas[1] None # 仍然能写 client.write(data2) print([r for r in replicas if r is not None]) # 仍然能读 val client.read() print(Read value:, val) test_quorum_with_failure()在这个测试中由于多数派节点仍然存在写操作 Phase 2 只需要两个 ack 就能完成。这个特性保证了 ABD 在少于一半节点故障时依然可用而不是像单主复制那样完全依赖主节点的可用性。5. ABD 的边界与 Quorum 复制的局限性5.1 读写 Quorum 必须相交ABD 大多数实现中都要求写 Quorum 和读 Quorum 有交集。也就是说每次写操作至少接触 N/2 1 个节点每次读操作也至少接触 N/2 1 个节点这样才能保证读 Quorum 里至少有一个节点包含最新写入的数据。如果系统为了降低延迟把写 Quorum 设置为 1只写主副本读 Quorum 也设置为 1只读某个固定副本那么读写 Quorum 可能没有交集读请求可能一直打到没有最新数据的副副本上从而读到过期数据。这种配置在弱一致性场景下可以接受但不适合 ABD。5.2 并发写无法保证全排序ABD 的版本号只能区分“新”和“旧”不能区分并发写发生的先后顺序。如果两个客户端同时发起写操作在 Phase 1 阶段它们可能都读取到同样的 maxVersion然后同时生成相同的新版本号 maxVersion 1。这在多数派交叉节点上会表现为“版本号相同但值不同”。这种情况 ABD 本身无法处理需要业务层引入唯一标识符、时间戳或者 CASCompare-And-Swap机制来解决。实际生产系统中通常会限制同一时刻只有一个写者或者引入租约机制。更准确的表述是ABD 保证“最终能读到最新写入”但它不保证“每次写操作都严格串行化”。如果业务需要严格的并发写顺序需要叠加其他机制。5.3 时钟和网络延迟的影响ABD 不依赖物理时钟但它依赖版本号的单调递增。如果某个副本重启后版本号没有持久化可能重新从 0 开始此时如果其余副本已经收到了更高版本号这个重启副本会拒绝低版本号的写入因为它的 write 方法要求 version current_version。这不会破坏一致性但可能导致已重启副本一直无法同步数据需要手工修复或者启动时从其他节点拉取快照。网络延迟会导致 Phase 1 等待时间变长。如果客户端只等待固定超时时间超时后收不到多数派响应就无法继续。不同于 RaftABD 没有 Leader 选举机制不需要处理投票超时但每次读写都需要客户端等待多数派响应所以延迟敏感型业务需要仔细调优超时参数。5.4 与 Raft / Paxos 适用场景对比维度ABDRaft / Paxos是否有 Leader无有解决的问题共享寄存器读写日志复制和全序广播版本机制客户端生成版本号Leader 生成日志索引写冲突处理版本号覆盖日志条目幂等适用场景配置存储、元数据存储、分布式锁数据库主从复制、共识日志、状态机复制复杂度较低较高从表格可以看出ABD 更适合那些不需要严格顺序、只需要“读写一致”的场景。例如服务发现中的服务列表存储、分布式缓存中的配置版本管理都可以用 ABD 类的算法实现。6. 常见问题与排查思路下面整理了理论学习中最常遇到的几种问题以及对应的解决思路。问题现象可能原因解决思路读操作返回旧值读写 Quorum 没有交集客户端没有执行写回阶段检查 quorum 大小配置在读阶段增加写回步骤写操作不断失败部分副本宕机网络超时导致拿不到多数派响应排查节点存活状态延长超时时间确认故障节点数小于一半两个并发写互相覆盖没有处理相同版本号冲突引入客户端唯一 ID使用 CAS 机制限制并发写者重启后的副本一直拒绝新写入版本号没有持久化持久化版本号启动时同步最新快照延迟偏高Phase 1 和 Phase 2 都等待多数派响应减少副本数量使用更快的网络考虑读写分离配置6.1 为什么读后要写回如果不执行写回阶段可能出现一种情况客户端第一次读到最新值但第二次读请求访问的多数派节点集合和第一次不同导致第二次读到旧值。写回阶段确保最新值被尽可能多的副本接收从而减少这种概率。6.2 版本号相同时如何处理当两个写操作生成相同的版本号时副本无法判断哪个值更新。一种常见做法是给每个写操作附加一个唯一 timestamp 或 UUID副本在版本号相同时比较 timestamptimestamp 较大的值获胜。另一种做法是在应用层禁止并发写例如通过分布式锁串行化写请求。6.3 如何选择副本数量副本数量 N 决定了容错能力和成本。N 3 时可以容忍 1 个节点故障N 5 时可以容忍 2 个节点故障。需要注意的是quorum 大小是 N/2 1所以 N 越大读写需要等待的节点越多延迟越高。实际项目需要根据业务对可用性和延迟的要求来权衡。7. 最佳实践与工程建议7.1 明确使用场景不要滥用 ABDABD 适合“读多写少、单写者、弱顺序要求”的业务场景。如果业务依赖严格的事务语义、多行原子更新或者全排序的日志复制仍然应该选择 Raft 或者 Paxos。ABD 不是万能的替代品而是面对特定问题时的一种轻量方案。7.2 版本号持久化与恢复策略副本节点在写入版本号和值的同时应该将版本号持久化到本地存储比如 RocksDB、LevelDB 或普通文件。否则节点重启后可能重新从 0 开始导致无法识别更高版本的写入。恢复时可以采用两种策略启动时从其他节点拉取快照以最高版本号为准每次写操作前先读取本地持久化版本再决定是否接受7.3 超时与重试机制客户端在 Phase 1 和 Phase 2 中都应该设置合理的超时时间超时后可以选择重试或者直接失败。重试需要注意幂等性如果第一次写入已经成功但响应丢失客户端重试时可能生成重复版本号这时应该在请求中携带全局唯一的操作 ID服务端做去重处理。7.4 安全边界与最小权限在实际生产系统中部署副本服务时需要在网络层限制只有可信客户端能够访问副本端口避免未授权节点直接读取或篡改数据。同时所有节点之间的通信建议启用 TLS 加密防止数据在传输过程中被窃取或篡改。在测试环境可以先使用明文通信生产环境务必开启认证和加密。此外副本节点上要配置日志审计记录谁在什么时候发起了什么写操作方便追踪数据异常变更。运维人员在执行节点下线、数据迁移等操作时应当先确认当前副本数量仍满足 quorum 要求再进行变更避免操作期间系统失去大多数副本而不可用。7.5 监控与告警需要监控的核心指标包括每个副本的版本号、读写延迟、读写失败率、节点宕机时间、quorum 是否满足。当节点故障数接近 N/2 时系统应该触发告警提醒运维人员及时恢复节点。版本号如果出现断崖式下跌说明可能存在数据被回滚或者恢复了旧快照是异常信号。7.6 从模拟到生产本文的 Python 模拟代码只展示了算法核心逻辑生产级实现还需要考虑用 RPC 框架替代函数调用引入持久化存储支持节点动态加入和退出实现节点故障检测设计客户端缓存和批量操作接口以 Go 语言为例可以使用 gRPC 作为通信框架每个副本节点实现两个 RPC 方法Read 和 Write。客户端通过服务发现获取节点列表然后执行 ABD 的两阶段流程。在存储层可以使用 BadgerDB 或 BoltDB 保存版本号和值保证重启后数据依然存在。8. 总结与延伸思考本文从 Quorum 复制的基础出发拆解了 ABD 算法的读写流程、版本号机制以及它和 Raft/Paxos 这类强共识算法的边界。通过可运行的 Python 模拟代码可以直观看到多数派机制如何保证数据的一致性和可用性。掌握 ABD 之后建议继续深入几个方向学习 Raft 的 Leader 选举和日志复制对比它和 ABD 在容错模型上的差异阅读原版论文《Sharing Memory Robustly in Message-Passing Systems》中对读写的形式化定义研究 Multi-Paxos 和 Vertical Paxos 等变体理解不同共识算法家族之间的演进关系分布式系统没有银弹每种一致性模型都在可用性、性能和实现复杂度之间做了取舍。理解 ABD就是理解 Quorum 复制这条技术路线的一个重要基石。