[!info] related notes

• 所属 MOC：Backend 常用中间件与基础设施 MOC、Distributed Systems MOC
• 前置：一致性模型、Leader Election、分布式锁
• 对比：Apache ZooKeeper、Redis

etcd

[!abstract] 一句话定位 etcd 是面向分布式协调元数据的强一致、持久化 Key-Value Store，提供 Revision、Watch、Lease、Transaction、Election 和 Lock 等原语。它适合存小而关键、必须有明确顺序的状态，不适合承载大规模业务数据或高吞吐事件流。

核心数据模型

/service/api/instance-1 → endpoint metadata
/config/payment/version → 42
/election/scheduler     → node-3

每次修改都会推进全局 Revision：

Revision
→ cluster state machine 的单调逻辑版本

Revision 可用于事件排序、Watch 恢复、Compare-and-Swap 和 Fencing。

Raft 与写入链路

Client Write
→ Raft Leader
→ replicate log to quorum
→ commit
→ apply state machine
→ response

客户端收到成功响应时，操作已经通过共识提交。etcd 通过单个一致性复制组换取全局有序 Revision；这也意味着它不是通过 Sharding 扩展到 TB 级业务数据库的系统。

读一致性

etcd 的 KV 操作默认提供严格的可串行化保证；常用默认读路径可获得线性一致结果。

为了降低延迟和协调成本，也可以请求 Serializable Read，但它可能从本地成员读到相对 Quorum 较旧的数据。

Linearizable Read → 更强新鲜度，需活跃共识确认
Serializable Read → 更低协调成本，允许 stale

设计时必须明确该元数据是否允许读旧。

Watch

Watch 从指定 Revision 订阅 Key / Range 的变化：

Watch /config/service-a from revision 100
→ PUT at 101
→ DELETE at 102
→ client receives ordered events

Watch Event 按 Revision 有序，但 Watch 本身不是线性一致读。正确模式通常是：

initial KV read + revision
→ start watch from next revision
→ apply ordered events
→ on compaction / gap, re-read current state

不要把 Watch 当“绝不会漏、永远实时”的消息队列。

Lease

Lease 是带 TTL 的存活与所有权原语：

Grant Lease
→ Attach Key
→ KeepAlive
→ Lease expires / revoked
→ attached keys deleted

适合服务注册、临时成员、Leader Ownership 和 Lock Key。

[!warning] Lease 不是永久互斥 Server 可能已撤销 Lease，而旧 Client 因暂停或网络分区仍在执行。保护 etcd 外部资源时，下游必须用 Revision / Epoch / Fencing Token 拒绝旧 Owner。

Transaction 与 Compare-and-Swap

etcd Transaction 可以根据 Value、Version、Create Revision、Mod Revision 等条件选择操作：

IF mod_revision == expected
THEN Put(new_value)
ELSE return conflict

可用于：

• 配置的乐观并发更新；
• Leader Election；
• Lock / Ownership；
• 状态迁移和版本验证。

它只保证 etcd Keyspace 内的原子条件操作，不能自动把外部数据库或 API 纳入同一事务。

三个典型协调模式

服务发现

instance starts
→ Put /services/api/<id> with Lease
→ KeepAlive

client / gateway
→ initial list + Watch
→ maintain local endpoint set

Leader Election

候选者围绕一个 Election Prefix 竞争；获胜者拿到与 Session / Lease 关联的 Leadership。新 Leader 仍应携带 Epoch / Revision 操作外部资源。

Distributed Lock

Lock API 适合减少并发竞争，但对外部资源的严格互斥仍依赖 Version Validation / Fencing。完整边界见 分布式锁。

etcd、Redis 与 ZooKeeper

系统	核心定位	关键模型
etcd	强一致协调元数据	KV、Revision、Watch、Lease、Txn、Raft
Redis	低延迟数据结构与短期状态	Rich Types、TTL、Replication、Cluster
ZooKeeper	层级协调命名空间	ZNode、Session、Ephemeral/Sequential、Watch

不要因为三者都有 Key/Value 或 Lock 能力就视为可互换。

适用与不适用

适合：

• Kubernetes / Controller Metadata；
• 配置和成员关系；
• Leader Election；
• 小规模强有序状态；
• 分布式协调原语。

不适合：

• 订单、聊天记录等大量业务数据；
• Cache；
• 高吞吐 Event Log；
• 图片、模型、备份等大对象；
• 高频大 Value 更新。

运维与维护

Cluster Size

常见 3 或 5 个 Voting Members。更多成员增加故障容忍上限，也增加共识延迟与运维成本。

Compaction 与 Defragmentation

Compaction
→ 丢弃旧 Revision 的可读历史

Defragmentation
→ 将内部空洞真正归还给文件系统

Defrag 是逐成员操作，可能阻塞该成员读写，应纳入维护窗口和容量计划。

Snapshot

定期 Snapshot 用于逻辑误操作、损坏或灾难恢复；必须验证 Snapshot 状态并实际演练恢复。

观测重点

leader changes / has leader
proposal commit and apply latency
peer round-trip latency
DB size / quota / NOSPACE alarm
watch count and slow watchers
lease count / expiry behavior
fsync and disk latency
member health / quorum

面试掌握标准

• KV、Revision、Watch、Lease、Txn；
• Raft Leader / Quorum / Commit 的作用；
• Linearizable 与 Serializable Read；
• Watch 为什么不等于线性一致读；
• Lease 为什么不能单独保护外部资源；
• Compaction、Defrag 与 Snapshot 的区别；
• 与 Redis、ZooKeeper 的边界。

官方资料

• API guarantees: https://etcd.io/docs/v3.6/learning/api_guarantees/
• API / Watch / Lease: https://etcd.io/docs/v3.6/learning/api/
• Why etcd / coordination boundaries: https://etcd.io/docs/v3.6/learning/why/
• Maintenance: https://etcd.io/docs/v3.7/op-guide/maintenance/

Related notes

• Distributed Systems MOC
• 分布式锁
• Apache ZooKeeper