那些被 etcd 教会我的事

很多工程师对 etcd 的认知停留在"K8s 用的 KV 存储"。但当你认真读它的设计与代码，会发现它是一份"分布式系统教科书"。本文整理我从 etcd 里学到的几件事。

Raft 不是"复制状态机"那么简单

etcd 用 Raft 做复制。Raft 的核心三件事：leader election、log replication、safety。但 etcd 在工程上做了很多细节：

• Pre-vote：避免网络分区恢复时频繁触发选举。
• ReadIndex：线性一致读不写日志，但需要 leader 心跳确认。
• Batch + Pipeline：多个 proposal 合并 + 流水线发送，吞吐显著提升。

理解这些细节，是理解"为什么 etcd 能扛住 K8s 的元数据压力"的关键。

Lease：etcd 最被低估的设计

Lease 是 etcd 实现的"带 TTL 的 key"。它的本质是"到期自动失效的合约"。在分布式系统里，lease 解决的是"如何在不依赖时钟同步的前提下，约定一段时间内的承诺"。

Lease 是分布式系统的"时间抽象"。它把"何时过期"这种全局时钟问题，转化为"leader 心跳续约"这种局部协议问题。

K8s 用 etcd lease 做 node heartbeat：每个 kubelet 持有一个 lease，每 10 秒续约一次。如果续约断了，controller-manager 等待 lease 过期后判定 node notReady。整个过程不依赖任何全局时钟。

Watch：把"变更通知"做成产品

etcd 的 watch 是它的杀手锏。它不是简单的 pub/sub，而是"基于 revision 的事件流"。每个 key 的每次变更都有一个全局递增的 revision，watch 可以从任意 revision 开始重放。这意味着：

• 客户端断连重连后可以从上次的位置继续。
• 多个 watcher 看到的事件顺序一致。
• "当前值 + 历史变更"可以无缝衔接。

这套设计被 K8s 的 informer 完整继承。理解了 etcd watch，就理解了 K8s 控制循环的根基。

Compaction：被遗忘但致命的细节

etcd 默认保留所有历史 revision。如果不压缩，数据库会无限增长。我们曾遇到一个事故：K8s 集群跑了一年没压缩 etcd，db size 涨到 8GB，每次 list 操作都要扫全库，apiserver 拖垮整个控制面。

解决方法：定期 etcdctl compact + defrag。K8s 1.20+ 自动压缩，但老版本要手动。这件事让我学到："任何'保留所有历史'的设计都必须配压缩机制，否则只是延迟爆炸"。

性能：etcd 不是数据库

etcd 设计目标不是高吞吐，是低延迟 + 强一致。典型性能：

操作	延迟	建议 QPS
write	5–15ms	< 1000
read (serializable)	1–5ms	< 10000
read (linearizable)	5–15ms	< 1000
watch event	< 1ms	event-driven

把 etcd 当数据库用，QPS 超过几千就会出问题。它适合"元数据 + 配置 + 协调"，不适合业务数据。

运维上的几个细节

• 三节点起步，五节点更稳：能容忍 1 个/2 个节点挂。再多就是浪费。
• 磁盘决定性能：fsync 是 Raft 写入的瓶颈。用 NVMe SSD，不要用云盘。
• 网络要快：Raft 心跳与日志复制对延迟敏感，跨机房 etcd 要小心。
• 定期 defrag：compaction 只标记删除，defrag 才回收空间。
• 备份不能少：etcd snapshot 是 K8s 的最后防线。

从 etcd 看分布式系统设计

etcd 教会我的几条分布式系统设计原则：

1. 把"时间"问题转化为"协议"问题。Lease 就是这个思路。
2. 把"全局状态"转化为"事件流"。Watch 就是这个思路。
3. 用 revision 而不是 timestamp 做全局序。避免时钟同步问题。
4. 强一致是有限资源。不要把它当通用能力用。

给团队的简短建议

• 把 etcd 当"协调者"，不要当"数据库"。
• 用 lease 做 heartbeat、用 watch 做配置下发。
• 定期压缩 + defrag + snapshot。
• 读 etcd 源码比读 Raft 论文更接近工程现实。

etcd 不大，但它把分布式系统的核心问题（一致性、可用性、时间、变更通知）都做了一份工程化答案。读懂它，等于读完一本浓缩的分布式系统教材。