📚 课程目录第2章 etcd核心架构

2. etcd架构基础：Raft共识算法核心概念、etcd集群角色与Term任期机制

etcd 是一个高可用的分布式键值存储系统，其核心基石是 Raft 共识算法。理解 Raft 是掌握 etcd 故障排查与压测调优的前提。本节将深入剖析 Raft 的核心概念、集群角色模型以及 Term（任期）机制，为后续的 Leader 选举超时分析打下理论基础。

Raft 是一种用于管理复制日志的共识算法，它将共识问题分解为三个相对独立的子问题：Leader 选举、日志复制和安全性。与 Paxos 相比，Raft 更易于理解且实现更简洁，这也是 etcd 选择它的主要原因。

  核心设计哲学： Raft 通过“强领导者”模型简化了共识流程。在任意时刻，集群中只有一个有效的 Leader，它负责处理所有客户端请求并将日志复制到其他节点。

Raft 算法的关键机制包括：

在任意时刻，etcd 集群中的每个节点都处于以下三种角色之一：

角色	职责	状态特征	故障影响
Leader	处理所有客户端读写请求；管理日志复制；发送心跳（Heartbeat）维持权威。	定期向所有 Follower 发送 AppendEntries RPC（空日志作为心跳）。	Leader 宕机将触发新一轮选举，期间集群不可写入。
Follower	被动响应 Leader 和 Candidate 的 RPC 请求；接收并应用 Leader 复制的日志。	等待 Leader 心跳；若超时未收到心跳，则转换为 Candidate。	Follower 宕机不影响集群可用性，但会降低容错能力。
Candidate	发起 Leader 选举；向其他节点请求投票（RequestVote RPC）。	选举超时后进入此状态；获得多数票后成为 Leader。	多个 Candidate 同时发起选举可能导致选票分裂，延长选举时间。

压测视角： 在压测场景下，Leader 节点承受的负载远高于 Follower。如果 Leader 因 CPU 或网络延迟无法及时发送心跳，Follower 会误判 Leader 失效并触发选举，导致集群短暂不可用。这是“Leader 选举超时”故障的典型诱因。

Term（任期）是 Raft 算法中一个逻辑时间概念，它将时间划分为一段段连续且单调递增的编号。每个 Term 以一次选举开始，如果选举成功，该 Term 内由新选出的 Leader 管理集群；如果选举失败（选票分裂），该 Term 可能很快结束并进入下一个 Term。

Term 机制在 etcd 中扮演着至关重要的角色：

故障排查关键点： 在压测或故障场景下，如果频繁观察到集群中 Term 快速递增（例如在短时间内从 10 增长到 100），这通常意味着 Leader 频繁切换或选举失败。Term 的异常增长是“Leader 选举超时”问题的最直接信号之一。

为了帮助你在压测沙盘故障排查中快速定位问题，下表总结了 Raft 核心机制与 etcd 运维的对应关系：