etcd增量备份与蓝绿灾备RPO监测 - 第1节
1.1 etcd 是什么
etcd 是一个开源的、分布式的、强一致性的键值存储系统，用于存储分布式系统中的关键数据。它由 CoreOS 团队开发，采用 Go 语言编写，底层基于 Raft 共识算法实现数据复制与一致性。etcd 常被用作服务发现、配置管理和分布式锁的底层基础设施，是 Kubernetes 等云原生平台的核心组件。
核心定位：分布式系统中的“协调者”与“状态存储库”，保证数据在集群各节点间严格一致。
1.2 核心特性
| 特性 | 说明 | 实现方式 |
|---|---|---|
| 强一致性 | 所有节点在同一时刻看到的数据完全相同，读操作返回最新写入的数据 | 基于 Raft 共识算法，写入需多数节点确认 |
| 高可用 | 集群容忍少数节点故障（如 3 节点集群可容忍 1 个节点宕机） | Leader 选举 + 日志复制 + 故障转移 |
| 键值存储 | 以层级目录结构组织数据，支持 TTL 自动过期 | 基于 B+ 树存储引擎，支持范围查询 |
| Watch 机制 | 客户端可监听键的变化，实现事件驱动 | 长轮询 + 事件推送 |
| 租约机制 | 支持键绑定租约，租约过期自动删除关联键 | Lease 对象 + TTL 计时器 |
Raft 共识与强一致性
etcd 使用 Raft 协议确保数据一致性。Raft 将节点分为 Leader、Follower 和 Candidate 三种角色。所有写请求必须由 Leader 处理，Leader 将日志条目复制到多数 Follower 后，才提交并返回客户端。这种机制保证了即使部分节点故障，数据也不会丢失或出现不一致。
# 写入流程（简化）
1. 客户端发送写请求到 Leader
2. Leader 将操作追加到本地日志
3. Leader 并行发送日志条目到所有 Follower
4. 多数 Follower 确认后，Leader 提交日志
5. Leader 返回成功给客户端
6. Follower 异步应用日志到状态机1.3 典型应用场景
etcd 在分布式系统中扮演“协调者”角色，以下三个场景最为常见：
- 服务发现：服务实例启动时在 etcd 注册自身地址，客户端通过 Watch 机制实时获取可用服务列表。Kubernetes 使用 etcd 存储所有 Pod、Service、Endpoint 等资源对象。
- 配置管理：将应用配置集中存储在 etcd 中，配置变更时通过 Watch 推送到所有客户端，实现动态配置更新，无需重启服务。
- 分布式锁：利用 etcd 的强一致性和租约机制实现分布式锁，确保同一时间只有一个客户端执行关键操作，常用于选主、任务调度等场景。
课程关联：本课程的增量备份与蓝绿发布灾备方案，正是围绕 etcd 的强一致性和高可用特性设计，确保在故障切换时 RPO 可控。
1.4 etcd 架构概览
下图展示了 etcd 集群的核心组件与交互关系，帮助理解后续备份与灾备方案的设计基础。
1.5 数据模型与存储
etcd 的数据模型采用扁平化的键值结构，键以 / 分隔形成层级命名空间。每个键值对关联一个版本号（revision），支持多版本并发控制（MVCC）。
| 概念 | 说明 | 示例 |
|---|---|---|
| Key | 字符串形式的键，支持前缀查询 | /app/config/db_host |
| Value | 任意字节序列，最大 1.5 MB | 192.168.1.100 |
| Revision | 全局递增版本号，每次写操作递增 | 10023 |
| Lease | 租约，绑定键后实现 TTL 自动过期 | lease_id: 12345, TTL: 30s |
备份关注点：etcd 的 MVCC 机制会保留历史版本，但默认会定期压缩（compact）旧版本。增量备份需要基于 revision 或时间戳捕获变更，压缩策略直接影响备份数据的完整性。
1.6 本章小结
- etcd 是分布式系统的“状态存储库”，提供强一致性和高可用保障。
- Raft 共识算法是 etcd 一致性的核心，Leader 负责写请求，Follower 保持数据同步。
- 典型场景包括服务发现、配置管理和分布式锁，这些场景对数据可靠性要求极高。
- 理解 etcd 的架构和数据模型，是设计增量备份与灾备方案的前提。