etcd 核心原理 专栏导览
专栏定位
本专栏聚焦 etcd 分布式键值存储的核心原理——从 Raft 共识协议的 Leader 选举与日志复制，到 MVCC 多版本存储引擎（BoltDB），再到 Watch 流式推送和 Lease TTL 机制。etcd 是 Kubernetes 集群的”大脑”——所有集群状态（Pod/Service/ConfigMap）都存储在 etcd 中。理解 etcd 的内部机制，是理解 Kubernetes 高可用和故障恢复的基础。
目标读者
- 运维 Kubernetes 集群需要理解 etcd 工作原理的 SRE/平台工程师
- 需要使用 etcd 做服务发现或分布式锁的后端开发者
- 对 Raft 共识协议和分布式存储引擎感兴趣的技术爱好者
专栏目录
| 序号 | 标题 | 核心内容 |
|---|---|---|
| 01 | 01 etcd 全局架构——Raft 共识与 MVCC 存储 | etcd 在 Kubernetes 中的角色、Client → gRPC → Raft → WAL → BoltDB 的请求链路、MVCC 的多版本语义 |
| 02 | 02 Raft 共识协议——Leader 选举、日志复制与安全性 | Raft 的三种角色（Leader/Follower/Candidate）、选举超时与任期（Term）、日志复制的 AppendEntries RPC、日志匹配与安全性保证、Joint Consensus 成员变更 |
| 03 | 03 存储引擎——BoltDB、WAL 与 Compaction | BoltDB 的 B+ 树存储、WAL 的持久化保证、历史版本的 Compaction 与碎片整理（Defragmentation）、Backend Quota 限制 |
| 04 | 04 Watch 与 Lease 机制 | Watch 的流式推送实现（Event History + Watch Store）、Lease 的 TTL 自动过期与续约、Lease 在服务发现和分布式锁中的应用 |
| 05 | 05 etcd vs ZooKeeper——设计哲学与选型对比 | 线性一致性读（Raft ReadIndex）vs 顺序一致性、gRPC vs 自定义协议、Watch 的多版本 vs Watcher 的一次性、API 易用性与生态对比 |
| 06 | 06 etcd 运维——集群管理、备份恢复与性能调优 | 集群健康检查（endpoint health/status）、snapshot save/restore 备份恢复、磁盘 IOPS 要求与 SSD 推荐、告警（Alarm）机制与 quota 管理 |
推荐阅读路径
核心原理路径：01 → 02 → 03
应用与对比路径：04 → 05
运维路径：06
前置知识
- 分布式系统基础概念（CAP 定理、一致性模型）
- 建议对比阅读 ZooKeeper 专栏了解 ZAB 协议
- Kubernetes 基础知识有助于理解 etcd 的使用场景