mongodb事务默认采用快照隔离（snapshot isolation），依托mvcc实现强一致性，支持acid特性；其隔离性由readconcern控制，包括local、majority、snapshot三级，不直接对应sql标准隔离级别。
为什么不能直接用 findAndModify 做秒杀库存扣减
单靠 findAndModify 无法保证秒杀场景下的强一致性——它只提供文档级原子性，不解决并发请求同时读到同一库存值后各自扣减的问题。比如库存剩 1，两个请求几乎同时执行 findAndModify({$inc: {stock: -1}})，都成功返回，结果库存变成 -1。
根本原因是：MongoDB 的 findAndModify 默认运行在“未提交读”隔离级别下，不阻塞其他读写，也不参与事务协调。它适合简单计数器或幂等更新，但不适合带条件判断的业务逻辑（如“仅当 stock > 0 才扣减”）。
实操建议：
- 必须把“检查库存是否充足 + 扣减”封装在同一个原子操作内，且该操作需受事务隔离保护
- 不能依赖应用层 if 判断后再调
findAndModify，这中间存在竞态窗口 - 若坚持用
findAndModify，至少要加$gt: 0条件并检查返回结果是否匹配（即返回 doc 不为空），但这仍不是事务，失败后需重试逻辑兜底
如何用 MongoDB 多文档事务正确实现秒杀扣减
MongoDB 4.0+ 支持副本集上的多文档 ACID 事务，是秒杀库存控制的合理选择。关键在于把查询、判断、更新收束在一次事务中，并利用写锁和快照隔离避免超卖。
实操建议：
- 事务必须在副本集（而非单节点）上启用，且驱动版本 ≥ 4.0（Node.js 驱动需 3.6+）
- 开启事务前，确保集合已建好索引：
{ skuId: 1 }，否则事务内查询可能全表扫描，拖慢提交并增加锁持有时间 - 事务内不要做 HTTP 调用、日志 IO 或长耗时计算，否则会延长锁持有，引发超时（默认 60 秒）
- 典型流程：启动事务 →
findOne({skuId: "A", stock: {$gt: 0}})→ 若存在则updateOne({skuId: "A"}, {$inc: {stock: -1}})→ 提交；否则 abort
示例（Node.js）：
const session = client.startSession();
try {
await session.withTransaction(async () => {
const item = await collection.findOne(
{ skuId: "SKU123", stock: { $gt: 0 } },
{ session }
);
if (!item) throw new Error("out of stock");
await collection.updateOne(
{ skuId: "SKU123" },
{ $inc: { stock: -1 } },
{ session }
);
});
} catch (err) {
// 处理库存不足或事务冲突
}
findAndModify 在事务里能用吗？性能影响有多大
能用，但没必要。在事务上下文中，findAndModify 和先 findOne 再 updateOne 行为一致，都受事务隔离保护。但它隐藏了“查-判-改”的逻辑分支，不利于错误归因和重试控制。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
更实际的问题是性能：事务内使用 findAndModify 并不会比两步操作更快，反而因返回整个文档可能增加网络和内存开销。尤其当商品文档很大（含详情、图片 URL 等），而你只关心 stock 字段时，浪费明显。
实操建议：
- 优先用
findOne+ 显式条件判断，逻辑清晰，便于打点监控“命中率”和“拒绝率” - 若坚持用
findAndModify，务必指定projection: { stock: 1, _id: 0 }减少数据传输 - 注意：事务内所有操作共享同一快照时间点，所以
findAndModify看到的库存值，就是事务开始时的值，不会被其他并发事务中途修改——这点才是隔离性的核心保障
容易被忽略的隔离性细节和线上坑
MongoDB 事务默认使用“快照隔离（SI）”，不是可串行化（SERIALIZABLE）。这意味着：两个事务同时读写不同文档，但逻辑上存在依赖（比如 A 事务扣减库存，B 事务基于该库存发通知），B 可能读到旧值，导致业务逻辑错乱。
更隐蔽的是：事务超时后自动 abort，但客户端可能没捕获异常，误以为成功；或者重试时没清空本地缓存，重复提交。
实操建议：
- 永远校验事务返回结果：比如
updateOne的result.matchedCount必须为 1，否则说明条件不满足（库存已被抢完） - 给事务设置显式
maxTimeMS（如 3000），避免长事务拖垮整个 replica set - 不要在事务里更新多个 SKU——秒杀通常是单 SKU 高并发，跨 SKU 事务会扩大锁范围，降低吞吐
- 上线前压测重点不是 QPS，而是“事务冲突率”和“abort 后重试成功率”，这两个指标比平均响应时间更能反映真实瓶颈
真正卡住系统的，往往不是语法写错，而是事务粒度没对齐业务边界，或者没意识到快照隔离下“读不阻塞写、写不阻塞读”带来的逻辑时序错位。
