事务与Read/Write Concern

基础信息

MongoDB事务的使用和交互习惯与关系型数据库的事务基本一致，API使用方法也类似，无额外的学习成本。

以下示例为一个完整事务，您可以看到API（startTransaction/abortTransaction/commitTransaction）以及相关联的session和readConcern/writeConcern设置。

// 创建集合
db.getSiblingDB("mydb1").foo.insertOne(
    {abc: 0},
    { writeConcern: { w: "majority", wtimeout: 2000 } }
)
db.getSiblingDB("mydb2").bar.insertOne(
   {xyz: 0},
   { writeConcern: { w: "majority", wtimeout: 2000 } }
)
// 开启一个会话
session = db.getMongo().startSession( { readPreference: { mode: "primary" } } );
coll1 = session.getDatabase("mydb1").foo;
coll2 = session.getDatabase("mydb2").bar;
// 开启一个事务
session.startTransaction( { readConcern: { level: "local" }, writeConcern: { w: "majority" } } );
// 在事务中执行若干操作
try {
   coll1.insertOne( { abc: 1 } );
   coll2.insertOne( { xyz: 999 } );
} catch (error) {
   // 遇到问题时中止事务
   session.abortTransaction();
   throw error;
}
// 提交事务
session.commitTransaction();
session.endSession();

事务的使用说明如下：

• 事务需要与会话（session）关联，一个会话同一时间只能有一个未完成事务。如果会话结束，其关联的未完成事务也会回滚。

• 一个分布式事务可以同时包含对不同库表的不同文档的操作。

• 在事务执行期间，事务能够读取自己未提交的写操作，但事务外部的其他操作不会读取到事务中未提交的写操作。

• 在事务提交之前，不会将未提交的写入数据复制到从节点。一旦事务被提交，写入的数据将被复制并自动应用于所有副本集中的从节点。

• 在修改文档时，事务将锁定文档，使文档无法被其他操作更改，直至事务完成。如果一个事务无法获得它需要修改文档上的锁，可能是因为另一个事务已经持有该锁，那么该事务将在5毫秒后立即终止（该时间由maxTransactionLockRequestTimeoutMillis内核参数控制），并提示写冲突（WriteConflicts）。

• 事务有重试机制，如果遇到了暂时的可重试错误（比如网络临时中断），事务会自动重试。而且客户端对重试操作无感知。

• 事务有生命周期，运行超过60秒的事务将会被后台线程强制终止（该时间由transactionLifetimeLimitSeconds内核参数控制）。

使用限制

• 分布式事务不能创建新的集合和索引。

• 事务不能写入capped集合。

• 事务不能使用快照（snapshot）的Read Concern读取capped集合（该限制存在于MongoDB 5.0及以上版本）。

• 事务不能读写config/admin/local库里的集合。

• 事务不能写形如system.*的系统库表。

• 事务不支持explain。

• 事务无法通过getMore读取事务外创建的游标；事务外也无法通过getMore读取事务内创建的游标。

• 事务内的第一个操作不能为killCursors/hello等。

• 事务内无法执行非CURD的命令，包括listCollections/listIndexes/createUser/getParameter/count等。

• 分布式事务不支持将分片上的writeConcernMajorityJournalDefault参数设置为false。

• 分布式事务不支持带arbiters的分片。

最佳实践

内核缺陷风险说明

创建长时间运行的大事务，或者试图在单个事务中执行过多的操作，都会给WiredTiger存储引擎的缓存带来很大压力。因为自最早的已创建未提交事务起，WiredTiger缓存必须能为所有后续的写入维持相关数据和状态。由于事务在运行时使用相同的快照，因此，在整个事务运行期间，新的写操作会持续累积在WiredTiger缓存中。当前运行在旧快照上的事务在提交或中止之前，缓存中的这些写操作都不能被逐出。而长事务引起的WiredTiger缓存压力超载（wt cache使用率以及dirty使用率超阈值）通常会带来更多的问题，包括数据库卡顿、请求延时大幅增加、CPU使用率满等问题，甚至出现“死锁”，导致业务受损。更多关于内核风险的介绍，请参见SERVER-50365和SERVER-51281。

云数据库 MongoDB 版建议所有重度使用事务的业务都将MongoDB实例升级至5.0及以上的版本来规避相关风险和隐患。

基础信息

控制一致性和隔离级别的Read Concern包括以下几种：

• "local"：副本集架构下读主或从节点时的默认级别，从本地读取，可能会读到被回滚的数据。

• "available"：分片集群架构下读从节点时的默认级别，可能读到会被回滚的数据。读数据前不会进行shardVersion的检查，因此可能读到孤立文档。优点是提供了最优的访问延迟。

• "majority"：读取的是已被大多数节点确认的数据，即不会被回滚的数据。

• "linearizable"：数据一致性要求最严格的线性化级别，读操作需要等待所有前序写入都已经被大多数节点确认。性能最差，只能在主节点上使用。

• "snapshot"：基于快照读取，同样读取的是已被大多数节点确认的数据，只不过可以关联某一个特定时间点的快照，比如配合atClusterTime使用。

Read Concern的使用说明如下：

• 无论Read Concern的级别如何，某一个mongod节点上最新的数据都不代表副本集中最近版本的数据。

• 可以为不同的操作指定不同的Read Concern，4.4及以上版本也可以设置服务器端默认的Read Concern，操作的Read Concern优先级高于服务器端设置的Read Concern。

• 当读取local库时，您指定的Read Concern会被忽略，您总是能在local库里读到所有本地数据。

• 分布式事务里仅支持3种Read Concern级别，分别为"local"、"majority"、"snapshot"。

• 因果一致性会话里，必须使用"majority"级别的Read Concern。

最佳实践

基础信息

指定Write Concern的格式如下。关于Write Concern的更多介绍，请参见Write Concern。

{ w: <value>, j: <boolean>, wtimeout: <number> }

• 控制数据持久化保证级别的Write Concern可以简单分为以下几种主要级别：

  • {w: 0}：表示写（write）不确认，不确认写操作是否完成，可能发生写入数据丢失。

  • {w: 1}：表示写（write）确认，为MongoDB 5.0版本以前的默认行为。确认写操作在内存中已完成，但由于还没有持久化，依然可能发生数据丢失。

  • {j: true}：表示日志（journal）确认。确认写操作已完成并刷到持久化存储的WAL中，写操作不会丢失。

  • { w: "majority" }：表示大多数（majority），为MongoDB 5.0及以上版本的默认行为。等待写操作被复制到副本集中大多数节点上后才确认，数据不会被回滚。

  • 副本确认：等待写操作被复制到副本集中指定数量的节点上后才确认。

  • 自定义确认：可以通过settings.getLastErrorModes参数指定其他自定义的带tag确认方式。

Write Concern的使用说明如下：

• 您可以在任何写操作或者事务中指定Write Concern，未显示指定时会使用默认值。

  说明

  从MongoDB 5.0版本开始，标准3副本拓扑结构下，默认的全局Write Concern已经从之前的{w:1}调整为{w:"majority"}。这可能会导致您将数据库版本升级至5.0及以上版本后出现性能退化问题。

• 副本集中的隐藏（Hidden）节点、延迟（Delayed）节点、或其他优先级为0的可投票节点均可以视为"majority"中的一员。

• 您可以为不同的操作指定不同的Write Concern，4.4及以上版本也可以设置服务器端默认的Write Concern，操作的Write Concern优先级高于服务器端设置的Write Concern。

• 当写入local库时，您指定的Write Concern会被忽略。

• 因果一致性会话里，必须使用"majority"的Write Concern。

最佳实践