【etcd】选型收束与开放问题：排除树与系列边界关闭
内容提要
本文是etcd生产内核系列终章，通过机制排除树指导选型：数据量小且需Watch/Lease时选etcd，否则转向TiKV或FoundationDB。明确etcd适用甜区（K8s控制面）与苦区（通用OLTP），列出否证条件如backend触顶、需水平分片等。回收姊妹系列指针，对比三系统机制差异，提出Watch背压、Lease fencing等开放问题，并给出ADR友好的收束建议。
延伸解读
排除树：从“看场景”到可证伪判据
本文用机制排除树替代模糊的“看场景”选型，每个分支都对应可验证的机制问题，如数据量是否fit单Raft组quota、Watch/Lease是否为一等语义。这种设计让选型决策可审计、可写入ADR，避免仅凭经验或海报QPS做判断。读者可对照自身场景，逐条回答判据，快速定位适用存储。
etcd的甜区与苦区：明确边界
文章清晰划出etcd的适用甜区：K8s控制面或等价协调场景，键空间在quota内、写入以元数据为主、依赖Watch有序追赶与Lease自动删键。苦区则包括通用OLTP、单key过大、百万key全量Range、需要水平分片等。理解这些边界有助于避免误用，例如将etcd当数据库或期望通过加节点提升写吞吐。
否证条件：何时必须放弃etcd
文章列出六条否证条件，如backend持续触顶、需要水平分片、跨key事务、Watch背压主导可用性等。这些条件可作为ADR中的硬性退出标准，一旦触发即应重跑排除树，而非因“已上线”而继续。这提醒读者，选型不是一次性决定，需持续评估机制是否仍匹配。
开放问题：选型后的运维与演进挑战
文章指出四个开放问题，包括Watch背压与Compaction的SLO量化、Lease fencing与K8s语义、quota触顶后的迁移路径、以及3.5到3.6/3.7的升级矩阵。这些问题尚无定论，需要测量或上游变更才能关闭。读者在采用etcd时，应关注这些领域，并准备应对策略，如监控指标、制定迁移预案。
Q&A
etcd 选型时，什么情况下应该选择 TiKV 或 FoundationDB？
当数据量或写入 churn 超出单 Raft 组 quota（约 2–8 GB backend）时，若需要水平分片和多键事务，且可接受快照隔离（SI），则选 TiKV；若需要严格可串行化（strict serializable）和 Layer 支持，则选 FoundationDB。
etcd 的甜区（适用场景）是什么？
etcd 的甜区是 K8s 控制面或等价协调场景：键空间在 quota 内，写入以元数据为主，强依赖 Watch 从指定 revision 有序追赶和 Lease 自动删键，团队能进行 compact/defrag/backup，版本钉在 v3.5.33 或发行版对齐的 3.5.x patch。
哪些情况表明不应该继续使用 etcd？
以下任一情况成立时，etcd 叶判负：backend 持续触顶或 alarm，compact/defrag 无法稳住 MVCC 轴；写入/churn 需要水平分片；需要跨 key 分布式事务；Watch 背压主导可用性且无法调 retention；编制撑不住五轴运维；必须 strict serializable 协调；误以为 FDB/TiKV 可无缝替换 K8s etcd。
etcd 与 TiKV、FoundationDB 在机制上有哪些主要差异？
扩展单位：etcd 是单 Raft 组，TiKV 是 Multi-Raft Region，FoundationDB 是角色+shard；协调原语：etcd 提供 Watch/Lease/Txn，TiKV 提供 KV+分布式 SQL 栈，FoundationDB 提供 KV+Layer；容量边界：etcd 约 2–8 GB backend，TiKV 可达 PB 级，FoundationDB 集群规模另论；一致读：etcd 用 ReadIndex 线性读，TiKV 用 Percolator SI，FoundationDB 是 strict serializable；存储引擎：etcd 用 bbolt 单写者，TiKV 用 RocksDB LSM，FoundationDB 用 Redwood 等。
etcd 的 Watch 背压和 Compaction 存在哪些开放问题？
开放问题包括：ErrCompacted 后全量 List 的成本如何写进 controller 与 apiserver 的 ADR；auto-compaction retention 与 watch 客户端断连时长如何定量 trade-off；如何测量一次 forced resync 的 List 字节与 etcd/apiservers 延迟。
etcd 的 Lease 锁在部分故障序下是否安全？
Jepsen 证明 Lease 锁在部分故障序下不安全；K8s Node Lease 和控制器依赖 Lease 过期，应用层 fencing 是否足够仍待验证，与 apiserver 全链路形式化 spec 仍缺。
etcd quota 触顶后有哪些迁移路径？
迁移路径包括：events 分集群、降低 churn、换存储；何时应评估 TiKV/FDB 而非继续调 etcd，以及 Kine 等兼容层 Watch 语义差是否被系统性测试，都是开放问题。
etcd 3.5 升级到 3.6/3.7 时需要注意什么？
需要注意 feature gate 替代 experimental flag、v2 全移除后，发行版钉死的 etcd 版本与自建集群升级窗口如何对齐；升级前需做 snapshot、官方 etcdutl check v2store 和 K8s release notes 三联检查；3.7 已发布，但各 K8s 发行版默认嵌入版本仍须逐家核对。
etcd 选型时，如何将排除树应用到 ADR 中？
在 ADR 中写清卡在排除树的哪一叶（quota / Watch / 五轴 / 事务模型），附否证条件（触顶、背压、编制、strict serializable 需求、误把 TiKV 当 etcd 加速）。示例句：若 backend 连续触 alarm 或 Watch resync 占 apiserver P99，则 etcd 叶必须重跑排除树，禁止以『K8s 默认 etcd』阻止 events 分集群或迁移评估。
