解读

面试官真正想考察的是：

1. 你是否清楚 CouchDB 当前版本（3.x）默认使用 基于序列号（seq-based） 的冲突检测，而非早期版本的 vector-clock；
2. 你是否知道“回退”并不是改一行配置就能完成，而是要在 集群拓扑、复制参数、客户端代码 三个层面同时动手；
3. 你是否能权衡回退带来的 磁盘放大、CPU 开销、网络流量 等副作用，并给出可落地的灰度方案。
   在国内金融、运营商、政务云等合规场景里，审计日志要求“冲突可追溯”，vector-clock 的 全量因果历史 比 seq-based 更易过审，因此面试官希望听到“为什么必须回退”以及“怎么回得稳”。

知识点

1. seq-based 与 vector-clock 差异

   • seq-based 只在 _changes 流里带一个单调递增整数，冲突检测轻量但丢失“谁先于谁”的因果细节；
   • vector-clock 在每个修订里保留 节点ID:计数器 映射，能精确回答“两个修订是否有因果序”，但会随编辑次数线性膨胀。

2. 回退前提条件

   • 集群所有节点必须 停机升级 到同一小版本（≥3.2.2），否则混合模式会触发 {bad_clock,merge} 异常；
   • 已有桶若含 seq-based 修订，需先 dump→purge→restore，否则新旧时钟混用会造成 split-brain。

3. 操作入口

   • 单节点：在 local.ini 的 [couchdb] 段增加 use_vclock = true 后重启；
   • 集群：通过 /_node/_all/config 接口一次性写入，再执行 hot_reload（国内机房常禁用，需走变更工单）；
   • 复制任务：把 /_replicator 文档里的 query_params 加上 ?vclock=true，否则源库依旧走 seq。

4. 灰度与回滚

   • 先选 同城双活 中的一条 AZ 下线，用 couchdb-dump 导出 10% 桶验证膨胀率；
   • 若磁盘增长 >30%，可打开 vclock_prune_interval=86400 做 每日裁剪，但裁剪后无法再做 增量回溯，需提前报备审计；
   • 回滚时只需去掉 use_vclock 并执行 compact，vector 字段会被 自动丢弃，但已膨胀的 .couch 文件需等到下一次 全量压缩 才能回收。

答案

“回退”分三步：
第一步，停机变更：在维护窗口内把集群所有节点的 local.ini 添加 use_vclock = true，通过运维工单走 配置中心统一下发，确保 哈希一致；
第二步，数据净化：对存量桶执行 couchdb-dump | couchdb-purge | couchdb-load 的闭环，消除旧 seq 修订，防止 时钟混合；
第三步，复制链改造：把现网 /_replicator 任务全部重建，URL 后强制带 ?vclock=true，并在客户端 SDK 里把 open_revs=all 改为 open_revs=vclock，保证移动端 离线同步 也走 vector-clock。
完成以上三步后，用 /_active_tasks 观察 clock_merge 计数不再增长，即视为回退成功。

拓展思考

1. 国内 等保 2.0 要求“数据修改可追溯”，vector-clock 的 全量因果链 可直接作为 电子证据，但膨胀后可能触发 磁盘配额告警，你会如何设计 冷热分层 把 90 天前的 vector 字段自动归档到 对象存储？
2. 如果业务已用 PouchDB 做离线优先，回退后移动端会出现 doc conflicts 暴增，你会在 service worker 里加一层 vclock 压缩 还是直接改 sync gateway 策略？
3. 在 跨洋双活 场景里，vector-clock 的 计数器溢出 概率随 RTT 增大而升高，你如何基于 NTP 误差 动态调整 计数器位宽，避免 {clock_overflow,restart} 导致集群重启？