解读

在 CouchDB 的 Map/Reduce 框架里，重新 Reduce（re-reduce） 是查询层把已经 Reduce 过的中间结果再次聚合的过程。
国内生产环境常出现“分片节点先本地 Reduce、协调节点再全局 Reduce”的两级场景，也常见于增量视图更新与跨机房复制后视图合并。
如果自定义 Reduce 函数不具备特定数学性质，就会出现“先合后算 ≠ 后算再合”的偏差，导致最终数值错误，甚至触发业务对账失败。
面试官问这条，既考察候选人对 CouchDB 内部机制的理解，也验证其是否具备“写可扩展聚合逻辑”的工程素养，属于分布式 NoSQL 岗位的高频进阶题。

知识点

1. CouchDB 视图索引以 B+ 树形式持久化，每个节点保存 <键, 已聚合值> 对。
2. 查询时，Coordinator 把多个节点的中间结果拉回，调用同一 Reduce 函数做 re-reduce。
3. 因此 Reduce 必须满足：
   幂等性（Idempotence）：对同一批中间值重复 Reduce，结果不变。
   结合律（Associativity）：(a ⊕ b) ⊕ c = a ⊕ (b ⊕ c)，保证分块合并顺序不影响结果。
4. 不满足这两条的经典反例：
   • 简单字符串拼接（无分隔符）→ 结合律破坏；
   • 带“样本顺序号”的平均值 → 幂等性破坏。
5. 国内金融、运营商场景对最终一致性要求极高，若 Reduce 写错，会直接造成报表差异，因此面试时必须把“数学性质”与“业务正确性”挂钩阐述。

答案

自定义 Reduce 必须同时满足：
1. 结合律（Associativity）——保证分片结果可以任意顺序合并；
2. 幂等性（Idempotence）——保证同一中间结果多次参与合并仍输出相同值。
只有同时满足这两条，CouchDB 的 re-reduce 阶段才能在不同节点、不同时间、不同顺序下都得到一致且正确的聚合值。

拓展思考

1. 实际写代码时，“平均值” 应输出 {sum, count} 二元组，而非直接返回 avg；最终由客户端再做一次除法，既满足结合律又满足幂等性。
2. 国内大厂常把 CouchDB 视图结果同步到离线数仓做二次分析，若 Reduce 不幂等，会导致离线增量回刷与实时查询数值漂移，触发数据质量告警。
3. 面试中可以主动提及：
   • 用 _count、_sum 等内置 Reduce 可天然满足两条性质；
   • 自定义时先写单元测试，用 randomized partitioning 验证结合律，用 duplicate injection 验证幂等性，体现工程化思维。