解读

在国内中大型团队落地 CouchDB 时，面试官问“如何追踪视图依赖”并不是想听你背文档，而是考察三件事：

1. 你是否理解视图（Design Document + Map/Reduce）在B+ 树索引中的物理形态；
2. 当上游业务字段变更或设计文档版本升级时，你能否低成本、可灰度、可回滚地评估影响面；
3. 你是否能把“索引重建耗时”与“在线集群 QPS”这两个矛盾点量化给产品方。
   一句话，面试官要的是可落地的变更风控方案，而不是一句“看版本号”。

知识点

1. 设计文档（_design/doc） 本身是可版本化的 JSON，_rev 字段只能解决“写冲突”，不能解决“语义依赖”。
2. 视图索引文件（.view 文件） 落地在 couchdb@node/data/.shards/ 目录，文件名以 md5(设计文档id+视图名) 规则生成，重启或副本重平衡会触发重新索引。
3. couch_indexupdater 进程会写 couch.log：Starting index update for db:shard/... group:ddocid signature:xxxx，signature 就是设计文档内容哈希，这是追踪依赖的黄金字段。
4. GET /db/_design/doc/_info 返回 view_index.signature 与 updater_running/purge_seq，可在上线前对比 signature 是否变化；若变化，说明索引必重建。
5. GET /db/_design/doc/_view/viewname?update=lazy&limit=0 只拿签名不拿数据，对线上零冲击，可写脚本批量巡检成百上千个设计文档。
6. 国内金融、政务场景 要求“先热升级、后冷删除”，因此需要维护 “设计文档影子库”：
   • 在灰度库里先 PUT 新设计文档 → 触发索引 → 对比 signature → 回归测试 → 再推送生产；
   • 生产保留旧设计文档 7 天，利用 _revs_limit 与 _view_cleanup 做惰性回收，防止凌晨副本迁移时无索引可用。
7. 若使用 couchdb 3.x 的“分区查询”（?partition=xxx），分区字段一旦变更，索引签名同样会变，需纳入回归范围。
8. 国内信创环境 常关闭 jsengine 的 os_process_limit，Map 函数里若引用外部 lib，必须显式声明版本，否则签名一致但语义不一致，造成“幽灵依赖”。

答案

线上追踪视图依赖分四步：

1. 预发布阶段：把新旧两份设计文档分别 PUT 到灰度集群，记录 signature；
2. 巡检阶段：用 ?update=lazy&limit=0 批量比对生产库与灰度库的 signature，输出差异清单；
3. 变更阶段：通过 signature 白名单 控制滚动重启顺序，优先重启副本分片，再重启主分片，确保任意时刻 2/3 节点持有可用索引；
4. 回收阶段：7 天后执行 _view_cleanup，并在影子库里保留设计文档历史版本 90 天，满足国内审计“可回溯、可比对”要求。
   整套流程脚本化后，单次全库巡检 500 个设计文档可在 3 分钟内完成，对线上 QPS 影响 <1%。

拓展思考

1. 如果业务要求字段级血缘（例如 A 视图用到了 doc.profile.age，B 视图用到了 doc.profile.name），CouchDB 原生无法解析 JS 语法树，需要借助 ANTLR4 + 自研静态分析工具 把 Map 函数转成 AST，再与 JSON Schema 注册中心 联动，实现“字段变更 → 影响视图列表 → 自动创建灰度任务”的闭环。
2. 在多活容灾场景，北京与深圳双集群同时写，视图索引签名一致但 purge_seq 可能不同，需引入 “签名+purge_seq”二元组 作为依赖键，防止跨地域副本切换时触发全量重建。
3. Serverless 边缘节点（如微信小程序本地 PouchDB）没有 _view_cleanup，索引文件只增不减，要在同步协议里加 “索引签名协商头”，边缘节点只拉取签名匹配的视图分段，节省 60% 流量。