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 < 3; i++) {
try (ClientSession session = mongoClient.startSession()) {
session.withTransaction(() -> {
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 强一致性模型的诚实反馈。重试代码写起来简单，但真正难的是判断——这一删操作，到底有没有必要放在事务里。
