如何增量更新权重？
解读
在国内 CouchDB 面试中，面试官问“增量更新权重”并不是想让你背诵 MapReduce 语法，而是考察三层能力：
- 是否理解 CouchDB 的无锁、追加写模型——所有更新本质上是新增修订版本；
- 能否把“权重”这一业务概念映射成文档字段，并用视图聚合实现增量累加，而不是拉回全表；
- 是否熟悉国内高并发场景下的幂等设计与冲突解决策略，防止同一条权重被重复累加或丢失。
因此，回答必须围绕“只写增量、视图聚合、冲突可回溯”三个关键词展开，并给出可直接落地的代码片段与运维要点。
知识点
- 修订版本（_rev）机制：CouchDB 对同一文档 id 的任何修改都会产生新 _rev，旧版本保留到数据库压缩前，天然支持“写增量”。
- 视图（View）与聚合：Map 函数只跑一次，后续增量数据通过b-tree 追加方式进入同一视图，因此 sum、count、stats 等内置 reduce 函数可做到增量聚合。
- 幂等键设计：国内生产环境常把“用户 id + 业务日期 + 随机 nonce”作为 _id，确保重试写入不产生脏权重。
- 冲突文档（_conflicts）：多主复制场景下，同一条权重可能出现分支版本，需用winningRev + 业务合并脚本解决，否则聚合结果会漂移。
- update 函数局限：CouchDB 的 design/update 函数只能把“旧文档 + 入参”变成“新文档”，不能部分更新字段，所以权重增量必须客户端先读后改或采用“事件溯源”模式。
- 国内云厂商优化：阿里云 CouchDB 兼容版在 3.x 后支持子文档更新插件，但开源主线仍要走“追加写 + 视图聚合”路线，回答时需明确区分。
答案
步骤一：文档模型
把每一次权重变更建模成独立事件 doc，核心字段：
{
"_id": "weight_evt#user123#1654321000#uuid",
"type": "weight_delta",
"user": "user123",
"delta": 5.5,
"created_at": "2022-06-04T12:00:00Z"
}
_id 里带业务主键与时间戳，保证幂等；delta 可正可负，支持回滚。
步骤二：视图聚合
在 design doc 里定义视图：
function (doc) {
if (doc.type === 'weight_delta') {
emit(doc.user, doc.delta);
}
}
reduce 用内置 _sum， CouchDB 会对同一 user 的增量自动累加，时间复杂度 O(logN)，完全增量。
步骤三：写入流程（Java 举例）
- 客户端本地计算 delta；
- 生成幂等 _id，直接 PUT /db/{_id}；
- 若返回 409，说明网络重试造成冲突，立即用 GET /db/{_id}?revs=true 确认已写入，无需再重试；
- 写入成功后，可立即本地缓存最新聚合值，也可再次查询视图，延迟通常 <100 ms。
步骤四：冲突修正
定期跑巡检脚本：
GET /db/_all_docs?include_docs=true&conflicts=true
对每条带 _conflicts 的文档，比较 delta 字段，把缺失的 delta 补写入新事件，然后删除冲突分支，确保视图聚合结果最终一致。
步骤五：压缩与性能
国内线上经验：
- 单节点 8C16G，每天 2000 万条增量事件，视图刷新延迟控制在 5 秒以内；
- 开启 q=8 分区，磁盘占用降低 30%；
- 每周一次 /_compact 释放旧版本，避免视图文件膨胀。
一句话总结：把“权重”拆成不可变事件，利用 CouchDB 的追加写与视图聚合能力，实现真正的增量更新，同时用幂等 _id 与冲突巡检保证数据一致。
拓展思考
- 如果权重需要实时滑动窗口（近 5 分钟），可在 Map 里 emit([doc.user, minute_bucket], delta)，再用 startkey/endkey 查询，避免拉回全量数据。
- 当业务要求事务级回滚时，可引入“补偿事件” doc.delta = -original_delta，同样走视图聚合，无需改历史数据，符合国内审计规范。
- 对超大规模用户（亿级），可将 user 做一致性哈希拆库，每个分片独立视图，上层网关做二次聚合，这是国内头部互联网公司验证过的水平扩展方案。