1. etcd 概述：分布式系统的基石
etcd 是一个强一致性、高可用的分布式键值存储系统，由 CoreOS 团队使用 Go 语言开发并开源。它采用 Raft 共识算法确保数据在集群各节点间严格一致，是云原生架构中服务发现、配置管理和分布式协调的核心基础设施。
核心定位：etcd 不是通用数据库，而是为分布式系统提供可靠元数据存储与协调能力的“控制面”存储。
1.1 核心特性一览
| 特性 | 说明 | 技术实现 |
|---|---|---|
| 强一致性 | 所有节点对同一 key 的读取返回最新写入值，无最终一致窗口 | Raft 共识算法 + 线性化读（Linearizable Read） |
| 高可用 | 集群容忍少数节点故障（N 节点集群容忍 (N-1)/2 节点宕机） | Leader 选举 + 日志复制 + 自动故障转移 |
| 分布式键值存储 | 扁平的 key-value 模型，支持目录式前缀查询与 Watch 机制 | BoltDB 本地存储 + gRPC v3 API |
| Watch 机制 | 客户端可监听 key 或前缀的变化，实现实时事件驱动 | 长轮询 + 事件流推送 |
| 租约（Lease） | 为 key 绑定 TTL 自动过期，支持心跳续约 | 租约机制 + 时间轮调度 |
1.2 系统架构与数据流
下图展示了 etcd 集群的典型架构：客户端通过 gRPC 与集群交互，Raft 层保证日志一致性，底层 BoltDB 完成持久化。
1.3 典型应用场景
etcd 在云原生生态中扮演“分布式系统控制面”的角色，以下三个场景最为核心：
- 服务发现：微服务启动时将自身地址注册到 etcd，客户端通过 Watch 机制实时感知服务实例上下线。典型代表：Kubernetes 使用 etcd 存储所有集群状态。
- 配置中心：将应用配置集中存储在 etcd 中，配置变更后通过 Watch 推送到所有客户端，实现动态配置热更新。
- 分布式锁：利用 etcd 的强一致性与租约机制实现分布式互斥锁，支持锁自动释放（租约过期），避免死锁。
压测视角：在后续章节中，我们将针对这三个场景构造压测脚本，重点测试 etcd 在读写混合、Watch 订阅、租约续约等高并发模式下的性能瓶颈。
1.4 为什么选择 etcd 而非 ZooKeeper/Consul？
| 对比维度 | etcd | ZooKeeper | Consul |
|---|---|---|---|
| 一致性算法 | Raft（简洁、易理解） | ZAB（类 Paxos） | Raft |
| API 风格 | gRPC + JSON/Protobuf | 自定义 TCP 协议 | HTTP API |
| Watch 机制 | 前缀 Watch，支持流式推送 | 单节点 Watch，需重连 | 长轮询 + 阻塞查询 |
| 性能（写吞吐） | ~10K ops/s（3 节点） | ~3K ops/s | ~5K ops/s |
| 云原生生态 | Kubernetes 默认存储 | Hadoop/Storm 生态 | HashiCorp 生态 |
压测前提：etcd 的强一致性写入性能受磁盘 I/O 和网络延迟影响显著。在压测脚本设计时，必须关注 fsync 策略（如 SSD vs HDD）、集群节点数以及客户端连接数对吞吐量的影响。
1.5 本章小结
etcd 以 Raft 共识算法为基石，提供了强一致性、高可用的分布式键值存储能力。其简洁的 gRPC v3 API、高效的 Watch 机制和灵活的租约系统，使其成为服务发现、配置中心和分布式锁的首选组件。在接下来的课程中，我们将基于 v3 API 开发 Go/Python 客户端，并设计针对这些场景的压测脚本，深入理解 etcd 的性能边界。