分布式共识算法：Raft 为什么比 Paxos 更好懂

分布式系统的核心难题：多个节点如何对一个值达成一致？Raft 是目前最流行的共识算法。

Raft 的三个角色

┌──────────────────────────────────────┐
│  Leader   ← 处理所有客户端请求       │
│  Follower ← 被动响应 Leader          │
│  Candidate ← 选举中的临时状态        │
└──────────────────────────────────────┘

Leader 选举

1. Follower 在 election timeout（150-300ms 随机）内没收到心跳 → 变成 Candidate
2. Candidate 给自己投一票，向所有节点发送 RequestVote
3. 获得多数票 → 成为 Leader，开始发送心跳
4. 票数相同 → 重新选举（随机超时避免死循环）

日志复制

Client → Leader: SET x = 1
Leader → Followers: AppendEntries(x=1, term=3, prevLogIndex=4)
Followers → Leader: ACK
Leader → Client: OK (多数确认后)

关键：Leader 只提交当前 term 的日志。这保证了安全性。

Raft vs Paxos

实际应用

• etcd：K8s 的后端存储，使用 Raft
• TiKV：TiDB 的存储层
• Consul：HashiCorp 的服务发现

Raft 的成功在于：用「可理解性」换来了「可实现性」。

参考来源：

• Diego Ongaro — Raft Consensus Algorithm (2014)