3. Leader选举机制详解：选举触发条件、选举超时原理与投票分裂

etcd 的 Raft 共识算法依赖 Leader 选举 来维持集群的写入一致性与可用性。理解选举的触发条件、超时机制以及投票分裂场景，是排查压测环境下 Leader 频繁切换、选举超时等故障的核心基础。

3.1 选举触发条件

etcd 集群中的 Follower 节点在以下三种情况下会发起新一轮 Leader 选举：

3.2 选举超时（Election Timeout）原理

选举超时是 Raft 保证选举稳定性的核心参数。每个 Follower 节点维护一个独立的选举超时计时器，其工作原理如下：

1. 计时器重置： Follower 每收到来自 Leader 的有效心跳，立即重置选举超时计时器。
2. 超时触发： 若计时器到期仍未收到心跳，Follower 认为 Leader 已失联，将自身任期（Term）+1，并转为 Candidate 状态。
3. 发起投票： Candidate 向集群中所有其他节点发送 RequestVote RPC，请求选举自己为新的 Leader。

etcd 默认的选举超时配置如下：

3.3 随机超时与投票分裂

Raft 通过 随机超时 机制来避免多个 Follower 同时发起选举导致的 投票分裂（Split Vote）。

3.3.1 随机超时机制

每个 Follower 的选举超时并非固定值，而是在 [election-timeout, 2 * election-timeout) 范围内随机选取。例如，默认 1000ms 的基准值下，实际超时在 1000ms ~ 2000ms 之间随机分布。

• 目的： 确保在 Leader 失效后，不同 Follower 的选举超时时间错开，大概率只有一个节点先超时并发起选举。
• 效果： 先发起选举的 Candidate 有更大机会获得多数票，快速成为新 Leader，避免多个 Candidate 同时竞争。

3.3.2 投票分裂场景

当随机超时未能有效错开，或网络延迟导致多个 Candidate 几乎同时发起选举时，可能发生投票分裂：

1. 两个或多个 Follower 几乎同时超时，各自成为 Candidate。
2. 每个 Candidate 向所有节点发送 RequestVote，并为自己投票。
3. 由于每个节点在一个任期内只能投一票，且先收到的投票请求会被优先处理，可能导致没有任何 Candidate 获得超过半数的选票。
4. 选举超时（Election Timeout）再次触发，所有 Candidate 退回 Follower 状态，等待下一次随机超时后重新选举。

3.4 选举超时参数调优建议

在压测沙盘环境中，合理调整选举超时参数可以有效减少不必要的选举抖动：

3.5 选举超时故障排查清单

在压测沙盘中遇到 Leader 选举超时问题时，按以下清单快速定位根因：

• 检查心跳间隔： 确认 --heartbeat-interval 是否过大（> 200ms），导致 Leader 心跳发送频率不足。
• 检查选举超时： 确认 --election-timeout 是否过小（< 800ms），在压测负载下容易误触发。
• 监控磁盘延迟： 使用 iostat 或 etcd 内置指标 etcd_disk_wal_fsync_duration_seconds，确认是否存在磁盘 I/O 瓶颈。
• 观察网络延迟： 检查节点间 RTT（Round-Trip Time），确认是否因网络抖动导致心跳丢失。
• 分析选举日志： 搜索 etcd 日志中的 leader election、term、vote 关键词，统计选举频率和投票分裂次数。