解读

国内面试官问此题，并非单纯考察参数拼写，而是想看候选人能否把“版本保留数量”与“业务可恢复时间窗口”这两个维度闭环设计。
CouchDB 的 _revs_limit 仅决定文档级版本链长度，默认 1000 已满足数量要求；但版本链不会按时间老化，若写入频繁，1000 个版本可能 10 分钟就刷满，导致 24 h 前的版本早已被压缩。因此，必须引入外部机制把“版本数量”翻译成“时间维度”的可恢复能力，并兼顾磁盘与同步流量成本。

知识点

1. _revs_limit 作用域：单节点与整个集群共用同一值，修改后仅对新写入生效，旧短链不会自动拉长。
2. 版本回收规则：
   ‑ 每新增一次写入，CouchDB 把旧版本标记为“leaf”并加入压缩候选；
   ‑ 压缩进程(_compact) 会把超出 _revs_limit 的非冲突叶子版本物理删除，且删除后无法回滚。
3. 国内监管场景：等保 2.0 要求“可回溯 24 h 业务数据”，仅靠 _revs_limit 无法自证合规，需要可验证的备份链。
4. 复制边界：_revs_limit 差异会导致源库版本比目标库深，易触发“missing rev”冲突，国内多活架构必须保持全集群 _revs_limit 一致。
5. 磁盘与同步流量：_revs_limit 调高会线性增加 .couch 文件大小与跨省专线流量，需评估 ROI。

答案

步骤一：统一集群配置
在 ansible 或腾讯云 TKE 配置模板里固化
[couchdb] _revs_limit = 1000
确保南北双活节点同时重启，避免版本深度不一致造成复制回环。

步骤二：把时间窗口换算为“版本深度下限”
取近 7 天峰值 QPS 做基准，例如峰值 2 写/s，24 h 共 172 800 次写入；
1000 版本仅能覆盖 8.3 分钟，远小于 24 h。因此不能仅靠 _revs_limit，需要“版本冻结 + 定时备份”组合。

步骤三：版本冻结

1. 每整点通过 /_revs_diff 接口拉取过去 1 h 内变更列表；
2. 对变更 doc 调用 PUT /db/doc?new_edits=false 带上当前 rev，生成伪冲突叶子，强制保留该时刻版本；
3. 冻结后立刻打时间戳标签存入对象存储（如阿里云 OSS），保留 30 天。

步骤四：压缩策略
每日 03:00 业务低峰期执行 /_compact，但跳过当天冻结的 revs，通过 ?revs=true&open_revs=[...] 先校验再压缩，确保 24 h 内任意标签可回滚。

步骤五：验证与演练
每周末随机抽取 6 个时间点，使用 /_revs_limit=1000 的库直接 PUT 回滚至冻结 rev，再用业务脚本做账务对账，输出等保合规报告。

结论：
“_revs_limit=1000 只是入口，真正的 24 h 任意点恢复靠‘版本冻结 + 对象存储 + 定时演练’三位一体，才能在国内监管环境下落地。”

拓展思考

1. 若业务写入峰值突增 10 倍，冻结流量可能打满 OSS 回源带宽，可引入分层冻结：热数据保留在 CouchDB，温数据转存至 MongoDB 或 Loki，只存 diff。
2. 国内金融客户常要求“跨地域 RPO < 15 min”，可把冻结 rev 的 MD5 摘要写入区块链存证，满足不可篡改审计。
3. 当 _revs_limit 被迫提高到 10000 时，Erlang 进程邮箱在压缩期会出现消息堆积，需调优 vm_args +P 1000000 并监控 erlang:system_info(process_count)，避免节点假死。