Raft协议工作原理是什么？

### **Raft 协议详细解析** **Raft（Replicated and Fault-Tolerant）** 是一种 **分布式一致性协议**，主要用于**解决分布式系统中的一致性问题**，是 **Paxos** 的替代方案，但更易理解和实现。 ## **1. Raft 解决了什么问题？** 在分布式系统中，多个节点需要保持相同的数据状态，即 **数据复制一致性**。但由于 **网络延迟、消息丢失、节点宕机**，一致性变得复杂。 Raft **保证了以下几点**： - **强一致性（Linearizability）**：所有节点数据严格有序，所有客户端读写结果一致。 - **高可用性**：即使部分节点崩溃，仍能继续提供服务。 - **故障恢复**：当 Leader 宕机时，能迅速选出新 Leader 并继续运行。 ✅ 适用于 **分布式存储、数据库、日志复制系统**，如 **Etcd、Consul、TiDB、CockroachDB** 等。 ## **2. Raft 角色** Raft 集群中的节点有三种角色： 1. **Leader（领导者）** - 处理客户端请求，负责 **日志复制** 和 **数据提交**。 - **周期性发送心跳** 维持自己是 Leader。 - **如果 Leader 宕机，Follower 会重新选举新 Leader**。 2. **Follower（跟随者）** - **只接受 Leader 的指令**，不主动处理请求。 - 负责**存储日志并响应 Leader** 。 - **如果 Leader 失联，会触发选举**。 3. **Candidate（候选者）** - 当 Follower **超时未收到 Leader 的心跳**，会成为 Candidate，发起 **选举** 。 - **如果获得大多数选票，成为 Leader**。  🔄 **状态转换** - `Follower` **超时未收到 Leader 心跳** → 变成 `Candidate` **开始选举**。 - `Candidate` **赢得选举** → 成为 `Leader` **开始管理日志**。 - `Leader` **宕机或网络异常** → `Follower` 超时后重新选举。 ## **3. Raft 核心流程** Raft **由三大核心流程** 组成： 1. **Leader 选举** 2. **日志复制** 3. **日志提交 & 故障恢复** ### **3.1 Leader 选举** 当 `Follower` 在 `election timeout` 时间内（150ms~300ms）**未收到 Leader 的心跳**，会触发选举： 1. **Follower 变成 Candidate，递增 `term` 并发送投票请求 (`RequestVote`) 给所有节点**。 2. **其他节点收到投票请求**： - 如果 `term` **比自己大**，同意投票。 - 如果 `term` **比自己小**，拒绝投票（可能已经有 Leader）。 - 如果已经投过票，拒绝再次投票。 3. **Candidate 获得大多数（超过 `N/2`）投票，则成为 Leader**。 4. **Leader 开始发送心跳**（`AppendEntries`），通知集群**自己是新的 Leader**。 ✅ **选举条件** - **大多数节点同意**（即 `N/2+1`）。 - **日志最新**（优先投票给 `log index` 最大的节点）。 - **如果选举超时**（未选出 Leader），重新发起选举。 🔴 **注意** - Raft 采用 **随机超时时间（150ms~300ms）**，避免两个 Candidate 同时竞争导致**选举冲突**。 ### **3.2 日志复制** 选举完成后，Leader 开始处理**客户端请求**，并将请求**复制到所有 Follower**。 1. **客户端发送请求给 Leader**（如写入 `key=value`）。 2. **Leader 生成日志条目**（`log index` + `term`），然后**并行发送 `AppendEntries` 给所有 Follower**。 3. **Follower 追加日志并返回 ACK**。 4. **超过半数节点写入成功，Leader 发送 `commit` 指令**，表示日志已提交。 ✅ **日志复制保证** - **顺序一致**：日志条目按照 `log index` 顺序执行。 - **多数派提交（Quorum）**：即使部分 Follower 宕机，仍能保证数据完整。 - **Follower 崩溃恢复时，Leader 会自动补充缺失日志**。 ### **3.3 日志提交 & 故障恢复** **日志只有在 Leader 提交后才能对外生效！** 1. Leader **等待多数派（Quorum）Follower 确认日志**。 2. 一旦**超过 `N/2+1` 服务器存储成功**，Leader **提交日志**。 3. Leader 通过 `AppendEntries` **通知所有 Follower 提交日志**。 4. **Follower 也提交日志**，最终所有节点数据一致。 ✅ **保证** - **所有日志都按相同顺序提交**（线性一致性）。 - **如果 Leader 崩溃，新的 Leader 继续提交未完成的日志**。 ## **4. Raft 如何保证一致性？** ### **4.1 Raft 采用强一致性（Linearizability）** - 所有写入操作都要 **Leader 先确认**，再复制到 Follower。 - 只有当**过半节点确认后**，Leader 才能提交数据。 - **防止脑裂**：Follower **只接受当前 Leader** 的日志，不接受旧 Leader。 ### **4.2 Raft 选举时保证日志不会回退** - **只有最新日志的 Candidate 才能成为 Leader**，避免 Leader 回滚旧数据。 ### **4.3 日志同步防止丢失** - **Follower 崩溃恢复时，Leader 会同步最新日志，确保一致性**。 ## **5. Raft vs Paxos** | **特性** | **Raft** | **Paxos** | |------|------|------| | **易实现** | ✅ 简单，状态机明确 | ❌ 复杂，难以理解 | | **Leader 选举** | ✅ 明确 Leader，写操作稳定 | ❌ 没有固定 Leader，效率低 | | **日志存储** | ✅ 线性日志 | ❌ 复杂多轮确认 | | **故障恢复** | ✅ 直接同步 Leader 数据 | ❌ 依赖多个阶段 | | **应用场景** | ✅ Etcd、TiDB、Consul | ❌ Google Chubby | **结论**： - **Raft 更易理解、实现，适用于数据库、KV 存储**（如 **Etcd、TiDB**）。 - **Paxos 适用于分布式锁、共识协议**，但实现复杂（如 **Chubby**）。 ## **6. 总结** ### **Raft 核心点** 1. **三种角色**：Leader 负责处理请求，Follower 只同步日志，Candidate 参与选举。 2. **Leader 选举**：基于**超时 + 随机投票**，防止选举冲突。 3. **日志复制**：Leader 提交后，Follower 同步，**确保数据一致**。 4. **日志提交**：只有当多数派确认后，日志才对外可见。 5. **崩溃恢复**：新 Leader **同步未提交日志**，防止数据丢失。 💡 **一句话总结：** Raft 通过 **Leader 选举 + 多数派确认 + 顺序日志复制**，保证了**高可用、强一致**的分布式系统。