MongoDB写关注配置保障数据安全

先上结论：事务里的 writeConcern 只在 commitTransaction 那一刻才生效，内部那些 insert / update 操作传的参数？全被 MongoDB 当空气。想靠单条操作堆 w: "majority" 来兜底？门儿都没有。

事务中写关注只在 commitTransaction 时生效，单条操作传 writeConcern 参数完全无效。

事务内 insert/update 操作不支持 writeConcern

不少同学天真地以为，给 insertOne 或 updateOne 加上 { writeConcern: { w: "majority" } } 就能让事务更安全——结果 MongoDB 根本不鸟你。事务内部的所有写操作，强制用 { w: 1 } 走天下：主节点内存里写一下就返回，不等着复制，也不等着刷 journal。

• 这是硬编码行为，客户端默认设置也改不了，没得商量。
• 哪怕你写了 collection.insertOne(..., { writeConcern: { w: 3 } })，MongoDB 也是静默忽略，参数压根没落地。
• 唯一能真正把控安全边界的，就是 session.commitTransaction({ writeConcern: ... }) 这一步，绝无第二个入口。

commitTransaction 的 writeConcern 决定最终一致性

commitTransaction 上配置的 writeConcern，控制的是整个事务的 oplog entry 被多少个节点确认后才算成功。它不关心单步操作写没写盘，只关心“这个事务在集群眼里到底算不算已提交”。

• { w: "majority" }（默认）：投票节点里多数写入 oplog 就返回，最适合大部分业务场景。
• { w: "majority", j: true }：多数节点不仅写入 oplog，还得刷到 journal 上才算数。抗宕机能力拉到顶，但延迟也实打实地上去了。
• { w: 1 }：主节点写完 oplog 就返回，延迟最低。但主节点如果挂了且没来得及同步，这个事务就可能回滚。
• w 值不能超过当前健康节点数量。比如你设了 { w: 5 }，但集群里只有 3 个节点活着，事务就会卡住，直到默认超时（60 秒）抛 WriteConcernFailed 错误。

非事务写操作的 writeConcern 配置位置

非事务场景下的普通 CRUD，writeConcern 可以灵活设置，但优先级顺序必须理清楚：事务 > 集合 > 数据库 > 客户端全局。高优先级永远覆盖低优先级。

• 集合级设置最常见：Ja va 里用 collection.withWriteConcern(WriteConcern.MAJORITY)，Python 里用 collection.with_write_concern(WriteConcern("majority"))。
• 客户端全局设置（比如 C# 的 MongoClientSettings.WriteConcern）只影响那些没有显式覆盖的操作。
• Shell 里可以用 db.getMongo().setWriteConcern({ w: 2, wtimeout: 1000 })，但注意它只管后续命令，不回溯前面。
• 避免混用？其实恰恰相反：事务外用 { w: 1 } 提升吞吐，事务内靠 { w: "majority", j: true } 保底——这种组合合理且常见。

容易被忽略的隐式开销

就算你把 commitTransaction 的 writeConcern 降到 { w: 1 }，事务延迟也不一定低。因为 MongoDB 还有两块暗账：

• 事务日志（oplog entry）必须先序列化、加锁、写入主节点的 oplog collection，这本身就是开销。
• 所有参与事务的文档都要先抢两阶段锁（2PL），锁持有时间随操作复杂度线性增长。
• 如果事务还跨了多个分片，协调节点还得额外等各分片 prepare 和 commit 的 RPC 来回跑。

所以，单纯调低 w 值只能砍掉复制等待的时间，但事务本身的串行化和锁竞争成本一样不少，该慢还是慢。