2. Raft基础：Leader选举机制详解、Term与Epoch概念、选举超时与心跳交互流程

Raft 是一种易于理解的分布式共识算法，其核心目标是在一个由多个节点组成的集群中，就一系列日志条目达成一致。Leader 选举是 Raft 算法中最关键、最基础的机制，它确保了在任何时刻，集群中最多只有一个有效的 Leader 来负责处理客户端请求和日志复制。理解 Leader 选举的细节，是定位 etcd 性能瓶颈和异常行为的基石。

2.1 Term 与 Epoch：逻辑时钟与任期

在 Raft 中，Term（任期）是一个递增的逻辑时钟，它将时间划分为一段段连续的、长度不固定的时期。每个 Term 都以一次 Leader 选举开始，选举出的 Leader 将负责该 Term 内的所有决策。如果选举失败（例如选票分裂），该 Term 会立即结束，并进入下一个 Term 发起新的选举。

2.2 Leader 选举机制详解

Raft 集群中的每个节点都处于三种状态之一：Leader、Follower 或 Candidate。选举过程由 Follower 在检测到 Leader 心跳超时后触发。

选举流程步骤

1. 发起选举：Follower 在选举超时时间内未收到 Leader 的心跳，它会增加自己的当前 Term，转换为 Candidate 状态，并为自己投票。
2. 请求投票：Candidate 向集群中所有其他节点并行发送 RequestVote RPC，请求中携带自己的 Term、候选者 ID、以及最后一条日志的索引和 Term。
3. 投票规则：其他节点收到 RequestVote 后，根据以下条件决定是否投票：
   • Term 比较：如果请求中的 Term 小于接收方当前的 Term，则拒绝投票。
   • 日志比较：接收方会检查候选者的日志是否至少与自己一样新（最后一条日志的 Term 更大，或 Term 相同但索引更大）。如果候选者的日志更旧，则拒绝投票。
   • 一票制：每个 Term 内，每个节点只能投出一张赞成票。
4. 赢得选举：如果 Candidate 获得了超过半数节点（包括自己）的投票，则成为该 Term 的 Leader。
5. Leader 上任：新 Leader 立即向所有节点发送心跳（AppendEntries RPC，不包含日志条目），以确立权威并阻止新的选举。

选举超时与心跳交互流程

选举超时和心跳是维持 Raft 集群稳定运行的两个核心时间参数。它们之间的交互决定了 Leader 故障检测的速度和选举的稳定性。

• 选举超时（Election Timeout）：Follower 等待 Leader 心跳的最长时间。该时间通常是一个随机值（例如 150ms ~ 300ms），以防止多个 Follower 同时发起选举导致选票分裂。
• 心跳间隔（Heartbeat Interval）：Leader 向所有 Follower 发送心跳的频率。通常设置为选举超时最小值的 1/10 到 1/5（例如 10ms ~ 50ms），以确保 Follower 能及时收到心跳。

2.3 选举超时与心跳的详细交互

为了更清晰地展示选举超时和心跳如何协同工作，下图展示了正常情况下的心跳维持和异常情况下的选举触发过程。

2.4 选举过程中的关键参数与性能影响

在 etcd 压测中，选举相关的参数直接影响集群的可用性和性能。以下表格列出了核心参数及其对性能的影响。