MongoDB 的多文档 ACID 事务虽然强大，但在使用时确实有一些限制和需要特别注意的事项。
以下是主要的限制和注意事项：

1. 性能开销 (Performance Overhead)

• 额外协调: 事务需要额外的协调工作，包括跟踪事务状态、管理锁（即使是乐观锁，也需要检测冲突）等。
• 资源消耗: 事务会消耗更多的服务器资源（CPU、内存）。
• 写关注 (Write Concern): 事务默认使用 writeConcern: "majority" 来保证持久性，这比某些非事务性操作使用w:1 更耗时。
• 对吞吐量的影响: 对于高并发、高吞吐量的写密集型应用，大量使用事务可能会降低整体吞吐量。
• 建议:
  • 优先考虑通过数据建模（如内嵌文档）来利用 MongoDB 的单文档原子性，这通常性能更高。
  • 仅在确实需要跨多个文档、多个集合进行原子操作时才使用事务。
  • 保持事务简短。

2. 事务生命周期和大小限制 (Transaction Lifetime and Size Limits)

• 事务最大运行时长 (transactionLifetimeLimitSeconds):
  • MongoDB 事务有一个默认的最大运行时长，通常是 60 秒。可以通过服务器参数 transactionLifetimeLimitSeconds 进行配置。
  • 长时间运行的事务会占用资源并可能阻塞其他操作，因此应尽量避免。如果事务超时，它将被自动中止。
• 事务内操作大小:
  • 事务中所有操作的总 BSON 大小不能超过 MongoDB BSON 文档的最大大小（目前是 16MB）。
  • 更准确地说，是事务中所有写操作产生的 oplog 条目总大小有限制。单个 oplog 条目本身也受 16MB 限制。
  • 大型事务会消耗大量内存来跟踪状态。
• 建议:
  • 将大型操作分解为多个较小的事务（如果业务逻辑允许）。
  • 确保事务涉及的数据量和操作数量在合理范围内。

3. 写冲突 (Write Conflicts)

• MongoDB 事务使用乐观并发控制 (Optimistic Concurrency Control) 和快照隔离 (Snapshot Isolation)。
• 如果两个或多个并发事务尝试修改同一个文档，只有一个事务能够成功提交，其他事务会因为写冲突而失败并中止。
• 当发生写冲突时，MongoDB 会抛出 MongoException 的子类，如 MongoTransactionException (通常是 MongoWriteConflictException 或 TransientTransactionError 标签)。
• 建议:
  • 应用程序必须捕获这些与事务相关的异常，并实现重试逻辑。 这是使用 MongoDB 事务时非常关键的一点。
  • 重试时可以考虑加入退避策略（如指数退避）。
  • 设计应用时尽量减少不同事务对同一文档的并发写操作。

4. 操作限制 (Operational Constraints)

• DDL 操作限制:
  • 不能在事务内创建集合或索引。 如果事务中的操作需要一个尚不存在的集合或索引，你必须在事务开始之前创建它们。
  • 如果在一个事务正在使用某个集合时，另一个操作（事务外或事务内，取决于具体操作）尝试删除、重命名该集合，或修改该集合的元数据（如 collMod），可能会导致事务中止。
  • 在事务内可以创建视图（createView）。
• 非 CRUD 操作:
  • 许多管理命令和非 CRUD 操作（如 listCollections, listIndexes, explain, getDiagnosticData, ping, mapReduce 等）不能在事务内运行。
  • 支持的命令主要集中在 CRUD (insert, update, delete, find) 和一些辅助命令如 findAndModify。
• Capped Collections: 不能在事务中对 capped collections 执行写操作。
• system.* 集合: 不能在事务中对 system.* 命名空间下的集合（如 system.users, system.profile）执行写操作。
• config 数据库: 通常不允许在事务中写入 config 数据库中的集合。
• count 命令: 在 MongoDB 4.0.3+ 的事务中，count 命令及其 shell 辅助方法 db.collection.count() 不可用。应使用 db.collection.countDocuments() 或 db.collection.estimatedDocumentCount()，或者通过聚合 $count 或 $group 实现。

5. 环境和版本要求

• MongoDB 版本:
  • 副本集: 4.0 或更高版本。
  • 分片集群: 4.2 或更高版本。
• 部署模式: 必须是副本集 (Replica Set) 或分片集群 (Sharded Cluster)。Standalone (单节点) 模式不支持多文档事务。
• 存储引擎: 必须使用 WiredTiger 存储引擎（这是 MongoDB 3.2 以来的默认引擎）。
• 驱动程序版本: 必须使用支持 MongoDB 事务 API 的官方驱动程序版本。Spring Data MongoDB 会依赖于兼容的 Java 驱动。

6. Oplog 大小 (Oplog Size)

• 事务中的每个写操作都会生成 oplog 条目。
• 如果事务包含大量写操作，或者事务本身很大，会消耗更多的 oplog 空间。
• 如果 oplog 大小不足，可能会导致副本集成员同步滞后或需要更频繁地调整 oplog 大小。
• 建议: 监控 oplog 使用情况，并根据需要调整 oplog 大小。

7. 分片集群的额外考虑 (Sharded Clusters)

• 协调器 (Coordinator): 跨分片事务需要一个分片作为事务协调器，这会增加一些复杂性和潜在的单点瓶颈（尽管协调器本身是高可用的）。
• 性能: 跨分片事务的开销通常比单分片事务或副本集事务要高，因为涉及到多个分片之间的通信和协调。
• Chunk 迁移: 如果事务涉及的集合正在进行 chunk 迁移，事务可能会失败。MongoDB 会尝试处理这种情况，但长时间或大规模的迁移可能会增加冲突的概率。
• 事务提交协议: 使用两阶段提交 (2PC) 或类似的协议来确保跨分片的原子性。

8. 外部交互 (External Interactions)

• 事务的原子性仅限于 MongoDB 内部的操作。如果事务中包含对外部系统（如消息队列、其他数据库）的调用，MongoDB 无法保证这些外部操作的原子回滚。
• 建议: 如果需要与外部系统进行原子交互，可能需要考虑使用 Saga 模式或其他分布式事务协调策略。

9. 客户端会话 (Client Sessions)

• 事务必须在客户端会话 (client session) 的上下文中执行。
• Spring Data MongoDB 和 @Transactional 注解会自动处理会话的创建、传递和结束。
• 如果直接使用 MongoTemplate 手动管理事务，需要确保正确处理会话。

总结建议：

1. 优先数据建模: 尽可能通过内嵌文档或合理的 schema 设计来利用单文档原子性，避免不必要的事务。
2. 事务要精简: 保持事务简短，只包含真正需要原子性的操作。
3. 处理写冲突: 务必在应用程序中实现对 MongoTransactionException (尤其是 MongoWriteConflictException 和 TransientTransactionError 标签) 的捕获和重试逻辑。
4. 了解操作限制: 清楚哪些操作可以在事务内执行，哪些不能。
5. 监控: 监控事务性能、oplog 使用情况和写冲突率。
6. 测试: 充分测试事务逻辑，特别是在并发场景下。

MongoDB 事务是一个强大的功能，但并非万能药。合理的使用可以帮助我们构建出更健壮的应用程序，但滥用则可能导致性能问题。