1. 课程导论：etcd在云原生中的核心地位、Raft协议的价值、压测沙盘的整体架构与学习路径
1.1 etcd：云原生世界的“状态中枢”
在云原生技术栈中，etcd 扮演着不可替代的“状态中枢”角色。它不仅是 Kubernetes 控制平面的持久化存储后端，更是整个分布式系统一致性与可靠性的基石。理解 etcd 的定位，是进行性能压测与瓶颈定位的前提。
| 应用场景 | 核心作用 | 性能敏感度 |
|---|---|---|
| Kubernetes 控制面 | 存储集群状态、Pod/Service/ConfigMap 等所有资源对象 | 极高：直接影响调度、编排、API Server 响应 |
| 服务发现与配置中心 | 提供强一致的分布式键值存储，支持 Watch 机制 | 高：Watch 延迟影响服务感知速度 |
| 分布式锁与选主 | 基于 Lease 和 Revision 实现分布式协调 | 中高：锁竞争与 TTL 精度影响业务稳定性 |
| 元数据存储 | 存储网络配置、容器运行时状态等关键元数据 | 中：读写延迟影响系统初始化与恢复速度 |
关键认知：etcd 的性能瓶颈往往不是 CPU 或内存的不足，而是 Raft 协议带来的网络开销、磁盘 I/O 延迟以及 Follower 节点同步滞后。压测沙盘正是为了系统性地暴露这些瓶颈而设计。
1.2 Raft 协议：分布式一致性的工程化答案
Raft 协议是 etcd 实现强一致性的核心引擎。它将复杂的分布式共识问题分解为三个关键子问题：Leader 选举、日志复制、安全性。理解 Raft 的运作机制，是定位 etcd 性能瓶颈的钥匙。
- Leader 选举：集群通过心跳超时机制选举出唯一的 Leader，所有写请求必须经过 Leader。
- 日志复制：Leader 将客户端请求封装为日志条目，并行复制到所有 Follower，等待多数派（Quorum）确认后才提交。
- 安全性：通过 Term 和 Index 保证日志的连续性，确保已提交的日志不会被覆盖。
性能启示：Raft 的“多数派写入”机制决定了 etcd 的写性能上限受限于网络往返时间（RTT）和磁盘 fsync 延迟。压测时，Quorum 延迟是最核心的观测指标。
1.3 压测沙盘：整体架构与设计哲学
本课程打造的“压测沙盘”并非简单的压测工具使用教程，而是一套从原理到实践、从指标到根因的完整分析框架。其整体架构分为四个层次：
| 层次 | 核心组件 | 学习目标 |
|---|---|---|
| 压测层 | 自定义压测客户端、分布式负载发生器 | 掌握不同负载模型（读写混合、Key 分布、并发数）对 etcd 的影响 |
| 观测层 | Prometheus + Grafana 监控、etcd 内置 metrics、pprof 性能剖析 | 学会从延迟、吞吐、错误率、资源使用率四个维度量化性能 |
| 分析层 | Raft 日志追踪、磁盘 I/O 分析、网络延迟模拟 | 定位瓶颈是 Leader 过载、Follower 滞后、磁盘慢还是网络抖动 |
| 调优层 | 参数调优、集群拓扑调整、硬件选型建议 | 基于瓶颈定位结果，给出可落地的优化方案 |
避坑提示：很多工程师在压测时只关注 QPS 和 P99 延迟，忽略了 Raft 协议层面的指标（如 proposal 提交延迟、心跳间隔、snapshot 触发频率）。本沙盘将强制你关注这些“隐藏”指标。
1.4 学习路径与前置要求
本课程采用“原理 → 实验 → 分析 → 调优”的螺旋式学习路径。建议按以下顺序推进：
- 基础夯实：掌握 Raft 协议核心流程（选举、日志复制、安全性），理解 etcd 的存储引擎（BoltDB / bbolt）与 MVCC 机制。
- 环境搭建：使用 Docker Compose 或 Kind 快速部署 3 节点 etcd 集群，配置 Prometheus + Grafana 监控栈。
- 压测实战：运行预设的压测场景（纯写、读写混合、热点 Key 竞争、网络分区模拟），采集性能数据。
- 瓶颈定位：结合 Raft 指标（proposal 提交延迟、心跳超时次数、snapshot 持续时间）与系统指标（磁盘 IOPS、网络带宽、CPU 上下文切换）进行根因分析。
- 优化验证：应用调优策略（如调整心跳间隔、优化磁盘挂载参数、使用 SSD、调整批量大小），重新压测验证效果。
前置要求：具备基本的 Go 语言阅读能力（能看懂 etcd 关键代码片段）、熟悉 Linux 性能工具（iostat、perf、tcpdump）、了解 PromQL 基础语法。课程会提供完整的 Docker 镜像和压测脚本，降低环境门槛。