1. 课程导论：etcd限流背景、为什么需要客户端QPS控制、课程目标与前置知识

1.1 为什么需要为 etcd 做请求限流？

etcd 是云原生架构中的关键元数据存储组件，Kubernetes、服务发现、分布式锁等核心能力都依赖其强一致性与高可用性。然而，etcd 并非无限吞吐的“黑盒”——它的性能受限于底层 Raft 共识算法的日志提交速率、磁盘 I/O 以及内存索引结构。当客户端请求量超过集群的处理能力时，会出现以下连锁问题：

• Raft 日志堆积：Leader 节点需要将每个写请求同步到多数 Follower，过高的 QPS 会导致 Raft 日志条目积压，增加磁盘写入压力与网络延迟。
• 内存膨胀与 OOM：etcd 的 MVCC 存储引擎会在内存中维护多版本数据，高并发写入会迅速消耗内存，触发 OOM Killer。
• 请求超时与级联故障：当 etcd 响应变慢，客户端（如 kube-apiserver）的重试机制会进一步放大流量，形成“请求风暴”，最终导致集群不可用。
• 租约续期失败：Leader 选举、分布式锁等依赖租约机制，限流不足可能导致租约无法及时续期，引发服务中断。

1.2 为什么需要客户端 QPS 控制？

etcd 服务端内置了 --max-request-bytes、--quota-backend-bytes 等粗粒度限制，但这些机制存在两个关键盲区：

1. 服务端限流是“事后”防御：当请求已经到达 etcd 进程并开始处理时，CPU 和内存资源已被消耗。服务端限流只能拒绝过量请求，无法避免资源浪费。
2. 缺乏客户端视角的精细化控制：不同业务模块对 etcd 的访问模式差异很大——监控组件可能每秒写入数百个 key，而调度器只做低频读取。服务端无法区分“正常突发”与“异常流量”，容易误杀合法请求。

客户端 QPS 控制将限流决策前置到应用层，带来三个直接收益：

1.3 课程目标

本课程旨在帮助学员掌握从理论到实战的 etcd 请求限流全链路技能。完成学习后，你将能够：

• 理解 etcd 限流架构：掌握 etcd 服务端限流（如 --max-txn-ops、--max-request-bytes）与客户端限流的区别与适用场景。
• 实现客户端 QPS 控制：使用 Go 语言编写基于令牌桶、漏桶或滑动窗口的限流中间件，集成到 etcd 客户端调用链中。
• 设计并执行压测方案：使用 ghz、wrk 或自定义压测工具，模拟不同 QPS 场景，采集延迟、错误率、Raft 指标等关键数据。
• 分析压测结果并调优：通过 etcd 内置指标（如 etcd_server_leader_changes_seen_total、etcd_disk_wal_fsync_duration_seconds）定位限流阈值，并调整限流参数。
• 构建生产级限流策略：结合熔断、背压、优先级队列等模式，设计适应高可用环境的限流方案。

1.4 前置知识

为了顺利学习本课程，建议你具备以下基础：

1.5 课程知识体系总览

下图展示了本课程的核心知识模块及其关系。从限流背景出发，依次覆盖客户端限流实现、压测方案设计、结果分析与生产调优，最终形成完整的实战闭环。

1.6 课程章节速览

本课程共 30 章，按“基础→实现→压测→调优→生产”五阶段组织。下表列出了各阶段的核心章节与产出物：