一、什么是Raft协议
Raft协议是一种分布式共识算法，常应用于分布式集群中，保障系统的高可用，避免单节点故障导致服务中断
二、拆解Raft协议
对于Raft协议可以从以下3个部分进行拆解
1、 节点角色
集群中的每个节点会在不同状态间进行切换，主要包含三个角色：
领导者（leader）：
- 集群中唯一的写操作入口，由领导者同步给其他节点
- 负责向集群内其他节点发送心跳包，维持领导地位
跟随者（follower）：
- 集群中其他节点的默认角色，被动接收领导者的心跳和日志同步指令，不主动发起写操作
候选者（candidate）：
- 当跟随者在选举超时时间内未接收到领导者的心跳包，则会切换成候选者，触发选举流程，发起投票请求，争取成为领导者
注：协议本身并未规定固定的选举超时时间，只要求这个时间是随机化的（一般在某一区间内随机，且远大于心跳包的发送间隔）。随机化的设计是为了避免多个跟随者同时发起投票请求，导致选票分散，选举僵持。同时选举超时时间也支持自定义，需要注意的是，时间配置需要平衡“故障检测灵敏度”和“集群稳定性”，时间过短，容易因网络抖动导致频繁选举，影响集群稳定性，时间过长，容易导致领导者故障后，无法及时重新选举出新的leader，导致服务长时间故障
2、 共识同步
Raft的共识同步分为选举领导者和日志复制
选举领导者：
这是共识的前提，只有确定领导者，才能统一数据的写入和同步入口，避免多节点各自为政，出现脑裂
<触发条件>
- 跟随者在选举超时时间内未接收到领导者发送的心跳包，判定领导者可能故障
<选举流程>
- 跟随者将自己的任期号+1，随后角色切换为候选者
- 候选者向集群内所有其他节点发送投票请求，请求其他节点为自己投票
- 其他节点遵循“先到先得，任期号优先”原则投票，若候选者的任期号 ≥ 本地任期号，且未给其他候选者投过票，则投赞成票
- 若候选者在选举超时时间内获得多数节点（N/2 + 1）的赞成票，则成功当选为新的领导者
- 新领导者立即向所有其他节点发送心跳包，宣告领导者地位，其他节点切换为跟随者
注：集群节点数需为奇数，确保能快速选举出领导者，避免选举僵持
日志复制：
领导者产生后，所有写入变更操作都会通过日志复制实现集群一致
<日志结构>
Raft日志是有序的日志条目列表，每个条目包含3部分：
- 任期号：该条目创建时的任期号
- 指令：具体的写入变更操作
- 索引：条目的唯一序号，保证顺序
<同步流程>
- 接收请求：领导者接收写入变更操作请求
- 写入日志：领导者将请求封装为一条日志条目，先写入本地日志（此时未生效，处于“待提交”状态）
- 同步日志：领导者向所有跟随者发送日志同步指令，要求跟随者复制这条日志条目
- 多数确认：当领导者收到多数节点（包括自己）的“日志已成功写入”确认后，将该日志条目标记为已提交，并执行该操作
- 通知生效：领导者向所有跟随者发送“条目已提交”的通知，跟随者收到后，执行该条目对应的操作，至此整个集群的元数据达成一致
3、 异常场景
Raft 协议能通过自身机制处理节点故障、网络分区等异常，保障共识不中断
<领导者故障>
- 若领导者宕机，集群内跟随者会因收不到心跳触发新的选举，重新选出领导者；新领导者会先同步本地最新的日志到其他节点，确保集群日志一致后再提供服务。
<网络分区（脑裂）>
- 假设 3 节点集群（A、B、C，其中A 为领导者）因网络故障分裂为两个分区：分区 1（A）、分区 2（B、C）
- 分区 2 中，B、C 因收不到 A 的心跳，会触发选举并选出新领导者（如 B），由于 B、C 占多数节点（2/3），可正常处理写入变更操作
- 分区 1 中的 A 因节点数不足多数，会自动进入 “不可写” 状态，无法处理写入变更操作
- 当网络恢复后，A 会发现集群的任期号已更新（B 当选后任期号 + 1），便会自动切换为跟随者，同步 B 的最新日志，最终集群恢复统一状态
