解读

国内生产环境普遍采用 三节点或五节点 的 CouchDB 集群，跨 AZ 部署在阿里云、腾讯云或私有 KVM 上。面试官想确认你：

1. 理解 CouchDB 最终一致性模型 与 quorum 读写（r/w 参数） 的边界；
2. 能在 节点随机宕机、网络分区、VM 被强制下线 等真实故障场景下，设计可重复的验证方案；
3. 会用 自动化脚本 + 监控指标 给出量化结论，而不是口头“感觉”。

知识点

• q 值：分片数，决定数据哈希范围。
• n 值：副本数，默认 3。
• r/w：读写 quorum，必须满足 r + w > n 才能保证 强一致。
• /_membership 与 /_up 接口：实时查看节点状态。
• /_dbs 元数据：记录分片→节点的映射。
• read_repair & write_quorum：触发条件与失败重试策略。
• 混沌工程工具：ChaosBlade、阿里云 AHAS、K8s Pod-kill，符合国内云原生审计要求。
• 一致性验证黄金指标：单调递增序列号、MD5 摘要、时间戳漂移。

答案

验证分五步，全部用脚本固化到 Jenkins Pipeline，方便面试官追问细节。

1. 基线准备
   a. 搭建 3 节点集群，n=3，q=8，r=2，w=2（满足 r+w>n）。
   b. 关闭 自动故障转移（enable_auto_failover=false），防止人工干扰。
   c. 预热 10 万条测试 doc，key 前缀 “consistency_”，value 带 UUID + 毫秒时间戳。

2. 注入故障
   使用 ChaosBlade 0.9.0 随机下线一台 VM：
   blade create os process stop --process beam.smp --timeout 120
   同时监听 /_membership，确保集群标记该节点为“down”。

3. 持续读写
   启动 Gatling 脚本 双线程：

   • 写线程：每 200 ms PUT 一条新 doc，w=2，超时 5 s；若异常则记录 “write_fail”。
   • 读线程：每 300 ms 随机读任意 doc，r=2；把返回的 UUID 与本地缓存比对，出现 “UUID 不一致” 即记为“read_stale”。

4. 恢复与数据校验
   a. 120 s 后重启宕机节点，等待 internal_replication 完成（监控 /_active_tasks 中 “replication” 任务归零）。
   b. 用 /_all_docs?include_docs=true 拉取全量数据，计算 MD5；与基线 MD5 比对，必须完全一致。
   c. 检查 “write_fail” 次数 = 0 且 “read_stale” 次数 = 0，方可判定“读写一致性未被破坏”。

5. 报告与复盘
   输出 Prometheus 指标：

   • couchdb_write_quorum_fail_total
   • couchdb_read_stale_total
     连同 Jenkins Blue Ocean 链路 截图一起归档，供审计。

拓展思考

• 如果业务把 w=1 为了高吞吐，上述验证必然出现 “read stale”，此时要向面试官说明：
  “这是预期行为，CouchDB 退化为最终一致，需业务层做幂等或客户端冲突解决。”
• 国内金融场景常要求 RPO=0，可改用 “w=majority + 双集群跨地域双向同步”，并用 Kafka 顺序写日志 做回滚点，验证脚本里再增加 “rollback 演练” 环节。
• 若集群扩容到 5 节点、n=5，记得把混沌实验改为 “一次下线 2 节点”，并验证 r=3, w=3 仍满足 r+w>n，否则面试官会质疑你对 quorum 数学 的敏感度。