怎样配置MongoDB的写关注（Write Concern）以确保数据安全？

事务中writeConcern仅在commitTransaction时生效，内部insert/update操作强制使用{w:1}且忽略传入参数；commit时指定{w:"majority",j:true}可确保多数节点持久化，但w值不可超过健康节点数。

事务中写关注只在 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，但优先级顺序必须清楚：事务 > 集合 > 数据库 > 客户端全局。高优先级设置会覆盖低优先级。

• 集合级最常用：collection.withWriteConcern(WriteConcern.MAJORITY)（Java）或 collection.with_write_concern(WriteConcern("majority"))（Python）
• 客户端全局设置（如 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 值只能减少复制等待，不能消除事务本身的串行化和锁竞争成本。