Etcd
etcd 是 CoreOS（现属 CNCF）开源的分布式键值存储——它用 Raft 共识算法保证强一致，专门为「分布式系统的配置存储、服务发现、协调元数据」而设计。etcd 本身不是注册中心，而是「构建注册中心与协调服务的底座」：它只提供原子读写 KV + Watch + Lease（租约），上层应用自己拼语义。最著名的身份是 Kubernetes 的唯一状态存储——K8s 把所有集群状态（Pod、Service、ConfigMap、Deployment）都存进 etcd，apiserver 是唯一的读写入口。理解 etcd，就理解了强一致分布式 KV 的本质：Raft 选主与日志复制、线性一致读、Watch 的 MVCC 多版本、Lease 做领导选举与存活——这是它区别于 Redis（内存 AP）、ZooKeeper（重型、ZAB）的核心。
etcd 的全部考点围绕三大机制展开：①Raft 共识（Leader 选举、日志复制、过半提交、脑裂防护）；②数据模型与一致性（MVCC 多版本、线性一致读、租约 Lease、事务 TXN）；③工程用法（K8s 底座、Watch 机制、命名服务、分布式锁）。本叶还覆盖读写一致性（stale read vs linearizable read）、leader election（用 Lease + compare-and-swap）、与 ZooKeeper 的历史背景对比（ZAB vs Raft、重型 vs 轻量、观察者节点）、以及与 Consul/Nacos 的边界（纯 KV 底座 vs 业务服务发现）。
评价
优点
- 强一致：Raft 保证所有写都过半复制，读可线性一致，是「绝不能丢/错数据」的元信息存储首选
- 轻量：单个 Go 二进制，HTTP/gRPC API，部署运维比 ZooKeeper（JVM 重型）简单
- Watch 实时：基于 MVCC 修订号的长轮询/流式 Watch，key 变化秒级推送，是 K8s 控制器的根基
- K8s 生态：作为 K8s 唯一状态存储，生态与文档密集，社区活跃（CNCF 毕业）
缺点
- 无业务语义：纯 KV，没有 Consul 那种「服务注册/健康检查/DNS」开箱能力，业务发现要自拼
- 写性能受 Raft 限制：每次写要过半 etcd 节点 ack，跨 DC 延迟敏感，不适合高频写
- 容量有限：设计目标「小而精」（官方建议几 GB 内），存大量业务数据要上专门的数据库
- 运维门槛：Raft 集群脑裂、备份恢复、压缩历史修订需要专业知识，比 Redis 单机复杂
本叶地图
- 入门 —— etcd 定义、Raft 共识核心、K8s 底座角色、MVCC/Lease/Watch、CP 定位
- Raft 共识与一致性 —— Leader 选举、日志复制、过半提交、脑裂防护、线性一致读、leader election
- Kubernetes 与工程用法 —— K8s 状态存储、Watch 机制、命名服务/分布式锁、与 ZooKeeper 对比
- 参考 —— Raft 术语速查、API 清单、一致性级别表、易错点、命令速查