解读

在国内 CouchDB 面试中，这道题考察的是“精准同步”能力。
面试官想确认你是否理解：

1. 复制（replication）默认会把整个数据库搬过去，带宽与存储成本在移动/边缘场景下不可接受；
2. 通过 doc_ids 过滤器 可以只同步白名单内的文档，降低 70% 以上流量；
3. 你能否把“配置方式 → 触发流程 → 冲突与权限 → 监控验证”完整闭环讲清楚，而不是只背参数。

知识点

1. doc_ids 是 CouchDB 内置的、最轻量的过滤机制，在 2.x/3.x 集群与单节点均有效。
2. 本质：把 _replicator 文档或 POST /_replicate 请求里的 "doc_ids": ["id1","id2"] 传给 changes feed，CouchDB 在源端就跳过非白名单文档，目标端不会收到多余数据。
3. 与自定义 filter 函数相比，doc_ids 不走 JavaScript，性能高、CPU 占用低，适合国内 4G/5G 弱网、IoT 网关、政务内网单向光闸等场景。
4. 限制：
   • 单次最多 8000 个 ID（国内实测 3.3.2 版本），超限需分批；
   • 只能按 精确 ID 过滤，不支持通配符；
   • 如果文档后续被删除，删除标记（tombstone）仍会同步，否则下次全量复制会误判为新增。
5. 安全：doc_ids 过滤不绕过权限，源端仍需对认证用户开启 read 权限；国内等保 2.0 场景下，传输层必须开启 TLS1.2+，防止 ID 列表在公网泄漏。
6. 监控：在 _active_tasks 中看 doc_write_failures 与 docs_read，可验证是否真正过滤；国内金融客户常把指标接入 夜莺/N9e 做实时告警。

答案

线上实战分四步：

1. 准备白名单：
   在业务系统里把需要下发的订单 ID 拼成数组，长度≤8000，例如
   ["order::202506::BJ001", "order::202506::BJ002", …]
2. 写入持久化复制文档（推荐，支持断点续传）：

   PUT /_replicator/order_partial_sync
   {
     "source": "https://user:pass@source.couchdb.local:6984/order_db",
     "target": "https://user:pass@edge.couchdb.local:6984/order_db",
     "doc_ids": ["order::202506::BJ001", "order::202506::BJ002"],
     "continuous": true,
     "create_target": false,
     "owner": "order_app"
   }
   

   注意：国内公有云主机需在安全组放行 6984 端口，并绑定 SSL 证书满足合规。
3. 触发后立即观察：
   GET /_active_tasks 返回的 docs_read 应等于 doc_ids.length；若出现 doc_write_failures>0，多数是目标端 磁盘只读 或 权限不足，需检查 _security 对象。
4. 增量维护：
   业务系统每天凌晨把新增的订单 ID 追加到数组，通过 _update 函数原子更新 _replicator 文档；老 ID 保留 7 天，防止边缘节点离线后错过删除标记。

一句话总结：把 doc_ids 当成“精准白名单”，在源端就拒绝非名单流量，既省 4G 流量费，又满足等保最小同步原则。

拓展思考

1. 如果白名单动态超过 8000 条，国内常见做法是 “分层过滤”：
   • 第一层用 doc_ids 把最近 7 天热点订单同步到边缘节点；
   • 第二层在边缘节点部署 自定义 filter 函数，按 customer_region=="华东" 二次过滤，把 CPU 压力下沉到边缘，中心库 CPU 下降 40%。
2. 在 政务横向级联 场景，省厅 CouchDB 需要向地市同步“已脱敏”文档，可结合 doc_ids + 选择性复制中间库：
   先通过 ** Mango 索引** 把涉密字段剔除并写入中间库，再用 doc_ids 把中间库文档同步到地市，实现“数据不出域”与“最小可用”双合规。
3. 未来 CouchDB 4.x 若支持 changes feed 的 _bulk_get 压缩，doc_ids 过滤后的流量可再降 30%，边缘 Kubernetes 集群能节省一半出口带宽费用，这是国内运营商目前 POC 的重点方向。