Raft协议
Raft 协议是一种分布式系统中的一致性算法，核心目标是让多个节点在存在故障（如节点崩溃、网络分区）的情况下，依然能协同工作并维护一份一致的数据副本，常用于分布式数据库、分布式存储等场景（如 Etcd、Consul 均基于 Raft 实现）。
Raft 协议的核心设计：角色与任期
Raft 通过 “角色划分” 和 “任期机制” 简化一致性逻辑，避免了复杂的状态转换，这也是它比传统 Paxos 算法更易理解和实现的关键。
1. 三种核心角色
每个节点在任意时刻只能扮演一种角色，角色会根据集群状态动态切换：
- Leader（领导者）：集群中唯一的 “决策者”，负责接收客户端请求、向 Followers 同步数据、发起投票等。
- Follower（追随者）：被动接收 Leader 的数据同步和指令，不主动发起请求；当 Leader 失联时，可能转为 Candidate。
- Candidate（候选者）：当 Follower 长时间未收到 Leader 的心跳时，会转为 Candidate 并发起 “选举”，争取成为新 Leader。
2. 任期（Term）
Raft 将时间划分为连续的 “任期”（用整数编号，如 Term 1、Term 2），每个任期对应一次 Leader 选举：
- 任期开始时，若原 Leader 失联，集群会发起选举，产生新 Leader（若选举成功，该 Leader 会主导整个任期）。
- 若选举失败（如多个 Candidate 同时竞争，无节点获得多数票），则进入下一个任期，重新选举。
- 任期机制能有效解决 “脑裂”（多个 Leader 并存）问题：新任期的 Leader 会覆盖旧任期 Leader 的数据。
Raft 协议的三大核心流程
Raft 一致性通过 “Leader 选举”“日志复制”“安全性保证” 三个核心流程实现，确保集群数据一致。
1. Leader 选举：从无 Leader 到产生 Leader
当 Follower 超过一定时间（“选举超时时间”，通常 150-300ms）未收到 Leader 心跳时，触发选举：
- Follower 转为 Candidate：该节点自增任期号（如从 Term 2 到 Term 3），给自己投 1 票，并向集群所有其他节点发送 “投票请求（RequestVote）”。
- 其他节点投票：节点收到请求后，若未在当前任期投过票，且请求节点的日志 “至少和自己一样新”（日志完整性保证），则投赞成票。
- 选举结果判定：
- 若 Candidate 收到多数节点（超过集群节点数的 1/2，如 3 节点需 2 票，5 节点需 3 票）的赞成票，则成为新 Leader。
- 新 Leader 立即向所有节点发送 “心跳（AppendEntries）”，宣告自己的 Leader 身份，防止其他节点发起新选举。
- 若多个 Candidate 同时发起请求，导致无节点获多数票，则所有节点等待随机的 “选举超时时间” 后重试，避免再次冲突。
2. 日志复制：Leader 确保数据一致
Leader 产生后，所有客户端请求（如写数据）都会先发送给 Leader，再由 Leader 同步到所有 Follower，流程如下：
- Leader 接收请求：客户端发送写请求，Leader 将请求内容封装为 “日志条目”，加入自己的日志（此时日志为 “未提交” 状态）。
- 同步日志到 Follower：Leader 向所有 Follower 发送 “AppendEntries 请求”，携带日志条目和当前任期号，要求 Follower 追加日志。
- Follower 确认与 Leader 提交：
- Follower 收到请求后，若日志完整性符合要求（如前序日志已提交），则追加日志并向 Leader 回复 “成功”。
- 当 Leader 收到多数 Follower 对该日志条目的 “成功” 回复后，将该日志标记为 “已提交”，并执行请求（如修改本地数据）。
- Leader 在下一次心跳中，告知所有 Follower 该日志已提交，Follower 收到后执行日志并回复客户端。
- 容错性：若部分 Follower 因故障未收到日志，Leader 会在 Follower 恢复后，重新发送未同步的日志，确保最终所有节点日志一致。
3. 安全性保证：避免数据不一致
Raft 通过以下规则确保 “无论发生何种故障，集群数据始终一致”：
- 选举时日志优先：Candidate 必须拥有 “至少和其他节点一样新” 的日志，才能被投票（避免日志落后的节点成为 Leader，导致旧数据覆盖新数据）。
- Leader 只追加日志：Leader 不会修改或删除已有的日志条目，只会追加新日志（防止 Leader 篡改历史数据）。
- Follower 日志冲突处理：若 Follower 的日志与 Leader 不一致，Leader 会找到两者的 “日志分歧点”，要求 Follower 删除分歧点后的所有日志，再重新同步 Leader 的日志。
Raft 协议的核心优势
- 易理解：通过角色、任期划分，将复杂的一致性问题拆分为 “选举、日志复制、安全性” 三个独立流程，比 Paxos 更易学习和实现。
- 强容错：能容忍集群中 (N-1)/2 个节点故障（如 3 节点集群可容忍 1 个故障，5 节点可容忍 2 个故障），且故障节点恢复后能自动同步数据。
- 适用场景广：支持 “读多写少” 或 “写多” 场景，可通过 “只读 Leader”“租约机制” 优化读性能，常用于分布式配置中心、分布式锁、分布式数据库等。
总结
Raft 协议的本质是 “通过 Leader 主导、多数节点确认” 的机制，在分布式环境中实现数据一致性。它通过角色划分简化流程，用任期避免脑裂，靠日志复制和安全性规则确保数据不丢失、不冲突，是目前工业界最主流的分布式一致性算法之一。