2. etcd 架构与数据模型：Raft 共识、键值存储与 MVCC
etcd 是一个高可用的分布式键值存储系统，其核心架构围绕 Raft 共识算法、有序键值存储和多版本并发控制（MVCC）三大支柱构建。理解这三者之间的协作关系，是制定灾备策略、评估 RPO 目标的基础。
2.1 Raft 共识机制：分布式一致性的基石
etcd 使用 Raft 算法来保证集群中多个节点之间的数据一致性。Raft 将节点划分为三种角色，并通过领导者选举和日志复制来达成共识。
| 角色 | 职责 | 灾备关联 |
|---|---|---|
| Leader（领导者） | 处理所有客户端写入请求，管理日志复制，定期发送心跳。 | Leader 节点故障将触发重新选举，期间写入不可用。 |
| Follower（跟随者） | 被动接收 Leader 的日志复制，响应 Leader 和 Candidate 的请求。 | Follower 节点可用于读取（线性一致性读），也可作为灾备恢复的数据源。 |
| Candidate（候选者） | 在选举超时后发起领导者选举，争取成为新 Leader。 | 选举过程需要多数节点（quorum）存活，直接影响集群可用性。 |
关键指标：Raft 要求集群中超过半数（N/2 + 1）的节点存活才能正常提供服务。例如，3 节点集群允许 1 个节点故障；5 节点集群允许 2 个节点故障。这是灾备设计中计算最小集群规模的核心依据。
2.2 键值存储结构：有序的扁平化数据模型
etcd 的存储模型是一个扁平的、有序的键值空间。所有数据都以键值对的形式存储，并且键按照字典序（byte-wise lexicographic order）进行排序。这种有序性使得范围查询（Range Query）非常高效。
- Key（键）：字节数组，支持任意二进制数据，但通常使用可读字符串。
- Value（值）：字节数组，存储与键关联的数据。
- Revision（修订版本）：全局单调递增的整数，每次写入（Put/Delete/Txn）都会生成一个新的 revision。
- Lease（租约）：一种 TTL 机制，关联的键会在租约到期后自动删除。
| 操作 | 说明 | 对 Revision 的影响 |
|---|---|---|
| Put | 写入或更新一个键值对 | 生成一个新的 revision |
| Get | 读取一个键或一个范围内的键 | 不生成 revision |
| Delete | 删除一个键或一个范围内的键 | 生成一个删除标记（tombstone）的 revision |
| Txn（事务） | 原子性地执行一组条件判断和操作 | 根据内部操作生成一个或多个 revision |
灾备提示：备份时，除了保存键值数据本身，还必须记录备份时刻的 revision。恢复时，可以通过指定 revision 实现时间点恢复（Point-in-Time Recovery），这是对齐 RPO 目标的关键手段。
2.3 MVCC 多版本并发控制：支持快照与历史查询
etcd 通过 MVCC 机制实现高效的并发控制，同时为备份恢复提供了天然的快照能力。每次写入操作不会原地覆盖旧值，而是创建一个新版本。
2.4 数据模型与灾备恢复的映射关系
理解 etcd 的数据模型，可以直接指导灾备策略的设计：
| 数据模型特性 | 灾备恢复应用 | RPO 影响 |
|---|---|---|
| Raft 日志复制 | 从 Follower 节点备份数据，避免影响 Leader 性能 | 日志复制延迟决定 RPO 下限 |
| 有序键值空间 | 支持增量备份：只备份自上次备份以来修改的键范围 | 增量备份可缩短备份窗口，降低 RPO |
| MVCC 版本链 | 支持时间点恢复：恢复到指定 revision 的历史状态 | 精确到单个写入操作的 RPO |
| Revision 全局单调递增 | 作为备份的“水位线”标记，确保恢复数据的一致性 | 避免部分恢复导致的数据不一致 |
重要警告：etcd 的 MVCC 后台压缩（Compaction）会定期删除旧版本数据。如果备份频率低于压缩频率，将无法恢复到较早的时间点。灾备策略必须确保备份周期短于 etcd 的
--auto-compaction-retention 配置周期。
2.5 核心组件协作关系
etcd 内部各组件如何协同工作，完成一次写入操作？
- 客户端向 Leader 节点发起 Put 请求。
- Raft 模块将请求封装为日志条目，并复制到所有 Follower 节点。
- 当多数节点确认写入后，日志条目被标记为已提交（committed）。
- MVCC 模块将日志条目应用到键值存储，生成一个新的 revision。
- 后端存储（Backend）将数据持久化到 BoltDB（etcd v3 的底层存储引擎）。
这个流程决定了灾备恢复的两个关键点：
- Raft 日志是数据一致性的第一道防线，备份 Raft 日志可以实现接近零 RPO 的持续复制。
- MVCC 快照是数据恢复的最终载体，定期创建快照备份是满足 RPO 目标的最可靠手段。