解读

面试官真正想考察的是：

1. 对 CouchDB 最终一致性模型 与 MVCC 机制 的理解深度；
2. 能否把“分布式场景下牺牲 ACID 换取高可用”讲清楚；
3. 是否具备在业务层用幂等设计 + 补偿流程替代刚性事务的落地经验；
4. 对国内金融、电商等高并发场景下“宁可补偿、不可阻塞”的架构思路是否熟悉。

知识点

1. MVCC + 追加写：每次更新生成新的文档版本（_rev），老版本保留，冲突检测靠 _rev 树，跨文档无法原子比对。
2. 单文档原子性：CouchDB 保证单文档写操作的原子性与持久性，但没有全局锁或两阶段提交，因此多文档间无法隔离。
3. 多主复制：集群任意节点可写，离线优先场景下网络分区常见，若引入分布式锁将严重降低可用性，违背“CAP 中优先 AP”的定位。
4. 业务补偿模式：包括“本地消息表 + 幂等消费”、“Saga 事务”、“TCC 尝试-确认-取消”三种国内主流实现。
5. 国内监管要求：支付类业务需资金对账平账，即使技术层无事务，也要通过日间批次 + 夜间差额补账完成合规。

答案

CouchDB 不提供多文档 ACID 事务，根本原因是其面向高可用与离线同步的设计目标：

1. 采用 MVCC 追加写 与 多主复制，任何节点都可接受写入；若引入跨文档锁或两阶段提交，网络分区时会出现写拒绝，破坏“始终可写”承诺。
2. 单文档已具备原子性，而多文档事务需要全局版本戳 + 锁管理器，在分布式环境下会急剧放大写冲突与延迟，与 CouchDB 的“离线优先、移动同步”场景背道而驰。
3. 国内互联网主流架构同样遵循“最终一致性 + 业务补偿”而非刚性事务，因此 CouchDB 的选择与业务实践一致。

业务层补偿案例（电商库存扣减 + 优惠券核销）：

1. 订单服务在 CouchDB 创建订单文档，状态为“CREATE”，同时写入一条本地消息表（也是 CouchDB 文档），包含 orderId、couponId、版本号。
2. 优惠券服务通过_changes 接口监听消息表，幂等消费：先根据 couponId 查询自身文档，若状态仍是“UNUSED”，则更新为“LOCKED”并记录 orderId；更新失败（冲突）则放弃，等待下次重试。
3. 库存服务同样监听消息，扣减成功后把订单状态改为“CONFIRM”；若库存不足，则写入“STOCK_FAIL”事件。
4. 订单服务捕获到“STOCK_FAIL”后，触发反向补偿：再次查询优惠券文档，若已 LOCKED 且匹配当前 orderId，则将其改回“UNUSED”，实现释放优惠券。
5. 每日凌晨跑对账批次，扫描订单、优惠券、库存三方的“成功/失败”标记，对中间状态超过 30 分钟的记录人工复核，确保资金与库存平账，满足国内财务合规。

该方案利用 CouchDB 的单文档原子性 + 变更监听，通过幂等消费 + 状态机 + 反向补偿替代多文档事务，已在多家国内电商平台落地，峰值可支撑2 万 TPS 下单而无锁等待。

拓展思考

1. 若业务必须强一致读，可在关键路径外再建一套MySQL 悲观锁作为“对账副本”，写时双写、读时以 MySQL 为准，CouchDB 仅负责高并发写入与离线同步。
2. 对于跨分片场景，可把补偿消息写入Kafka，利用顺序分区键保证同一订单的事件顺序消费，避免 CouchDB 多节点重试带来的乱序风险。
3. 国内金融级项目常要求秒级对账，可在 CouchDB 文档里增加“账务时间戳 + 全局流水号”，通过 Spark Streaming 每 5 分钟做一次批量校验，提前发现差错，降低夜间批处理压力。