3. Leader选举基础：分布式一致性算法（Raft/Paxos）简介、Leader选举在控制面组件中的典型应用场景
3.1 分布式一致性算法：从 Paxos 到 Raft
在 Serverless 控制面中，多个组件副本必须就系统状态（如函数版本、触发器绑定、SLO 配置）达成一致。分布式一致性算法正是解决这一问题的数学基础。业界主流从 Paxos 演进到 Raft，核心差异在于可理解性与工程落地成本。
| 维度 | Paxos（经典） | Raft（工程友好） |
|---|---|---|
| 设计哲学 | 最小化消息轮次，理论优雅 | 可理解性优先，分解为子问题 |
| Leader 角色 | 弱化，多 Proposer 可并行 | 强 Leader，所有写入必须经过 Leader |
| 选举触发 | 无固定心跳，依赖 Prepare 阶段 | 固定心跳超时，随机化选举超时 |
| 日志复制 | 两阶段提交（Prepare + Accept） | 单向 Append-Entries，Leader 主导 |
| 成员变更 | 复杂，需联合共识 | 单节点阶段变更（Joint Consensus） |
| 工程落地 | etcd、ZooKeeper 内部变体 | etcd（Raft）、Consul、TiKV |
关键结论：Serverless 控制面组件（如调度器、函数元数据服务、SLO 仲裁器）几乎全部采用 Raft 或其变体。Raft 的强 Leader 模型天然适配控制面“主从协同”的运维模式，且 Leader 选举的确定性降低了故障排查成本。
3.2 Raft Leader 选举核心机制
Raft 将节点划分为三种角色：Leader（处理所有客户端请求）、Follower（被动复制日志）、Candidate（发起选举的临时角色）。选举过程遵循以下步骤：
- 超时触发：Follower 在选举超时（通常 150–300ms，随机化）内未收到 Leader 心跳，转换为 Candidate。
- 发起投票：Candidate 自增 term（任期号），向所有节点发送 RequestVote RPC。
- 投票规则：每个节点在每个 term 内只能投一票，且只投票给日志至少与自己一样新的 Candidate。
- 赢得选举：Candidate 获得超过半数（N/2 + 1）节点的投票，成为新 Leader。
- 心跳确立：新 Leader 立即发送 AppendEntries（空日志作为心跳）抑制其他节点超时。
工程避坑：选举超时随机化是防止“选票分裂”的关键。如果所有 Follower 使用相同超时，它们会同时变成 Candidate，导致无人获得多数票，反复选举。生产环境建议超时范围 150–300ms，且每个节点独立随机。
3.3 Leader 选举在控制面组件中的典型应用场景
Serverless 控制面并非单一单体，而是由多个微服务组件构成。每个组件都可能需要 Leader 选举来保证高可用与状态一致性。以下列出四个最典型的应用场景：
| 组件 | 选举目的 | 选举粒度 | 典型实现 |
|---|---|---|---|
| 函数元数据服务 | 保证函数版本、别名、触发器配置的写入一致性 | 全局单 Leader | etcd + Raft |
| SLO 仲裁器 | 避免多个副本同时发起 SLO 违约重调度，造成资源震荡 | 每个 SLO 维度一个 Leader | 基于 Lease 的选主 |
| 调度器（Scheduler） | 全局调度决策唯一性，防止重复调度或资源超卖 | 全局单 Leader + 影子副本 | Raft + 预选日志 |
| 事件网关（Event Gateway） | 保证事件投递的有序性与去重 | 分区（Partition）级别 Leader | 基于 Raft 的分组分片 |
注意：并非所有控制面组件都需要强一致性选举。例如只读缓存组件、日志收集组件可以使用 gossip 协议或最终一致性模型。过度使用 Raft 会增加延迟和运维复杂度。建议仅在“写入一致性 + 故障自动切换”场景下引入 Leader 选举。
3.4 控制面 Leader 选举的典型架构模式
在实际 Serverless 平台中，Leader 选举通常与分布式协调服务（如 etcd、ZooKeeper）结合。组件副本通过竞争分布式锁或 Lease 来确立 Leader 身份。以下架构图展示了三副本元数据服务的选举拓扑：
3.5 选举后的关键动作：Lease 续约与故障检测
Leader 选举并非一次性事件，而是一个持续的过程。当选的 Leader 必须通过定期续约（Lease Renewal）来维持身份。一旦续约失败，其他副本将触发重新选举。以下是生产环境中的典型参数配置：
| 参数 | 推荐值 | 说明 |
|---|---|---|
| Lease TTL | 5–10 秒 | Leader 失效后，其他副本等待的最长时间 |
| 续约间隔 | TTL / 3（约 1.5–3 秒） | Leader 定期刷新 Lease，避免过期 |
| 选举超时 | 150–300ms（随机） | Follower 等待心跳的超时窗口 |
| 心跳间隔 | 50–100ms | Leader 向 Follower 发送心跳的频率 |
| 最大重试次数 | 3–5 次 | Leader 续约失败后的重试上限，超过则主动退位 |
生产建议：在 Serverless 控制面中，Lease TTL 不宜过短（<3 秒），否则网络抖动会频繁触发选举，导致控制面震荡；也不宜过长（>30 秒），否则 Leader 故障后恢复时间过长，影响 SLO 违约处置的时效性。推荐 5–10 秒作为平衡点。