etcd 基础概念
在搭建压测环境之前，必须先理解 etcd 的核心定位与设计哲学。etcd 是一个用于分布式系统的强一致性、高可用的键值存储系统，由 CoreOS 团队用 Go 语言开发，现已成为云原生生态中事实上的元数据存储标准。
etcd 是什么
etcd 的名字来源于两个词：“etc”（类 Unix 系统的配置文件目录）和 “d”（distributed，分布式）。它本质上是一个分布式的、可靠的键值数据库，专门用来存储分布式系统中那些“不能丢、不能错”的关键配置和状态信息。
一句话记忆：etcd 就是分布式系统的“大脑”——它存储了集群中谁是谁、服务在哪、配置是什么、锁在谁手里等核心元数据。
核心特性
etcd 的四大核心特性使其在云原生领域不可替代：
| 特性 | 说明 | 对压测的影响 |
|---|---|---|
| 强一致性 | 所有节点在任何时刻读到相同的数据，写入成功后所有客户端都能读到最新值 | 压测时写入延迟受 Raft 提交耗时影响，单节点与集群差异明显 |
| 高可用 | 集群模式下容忍少数节点故障（3 节点容忍 1 台宕机），服务不中断 | 压测需验证故障切换时的吞吐抖动和恢复时间 |
| 分布式键值存储 | 数据以 key-value 形式组织，支持目录结构（/a/b/c）和 TTL 自动过期 | 压测需关注 key 数量、value 大小对性能的影响 |
| Watch 机制 | 客户端可以监听 key 的变化，实现实时事件驱动 | 大量 Watch 连接会消耗服务端内存和 CPU，是压测重点 |
Raft 协议简介
etcd 的强一致性依赖 Raft 共识算法。Raft 将分布式一致性问题拆解为三个子问题：领导者选举（Leader Election）、日志复制（Log Replication）、安全性（Safety）。
在 etcd 集群中，Raft 的工作流程如下：
- 选举 Leader：集群启动或 Leader 宕机时，Follower 发起选举，获得多数票的节点成为 Leader。
- 客户端写入：所有写请求必须经过 Leader。Leader 将写操作封装为 Raft Log Entry，并行复制到所有 Follower。
- 提交确认：当 Leader 收到多数节点（例如 3 节点集群中的 2 个）的写入确认后，该 Entry 被标记为“已提交”，然后应用到状态机，返回客户端成功。
- 读取优化：etcd 默认使用 ReadIndex 或 Lease Read 机制保证线性一致性读，避免每次读都走一遍 Raft 日志。
压测关键点：Raft 的多数派写入机制决定了集群写入性能的上限。3 节点集群的写入延迟通常比单节点高 30%~50%，因为需要等待网络往返和磁盘 fsync。压测时务必关注
etcd_server_leader_designed_round_trip_latency_seconds 和 etcd_disk_wal_fsync_duration_seconds 指标。
典型应用场景
etcd 在云原生和分布式系统中扮演着三个核心角色：
| 场景 | 工作原理 | 压测关注点 |
|---|---|---|
| 服务发现 | 服务启动时在 etcd 注册自身地址（IP:Port），客户端通过 Watch 监听服务列表变化 | 大量服务注册/注销的吞吐量；Watch 连接数对内存的影响 |
| 配置管理 | 将配置以 key-value 形式存储在 etcd 中，应用通过 Watch 实时感知配置变更 | 大 value（>1MB）的读写性能；配置变更的传播延迟 |
| 分布式锁 | 基于 etcd 的 txn（事务）和 lease（租约）机制实现排他锁，支持锁续约和自动释放 |
锁竞争激烈时的吞吐量；锁超时和续约的可靠性 |
压测避坑提示：etcd 官方建议单个 value 不超过 1.5MB，超过此阈值会显著增加网络和磁盘 I/O 压力。在压测配置管理场景时，请严格控制 value 大小，否则可能触发 etcd 的
--max-request-bytes 限制（默认 1.5MB），导致请求被拒绝。
本章小结
etcd 的核心价值在于用 Raft 协议换来了强一致性和高可用，代价是写入性能受多数派提交机制的限制。在后续的压测沙盘搭建中，你将亲手验证单节点与三节点集群在吞吐量、延迟、故障恢复等方面的差异。理解这些基础概念，是后续配置压测参数、分析性能瓶颈的前提。