2. etcd 基础架构：Raft 共识算法原理、etcd 集群节点角色、Leader 选举与租约机制
2.1 Raft 共识算法核心原理
etcd 使用 Raft 共识算法来保证分布式系统中的数据一致性和高可用性。Raft 将共识问题分解为三个相对独立的子问题：Leader 选举、日志复制和安全性。其核心思想是通过一个强 Leader 来协调所有节点的日志写入，确保集群中超过半数节点（Quorum）确认后，数据才被视为已提交。
关键概念： Raft 保证在任意时刻，集群中最多只有一个有效的 Leader。所有写请求必须经过 Leader，Leader 将日志条目复制到 Follower 节点，当大多数节点（N/2 + 1）确认写入后，该条目才被提交并应用到状态机。
Raft 的日志复制流程可概括为以下步骤：
- 客户端请求：客户端将写请求发送给 Leader。
- 追加日志：Leader 将请求封装为日志条目，追加到本地日志中。
- 并行复制：Leader 通过
AppendEntriesRPC 并行将日志条目发送给所有 Follower。 - 确认响应：Follower 收到日志后写入本地，并返回成功响应。
- 提交执行：Leader 收到大多数节点的成功响应后，将日志条目标记为已提交，并应用到状态机。
- 通知客户端：Leader 将执行结果返回给客户端。
2.2 etcd 集群节点角色
在 etcd 集群中，每个节点在任意时刻都处于以下三种角色之一：
| 角色 | 职责 | 状态 | 关键行为 |
|---|---|---|---|
| Leader | 处理所有客户端请求，管理日志复制 | 活跃 | 定期发送心跳（Heartbeat）给 Follower；处理写请求；提交日志 |
| Follower | 被动复制日志，响应 Leader 的 RPC | 被动 | 接收并存储日志；投票给 Candidate；如果超时未收到心跳，转为 Candidate |
| Candidate | 发起 Leader 选举 | 过渡 | 增加任期号（Term）；请求其他节点投票；获得多数票后成为 Leader |
运维提示： 在 etcd 集群中，Follower 节点不直接处理写请求。如果客户端将写请求发送到 Follower，Follower 会将请求重定向到当前 Leader。因此，客户端应优先连接 Leader 节点以获得最佳写入性能。
2.3 Leader 选举机制
Leader 选举是 Raft 协议中保证集群可用性的关键机制。当 Leader 宕机或网络分区导致 Follower 无法收到心跳时，集群会触发新一轮选举。
选举过程遵循以下步骤：
- 触发条件：Follower 在 选举超时时间（Election Timeout，默认 1000ms）内未收到 Leader 的心跳，则转为 Candidate。
- 发起选举：Candidate 增加自己的任期号（Term），并向所有节点发送
RequestVoteRPC。 - 投票规则：每个节点在一个任期内只能投一票，且优先投票给日志更新、任期更大的 Candidate。
- 胜出条件：Candidate 获得超过半数（N/2 + 1）的投票后，成为新的 Leader。
- 心跳稳定：新 Leader 立即开始发送心跳给所有节点，重置选举超时计时器，稳定集群状态。
注意： 如果多个节点同时成为 Candidate，可能导致选票分散，无法产生多数票。此时会触发新一轮选举，直到某个 Candidate 获得多数票。频繁的选举失败会降低集群可用性，因此应合理配置选举超时时间，避免网络抖动引发不必要的选举。
2.4 租约机制（Lease）
etcd 的 租约（Lease） 是一种轻量级的分布式锁和心跳保活机制。租约允许客户端为 key 绑定一个 TTL（Time-To-Live），在租约有效期内，客户端可以通过续约（KeepAlive）保持 key 的存活；如果租约过期且未续约，etcd 会自动删除所有与该租约关联的 key。
租约机制在以下场景中非常有用：
- 分布式锁：客户端创建租约并关联锁 key，锁的持有者通过定期续约防止锁超时释放。
- 服务注册与发现：服务实例将自身信息写入 etcd 并绑定租约，实例下线后租约过期，服务自动注销。
- Leader 选举：在 etcd 之上实现应用层 Leader 选举时，租约用于控制 Leader 的有效期。
| 租约操作 | API 接口 | 说明 |
|---|---|---|
| 创建租约 | LeaseGrant |
指定 TTL（秒），返回租约 ID |
| 续约 | LeaseKeepAlive |
客户端定期调用，重置租约 TTL |
| 关联 key | Put 时指定租约 ID |
将 key 与租约绑定，租约过期时 key 自动删除 |
| 查询租约 | LeaseTimeToLive |
查看租约剩余 TTL 和关联的 key 列表 |
| 撤销租约 | LeaseRevoke |
主动删除租约，同时删除所有关联 key |
性能优化建议： 在压测场景中，大量短 TTL 租约的频繁创建和续约会增加 etcd 的写入负载。建议将租约 TTL 设置为合理范围（如 10~60 秒），并复用租约 ID 来减少 LeaseGrant 调用次数。同时，注意监控
etcd_server_lease_expired_total 指标，避免租约过期风暴。
2.5 小结
本章介绍了 etcd 基础架构的核心组件：Raft 共识算法保证了数据一致性，节点角色（Leader、Follower、Candidate）定义了集群的行为模式，Leader 选举机制确保了高可用性，而租约机制则为分布式协调提供了灵活的超时控制。理解这些基础原理是后续优化 Federation 调度参数的前提。