MongoDB事务仅保障单集群ACID，无法协调Redis等外部系统；跨系统原子性需结合Redis分布式锁、幂等操作、状态校验与全程监控。
为什么 MongoDB 事务本身不能解决跨系统原子性问题
MongoDB 的 session.startTransaction() 只能保证单集群内多文档操作的 ACID，一旦涉及 Redis（比如更新缓存、发消息、调第三方 API），事务就断了。MongoDB 不会、也不能把 Redis 操作纳入它的两阶段提交流程——这不是设计目标，也不是驱动层能协调的事。
常见错误现象：writeConcern: { w: "majority" } 设得再严，redis.set("order_status", "paid") 还是可能在 MongoDB 提交前/后失败，导致状态不一致。
所以“用 MongoDB 事务 + Redis”不是叠加两个原子操作，而是用 Redis 做协调者，让 MongoDB 操作变成“可重试的幂等步骤”，再靠锁控制执行时序。
用 Redis 实现可重入、带自动续期的分布式锁
直接用 SET key value NX PX 30000 太简陋：超时时间难估算、不可重入、崩溃后锁残留、没续期机制——这些都会让 MongoDB 事务卡死或重复执行。
实操建议：
- 用
Redlock算法（或更轻量的redisson客户端）管理多节点容错，避免单点故障导致锁失效 - 锁 value 必须是唯一请求 ID（如
UUID.randomUUID().toString()），不是固定字符串，否则无法安全释放 - 加锁后立即启动后台心跳线程，用
EVAL脚本原子地判断并延长PEXPIRE，续期间隔设为 TTL 的 1/3（比如 TTL=30s，每 10s 续一次） - MongoDB 事务体必须包裹在
try...finally中，且finally里调用unlock()脚本（用if redis.call("get",KEYS[1]) == ARGV[1]校验 ownership）
事务体内部必须满足幂等 + 显式状态检查
锁只解决“同一时刻只有一个进程进入”，不解决“进程中途挂了重试时怎么不重复扣款”。所以 MongoDB 操作要自带防御逻辑。
典型场景：支付成功后更新订单状态并扣减库存。
错误写法：db.orders.updateOne({ _id: oid }, { $set: { status: "paid" } }) —— 重试会覆盖，但库存已扣，状态却反复设为 paid。
正确做法：
- 先查当前状态：
db.orders.findOne({ _id: oid, status: { $in: ["created", "pending"] } })，查不到直接跳过整个事务 - 更新时带上前置条件：
db.orders.updateOne({ _id: oid, status: "pending" }, { $set: { status: "paid" } })，返回matchedCount === 1才继续扣库存 - 库存扣减也走条件更新：
db.inventory.updateOne({ sku: "A123", stock: { $gte: 1 } }, { $inc: { stock: -1 } })，匹配失败说明库存不足，整个事务应回滚
锁粒度与性能陷阱：别锁整库，也别锁太细
用订单 ID 当锁 key（lock:order:12345）是合理选择；用用户 ID（lock:user:6789）容易引发热点争抢；用业务类型（lock:payment）等于串行化所有支付，吞吐归零。
容易被忽略的点：
- Redis 锁的 TTL 必须明显长于 MongoDB 事务最坏执行时间（含网络抖动），但也不能过长——比如设 10 分钟，而事务平均 2 秒，那一个卡住的请求会让后续 10 分钟请求全排队
- 如果事务里调了外部 HTTP 接口，锁必须覆盖整个调用周期，不能只包 MongoDB 操作。否则接口成功但 MongoDB 回滚，状态就裂开了
- 监控一定要埋点：记录
lock_wait_time_ms、transaction_duration_ms、retry_count，三者同时飙升往往意味着锁设计或慢查询出了问题
跨系统原子性从来不是靠一个锁或一个事务实现的，而是靠锁控并发、事务保本地一致性、幂等保重试安全、监控保问题可见——少一环，数据就可能悄悄歪掉。
