解读

在 CouchDB 场景里，“增量样本”通常指自上次同步或分析以来发生变更的文档集合。面试官想确认候选人是否理解 CouchDB 的最终一致性模型、多版本并发控制（MVCC）以及离线优先架构下如何高效、准确地捕获“新增+修改+删除”三类变更，而不是把全库拉回来再做差分。回答必须体现对国内网络质量参差不齐、移动端频繁断网、政务/金融合规要求等痛点的落地经验。

知识点

1. _changes 反馈：CouchDB 内置的只追加变更日志，支持 since=now、last_seq、limit、include_docs、filter 等参数，是增量样本的唯一官方入口。
2. seq 标识与断点续传：每次请求返回的 last_seq 是逻辑时钟，可持久化到本地文件或 Redis，实现“宕机续传”，避免重复拉取。
3. 视图级增量：若业务只需部分字段，可在 _changes 上叠加 filter=_view 或自定义 Erlang 过滤函数，减少跨省专线带宽消耗。
4. 删除标记：国内等保场景要求“逻辑删除”，CouchDB 的 _deleted:true 会出现在 _changes 中，必须显式处理，否则样本会漏掉“墓碑”数据。
5. 权限隔离：政务多租户环境下，使用 _security 对象结合 userCtx.roles 做行级过滤，防止越权拉取增量。
6. 压缩与编码：在 4G/5G 弱网环境，开启 Accept-Encoding: gzip 并在客户端做流式解压，可把 30 MB 的变更压缩到 3 MB，降低工信部信安审计中的流量告警。
7. 冲突检测：多主复制下，增量样本可能携带 _conflicts 数组，需在合并策略里保留业务时间戳+操作员编号，满足央行 281 号文对可追溯性的要求。

答案

生产级增量样本收集分五步：
第一步，初始化游标。首次同步时调用 GET /db/_changes?limit=1 拿到当前最新 seq 并落盘，作为后续 since 参数的起点。
第二步，循环拉取。定时任务（建议 5 s～30 s，视政务内网压力调整）调用 GET /db/_changes?since={last_seq}&include_docs=true&attachments=false，返回数组即增量样本。
第三步，断点续传。把响应中的 last_seq 原子写回 Redis 或本地 LevelDB，进程崩溃后重启任务自动从该点继续，保证 exactly-once。
第四步，墓碑处理。遍历样本时判断 doc._deleted 字段，若存在则写入回收库并记录操作员 ID，满足银保监 39 条审计要求。
第五步，流量控制。当样本量大于 10 MB 时，使用 limit=5000 分页，并在 HTTP Header 带上 Prefer: return=minimal，降低跨省 MPLS 专线晚高峰丢包率。

拓展思考

1. 海量分区库场景：若使用 CouchDB 3.x 的分片集群，_changes 仅覆盖本节点，需在应用层合并各分片的 last_seq，并考虑一致性哈希再平衡后 seq 重置问题。
2. 实时流式消费：可基于 _changes?feed=continuous&heartbeat=10000 建立长连接，在 Node.js 中使用 follow 库，把增量直接推送到Kafka 集群，供 Flink 做实时风控；但要在 Nginx 层配置 proxy_read_timeout 3600s，防止政务云 WAF 误杀长连接。
3. 合规加密：涉密单位要求全流量加密，可在 _changes 请求上叠加 SSL_client_cert 双向认证，并把 seq 与国密 SM4 加密后的文档摘要一起落盘，实现端到端留痕。