解读

国内一线互联网公司在面试 P6/P7 级别 CouchDB 岗位时，常把 /_active_tasks 作为“现场排障”题切入。
面试官真正想考察的是：

1. 你是否一眼能识别任务类型，快速定位线上“索引堆积”还是“复制积压”；
2. 是否熟悉字段语义差异，能用脚本做监控告警；
3. 是否理解任务生命周期，知道什么值代表“正常”什么值代表“卡死”。
   答不到字段级差异，直接视为“没玩过生产环境”。

知识点

1. /_active_tasks 返回的是实时 JSON 数组，每个对象描述一个后台任务，关键字段如下：

   • type：字符串，唯一区分任务种类，indexer 或 replication；
   • database：所属库名，indexer 与 replication 都有；
   • design_document（仅 indexer）：设计文档 _id，如 _design/search；
   • progress（仅 indexer）：0–100 整数，表示视图构建百分比；
   • started_on：Unix 时间戳，任务启动时间；
   • updated_on：Unix 时间戳，最后一次进度更新时间，可用来判断是否“僵死”；
   • source / target（仅 replication）：分别是源与目标的 URL 或数据库名；
   • doc_write_failures / docs_read / docs_written（仅 replication）：反映复制落后与冲突；
   • checkpoint_interval（仅 replication）：上一次检查点间隔，单位毫秒，突增代表网络或磁盘瓶颈。

2. 区分逻辑
   第一步看 type 字段即可：

   • type == "indexer" → 视图索引构建，关注 progress 与 updated_on 是否长时间不变；
   • type == "replication" → 集群或移动端同步，关注 docs_pending 与 doc_write_failures，若 docs_pending 持续大于 0 且 updated_on 不刷新，即为“复制卡死”。

答案

调用 GET /_active_tasks 得到数组后，首先读取每个对象的 type 字段：

• 若值为 "indexer"，说明该任务是设计文档视图索引构建，此时必含 design_document 与 progress 字段，progress<100 且 updated_on 超过 5 分钟未变即可判定为“索引堆积”；
• 若值为 "replication"，说明该任务是跨节点或端到端同步，此时必含 source、target、docs_read、docs_written、doc_write_failures 等字段，docs_pending>0 且 updated_on 长时间不变即可判定为“复制积压”。
  其余公共字段 database、started_on、pid 用于快速定位业务库与进程号，方便运维 kill 或重启。

拓展思考

1. 灰度发布场景下，同一数据库可能同时出现 indexer 与 replication 任务，如何写一行 jq 命令分别统计两种任务的平均进度与积压量？
2. 当 progress=100 但 updated_on 仍持续刷新，说明视图已构建完却触发compaction，此时 type 仍是 indexer，如何二次确认？
3. 国内私有云常把 replication 源目标写成 **https://内网域名**，若 DNS 解析失败，doc_write_failures 会递增但 docs_pending 不变，如何结合 updated_on 与 checkpoint_interval 区分“网络断”还是“权限拒”？