2. etcd 集群架构：节点角色、节点规划与脑裂防护
etcd 使用 Raft 共识算法 来保证分布式系统中的数据一致性与高可用性。理解集群架构是制定备份策略与蓝绿发布回滚方案的基础。本节将深入剖析节点角色、奇数节点规划原则以及网络分区（脑裂）的防护机制。
2.1 节点角色：Leader、Follower、Candidate
在 Raft 协议中，etcd 集群中的每个节点在任一时刻都处于以下三种角色之一：
| 角色 | 职责 | 关键行为 |
|---|---|---|
| Leader（领导者） | 处理所有客户端写入请求，负责日志复制与数据同步。 | 定期向 Follower 发送心跳（Heartbeat）；在多数节点确认后提交日志条目。 |
| Follower（跟随者） | 被动接收来自 Leader 的日志复制与心跳，处理只读查询。 | 若在选举超时（Election Timeout）内未收到 Leader 心跳，则转为 Candidate。 |
| Candidate（候选者） | 发起新一轮 Leader 选举，争取成为新 Leader。 | 向其他节点发送投票请求（RequestVote）；获得多数票后晋升为 Leader。 |
关键指标： 选举超时时间通常为 100ms ~ 500ms（随机化），心跳间隔为 50ms ~ 100ms。合理的超时配置能减少不必要的选举，提升集群稳定性。
2.2 集群节点数规划：为什么必须是奇数节点
etcd 集群的节点数量直接影响其容错能力和选举成功率。Raft 要求写入操作必须获得 多数（Quorum） 节点的确认，Quorum 计算公式为：Quorum = ⌊N/2⌋ + 1。
| 集群节点数 (N) | Quorum (多数) | 最大容忍故障节点数 | 推荐场景 |
|---|---|---|---|
| 1 | 1 | 0 | 开发/测试环境，无高可用要求 |
| 3 | 2 | 1 | 生产环境最小推荐配置 |
| 5 | 3 | 2 | 高可用生产环境，允许同时故障 2 节点 |
| 7 | 4 | 3 | 超大规模集群，但写入性能会下降 |
为什么不用偶数节点？ 以 4 节点为例，Quorum = 3，最大容忍故障数 = 1。与 3 节点集群相比，容错能力相同，但多了一个节点带来的网络开销和选举复杂度反而增加。奇数节点在相同容错能力下，节点数更少，性能更优。
2.3 网络分区与脑裂防护
网络分区（Network Partition）是指集群中部分节点因网络故障无法互相通信。在 etcd 中，Raft 协议通过 Quorum 机制 天然防止脑裂（Split-Brain）——即多个分区各自选举出 Leader 导致数据不一致。
生产环境避坑： 若集群节点数为偶数（如 4 节点），网络分区为 2:2 时，两个分区都无法获得 Quorum（需要 3 票），集群将完全不可用。因此，始终使用奇数节点 是 etcd 集群规划的铁律。
2.4 节点规划最佳实践
- 生产环境最低 3 节点：容忍 1 节点故障，满足大多数业务高可用需求。
- 跨可用区部署：将节点分散到 3 个不同的物理或云可用区，避免单点故障。
- 避免单节点集群用于生产：无容错能力，一旦故障则数据完全丢失。
- 节点数不宜超过 7：节点越多，Leader 复制日志的网络开销越大，写入性能会显著下降。
- 监控选举频率：频繁的 Leader 选举通常意味着网络不稳定或节点负载过高，需及时排查。
与备份/回滚的关系： 理解集群架构有助于设计备份策略——例如，备份操作应优先从 Follower 节点执行，避免对 Leader 造成额外负载；蓝绿发布回滚时，需确保新旧集群的 Quorum 健康，避免因节点数不足导致回滚失败。