Etcd 通俗指南：分布式系统的"大脑"
如果说 Kubernetes 是分布式系统的操作系统，那么 etcd 就是这个操作系统的大脑（或者说是"注册表"）。
简单来说，etcd 是一个强一致性 的、分布式 的键值（Key-Value）存储系统。
1. 它是做什么的？(大总管的比喻)
想象一下，你有一个很大的部门（集群），有几百个员工（节点/服务）在干活。
大家都需要知道一些关键信息，比如：
- "现在的项目经理是谁？"
- "数据库的密码改成什么了？"
- "服务器 A 是不是挂了？"
如果没有 etcd：
- 员工 A 记在自己脑子里，员工 B 记在便签上。
- 项目经理换了，A 知道了，B 还不知道，去请示旧经理，结果乱套了。
Etcd 的角色 ：
它就是挂在办公室正中央的一块**"官方公告板"**。
- 权威性 ：任何配置、状态的变更，必须写在这块板子上才算数。
- 一致性 ：这块板子有魔法，它在所有分公司（分布式节点）都有分身，而且内容永远保持即时同步（底层依赖 Raft 协议）。
- 可靠性：就算哪怕几个分公司的板子被砸了，只要还剩下一半以上的板子在，数据就绝不会丢。
2. 它的三大必杀技
A. 强一致性 (The Source of Truth)
Etcd 最重要的特性就是**"稳"**。
- 它不追求极致的快（不像 Redis 那样每秒百万级读写）。
- 它追求的是数据绝对不丢、绝对不错。
- 当你向 etcd 写入一条数据
config=1并收到成功回复时，它保证你无论从集群的哪个角落去读，读到的永远是1。 - 这也是为什么 Kubernetes 把所有集群状态（Pod 跑在哪、有哪些 Service）都存在 etcd 里。
B. Watch 机制 (监听/订阅)
这是 etcd 最迷人的功能。普通的数据库是你去"问"它（Query），而 etcd 可以让你**"盯着"**它（Watch）。
场景：
- 应用 A ：我要盯着
/config/db-password这个 Key。 - 管理员 ：(修改了密码)
put /config/db-password = "new-pass-123" - Etcd：(立刻主动通知应用 A) "喂！你盯着的那个密码变了，新值是 new-pass-123！"
作用 ：这让分布式系统可以实时响应变化。比如 Kubernetes 中，当你修改了 Deployment 的副本数，Controller 是立马（通过 Watch）感知到并开始创建新 Pod 的，而不是轮询去查。
C. 分布式锁 (利用租约 Lease)
在多台机器争抢同一个资源时，etcd 可以充当裁判。
- 利用 etcd 的原子写入特性，谁先写入成功，谁就抢到了锁。
- 配合 Lease (租约/过期时间)：类似于"自动续租"。如果抢到锁的服务挂了，没办法续租，锁会自动过期释放，防止死锁。
3. Etcd vs Redis vs ZooKeeper
很多同学会问，我有 Redis 了，为什么要用 etcd？
| 特性 | Etcd | Redis | ZooKeeper |
|---|---|---|---|
| 核心定位 | 控制面数据 (配置、元数据) | 数据面数据 (缓存、业务数据) | 老牌协调服务 (Hadoop生态) |
| 一致性 | 强一致 (CP) | 默认为高性能 (AP/弱一致) | 强一致 (CP) |
| 开发语言 | Go (云原生宠儿) | C | Java (部署维护较重) |
| 存储数据量 | 小 (几GB级别)，存关键数据 | 大 (可存几十几百GB)，存海量数据 | 小 |
| 典型用途 | K8s后端、服务发现 | 缓存、排行榜、消息队列 | Hadoop/Kafka协调 |
总结：
- 如果你要存"用户的购物车、最近浏览记录"，用 Redis。
- 如果你要存"数据库的主节点是谁、服务的 IP 是多少、系统的核心配置"，用 etcd。
4. 常见误区
- "把它当数据库用"：千万别把业务日志、很大的 JSON 文档塞进 etcd。它对 Value 的大小很敏感（一般建议不超过 1MB），数据太多会把本来用于"心跳"和"选举"的带宽占满，导致集群不稳定。
- "不仅用于 K8s"：虽然它是随 K8s 火起来的，但任何需要"高可用配置中心"或"服务发现"的系统都可以单独使用 etcd。
关联阅读
- Raft 协议原理 (Etcd 底层就是基于 Raft 保证数据一致性的)