1. etcd 基础与架构
1.1 etcd 核心概念
etcd 是一个分布式、可靠的键值存储系统，用于分布式系统中的关键数据存储和服务发现。它是云原生计算基金会（CNCF）的毕业项目，也是 Kubernetes 的核心组件。
| 核心概念 | 说明 | 关键特性 |
|---|---|---|
| Key-Value 存储 | 以分层目录结构组织键值对，支持前缀查询和范围查询 | 有序键空间、TTL 自动过期、Watch 机制 |
| Raft 共识算法 | 保证集群中所有节点数据一致性的分布式共识协议 | 强一致性、Leader 选举、日志复制 |
| MVCC 多版本并发控制 | 每个键维护多个历史版本，支持时间旅行查询 | Revision 机制、压缩清理旧版本 |
| Watch 机制 | 客户端可以监听键的变化，实现事件驱动架构 | 实时推送、支持前缀和范围监听 |
| Lease 租约 | 轻量级心跳机制，用于键的自动过期和分布式锁 | TTL 续约、与 Key 绑定、KeepAlive |
运维要点：etcd 的 MVCC 机制是备份恢复的关键——全量备份保存当前快照，增量备份基于 Revision 范围捕获变更。理解 Revision 的单调递增特性，有助于设计 RPO 更优的备份策略。
1.2 Raft 共识算法原理
Raft 是一种易于理解的分布式共识算法，通过 Leader 选举、日志复制 和 安全性 三个核心机制保证集群数据一致性。etcd 使用 Raft 作为其一致性引擎。
1.2.1 节点角色与状态转换
| 角色 | 职责 | 状态转换条件 |
|---|---|---|
| Leader | 处理所有客户端请求，管理日志复制，发送心跳 | 获得多数派投票后成为 Leader |
| Follower | 被动响应 Leader 和 Candidate 的请求 | 启动时默认为 Follower；选举超时后转为 Candidate |
| Candidate | 发起 Leader 选举，请求其他节点投票 | 获得多数派投票转为 Leader；否则退回 Follower |
Raft 核心原则：一个 Term（任期）内最多只有一个 Leader；日志条目一旦被多数节点复制即视为已提交（Committed）；Leader 只能追加新日志，不能覆盖已提交的日志。
1.2.2 日志复制流程
- 客户端请求：客户端将写请求发送到 Leader。
- 追加日志：Leader 将请求封装为日志条目，追加到本地日志。
- 并行复制：Leader 并行向所有 Follower 发送 AppendEntries RPC。
- 多数派确认：当 Leader 收到多数节点（含自身）的成功响应后，日志条目进入 Committed 状态。
- 应用到状态机：Leader 将已提交的日志应用到状态机，并返回结果给客户端。
- 异步应用：Follower 在后续心跳中得知日志已提交，异步应用到本地状态机。
备份关联：Raft 日志复制保证已提交的日志不会丢失，但未提交的日志在 Leader 故障时可能丢失。备份策略必须考虑这一特性——全量快照 + WAL 日志的增量备份组合，才能覆盖已提交的所有数据。
1.3 etcd 集群架构与角色
etcd 集群采用 对等架构，所有节点通过 Raft 协议通信。典型的生产部署为 3 节点或 5 节点集群，以平衡可用性和性能。
1.3.1 集群节点角色
| 角色 | 功能 | 数据状态 | 可投票 |
|---|---|---|---|
| Voting Member | 参与 Raft 投票和日志复制，存储完整数据 | 完整数据副本 | 是 |
| Learner | 仅从 Leader 接收日志，不参与投票，用于扩容或灾备 | 追赶中，最终一致 | 否 |
生产建议：Learner 节点非常适合作为备份目标——它不参与 Raft 投票，不会影响集群的写入性能，同时保持数据的最终一致性，可以作为备份数据源。
1.3.2 集群架构组件
1.3.3 集群规模与容错
| 集群节点数 | 最大容忍故障数 | 推荐场景 | 写入性能 |
|---|---|---|---|
| 3 | 1 | 生产环境最小配置 | 高 |
| 5 | 2 | 高可用关键业务 | 中 |
| 7 | 3 | 跨地域部署 | 低 |
备份与集群规模的关系：节点数越多，Raft 日志复制开销越大，写入延迟增加。备份窗口应避开业务高峰期；对于 5 节点集群，建议使用 Learner 节点作为备份源，避免对 Voting Member 产生额外负载。
1.4 关键数据流与备份切入点
理解 etcd 的数据写入路径，有助于确定备份的最佳切入点和恢复策略。
- 客户端写入 → gRPC 请求到达 Leader 的 API 层。
- WAL 持久化 → 写入预写日志（WAL），保证崩溃恢复。
- Raft 复制 → 并行发送到 Follower，等待多数派确认。
- 状态机应用 → 日志提交后应用到 MVCC 存储引擎。
- Snapshot 压缩 → 定期生成快照，清理旧版本数据。
备份关键点：etcd 的备份必须包含 数据目录（含 WAL 和 Snapshot）或使用
etcdctl snapshot save 命令。仅备份 Snapshot 而不备份 WAL，会丢失两次 Snapshot 之间的增量数据，导致 RPO 不可控。
# 全量快照备份命令
etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/etcd/ca.pem \
--cert=/etc/etcd/client.pem \
--key=/etc/etcd/client-key.pem \
snapshot save /backup/etcd-snapshot-$(date +%Y%m%d%H%M%S).db
# 查看快照状态
etcdctl snapshot status /backup/etcd-snapshot-20250301120000.db -w table
RPO 优化思路：全量快照 + WAL 增量备份的组合策略，可以将 RPO 从小时级降低到分钟级。WAL 文件默认每 10MB 或每 5 分钟滚动一次，增量备份可以捕获这些滚动文件，实现接近实时的数据保护。