4. etcd 集群架构与 Raft 协议：Leader 选举、日志复制、安全性保证
etcd 作为分布式键值存储系统，其高可用与强一致性依赖于 Raft 共识算法。在灾备准入场景中，理解 Raft 协议是设计备份策略、评估故障影响范围以及制定恢复方案的理论基础。本节将深入剖析 etcd 的集群架构与 Raft 协议的核心机制。
4.1 etcd 集群节点角色与架构
一个标准的 etcd 集群通常由奇数个节点组成（如 3、5、7 节点），每个节点在 Raft 协议中扮演以下三种角色之一：
| 角色 | 职责 | 灾备关注点 |
|---|---|---|
| Leader（领导者） | 处理所有客户端写入请求；负责日志复制与心跳维持。 | Leader 节点故障将触发重新选举，期间写入不可用。 |
| Follower（跟随者） | 被动接收 Leader 的日志复制；响应 Leader 与 Candidate 的请求。 | 多数 Follower 故障将导致集群不可用（丧失仲裁）。 |
| Candidate（候选者） | Leader 选举期间的临时角色；发起投票请求。 | 选举风暴可能导致集群短暂不可用，需关注超时配置。 |
灾备准入提示： 在灾备架构设计中，集群规模直接决定故障容忍度。3 节点集群最多容忍 1 节点故障；5 节点集群最多容忍 2 节点故障。备份恢复演练应覆盖“多数节点故障”的极端场景。
4.2 Raft 协议核心机制
Raft 协议通过三个核心子问题保证分布式一致性：Leader 选举、日志复制、安全性。下面分别阐述。
4.2.1 Leader 选举
当 Leader 节点宕机或网络分区发生时，Follower 会转换为 Candidate 并发起选举。选举过程遵循以下步骤：
- 超时触发： Follower 在选举超时（election timeout）内未收到 Leader 心跳，增加当前任期（term），转换为 Candidate。
- 发起投票： Candidate 向集群中所有其他节点发送
RequestVote RPC。 - 投票规则： 每个节点在一个任期内只能投一票，且优先投票给日志更新、更完整的 Candidate。
- 赢得选举： Candidate 获得超过半数（N/2+1）节点的投票后成为新 Leader。
- 心跳广播： 新 Leader 立即发送心跳（AppendEntries RPC）给所有节点，确立权威并重置其他节点的选举超时。
关键参数： 默认选举超时时间为 1000ms，心跳间隔为 100ms。在灾备演练中，可通过调整
--election-timeout 参数模拟慢速网络或高延迟场景。
4.2.2 日志复制
所有客户端写入请求必须由 Leader 处理。日志复制保证了数据在集群中的强一致性：
- 追加日志： Leader 将客户端请求封装为日志条目（entry），追加到本地日志。
- 并行复制： Leader 向所有 Follower 发送
AppendEntries RPC，包含日志条目及前一条日志的索引与任期。 - 一致性检查： Follower 检查本地日志是否与 Leader 发送的 prevLogIndex/prevLogTerm 匹配。若匹配则追加；否则拒绝并返回冲突信息。
- 提交（Commit）： 当 Leader 收到多数 Follower 的成功响应后，将日志条目标记为已提交（committed），并应用到状态机。
- 通知客户端： Leader 向客户端返回写入成功。
灾备演练注意： 日志复制是异步的。在 Leader 提交日志但尚未通知 Follower 时发生故障，可能导致已提交日志丢失。备份策略必须考虑这种“脑裂”或“日志不一致”的恢复场景。
4.3 安全性保证
Raft 协议通过以下机制保证集群在故障、网络分区等异常情况下的安全性：
| 安全机制 | 描述 | 对灾备的影响 |
|---|---|---|
| Leader 完整性 | 只有日志最完整的节点才能当选 Leader。新 Leader 必须包含所有已提交的日志条目。 | 恢复时需确保备份数据包含已提交日志，否则新 Leader 可能丢失数据。 |
| 日志匹配 | Follower 只追加与 Leader 一致的日志条目。若不一致，Follower 会删除冲突日志并回退到匹配位置。 | 备份恢复后，Follower 可能因日志不匹配而触发大量日志回退，影响恢复速度。 |
| 选举限制 | Candidate 必须拥有比投票者更新的日志（通过 lastLogTerm 和 lastLogIndex 比较）才能获得投票。 | 在灾备恢复中，如果备份数据落后于集群，该节点无法成为 Leader，只能作为 Follower 同步。 |
| 状态机安全性 | 日志条目按顺序应用到状态机，且每个节点以相同顺序应用相同日志。 | 备份恢复必须保证日志顺序一致，否则状态机状态可能不一致。 |
工程落地要点： 在灾备准入演练中，应验证备份数据是否满足“Leader 完整性”要求。建议定期执行
etcdctl snapshot status 检查快照的哈希与修订版本，确保备份数据在逻辑上是一致的。
4.4 集群故障模型与灾备策略
基于 Raft 协议的特性，etcd 集群的故障模型可分为以下几类，每类对应不同的灾备策略：
- 单节点故障： 集群自动选举新 Leader，服务短暂中断（毫秒级）。灾备策略：确保备份频率足够高，减少数据丢失窗口。
- 多数节点故障： 集群丧失仲裁，无法选举 Leader，服务完全不可用。灾备策略：必须通过备份数据重建集群，恢复时间取决于备份大小与恢复流程。
- 网络分区： 少数分区节点无法与 Leader 通信，可能触发多次选举。灾备策略：配置合理的超时参数，避免选举风暴；演练网络分区恢复流程。
- 数据损坏： 磁盘故障或文件系统错误导致数据损坏。灾备策略：定期进行数据完整性校验，使用
etcdctl check datascale等工具验证。
演练建议： 在灾备准入演练中，至少覆盖“多数节点故障”和“数据损坏”两种场景。通过模拟故障、执行备份恢复、验证数据一致性，确保灾备方案的有效性。