题目重点：设计 get/put/delete，明确线性一致或最终一致，再谈扩容和故障恢复。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 只有distributed KV目标，容量/TTL/事务/读写比例未给；训练先选择按key分片、单key版本更新。
解题路线
- API定义value大小、missing、delete、条件写和一致性。key路由到partition，metadata记录配置epoch，避免新旧路由同时接写。
- 强一致单分片可用leader与多数复制日志，commit后确认，读需合适leader/lease/read-index合同。副本异步读可能陈旧，要明确标注。
- 若选多主/最终一致，需要版本、冲突合并和修复；last-write-wins依时钟和业务规则，不能天然防覆盖。
- rebalance先复制snapshot再追日志，切主/路由有fencing与所有权确认；迁移未完成不随意删除旧副本。
- 存储层WAL恢复、compaction/tombstone、备份与校验；复制防单机故障不等于防人为删除或全站损坏。
手动走一遍
同key两个客户端条件写version7，只允许一个变8，另一个冲突重读；跨key转账另需事务或业务协调。故障后旧leader恢复，epoch过期写入须拒绝，防脑裂。
规模与取舍
key定位可平均常数但网络/复制与持久化决定延迟；热点key限制吞吐，分片均匀不等于请求均匀。副本r倍数据+日志/索引额外空间。
易错点与追问
容易失分的边界
- 把一致性哈希当复制一致性协议。
- 异步副本读称线性一致。
- 复制代替备份。
继续深挖
- 大value与热点key怎样处理？
- TTL删除如何防旧值复活？
