WriteConflict 错误是 MongoDB 事务快照隔离机制触发的可重试信号,非数据逻辑冲突;并发删同一文档时后提交事务必失败,需配合指数退避重试或从设计上规避(如非事务删除、分片、建索引)。

WriteConflict 错误在 MongoDB 删除操作中不是数据逻辑冲突,而是事务快照机制触发的重试信号——删同一文档的并发事务会互相中断,必须重试。
为什么 deleteOne/deleteMany 会抛 WriteConflict
MongoDB 的事务基于快照隔离(SI),只要两个事务尝试修改(含删除)同一个文档,后提交者必然收到 WriteConflict 错误(错误码 112)。这和 MySQL 行锁阻塞不同,MongoDB 不等锁、直接中止并报错。常见于:定时任务清缓存、高并发用户注销、状态归档脚本批量删过期记录等场景。
- 即使只是
deleteOne({ _id: "xxx" }),只要另一事务正在更新或删除该文档,当前事务就可能失败 - 使用
withTransaction包裹删除时,整个事务生命周期内所有读写都受快照约束,冲突概率随事务时长线性上升 - 错误信息里带
"errorLabels": ["TransientTransactionError"],说明这是可重试的瞬态错误,不是数据损坏
Spring Boot 中用 @Retryable 捕获并重试 delete 操作
Spring Data MongoDB 的 UncategorizedMongoDbException 是 WriteConflict 的实际抛出类型,需靠表达式匹配错误消息才能精准捕获。
- 不要只写
@Retryable(value = UncategorizedMongoDbException.class)—— 它会把连接超时、权限错误等全重试,反而掩盖真问题 - 必须加
exceptionExpression = "#{message.contains('WriteConflict')}"过滤 -
maxAttempts = 8足够(指数退避下 8 次总耗时约 1.5 秒),再高容易拖垮下游服务 - 删除操作本身幂等,重试安全;但若删除前有查+删两步,需确保查询也走同一事务 session,否则可能重复删
@Retryable(
value = UncategorizedMongoDbException.class,
exceptionExpression = "#{message.contains('WriteConflict')}",
maxAttempts = 8,
backoff = @Backoff(delay = 100, multiplier = 2)
)
@Transactional(propagation = Propagation.REQUIRED)
public void deleteExpiredSessions(String cutoffTime) {
sessionCollection.deleteMany(
Filters.lt("lastAccessed", cutoffTime)
);
}
原生驱动中手动重试 delete 的最小闭环
不用 Spring 时,必须自己实现重试逻辑,且要区分“事务内删”和“非事务删”两种路径。
- 非事务删(推荐):
collection.deleteMany()本身不进事务,冲突极少;若仍报 WriteConflict,大概率是 WiredTiger 缓存不足或副本集同步延迟,应调大wiredTigerCacheSizeGB - 事务内删:必须用
session.withTransaction()包裹,且重试逻辑写在外层,不能在回调函数里递归调用自己(会泄漏 session) - 重试次数建议硬编码为 3–5 次,超过则 log.warn 并抛原始异常,避免无限循环
- 每次重试前 sleep 随机毫秒(如 50–200ms),减少再次撞上同一冲突窗口的概率
for (int i = 0; i {
collection.deleteMany(session, Filters.eq("_id", id));
});
return; // success
} catch (MongoCommandException e) {
if (e.getErrorCode() == 112 && e.getErrorMessage().contains("WriteConflict")) {
Thread.sleep(50 + (long)(Math.random() * 150));
continue;
}
throw e;
}
}
比重试更治本的三个规避点
重试是兜底手段,真正降低 WriteConflict 频次得从设计入手。
- 删操作尽量不进事务:除非它必须和其它集合的写入强一致,否则直接
deleteMany更快更稳 - 高频删同一类文档(如日志、会话)时,用时间分片:按小时建集合
sessions_20260512_10,删整库比删百万文档快十倍,且无冲突 - 避免
deleteMany扫全表:确保删条件字段有索引,否则 WiredTiger 在扫描过程中持续持快照页锁,极大提高冲突率
WriteConflict 看似是错误,实则是 MongoDB 强一致性模型的诚实反馈。重试代码写起来简单,但真正难的是判断——这一删操作,到底有没有必要放在事务里。











