当单个分区写入 QPS 超过 8 k 时，如何临时提升“n”值缓解？
解读
面试官把“n 值”放在“临时缓解”这一限定条件下提问，实质是考察你对 CouchDB 集群分片与副本机制、在线运维能力以及国内高并发场景下“先止血、后根治”的应急思路。
在国内互联网面试语境里，8 k 写/s 已远超单分片安全水位（通常 2 k 以内），此时若不快速打散写压力，极易触发BEAM 虚拟机 GC 抖动、btree 写放大以及磁盘顺序写热点，最终表现为 502/504 暴增。因此“临时提升 n”并不是让你改代码，而是利用 CouchDB 水平扩容副本的能力，把“写”变相转成“读-修复写”，在分钟级内把单机热点负载分摊到多台节点，为业务争取“窗口期”。
知识点
- n 值含义：CouchDB 的
q（分片数）与n（副本数）在集群层面由cluster.n参数控制，单个分片的 n 表示该分片在集群中的副本总量（含主）。 - 写路径：CouchDB 采用多主+MVCC，任意副本均可接受写，但同一文档在同一时间只能由一台节点负责协调写；协调节点会把写请求广播到所有副本，多数派成功即返回。因此提升 n 后，协调节点池变大，可把 8 k QPS 的协调压力均摊到更多节点，降低单机 CPU 与磁盘 IO。
- 临时扩容的约束：
- 必须保证集群已有空闲节点（国内公有云通常提前弹升 2~3 台“热备”Couch 节点，镜像与数据盘已就绪）。
- 只能对新创建的数据库或尚未达到上限的分片生效；已有分片的 n 值在线调高需要 CouchDB 3.x+ 并开启
cluster.enable_per_db_cluster_parameters。 - 调高 n 会立即触发内部复制，带来额外 20%~30% 网络带宽与磁盘读 IO（读-修复），需提前评估网卡与云盘 IOPS 余量。
- 国内云厂商差异：阿里云、腾讯云 CouchDB 托管版对“修改 n”做了白名单限制，需提工单开放超级管理员权限；自建 Kubesphere/TKE 环境则可直接改 StatefulSet 的
COUCHDB_CLUSTER_N环境变量并滚动重启。 - 配套监控：务必同步把beam.smp CPU>80%、disk_write_kbytes/s、httpd_status_codes.502 加入 Prometheus 告警，防止“扩容副本”变成“放大故障”。
答案
第一步：30 秒内确认热点范围
在任意节点执行 curl -X GET http://127.0.0.1:5984/_node/_local/_system | jq '.proc_mem' 与 /_stats/couchdb/httpd_request_methods.PUT.current，确认只有单个分片 db01 PUT 飙高，其余分片正常。
第二步：2 分钟内完成“临时提升 n”
- 登录集群 Fauxton → 右上角“Config” → 找到
cluster.n，把 db01 的 n 从 3 改成 5（必须确保已有 2 台空闲节点已加入集群）。 - 若使用国内云托管版，立即提交工单并电话升级，同步把工单号甩到钉钉应急群，让值班同学备注“高优”。
- 自建环境则直接
kubectl set env statefulset/couchdb COUCHDB_CLUSTER_N=5 -c couchdb，滚动重启一台验证后，再批量重启其余节点。
第三步：5 分钟内观察止血效果
通过 /_stats/couchdb/request_time.arithmetic_mean 看 P99 是否从 2 s 降到 500 ms 以内；同时 /_stats/couchdb/httpd_status_codes.502.current 归零即视为缓解成功。
第四步：记录临时变更
在 Confluence 留下“应急变更记录”：时间、操作人、旧 n/新 n、工单号、止血效果截图，次日晨会必须给出永久方案（如按 open_doc_id 做二次哈希、预分片 q=32、升级磁盘到 ESSD PL2 等）。
拓展思考
- 如果集群节点已达上限，无法继续提升 n，你会如何利用nginx+lua 在接入层做一致性哈希降级？
- 当 n 提升后，内部复制流量暴增导致云厂商出方向带宽打满，你如何通过修改 replication.max_history 与 checkpoint_interval 把复制流量削峰 40%？
- 国内金融场景要求同城双活+异地冷备，若主集群因 8 k 写 QPS 触发高延迟，你是否敢把 n 提升到 7？请量化说明脑裂概率与最小副本数公式 floor(n/2)+1 的权衡。