mongodb事务不会自动恢复，应用层需实现幂等重试逻辑；commit失败后事务已丢弃，需结合w:"majority"和j:true保障持久性，并依赖业务设计处理故障。
rs.commitTransaction() 失败后到底发生了什么
当 commitTransaction() 调用因网络中断、Primary 切换或超时而失败时：
- MongoDB 不会“记住”这个事务并稍后提交——它已丢弃，
session中的变更从未写入 oplog； - 客户端收到类似
WriteConcernError或InterruptedDueToReplStateChange的错误； - 如果事务已部分写入（例如某些语句成功但 commit 失败），且未使用
readConcern: "snapshot"，可能产生不一致视图； - 关键点：
abortTransaction()在 commit 失败后**不是必须调用**（因为事务已终止），但显式 abort 更利于调试和日志追踪。
写关注 w: "majority" 和 j: true 是前提条件
没有它们，事务即使返回成功，也可能在故障后丢失：
-
w: "majority"确保事务日志（oplog 条目）被多数节点确认——这是选举后新 Primary 能继续提供服务的基础； -
j: true强制 WiredTiger 日志刷盘，防止 mongod 崩溃导致已确认但未落盘的事务丢失； - 注意：若副本集启用了
writeConcernMajorityJournalDefault: true（默认开启），w: "majority"就隐含j: true；否则需显式指定； - 错误配置示例：
{ w: 1 }或{ w: "majority", j: false }→ 故障后大概率丢数据。
应用层必须实现幂等重试逻辑
驱动（如 Node.js 的 mongodb@6+、Python 的 pymongo）不会自动重试事务——这是有意设计，因为事务语义需由业务控制：
- 捕获特定错误码：
InterruptedDueToReplStateChange、NotMaster、PrimarySteppedDown、WriteConcernFailed； - 对可重试事务（如创建订单、扣库存），用唯一业务 ID（如
order_id）做幂等判断，避免重复提交； - 不要无条件重试所有事务——涉及外部调用（如支付回调）或状态变更（如发货）的事务，重试前必须检查前置状态；
- 示例伪代码（Node.js）：
async function runIdempotentTx(session, orderId) {<br> try {<br> await session.withTransaction(async () => {<br> const order = await orders.findOne({ orderId }, { session });<br> if (order) return; // 幂等：已存在则退出<br> await orders.insertOne({ orderId, status: "pending" }, { session });<br> await inventory.updateOne({ sku: "A123" }, { $inc: { qty: -1 } }, { session });<br> });<br> } catch (err) {<br> if (isRetryableTransactionError(err)) {<br> return runIdempotentTx(session, orderId); // 递归重试（加次数限制）<br> }<br> throw err;<br> }<br>}
副本集配置直接影响事务可用性边界
看似无关的配置，实际决定事务能否在故障窗口内存活：
-
electionTimeoutMillis（默认 10s）：主节点失联后触发选举的时间——越短故障转移越快，但可能误判网络抖动； -
heartbeatIntervalMS（默认 2s）：心跳频率，影响故障发现速度； -
oplogSize：过小会导致 Secondary 落后太多而变 stale，无法参与 majority 写——事务卡住或降级为w: 1； - 仲裁节点（arbiter）不存储数据，也不参与 majority 投票——如果只有 1 主 + 1 arbiter，
w: "majority"实际退化为w: 1，失去容错能力； - 真正可靠的最小配置是：1 Primary + 2 Secondary（或 1 Primary + 1 Secondary + 1 Arbiter），且三者都在线并能通信。
w: "majority" + j: true，它就一定不会因单点故障丢失——其余全是你的代码责任。
