2. etcd 基础概念
2.1 etcd 是什么
etcd 是一个分布式、可靠的键值存储系统，用于在分布式系统中存储关键配置数据和服务发现信息。它由 CoreOS 团队使用 Go 语言开发，现已成为云原生计算基金会（CNCF）的毕业项目。etcd 的核心定位是“分布式系统的协调层”，为集群中的多个节点提供一致性的数据访问能力。
一句话定义：etcd 是一个强一致性的分布式键值存储，常用于服务发现、配置管理和分布式锁。
2.2 核心特性
| 特性 | 说明 | 典型价值 |
|---|---|---|
| 强一致性 | 所有节点在同一时刻看到相同的数据视图，写入成功后所有后续读取都能读到最新值 | 避免分布式系统中的数据冲突和脏读 |
| 高可用 | 基于 Raft 协议，容忍少数节点故障（3 节点集群可容忍 1 台宕机） | 保障生产环境持续可用，不因单点故障丢失数据 |
| 键值存储 | 提供简单的 key-value 接口，支持目录结构（类似文件系统） |
易于理解和使用，适合存储配置、元数据 |
| Watch 机制 | 客户端可以监听某个键的变化，当键值变更时实时收到通知 | 实现服务发现、配置动态更新 |
| 租约（Lease） | 支持键绑定 TTL 自动过期，用于心跳和临时节点 | 健康检查、服务注册自动摘除 |
| 事务与 CAS | 支持比较-交换（Compare-And-Swap）和轻量级事务 | 分布式锁、选主等协调场景 |
2.3 Raft 协议简介
Raft 是一种易于理解的分布式共识算法，etcd 使用它来实现强一致性和高可用。Raft 将节点分为三种角色：Leader（领导者）、Follower（跟随者） 和 Candidate（候选者）。
- Leader：负责处理所有客户端写入请求，并将日志复制到 Follower 节点。
- Follower：被动接收 Leader 的日志复制，响应 Leader 和 Candidate 的请求。
- Candidate：当 Follower 超时未收到 Leader 心跳时，转为 Candidate 发起选举。
Raft 的核心流程分为三个子问题：Leader 选举、日志复制、安全性。etcd 在 Raft 基础上增加了 Multi-Raft 支持，允许一个 etcd 进程管理多个 Raft 组，提升资源利用率。
2.4 应用场景
etcd 在云原生和分布式系统中扮演着关键角色，以下是几个典型应用场景：
| 场景 | 具体用途 | 代表案例 |
|---|---|---|
| 服务发现 | 服务启动时注册自身地址到 etcd，客户端通过 Watch 机制实时获取可用服务列表 | Kubernetes 使用 etcd 存储 Pod、Service 的元数据 |
| 配置中心 | 集中存储应用配置，配置变更时通过 Watch 推送到所有客户端 | 微服务架构中的动态配置管理 |
| 分布式锁 | 利用 etcd 的 CAS 和租约机制实现跨节点的互斥锁 | 任务调度、选主（Leader Election） |
| 元数据存储 | 存储集群状态、拓扑信息、调度策略等关键元数据 | Kubernetes 集群状态、CNI 网络插件配置 |
| 分布式队列 | 基于有序键和 Watch 实现轻量级任务队列 | 异步任务分发、事件驱动架构 |
压测视角：在后续章节构建压测沙盘时，需要重点关注 etcd 的 写入吞吐（受 Raft 日志复制延迟影响）和 Watch 推送性能（大量客户端监听时的扇出压力），这两项是压测的核心指标。
2.5 架构概览
etcd 的内部架构分为多层：API 层（gRPC + HTTP）、Raft 层（共识引擎）、存储层（BoltDB 持久化 + 内存索引）。理解这些层次有助于在压测时定位瓶颈。
压测注意：etcd 的写入性能受 Raft 多数派确认延迟限制，3 节点集群的写入延迟通常比读取高 2-5 倍。压测时务必区分读写场景，单独测量 Put 和 Range 操作的 QPS 与延迟分布。