2. etcd 架构解析：Raft 共识算法与存储引擎
etcd 是一个高可用的分布式键值存储系统，其核心架构围绕 Raft 共识算法 和 BoltDB 存储引擎 构建。理解这两个组件是掌握 etcd 增量备份与灾备自动化的基础。本章将深入解析 Raft 的 Leader 选举、日志复制流程，以及 BoltDB 的底层存储机制。
2.1 Raft 共识算法原理
Raft 是一种用于管理复制日志的共识算法，它通过 Leader 选举 和 日志复制 两个核心过程，确保集群中所有节点状态一致。etcd 使用 Raft 来保证数据的一致性和高可用性。
核心概念： Raft 将节点分为三种角色：Leader（领导者）、Follower（跟随者）和 Candidate（候选者）。正常运行时，只有一个 Leader，其余为 Follower。
2.2 Leader 选举机制
Leader 选举是 Raft 保证集群可用性的关键。当 Leader 故障或网络分区发生时，Follower 会触发选举流程。
| 阶段 | 触发条件 | 关键行为 | 结果 |
|---|---|---|---|
| 选举超时 | Follower 在随机超时时间（150-300ms）内未收到 Leader 心跳 | 增加任期号（term），转换为 Candidate | 开始新一轮选举 |
| 请求投票 | Candidate 向所有节点发送 RequestVote RPC | 包含自己的 lastLogIndex 和 lastLogTerm | 等待其他节点响应 |
| 投票决策 | Follower 收到投票请求 | 比较日志新旧程度，每个任期只能投一票 | 投票给日志更新的 Candidate |
| 当选 Leader | Candidate 获得超过半数（N/2+1）投票 | 立即发送心跳（AppendEntries）确立权威 | 开始处理客户端请求 |
避坑指南： 选举超时时间应设置为随机值，避免多个 Follower 同时成为 Candidate 导致选票分裂。etcd 默认超时范围为 150ms-300ms。
2.3 日志复制流程
所有写操作必须通过 Leader 处理。Leader 将操作封装为日志条目，复制到所有 Follower，确保日志一致后提交。
日志复制关键步骤：
- 追加日志： Leader 将客户端请求追加到本地日志，状态为 未提交。
- 并行复制： Leader 通过 AppendEntries RPC 将日志条目发送给所有 Follower。
- 等待多数响应： Leader 等待超过半数 Follower 成功追加日志。
- 提交日志： Leader 将日志标记为 已提交，应用到状态机，并通知 Follower 提交。
2.4 存储引擎：BoltDB
etcd 使用 BoltDB 作为底层持久化存储引擎。BoltDB 是一个基于 B+ 树 的嵌入式键值数据库，提供事务性读写能力。
| 特性 | 说明 | 对备份的影响 |
|---|---|---|
| B+ 树结构 | 所有数据存储在 B+ 树中，支持范围查询和顺序遍历 | 增量备份可基于 B+ 树节点版本号实现 |
| 事务支持 | 支持 ACID 事务，读写事务可并发执行 | 备份时需使用只读事务，避免阻塞写操作 |
| MVCC | 多版本并发控制，每个事务看到一致的数据快照 | 支持基于时间点的增量备份 |
| 文件存储 | 所有数据存储在一个 .db 文件中 | 备份时直接复制文件可能导致数据不一致 |
重要提示： BoltDB 不支持热备份（直接复制文件）。etcd 提供了
etcdctl snapshot save 命令创建一致性快照，该命令通过 Raft 层确保数据一致性。
2.5 Raft 与 BoltDB 的协作关系
etcd 的整体架构中，Raft 层负责共识和日志复制，BoltDB 负责持久化存储。两者通过以下方式协作：
- 日志持久化： Raft 日志条目先写入 BoltDB 的 WAL（Write-Ahead Log）文件，确保崩溃恢复。
- 状态机应用： 提交的日志条目应用到 BoltDB 的 B+ 树中，形成最终数据。
- 快照机制： 当 Raft 日志过大时，etcd 会创建 BoltDB 快照，压缩日志并释放磁盘空间。
备份实践： 理解 Raft 和 BoltDB 的协作关系后，可以设计更高效的备份策略。例如，利用 BoltDB 的 MVCC 特性，在只读事务中获取一致性快照，避免阻塞写操作。