1. 课程导论：etcd在分布式系统中的核心作用、为什么需要压测、课程目标与学习路径
1.1 etcd在分布式系统中的核心作用
etcd 是一个高可用的分布式键值存储系统，由 CoreOS 开发并采用 Raft 共识算法保证数据一致性。在云原生和微服务架构中，etcd 扮演着“分布式系统基石”的角色，是集群状态与配置信息的唯一可信来源。
| 核心能力 | 说明 | 典型场景 |
|---|---|---|
| 服务发现 | 服务实例启动后向 etcd 注册自身地址与健康状态，客户端通过 watch 机制实时感知服务变化 | Kubernetes 中 kube-apiserver 通过 etcd 获取 Pod/Service 列表 |
| 配置管理 | 将集群配置、应用参数、feature flag 集中存储在 etcd 中，支持原子更新与版本回退 | Kubernetes ConfigMap/Secret 的底层存储 |
| 分布式锁 | 基于租约（Lease）和事务（Txn）实现跨节点的互斥操作，防止并发冲突 | 选主（Leader Election）、任务调度、资源分配 |
| 元数据存储 | 存储集群拓扑、网络策略、资源配额等关键元数据，要求强一致性与持久化 | Kubernetes 集群状态、容器网络插件（如 Calico）的策略存储 |
关键认知： etcd 是分布式系统的“控制面数据库”。一旦 etcd 出现性能瓶颈或故障，整个集群的控制平面将不可用，直接影响业务 Pod 的调度、扩缩容、服务发现与配置更新。
1.2 为什么需要压测
etcd 的性能瓶颈往往在极端负载下才会暴露。在生产环境中，etcd 需要同时处理大量并发读写、watch 事件推送、租约续期等操作。如果没有经过充分的压测，以下风险随时可能爆发：
- 请求延迟飙升： 当 QPS 超过集群处理能力时，读写延迟从毫秒级恶化到秒级，导致控制面组件超时重试，形成恶性循环。
- Raft 选举风暴： 高负载下节点心跳超时，触发频繁 Leader 选举，集群进入“抖动”状态，短暂不可用。
- 存储空间爆炸： 大量历史版本未及时压缩（Compact），导致磁盘空间耗尽，集群只读。
- Watch 事件堆积： 客户端 watch 数量过多或处理过慢，导致 etcd 内存持续增长，最终 OOM。
- 租约过期连锁反应： 高并发租约续期失败，导致大量 key 自动删除，服务注册信息丢失。
压测的核心目的： 不是“跑个好看的数字”，而是找到 etcd 集群的性能拐点与脆弱边界，为容量规划、限流配置、架构优化提供数据依据。
1.3 课程目标与学习路径
本课程以“压测复盘”为主线，从工具选型、场景设计、指标采集到瓶颈定位与优化落地，完整覆盖 etcd 压测的全生命周期。
| 模块 | 核心内容 | 产出物 |
|---|---|---|
| 基础篇 | etcd 架构、Raft 原理、存储模型、关键配置 | 压测前的知识储备清单 |
| 工具篇 | benchmark、ghz、k6、自定义压测工具对比与选型 | 压测工具选型决策表 |
| 场景篇 | 读写混合、watch 风暴、租约压力、大 key 写入等场景设计 | 压测场景模板库 |
| 指标篇 | 延迟、吞吐、错误率、磁盘 IO、网络、Raft 指标采集与分析 | 压测指标看板配置 |
| 复盘篇 | 瓶颈定位方法论、优化策略、限流与扩容方案 | 压测报告模板与优化 checklist |
学习建议： 本课程适合有一定分布式系统基础、正在或即将负责 etcd 运维与性能保障的工程师。建议在学习过程中搭建一套最小 etcd 集群（3 节点），跟随课程动手执行压测场景，效果最佳。
1.4 课程核心收益
完成本课程后，你将具备以下能力：
- 独立设计 etcd 压测方案： 根据业务场景选择合适的压测工具、参数与负载模型。
- 精准定位性能瓶颈： 通过指标关联分析，快速区分 CPU、内存、磁盘、网络或 Raft 层面的瓶颈。
- 制定优化策略： 从配置调优、集群扩容、限流降级、客户端优化等维度给出可落地的改进方案。
- 输出专业压测报告： 包含场景描述、指标数据、瓶颈分析、优化建议的结构化报告，直接用于团队决策。
接下来，我们将从 etcd 的架构与存储模型开始，逐步深入压测的每一个环节。