解读

面试官想考察两点：

1. 能否在中国国内真实网络环境下，用 CouchDB 原生或常见工具精准注入 500 ms 随机延迟，而不是简单 sleep；
2. 能否在延迟存在时，端到端验证多主节点最终一致性，并给出可量化的判断标准。
   回答必须体现对Erlang 层消息流、复制状态机、MVCC 版本向量的掌握，同时兼顾落地脚本与验收指标。

知识点

• CouchDB 3.x 集群复制通道：基于 _scheduler/jobs 的 crpc 连接，走 5986 端口，可被 tc/netem 精准控制。
• Linux tc/netem：国内云主机默认内核已编译 sch_netem，可注入固定+随机延迟；需关闭 offloading 以免被 ethtool 旁路。
• 复制一致性判据：doc._rev 的版本向量前缀计数相等，且 winning_rev 在全部节点一致；辅助指标 checkpoint_committed 时间戳差值 < 1 s。
• 国内公有云注意点：阿里云、腾讯云轻量服务器默认开启 tso/gso，必须在注入前 ethtool -K eth0 tso off gso off，否则延迟抖动失真。
• 离线优先场景：移动端 PouchDB 到 CouchDB 的filtered pull 同样受延迟影响，需用 seq_interval 与 timeout=60000 避免 502 网关。

答案

步骤一：精准注入 500 ms 随机延迟

1. 在两台 CentOS 7.9 节点上确认网卡为 eth0，执行

   ethtool -K eth0 tso off gso off ufo off gro off
   

2. 针对CouchDB 集群端口 5986（节点间复制）注入延迟，命令如下：

   tc qdisc add dev eth0 root handle 1: prio
   tc qdisc add dev eth0 parent 1:3 handle 30: netem delay 400ms 100ms distribution normal
   tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32 match ip dport 5986 0xffff flowid 1:3
   

   解释：平均 400 ms，正态随机 ±100 ms，99% 落在 500 ms 附近，满足题意。

步骤二：构造可验证的写负载

1. 在 nodeA 连续 PUT 100 条带自增字段的 doc，形如

   {"_id":"test_057","seq":57,"ts":"2025-06-05T14:12:00Z"}
   

2. 使用官方脚本 couchdb-load-balancer 的变种，每批写入后立刻读取 nodeB、nodeC，记录返回的 winning_rev 与 seq。

步骤三：一致性量化验收

1. 当 seq 在全部节点出现且 _rev 前缀计数相等时，记该文档达到一致；
2. 用 Python 脚本轮询 _scheduler/jobs，当 checkpoint_committed 时间戳差值 < 1 s 且落后 doc 数量为 0，判定集群级一致；
3. 重复 10 轮，统计平均一致时间与最大滞后 doc 数，输出报告：

   平均一致时间 2.3 s，最大滞后 7 条，符合国内 4G 到 5G 弱网预期。
   

步骤四：清理与复盘

tc qdisc del dev eth0 root

关闭延迟，再次跑相同负载，验证无延迟时平均一致时间 0.4 s，形成对比基线。

拓展思考

1. 若延迟注入在移动端 PouchDB → Sync Gateway → CouchDB 链路，需在 Android 侧用 OkHttp interceptor 注入 500 ms 随机延迟，再对比WebSQL 本地 seq与远程 last_seq 差值，思路与服务器侧一致。
2. 当集群跨北京与上海阿里云 VPC 时，需把 tc 规则挂在 VPN 隧道接口 tun0 而非 eth0，否则只延迟物理网卡，复制流量走隧道会绕过 netem。
3. 如果面试官追问“如何验证因果一致性而非最终一致”，可答：在 doc 内携带向量时钟向量nodeA:2,nodeB:1，通过 /_changes?style=all_docs 拉取全版本，检查任意两个版本是否存在并发标识(*)，从而证明 CouchDB 的 MVCC 仍保持因果一致。