为什么MongoDB事务执行时报WriteConflict错误_实施指数退避重试机制-MongoDB-PHP中文网

writeconflict（错误码112）是mongodb mvcc快照校验失败导致的事务中止，非业务逻辑错误；它由snapshot isolation机制触发，当事务依赖的文档快照被其他事务修改时立即抛出uncategorizedmongodbexception并含"writeconflict"字符串，需用spring retry精准匹配该关键字重试，同时拆分大事务、避免单文档热点，并合理调大maxtransactionlockrequesttimeoutmillis。

为什么mongodb事务执行时报writeconflict错误_实施指数退避重试机制

WriteConflict不是业务冲突，是MVCC快照检测失败

WriteConflict（错误码 112）不是你代码写错了，也不是文档被“锁死”了，而是 MongoDB 的 Snapshot Isolation（SI）机制在事务提交前发现：当前事务所依赖的文档快照，已被另一个已提交（或正在提交）的事务修改过。它立刻中止你这个事务，不重试、不等待，直接抛 UncategorizedMongoDbException 并带 "WriteConflict" 字符串。

这和 MySQL 的行锁阻塞完全不同——MongoDB 不会 hang 住请求等锁释放，而是乐观地执行、悲观地校验。只要两个事务碰巧改了同一文档（哪怕只是 updatedAt 字段），后提交者必败。

常见触发点：多个线程/服务同时 updateOne({ _id: orderId }, { $set: { status: "shipped" } }) 同一订单
容易被忽略：事务内先 findOne() 读某文档，再更新它 → 读操作也绑定快照，别人一改就冲突
注意：即使你没显式开启事务，只要用了 @Transactional + Spring Data MongoDB，默认就会进事务上下文

Spring Retry 必须匹配 WriteConflict 字符串判断

Spring 官方明确要求：不能只捕获 UncategorizedMongoDbException 就重试，因为该异常覆盖范围太广（网络超时、权限拒绝、语法错误都可能走这里）。必须用表达式精准匹配错误消息里的 WriteConflict 关键字，否则会把本不该重试的错误反复执行。

正确配置示例如下：

@Retryable(
  value = UncategorizedMongoDbException.class,
  exceptionExpression = "#{message.contains('WriteConflict')}",
  maxAttempts = 8,
  backoff = @Backoff(delay = 100, multiplier = 2.0)
)
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void updateOrderStatus(String orderId, String newStatus) {
  // ... 实际更新逻辑
}

delay = 100：首次重试延迟 100ms
multiplier = 2.0：每次翻倍，即 100 → 200 → 400 → 800 → 1600ms… 避免雪崩式重试
maxAttempts = 8：总重试上限建议 ≤ 8，再高大概率是设计问题，不是临时抖动
务必加 Propagation.REQUIRES_NEW：保证每次重试都在干净新事务里，避免嵌套事务状态污染

重试不是万能解药，得先砍掉长事务和热点文档

如果重试后仍高频报错，说明你在拿胶带修炸药桶——根本矛盾没解决。WriteConflict 频发本质是两种场景叠加：

疯狂翻译师App

疯狂翻译师App是一款面向语音、图片、文本和拍照识别场景的移动翻译工具。

下载

事务粒度太大：比如把 50 万条 insertMany 塞进一个事务 → WiredTiger 缓存爆、快照膨胀、锁持有时间长达数分钟 → 冲突概率指数上升
单文档热点太集中：如库存扣减、计数器累加、订单状态机，所有并发请求都打在同一 _id 上 → 冲突不可避免

此时光靠重试只会让延迟更毛刺、吞吐更低。必须同步做两件事：

把大事务拆成小事务：每批 ≤ 1000 条 insertMany，每个批次独立 startTransaction() → 事务生命周期压到 100ms 内
把单文档更新换成原子操作：findOneAndUpdate 或 updateOne 带条件更新，彻底绕过事务快照链；需要返回旧值？用 returnDocument: "before" 参数
对真·高频计数类场景（如 PV 统计），直接放弃单文档，改用分片计数器（counter_shard_0, counter_shard_1…）再聚合

别漏掉 maxTransactionLockRequestTimeoutMillis 这个隐藏开关

MongoDB 默认事务锁等待超时仅 5 毫秒，比一次 Redis 网络往返还短。当副本集负载稍高、WAL 刷盘延迟、或 WiredTiger 页面换入慢一点，就直接触发 WriteConflict —— 这不是冲突，是等不及。

调大它能显著降低误报，但必须服务端统一配置（不能只改应用）：

在线生效（推荐测试环境快速验证）：db.adminCommand({ setParameter: 1, maxTransactionLockRequestTimeoutMillis: 3000 })
配置文件（生产环境首选）：在 /etc/mongod.cnf 的 setParameter 下加一行 maxTransactionLockRequestTimeoutMillis=3000
重启 mongod 或滚动重启副本集节点（分片集群需每台都设）

注意：该参数治标不治本。3000ms 是合理上限，设到 10000ms 以上反而会掩盖真实热点问题，让系统在低吞吐下“假装正常”。