---
title: 共识在实际系统中的实践
url: https://doc.liz6.com/distributed-systems/02-consensus-protocols/03-consensus-in-practice
locale: zh
area: distributed-systems
tags:
- distributed-systems
- 共识协议
date: 2026-06-30
modified: 2026-07-11
description: etcd、Consul、ZooKeeper——三个实际系统中同一个共识问题的三种工程解法。Raft+boltdb、Raft+Gossip、ZAB,共识协议是核心但不是全部:线性一致性读、租约、watch 机制和成员管理各有一套工程取舍。
---
# 共识在实际系统中的实践
> etcd、Consul、ZooKeeper——三个实际系统中同一个共识问题的三种工程解法。Raft+boltdb、Raft+Gossip、ZAB,共识协议是核心但不是全部:线性一致性读、租约、watch 机制和成员管理各有一套工程取舍。
## etcd
etcd 是最广泛使用的 Raft 实现（Go），Kubernetes 的核心依赖——所有 K8s 对象（Pods, Services, ConfigMaps）都存在 etcd 中。
### 架构
每个写请求 → Raft propose → commit → apply to boltdb → response。读请求有两种模式：
- **Serializable Read**: 从本地 boltdb 直接读（不经过 Raft）→ 可能返回旧数据（stale）
- **Linearizable Read** (默认): ReadIndex 机制——1) leader 记录当前 commitIndex; 2) 发心跳给多数 follower 确认自己仍是 leader; 3) 等状态机 apply 到 ≥ 该 commitIndex; 4) 读。这保证了读不会看到已被更替的 leader 的数据。
### Watch
etcd 支持 long-poll watch: client 指定 key prefix → server 返回 change events。Kubernetes 的 controller pattern (Informer) 基于 etcd watch 实现。
## Consul
Consul 用 Raft 做服务目录（service catalog）的一致性复制，用 Gossip (SWIM) 做成员发现和健康检查传播——分离了"需要一致性的数据"和"可以最终一致的数据"。
设计原则：服务注册（谁在提供什么服务）需要强一致 → Raft。成员存活检测（谁还活着）可用最终一致 → Gossip。
## ZooKeeper (ZAB 协议)
ZooKeeper 的 ZAB (ZooKeeper Atomic Broadcast) 协议比 Raft 早 8 年，设计目标不同：
- Raft: 所有 server 的 log **完全相同**
- ZAB: leader 的 log 是权威的，followers 可能 leader 多一些 entries（但可以被 overwrite）
ZAB 的"顺序保证"不是全局 linearizability order 像 Raft，而是 **FIFO client order**——client 的多个请求保持发送顺序，但不同 client 之间没有顺序保证。
### 为什么 ZooKeeper 还活着
ZooKeeper 的先发优势和 Java 生态导致大量遗留系统依赖它（Kafka 旧版本、Hadoop、HBase），但新系统越来越倾向 etcd（更简、Go-native、K8s 依赖）。
## 共识的应用场景
共识不是万能的——它解决的是"多个节点对单个值达成一致"：
```
该用共识: 不该用共识:
- Leader election - 大容量数据复制 (用 gossip)
- 分布式锁 - 非 leader-based 的复制
- 配置中心 - 健康检查
- 元数据管理 - 日志聚合
```
大多数系统不需要共识——它们需要的是最终一致性的复制（Gossip, async replication）或者单 master + WAL（大多数 SQL DB 的主从复制）。
## 参考
- **etcd**: github.com/etcd-io/etcd, raft.github.io
- **Consul**: consul.io/docs/architecture
- **ZooKeeper**: "ZooKeeper: Wait-free coordination for Internet-scale systems" (2010)
*Keywords: etcd, Raft, boltdb, Consul, Gossip, ZooKeeper, ZAB, linearizable read, ReadIndex*