解读

国内生产环境普遍把 CouchDB 当成“离线优先 + 多端同步”的核心存储，文档版本链（_revs）随写操作线性增长，导致 元数据膨胀、磁盘占用飙升、复制流量放大 三大痛点。
面试官问“如何启用 revs_limit=10”，表面看是调一个参数，实则考察：

1. 是否理解版本链的存储机制与回收逻辑；
2. 能否在 不停服、不丢数据、不影响同步 的前提下完成调优；
3. 对国内云主机磁盘 IOPS 与带宽成本是否敏感。
   答得太浅（只给一句“改 ini”）会被判“没线上经验”；答得太深（直接聊 Erlang 源码）又显得“过度炫技”。必须给出可落地的国内运维套路。

知识点

• revs_limit 含义：单文档保留的最大版本数（含当前版本），超过即触发旧版本回收，默认 1000，对高频更新业务极不友好。
• 生效范围：库级别参数，每库可独立设置；新值只对后续写入生效，历史版本不会立即消失。
• 回收触发条件：
  – 下一次 compaction（手动或自动）；
  – 复制对端也设置相同或更小的 revs_limit，否则可能出现 “missing rev” 警告 导致复制回退。
• 国内云环境注意：
  – 低配 ECS 磁盘 IOPS 有限，禁止业务高峰触发全量 compaction；
  – 跨地域同步时，带宽按量计费，revs_limit 过大直接推高账单。
• 安全底线：
  – 禁止 revs_limit<2，否则 复制冲突检测失效；
  – 禁止在 双向同步 的库上随意降低，需先比对双方版本链深度。

答案

线上标准四步法（以 db 名为 order_demo 为例，目标 revs_limit=10）：

1. 低峰期预检
   登录任意节点，执行
   curl -u admin:pwd http://127.0.0.1:5984/order_demo/
   确认 cluster 状态 n=3、q=8、r=w=2，无“compact_running”。
2. 动态下发生效
   对每一个节点依次执行
   curl -X PUT -u admin:pwd http://127.0.0.1:5984/order_demo/_revs_limit -d '10' -H "Content-Type: application/json"
   返回 {"ok":true} 即代表内存热更新完成，无需重启。
3. 渐进式回收
   采用 分段 compaction 策略：
   – 先对 20% 的分片触发 POST /{db}/_compact，观察云监控磁盘 I/O <60%；
   – 再分批完成剩余分片，避开晚高峰 20:00-23:00。
4. 复制链路验证
   在 Fauxton 的“Active Tasks”里确认 连续 30 min 无 replication 报错，并在对端节点抽样 100 条文档，验证 _revs 数组长度 ≤10，确保无 missing rev 回退。
   完成后磁盘占用平均下降 35%-50%，同步流量下降 40% 以上，达到国内云成本优化 KPI。

拓展思考

1. 若业务需 保留冲突历史用于审计，可把 revs_limit 调到 50，同时打开 “_conflicts” 视图 并定期归档至冷存储（OSS 或 COS），兼顾合规与成本。
2. 在 K8s 有状态集群 中，可把 revs_limit 写入 ConfigMap，通过 sidecar 容器在 pod 启动时调用相同 PUT 接口，实现 GitOps 化治理，防止人工误改。
3. 未来升级到 CouchDB 4.x 后，官方引入 “tombstone_purge” 功能，可与 revs_limit 组合使用，进一步剔除删除墓碑，届时磁盘回收效率可再提升 15%-20%，面试时可作为技术演进亮点抛出，体现前瞻性。