【分布式系统百科】etcd 深度解剖：从 Watch 机制到 MVCC 存储引擎
内容提要
本文深入剖析etcd核心机制：Watch通过持久连接与Revision追溯保证事件不丢；Lease管理TTL与自动清理；MVCC采用treeIndex与BoltDB双层架构支持历史回溯；与Raft联动确保一致性。在Kubernetes中，etcd作为唯一持久化后端，Watch驱动控制循环。文章还涵盖性能调优、容量限制及适用场景，指出etcd适合小数据量、强一致性的协调场景。
延伸解读
Watch 机制对比：etcd 与 ZooKeeper 的取舍
etcd 的持久 Watch 与 ZooKeeper 的一次性 Watch 形成鲜明对比。ZooKeeper 在通知与重新注册之间可能丢失事件，而 etcd 通过 Revision 追溯保证不丢。但持久 Watch 也带来新的运维挑战：客户端需记录并处理 ErrCompacted 错误，否则需全量重同步。理解这一差异，有助于在选型时权衡事件可靠性与实现复杂度。
Lease 的隐藏风险：Leader 切换与 TTL 重置
Lease 的 KeepAlive 不经过 Raft，是纯本地操作，这带来一个微妙问题：Leader 切换时，新 Leader 可能不知道已发生的续约，导致 Lease 提前过期。etcd 3.4 引入的 Lease Checkpoint 机制缓解了 TTL 重置问题，但并未完全消除风险。对于依赖 Lease 精确过期时间的系统，需评估此行为的影响。
MVCC 存储：内存与磁盘的双重代价
etcd 的 MVCC 引擎通过 treeIndex（内存）和 BoltDB（磁盘）双层结构支持历史回溯，但代价是内存占用随 key 和 revision 数量增长，磁盘空间需定期压缩和碎片整理。压缩只标记空闲页，不归还磁盘空间，需手动 defrag。这解释了为何 etcd 不适合海量数据存储，以及为何容量规划需谨慎。
性能调优的关键：磁盘 IOPS 与超时配置
etcd 写入性能受磁盘 fsync 延迟限制，官方建议使用 SSD 并监控 WAL fsync 和 backend commit 延迟。网络延迟影响 Raft 超时设置，heartbeat-interval 应约为 RTT 的 0.5-1.5 倍，election-timeout 为其 10 倍。合理配置这些参数，可避免频繁选举和性能退化。
Q&A
etcd 的 Watch 机制如何保证事件不丢失？
etcd 的 Watch 是持久的，通过全局递增的 Revision 实现历史追溯。客户端可以指定从任意 Revision 开始监听，即使断开重连，只要记住上次的 Revision，就能从 Revision+1 继续，不会错过事件。但前提是历史 Revision 未被压缩，否则会返回 ErrCompacted 错误。
etcd 的 MVCC 存储引擎是如何工作的？
etcd 的 MVCC 存储引擎采用双层架构：内存中的 treeIndex（B 树）将 key 映射到 keyIndex，记录所有历史 Revision；磁盘上的 BoltDB（B+ 树）以 Revision 为 key 存储 KeyValue。写入时创建新版本，旧版本保留直到压缩。读取时先查 treeIndex 获取最新或指定 Revision，再查 BoltDB 获取数据。
etcd 的 Lease 机制是什么？有什么用途？
Lease 是 etcd 提供的带 TTL 的资源，可以附加多个 key。当 Lease 到期且未续约时，所有关联 key 自动删除。典型用途包括服务注册与发现、分布式锁、Leader 选举和临时配置管理。客户端通过 KeepAlive 定期续约，若实例崩溃则 Lease 过期，key 自动清理。
etcd 如何与 Raft 共识协议联动？
etcd 的写入路径：客户端发送请求到 Leader，Leader 将操作封装为 Raft 日志条目，通过 Raft 复制到多数派节点并提交，然后 apply 到 MVCC 存储，同时通知 Watcher。读取支持 Serializable（可能过期）和 Linearizable（默认，通过 ReadIndex 协议保证最新）。Raft 日志与 MVCC 操作通过 InternalRaftRequest 映射，apply 串行执行保证 Revision 全局有序。
etcd 在 Kubernetes 中扮演什么角色？
etcd 是 Kubernetes 的唯一持久化后端，存储所有集群状态。kube-apiserver 是唯一直接与 etcd 通信的组件，其他组件通过 API 间接访问。Kubernetes 的控制循环依赖 etcd 的 Watch 机制，例如 Deployment 控制器通过 Watch 感知副本数变化并调谐。Informer 机制在 apiserver 侧缓存 Watch 事件，降低 etcd 负载。
etcd 有哪些性能调优手段？
性能调优包括：使用 SSD 保证磁盘 IOPS，监控 WAL fsync 和 backend commit 延迟；将 WAL 放在独立磁盘；调整 heartbeat-interval 和 election-timeout 适应网络 RTT；调整 snapshot-count 平衡追赶速度和 IO 开销；客户端使用连接池、前缀 Watch 和事务批量操作。
etcd 的容量限制是什么？如何应对？
etcd 默认存储限制 2GB，最大可配置 8GB（--quota-backend-bytes）。达到限制后拒绝写入。应对措施包括：定期压缩（compaction）清理历史版本，碎片整理（defrag）回收磁盘空间，以及通过分片（如将 events 分离到独立集群）或使用 Kine 等替代方案。
etcd 不适合哪些场景？
etcd 不适合：大量数据存储（超过 GB 级）、高写入吞吐（单 Leader 和 BoltDB 单写入者限制）、大 value 存储（建议不超过 1.5MB）、消息队列（无消费者组等特性）、频繁全量扫描。它最适合小数据量、强一致性、需要 Watch 的协调场景，如配置管理、服务发现、分布式锁。
