etcd面试题：标准回答与原理跳转
本页只保留标准回答、追问点和精确知识链接；详细流程、Demo和Runbook统一放在etcd原理页。
高频问题
| 问题 | 标准回答 | 原理页 |
|---|---|---|
| etcd是什么 | etcd是使用Raft复制、提供MVCC、Txn、Watch和Lease的强一致键值存储，常用于Kubernetes控制面、服务发现、配置和协调。 | 定位、架构 |
| etcd写请求怎么走 | 写请求由Leader排序为Raft日志，复制到多数派后提交，再按序Apply到MVCC/Backend，产生全局revision并通知Watch。Leader本地追加不等于提交。 | 写链路 |
| Raft index和revision一样吗 | 不一样。Raft index属于共识日志，revision属于MVCC键空间逻辑版本；它们可能相关推进，但不是同一抽象或稳定一一映射。 | Raft与MVCC |
| revision和Key version区别 | revision是整个键空间修改事务的全局逻辑版本；Key version是当前Key生命周期修改次数。一个Txn改多个Key可共享同一revision，Key删除重建后version重新开始。 | MVCC、Key元数据 |
| 默认Range是什么一致性 | etcd v3 Range默认线性一致，需要确认Leader仍有多数派领导权并读取到安全Apply位置；代价高于可直接本地读取的Serializable模式。 | 线性一致读 |
| Serializable读是数据库可串行化吗 | 不是。etcd Serializable Range可从本地状态返回，结果可能陈旧；不能用于锁、选主和关键所有权裁决。 | Serializable读 |
| Txn怎样避免先查后写竞态 | 在同一Txn中比较version/mod_revision，成立才Put，失败分支读取已有状态；比较和写由etcd原子裁决。 | Txn、原子创建 |
| Watch怎样保证List后不漏事件 | List/Range先取得快照及Header revision R，原子发布本地快照，再从R+1 Watch；分页List也应固定revision R。 | List-Watch |
| Watch提示revision compacted怎么办 | 旧历史已不可恢复，应停止从旧revision重连，重新分页List最新快照R，原子替换本地状态，再从R+1 Watch。 | Compaction、Watch Runbook |
| Compaction和Defrag区别 | Compaction让旧MVCC revision不再可读；Defrag整理Backend空闲页并回收物理空间。Compaction后DB文件不一定缩小，Defrag应逐Member执行。 | Compaction、Defrag |
| Lease怎样工作 | Client Grant获得Lease并把Key绑定，KeepAlive续租；超过TTL后Leader撤销Lease并删除附着Key，产生Watch删除事件。Lease不是精确定时器。 | Lease、Lease边界 |
| KeepAlive成功是否代表服务健康 | 不代表，只说明注册客户端近期能续租；业务端口、数据库、线程池仍可能失败，需要readiness、主动探测、超时和熔断。 | 服务发现 |
| etcd锁为什么仍需Fencing | Lease过期后旧客户端可能从暂停中恢复，新持有者已取得锁；外部数据库必须比较create revision等单调Token并拒绝旧值。 | 锁、Fencing |
| NOSPACE怎么恢复 | 先确认DB size/in-use和增长源，对安全revision Compaction，再逐Member Defrag，确认低于quota后解除alarm，不能只反复disarm。 | Quota |
| 成员怎样安全替换 | 健康集群先加Learner，等追平后Promote为投票成员，确认稳定再移除旧Member；一次一个，不能同时替换多数。 | 成员变更 |
| Snapshot恢复要注意什么 | Restore创建新逻辑集群和data-dir；需按版本处理revision回退、Watch缓存失效、成员身份、TLS和Kubernetes兼容，恢复后验证控制器重新List。 | Snapshot、Restore |
| 为什么不能直接修改Kubernetes的etcd | 会绕过API Server认证、授权、Admission、版本转换、审计和对象校验，破坏控制器假设；正常操作必须走Kubernetes API。 | Kubernetes边界 |
项目回答模板
我会把etcd定位为控制面强一致KV，而不是业务缓存。写入经Raft多数派提交后Apply到MVCC，一次事务产生全局revision；配置和注册发现使用“List固定revision快照 + 从R+1 Watch”，Watch被Compaction就全量重建。实例Key绑定Lease并KeepAlive，但业务健康另做readiness。锁使用Txn和Lease，外部写入携带Fencing Token。运维重点监控Leader变化、WAL fsync、Backend commit、applied lag、DB/quota、Watch重建和Lease过期，成员替换先Learner追平再Promote，并定期做Snapshot Restore演练。
常见错误回答纠正
| 错误回答 | 正确说法 |
|---|---|
| revision就是Key修改次数 | Key version才是当前生命周期修改次数，revision是全局事务版本 |
| Follower读一定最新 | Serializable本地读可能陈旧，默认线性一致读需安全读确认 |
| Watch永远可以续接 | revision被Compaction后必须重新List |
| Compact会缩小DB | 通常还需逐Member Defrag回收物理空间 |
| Lease保证业务健康 | KeepAlive只表示租约客户端存活链路 |
| etcd锁绝对安全 | 外部资源仍需Fencing和幂等 |
本章小结
面试回答etcd时，应沿“Raft → MVCC revision → 线性读 → Txn → List-Watch → Compaction/Defrag → Lease → Fencing → Snapshot恢复”展开，并始终区分共识、存储历史、客户端缓存和业务正确性。