题目重点：Phone SD 来源要求先识别非功能需求，尤其一致性与可用性；本文给出训练 workload，逐项推导主从/仲裁、故障和恢复。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版支持 get(key)、put(key,value,version) 和 delete(key,version)，单 key 写采用条件版本；key/value 上限与 TTL 先列为需向面试官确认。
- 为展示推导，设读 100k QPS、写 20k QPS、平均值 1KB、100TB 逻辑数据、三副本；这些均非题目要求。
- 默认对单 key 需要线性一致写与读，可在少数派网络分区拒绝请求；如果业务优先可用且容忍旧读/冲突，则需改用多主与冲突合并。
解题路线
- 需求澄清先画矩阵：读写比例、单 key/跨 key 事务、条件写、持久性、过期、地域、p99 延迟、RPO/RTO、热点、租户隔离与成本。把“高可用”具体化到可允许的错误率和分区行为。
- 按稳定 hash 或 range 把 key 映到分片，元数据服务维护分片→复制组映射；range 便于扫描，hash 易均匀，热点 key 都需单独缓解。
- 每个复制组训练版用 leader + 多数派提交日志，写先落多数副本再确认；线性读走 leader/read-index。leader 租约若依赖时钟，要说明失效与脑裂边界。
- 节点故障后重选 leader、对比日志索引、补齐缺失项；新节点从快照加增量日志恢复，迁移期间保持旧组服务与节流。
- 条件写依赖服务端版本 compare-and-swap；幂等请求 ID 防客户端超时重试产生重复逻辑写，返回提交版本供调用方追踪。
- 监控按分片追踪 leader 更替、复制延迟、磁盘水位、热点 key、读写 p99、重试和不可用分钟数；做故障注入验证少数派拒绝与恢复时间。
手动走一遍
三副本 A/B/C，A 为 leader。put(k,v2,expectedVersion=1) 写入 A 并获 B 确认后提交版本 2；A 与 B 隔离但 C 可与 B 通信时，B/C 多数派可选新 leader 继续写，孤立 A 必须停止接受线性写。客户端对超时请求重试同一 idempotency key，返回同一结果。
规模与取舍
分片均衡时每节点空间约 3D/N（D 为逻辑字节、N 节点）；单 key get/put 的本地索引平均 O(1) 或 LSM O(log S)，网络写至少跨一个多数派往返。训练 100TB 三副本为约 300TB 原始数据，尚未计索引、日志和压缩。
易错点与追问
容易失分的边界
- 没问一致性语义便声称所有网络分区都持续可写。
- 把副本数 3 等同于任意两台故障都可写，忽略多数派。
- 客户端超时重试没有幂等键和条件版本，造成重复或覆盖。
- 只讲分片而没讲热点 key、再均衡和新节点追日志。
- 把跨 key 事务当作单 key 共识自动提供。
继续深挖
- 如果允许最终一致和多区域就近写，冲突怎样检测与合并？
- 跨 key 原子事务如何实现，代价是什么？
- 动态扩容时 range/hashing 的数据搬迁与可见性怎样协调？
- 强一致读的 p99 超预算时可否用有界陈旧读？
