一致性协议（Paxos, Raft）

🤝 几个人做出”同一个决定”

几个同学要决定晚上去哪吃饭。每个人有自己的想法——但最终所有人必须达成同一个决定。

• 如果大家坐在一起讨论——直接投票就行
• 但是：如果有人在线上（网络可能断）、有人可能迟到（节点可能挂）、消息可能延迟——怎么”达成共识”？

共识（Consensus） 就是：在分布式系统中，让所有正常运行的节点对同一个值达成一致——即使有节点故障或网络问题。

---

🏛️ Raft——通过选举领导者达成共识

Raft 把共识问题分解为三个独立的子问题：

1️⃣ 领导者选举（Leader Election）：选出一个节点当"班长"
2️⃣ 日志复制（Log Replication）：班长把决定通知所有人
3️⃣ 安全性（Safety）：如果有足够多人确认了——就是最终决定

三个角色

角色	状态	职责
领导者（Leader）	正常时只有一个	处理请求，管理日志复制
跟随者（Follower）	大多数节点	被动接受领导者的指令
候选者（Candidate）	选举中	发起新的领导者选举

Raft 工作流程

正常状态（有领导者）：
客户端 ──请求──→ 领导者 ──复制日志──→ 所有跟随者
                    ←──确认收到────
                多数确认 → 日志提交 → 通知客户端

领导者挂了：
跟随者1(等超时) → 变成候选者 → 发起选举投票
              → 获得多数票 → 成为新领导者
              → 开始处理新请求

关键规则：一个 term（任期）内最多只能有一个领导者
         → 保证不会出现"两个人都以为自己是班长"

# Raft 的简化版——判断"什么时候日志算提交了？"
# 如果领导者把日志复制到了多数节点（N/2 + 1）
# → 日志已提交 → 不会丢失

🏪 **类比：班长决定”

Raft = 全班选班长。班长做决定，通知全班。如果班长联系不上了——重新选一个新的。

关键保证：一个”任期”内只有一个班长——不会出现”两个班长同时发命令”的混乱。

只要大多数同学都收到了班长的通知——这个决定就”生效”了（已提交）。即使有少数同学没收到——等他们恢复后，新班长会补发。

---

📜 Paxos——理论上的”始组”

Paxos 比 Raft 更早（1990 年由 Leslie Lamport 提出），也更难理解。Raft 可以理解为”Paxos 的简化版”。

Paxos 核心矛盾：不用选举领导者也能达成共识
→ 更复杂（Lamport 的原始论文以"一个议员的故事"形式写——没人看得懂）
→ 更难实现

Raft 的贡献：用"强领导者"简化了共识
→ 更易理解 → 更容易正确实现
→ 成为 etcd、Consul 等主流工具的基础

---

🏢 实际应用

工具	使用的共识协议	用途
etcd	Raft	Kubernetes 的核心——存储集群配置
Consul	Raft	服务发现、配置管理
ZooKeeper	Zab（类 Raft）	Hadoop 生态的协调服务
TiDB	Raft	分布式数据库——Raft 保证数据一致性

---

📝 小结

概念	一句话
共识（Consensus）	所有正常节点对同一个值达成一致
Raft	通过选举领导者来简化共识过程
多数确认	日志复制到多数节点(N/2+1)后即为已提交
领导者选举	领导者挂了 → 跟随者超时 → 发起新选举
Paxos	共识协议的理论基础——比 Raft 更难理解和实现

为什么先学这个？ 共识是可靠性的基础。有了共识，才能构建分布式存储（GFS, HDFS）和分布式计算（MapReduce）。