如何聚合全局模型并写回？
解读
“聚合全局模型并写回”在 CouchDB 语境下，本质是把分散在多节点、多数据库、多版本的文档数据，经过业务维度聚合后，生成一份全局视图（Global Model），再把这份视图持久化回 CouchDB（或下游系统），供后续查询与业务决策。
国内面试场景里，面试官想确认三件事：
- 你是否理解 CouchDB 的最终一致性与多主复制带来的数据碎片问题；
- 能否用 CouchDB 原生机制（视图、变更 feed、冲突处理）完成聚合，而不是盲目把 MySQL 的“事务回写”思维搬过来；
- 是否具备线上灰度、回滚、幂等的工程意识，因为“写回”一旦出错，会再次触发复制风暴。
知识点
- 最终一致性 & 多版本：同一业务键在 A、B 两地同时修改，CouchDB 保留冲突分支，需应用层裁决。
- Map/Reduce 视图：唯一能在节点本地完成预聚合的原生手段，输出可直接落地为 _view 结果，但视图本身只读。
- /_changes feed：包含 seq、deleted、conflicts 字段，可增量扫描全库，是“全局模型”的输入源。
- _bulk_docs & new_edits=false：支持批量回写且可指定历史 rev，实现幂等更新；配合 _rev 冲突检测，避免写回时再起冲突。
- CRDT / 业务裁决函数：国内大厂离线优先场景（如骑手端 App）常用last-writer-wins或向量时钟策略，提前在边缘节点完成冲突合并，减少回写压力。
- 双写一致性：写回目标若是下游 MySQL/ES，须引入本地消息表 + 定时对账模式，防止“CouchDB 写成功、下游超时”的悬事务。
答案
线上实战分四步，全部脚本化落地在 Jenkins + Ansible，灰度发布：
-
拉取全局变更流
用 连续 _changes feed（since=now） 扫描所有分片库，filter 函数只保留业务类型=order 且状态=finished 的 doc；feed=longpoll 超时 60 s 自动重连，避免北京/上海跨城专线抖动造成漏数据。 -
内存窗口聚合
在 Node.js 聚合服务 内维护一个 5 min 的滑动窗口，按 riderId 分组累单量、客单价；窗口结束即触发 reduce 终聚，生成全局模型 JSON：
{“riderId”:“R123”,“totalOrder”:128,“totalFee”:3864.5,“_id”:“agg::R123::20250611”} -
冲突裁决 & 版本锁定
回写前先 HEAD 检查目标 doc 的 _rev；若返回 409，说明其他节点已写，则拉取当前版本，与本次聚合值做向量时钟比对，取 counter 高者；若 counter 相同，取 timestamp 晚者，确保裁决确定性。 -
批量幂等回写
使用 _bulk_docs 接口，设置 new_edits=false，把上一步确定的 _rev 一并提交；回写目标可以是：
a) 同库不同桶（推荐，利用 CouchDB 自身复制同步）；
b) 异构 MySQL，则先写本地 msg_order_agg 表，再用 Canal 同步到 MySQL，实现最终一致。
回写完成后，向 Prometheus 推送 agg_writeback_total{status="ok"} 指标，方便告警。
灰度策略：按 riderId 尾号 00-09 先灰 10%，观察 30 min 无 409 冲突增长率异常，再全量。
拓展思考
- 如果全局模型体积超过单文档 8 MB 上限，可把结果拆成 chunk 列表，用 attachment 存储二进制，或直接落地到 S3 协议对象存储，CouchDB 文档里只保留 chunkKeys 数组，实现“元数据与实体分离”。
- 对于小时级离线全量聚合，可改用 CouchDB 2.3+ 的 Mango 索引 + 覆盖查询，把热数据一次性拉到 Spark，通过 couchdb-spark-connector 生成 DataFrame，聚合后再 bulkSave 回 CouchDB；此时要注意 split size 与 shard 对齐，避免一个 Spark task 把单 shard 打满。
- 若业务要求秒级实时，可在边缘节点部署 PouchDB，利用 live replication 把变更同步到浏览器，前端直接做 localStorage 级别聚合，再把结果通过 REST 写回 CouchDB，实现“端-云”一体化；该方案在国内物流扫码枪场景已落地，网络隔离时仍能离线聚合，恢复网络后自动合并。