解读

在国内 CouchDB 面试中，这道题考察的是对 分布式副本机制 与 读写仲裁 的底层理解。面试官通常先让你解释四个字母的含义，再追问“如果金融场景必须强一致，你会怎么配”，目的是验证你是否能把理论映射到真实运维。回答时要先亮出“CAP 取舍”立场，再给出量化组合，最后用一句话点出 性能损耗 与 运维成本，体现权衡意识。

知识点

1. q（分片数）：决定哈希环区间数量，一旦设定不可改；值越大，单分片数据量越小，扩容更平滑，但视图索引与压缩任务增多。
2. n（副本因子）：每份分片在集群中的物理副本数，上限为节点数；n 越高，容错越好，但写放大显著。
3. w（写成功票数）：写操作必须收到 ≥w 个副本“写盘”确认才返回 201；w≤n。
4. r（读成功票数）：读操作必须收到 ≥r 个副本“最新版本”才返回 200；r≤n。
5. 读写一致性公式：当 w + r > n 时，任意一次读写必然存在副本交集，可保证 强一致性；否则为最终一致。
6. 国内机房惯例：三机柜三副本（n=3）是主流，跨 AZ 场景可能 n=5；w=r=(n+1)/2 是平衡选择。
7. 性能拐点：w=n 时写延迟最高，r=1 时读最快但可能读到旧数据；金融级强一致需接受 P99 写延迟翻倍 的代价。

答案

q 决定数据分片粒度，与一致性无直接关系，但分片过多会放大 r/w 的投票耗时；n 是总副本数，直接决定容错上限；w 与 r 构成仲裁阈值，只有当 w + r > n 时，系统才能拒绝“脏读”，实现强一致。
国内生产环境若要求强一致，推荐组合：

• 节点数 ≥3，n=3
• w=2、r=2
  此时 w+r=4>3，满足仲裁；若集群规模扩大到 5 节点，可升 n=5、w=3、r=3，依旧保持 w+r=6>5。
  注意：q 在建库时一次性设定，建议按未来三年数据量评估，通常单分片 ≤200 GB 可避免压缩风暴。

拓展思考

面试官可能追问“如果业务允许毫秒级延迟，但要求强一致，能否不降 w，而用其他手段？”
可答：

1. 局部仲裁：把 w 拆成“同步副本”+“异步 witness”，利用 CouchDB 的 write_quorum 插件 让 witness 只写元数据，降低磁盘 IO，但仍计入投票。
2. 读修复加速：开启 read_repair=on，让 r=2 的读取在返回前异步把最新版本推回落后副本，减少后续读冲突。
3. 机柜感知：在 n=5 的跨 AZ 场景，设置 zone-aware placement，保证 w=3 时至少 2 个副本落在主 AZ，降低跨机房 RTT，P99 写延迟可从 180 ms 降到 60 ms，同时依旧满足 w+r>n 的强一致约束。