Docs Home → MongoDB Manual

Read Isolation, Consistency, and Recency读取隔离性、一致性和近期性

On this page本页内容

Isolation Guarantees隔离保证

Read Uncommitted未提交读

Depending on the read concern, clients can see the results of writes before the writes are durable:根据读取关注的不同，客户端可以在写入持久之前看到写入的结果：

  • Regardless of a write's write concern, other clients using "local" or "available" read concern can see the result of a write operation before the write operation is acknowledged to the issuing client.无论写入的写入关注如何，使用"local"或"available"读取关注的其他客户端都可以在向发出请求的客户端确认写入操作之前看到写入操作的结果。
  • Clients using "local" or "available" read concern can read data which may be subsequently rolled back during replica set failovers.使用"local"或"available"读取关注的客户端可以读取数据，这些数据随后可能在副本集故障切换期间回滚。

For operations in a multi-document transaction, when a transaction commits, all data changes made in the transaction are saved and visible outside the transaction. That is, a transaction will not commit some of its changes while rolling back others.对于多文档事务中的操作，当事务提交时，事务中所做的所有数据更改都将保存并在事务外部可见。也就是说，事务在回滚其他更改时不会提交某些更改。

Until a transaction commits, the data changes made in the transaction are not visible outside the transaction.在事务提交之前，在事务中所做的数据更改在事务外部是不可见的。

However, when a transaction writes to multiple shards, not all outside read operations need to wait for the result of the committed transaction to be visible across the shards. 然而，当一个事务写入多个分片时，并不是所有的外部读取操作都需要等待提交的事务的结果在分片中可见。For example, if a transaction is committed and write 1 is visible on shard A but write 2 is not yet visible on shard B, an outside read at read concern "local" can read the results of write 1 without seeing write 2.例如，如果事务已提交，并且写1在分片a上可见，但写2在分片B上还不可见，则外部读取时关注点"local"可以读取写1的结果，而不会看到写2。

Read uncommitted is the default isolation level and applies to mongod standalone instances as well as to replica sets and sharded clusters.未提交读取是默认的隔离级别，适用于mongod独立实例以及副本集和分片集群。

Read Uncommitted And Single Document Atomicity读取未提交和单个文档原子性

Write operations are atomic with respect to a single document; i.e. if a write is updating multiple fields in the document, a read operation will never see the document with only some of the fields updated. 写入操作是针对单个文档的原子操作；即，如果写入操作正在更新文档中的多个字段，则读取操作将永远看不到只更新了某些字段的文档。However, although a client may not see a partially updated document, read uncommitted means that concurrent read operations may still see the updated document before the changes are made durable.然而，尽管客户端可能看不到部分更新的文档，但未提交读取意味着在更改持久之前，并发读取操作可能仍会看到更新的文档。

With a standalone mongod instance, a set of read and write operations to a single document is serializable. 使用独立的mongod实例，对单个文档的一组读写操作是可序列化的。With a replica set, a set of read and write operations to a single document is serializable only in the absence of a rollback.对于副本集，只有在没有回滚的情况下，对单个文档的一组读写操作才是可序列化的。

Read Uncommitted And Multiple Document Write读取未提交和多文档写入

When a single write operation (e.g. db.collection.updateMany()) modifies multiple documents, the modification of each document is atomic, but the operation as a whole is not atomic.当单个写操作（例如db.collection.updateMany()）修改多个文档时，每个文档的修改都是原子性的，但整个操作不是原子性的。

When performing multi-document write operations, whether through a single write operation or multiple write operations, other operations may interleave.当执行多文档写入操作时，无论是通过单个写入操作还是通过多个写入操作，其他操作都可能交错。

For situations that require atomicity of reads and writes to multiple documents (in a single or multiple collections), MongoDB supports multi-document transactions:对于需要对多个文档（在单个或多个集合中）进行原子性读写的情况，MongoDB支持多文档事务：

  • In version 4.0, MongoDB supports multi-document transactions on replica sets.，MongoDB支持副本集上的多文档事务。
  • In version 4.2, MongoDB introduces distributed transactions, which adds support for multi-document transactions on sharded clusters and incorporates the existing support for multi-document transactions on replica sets.，MongoDB引入了分布式事务，增加了对分片集群上多文档事务的支持，并整合了对副本集上多文档事务的现有支持。

For details regarding transactions in MongoDB, see the transactions page.有关MongoDB中事务的详细信息，请参阅事务页面。

Important

In most cases, multi-document transaction incurs a greater performance cost over single document writes, and the availability of multi-document transactions should not be a replacement for effective schema design. 在大多数情况下，与单文档写入相比，多文档事务会产生更高的性能成本，并且多文档事务的可用性不应取代有效的模式设计。For many scenarios, the denormalized data model (embedded documents and arrays) will continue to be optimal for your data and use cases. 对于许多场景，非规范化数据模型（嵌入文档和数组）将继续是您的数据和用例的最佳选择。That is, for many scenarios, modeling your data appropriately will minimize the need for multi-document transactions.也就是说，对于许多场景，对数据进行适当建模将最大限度地减少对多文档事务的需求。

For additional transactions usage considerations (such as runtime limit and oplog size limit), see also Production Considerations.有关其他事务使用注意事项（如运行时限制和操作日志大小限制），请参阅生产注意事项。

Without isolating the multi-document write operations, MongoDB exhibits the following behavior:在不隔离多文档写入操作的情况下，MongoDB表现出以下行为：

  1. Non-point-in-time read operations. Suppose a read operation begins at time t 1 and starts reading documents. 非时间点读取操作。假设读取操作在时间t1开始，并开始读取文档。A write operation then commits an update to one of the documents at some later time t 2. 写入操作然后在稍后的某个时间t2提交对其中一个文档的更新。The reader may see the updated version of the document, and therefore does not see a point-in-time snapshot of the data.读者可能会看到文档的更新版本，因此看不到数据的时间点快照。
  2. Non-serializable operations. Suppose a read operation reads a document d 1 at time t 1 and a write operation updates d 1 at some later time t 3. This introduces a read-write dependency such that, if the operations were to be serialized, the read operation must precede the write operation. 不可序列化的操作。假设读取操作在时间t1读取文档d1，并且写入操作在稍后的某个时间t3更新d1。这引入了读写依赖关系，因此，如果要序列化操作，则读取操作必须先于写入操作。But also suppose that the write operation updates document d 2 at time t 2 and the read operation subsequently reads d 2 at some later time t 4. 但是也假设写入操作在时间t2更新文档d2，并且读取操作随后在稍后的某个时间t4读取d2。This introduces a write-read dependency which would instead require the read operation to come after the write operation in a serializable schedule. 这引入了一个写-读依赖关系，它将要求在可序列化计划中的写操作之后进行读操作。There is a dependency cycle which makes serializability impossible.存在一个依赖循环，使可序列化性变得不可能。
  3. Reads may miss matching documents that are updated during the course of the read operation.读取操作可能会错过在读取操作过程中更新的匹配文档。

Cursor Snapshot游标快照

MongoDB cursors can return the same document more than once in some situations. 在某些情况下，MongoDB游标可以多次返回同一文档。As a cursor returns documents, other operations may interleave with the query. 当游标返回文档时，其他操作可能会与查询交织在一起。If one of these operations changes the indexed field on the index used by the query, then the cursor could return the same document more than once.如果其中一个操作更改了查询使用的索引上的索引字段，则游标可能多次返回同一文档。

Queries that use unique indexes can, in some cases, return duplicate values. 在某些情况下，使用唯一索引的查询可能返回重复的值。If a cursor using a unique index interleaves with a delete and insert of documents sharing the same unique value, the cursor may return the same unique value twice from different documents.如果使用唯一索引的游标与共享相同唯一值的文档的删除和插入交错，则游标可能会从不同文档中两次返回相同的唯一值。

Consider using read isolation. To learn more, see Read Concern "snapshot".考虑使用读取隔离。要了解更多信息，请参阅读取关注"snapshot"。

Monotonic Writes单调写作

MongoDB provides monotonic write guarantees, by default, for standalone mongod instances and replica set.默认情况下，MongoDB为独立的mongod实例和副本集提供单调的写入保证。

For monotonic writes and sharded clusters, see Causal Consistency.有关单调写入和分片集群，请参阅因果一致性。

Real Time Order实时订单

For read and write operations on the primary, issuing read operations with "linearizable" read concern and write operations with "majority" write concern enables multiple threads to perform reads and writes on a single document as if a single thread performed these operations in real time; that is, the corresponding schedule for these reads and writes is considered linearizable.对于主文档上的读写操作，发出具有"linearizable"读取关注的读操作和具有"majority"写入关注的写操作，使多个线程能够在单个文档上执行读写，就像单个线程实时执行这些操作一样；也就是说，这些读取和写入的相应时间表被认为是线性的。

Tip

See also: 另请参阅：

Causal Consistency因果一致性

Causal Consistency因果一致性

If an operation logically depends on a preceding operation, there is a causal relationship between the operations. 如果一个操作在逻辑上依赖于前一个操作，则这些操作之间存在因果关系。For example, a write operation that deletes all documents based on a specified condition and a subsequent read operation that verifies the delete operation have a causal relationship.例如，基于指定条件删除所有文档的写入操作和验证删除操作的后续读取操作具有因果关系。

With causally consistent sessions, MongoDB executes causal operations in an order that respect their causal relationships, and clients observe results that are consistent with the causal relationships.通过因果一致会话，MongoDB按照尊重因果关系的顺序执行因果操作，客户端观察到与因果关系一致的结果。

Client Sessions and Causal Consistency Guarantees客户端会话和因果一致性保证

To provide causal consistency, MongoDB 3.6 enables causal consistency in client sessions. 为了提供因果一致性，MongoDB 3.6在客户端会话中启用了因果一致性。A causally consistent session denotes that the associated sequence of read operations with "majority" read concern and write operations with "majority" write concern have a causal relationship that is reflected by their ordering. 因果一致会话表示具有"majority"读取关注点的读取操作和具有"majority"写入关注点的写入操作的相关序列具有因果关系，其顺序反映了因果关系。Applications must ensure that only one thread at a time executes these operations in a client session.应用程序必须确保一次只有一个线程在客户端会话中执行这些操作。

For causally related operations:对于与原因相关的操作：

  1. A client starts a client session.客户端启动客户端会话。

    Important

    Client sessions only guarantee causal consistency for:客户端会话仅保证以下方面的因果一致性：

    • Read operations with "majority"; i.e. the return data has been acknowledged by a majority of the replica set members and is durable.使用"majority"读取操作；即，返回数据已被大多数副本集成员确认，并且是持久的。
    • Write operations with "majority" write concern; i.e. the write operations that request acknowledgement that the operation has been applied to a majority of the replica set's voting members.具有"majority"写入关注的写入操作；即请求确认操作已应用于副本集的大多数投票成员的写入操作。

    For more information on causal consistency and various read and write concerns, see Causal Consistency and Read and Write Concerns.有关因果一致性和各种读写入关注的更多信息，请参阅因果一致性与读写关注。

  2. As the client issues a sequence of read with "majority" read concern and write operations (with "majority" write concern), the client includes the session information with each operation.当客户端发出一系列"majority"读取关注和写入操作（"majority"写入关注）时，客户端会在每个操作中包含会话信息。
  3. For each read operation with "majority" read concern and write operation with "majority" write concern associated with the session, MongoDB returns the operation time and the cluster time, even if the operation errors. The client session keeps track of the operation time and the cluster time.对于与会话关联的每个"majority"读取关注的读取操作和"majority"写入关注的写入操作，MongoDB都会返回操作时间和集群时间，即使操作出错。客户端会话跟踪操作时间和集群时间。

    Note

    MongoDB does not return the operation time and the cluster time for unacknowledged (w: 0) write operations. Unacknowledged writes do not imply any causal relationship.MongoDB不返回未确认（w:0）写入操作的操作时间和集群时间。未经承认的写作并不意味着任何因果关系。

    Although, MongoDB returns the operation time and the cluster time for read operations and acknowledged write operations in a client session, only the read operations with "majority" read concern and write operations with "majority" write concern can guarantee causal consistency. 尽管MongoDB在客户端会话中返回读取操作和已确认写入操作的操作时间和集群时间，但只有"majority"读取关注的读取操作和"majority"写入关注的写入操作才能保证因果一致性。For details, see Causal Consistency and Read and Write Concerns.有关详细信息，请参阅因果一致性和读写关注。

  4. The associated client session tracks these two time fields.关联的客户端会话跟踪这两个时间字段。

    Note

    Operations can be causally consistent across different sessions. 不同会话之间的操作可能是因果一致的。MongoDB drivers and mongosh provide the methods to advance the operation time and the cluster time for a client session. MongoDB驱动程序和mongosh提供了提前客户端会话的操作时间和集群时间的方法。So, a client can advance the cluster time and the operation time of one client session to be consistent with the operations of another client session.因此，客户端可以提前一个客户端会话的集群时间和操作时间，使其与另一个客户端的操作一致。

Causal Consistency Guarantees因果一致性保证

The following table lists the causal consistency guarantees provided by causally consistent sessions for read operations with "majority" read concern and write operations with "majority" write concern.下表列出了因果一致性会话为"majority"读取关注的读取操作和"majority"写入关注的写入操作提供的因果一致性保证。

Guarantees担保Description描述
Read your writes读取自己的写入Read operations reflect the results of write operations that precede them.读取操作反映在它们之前的写入操作的结果。
Monotonic reads单调性读取Read operations do not return results that correspond to an earlier state of the data than a preceding read operation.读取操作不会返回与先前读取操作之前的数据状态相对应的结果。
For example, if in a session: 例如，如果在会话中：
  • write 1 precedes write 2,写入1先于写入2，
  • read 1 precedes read 2, and读取1先于读取2，并且
  • read 1 returns results that reflect write 2读取1返回反映写入2的结果
then read 2 cannot return results of write 1. 则读取2不能返回写入1的结果。
Monotonic writes单调性写入Write operations that must precede other writes are executed before those other writes.必须在其他写入之前执行的写入操作将在其他写入之后执行。
For example, if write 1 must precede write 2 in a session, the state of the data at the time of write 2 must reflect the state of the data post write 1. 例如，如果在会话中写入1必须在写入2之前，则写入2时的数据状态必须反映写入1后的数据状态。Other writes can interleave between write 1 and write write 2, but write 2 cannot occur before write 1. 其他写入可以在写入1和写入2之间交错，但写入2不能在写入1之前发生。
Writes follow reads写入后读取Write operations that must occur after read operations are executed after those read operations. 必须在读取操作之后发生的写入操作在这些读取操作之后执行。That is, the state of the data at the time of the write must incorporate the state of the data of the preceding read operations.也就是说，写入时的数据状态必须包含前面读取操作的数据状态。

Read Preference读取首选项

These guarantees hold across all members of the MongoDB deployment. 这些保证适用于MongoDB部署的所有成员。For example, if, in a causally consistent session, you issue a write with "majority" write concern followed by a read that reads from a secondary (i.e. read preference secondary) with "majority" read concern, the read operation will reflect the state of the database after the write operation.例如，如果在因果一致会话中，您发出一个"majority"写入关注的写入，然后发出一个从"majority"读取关注的secondary（即读取首选项辅助）读取的读取，则读取操作将反映写入操作后数据库的状态。

Isolation隔离

Operations within a causally consistent session are not isolated from operations outside the session. 原因一致会话内的操作不会与会话外的操作隔离。If a concurrent write operation interleaves between the session's write and read operations, the session's read operation may return results that reflect a write operation that occurred after the session's write operation.如果并发写入操作在会话的写入和读取操作之间交错，则会话的读取操作可能返回反映在会话的写操作之后发生的写入操作的结果。

MongoDB Drivers

Tip

Applications must ensure that only one thread at a time executes these operations in a client session.应用程序必须确保一次只有一个线程在客户端会话中执行这些操作。

Clients require MongoDB drivers updated for MongoDB 3.6 or later:客户端需要为MongoDB 3.6或更高版本更新MongoDB驱动程序：
Java 3.6+
Python 3.6+
C 1.9+
Go 1.8+ 		C# 2.5+
Node 3.0+
Ruby 2.5+
Rust 2.1+
Swift 1.2+ 		Perl 2.0+
PHPC 1.4+
Scala 2.2+
C++ 3.6.6+

Examples实例

Important

Causally consistent sessions can only guarantee causal consistency for reads with "majority" read concern and writes with "majority" write concern.因果一致会话只能保证"majority"读取关注的阅读和"majority"写入关注的写作的因果一致性。

Consider a collection items that maintains the current and historical data for various items. 考虑一个集合items，该集合项维护各种项的当前和历史数据。Only the historical data has a non-null end date. 只有历史数据的end日期不为空。If the sku value for an item changes, the document with the old sku value needs to be updated with the end date, after which the new document is inserted with the current sku value. 如果某个项目的sku值发生了更改，则需要使用end日期更新具有旧sku值的文档，在此之后，将使用当前sku值插入新文档。The client can use a causally consistent session to ensure that the update occurs before the insert.客户端可以使用因果一致会话来确保在插入之前进行更新。

➤ Use the Select your language drop-down menu in the upper-right to set the language of this example.

If another client needs to read all current sku values, you can advance the cluster time and the operation time to that of the other session to ensure that this client is causally consistent with the other session and read after the two writes:如果另一个客户端需要读取所有当前的sku值，您可以将集群时间和操作时间提前到另一个会话的时间，以确保该客户端与另一会话因果一致，并在两次写入后读取：

Limitations局限性

The following operations that build in-memory structures are not causally consistent:以下构建在内存结构中的操作不一致：

Operation操作Notes备注
collStats
$collStats with latencyStats option.带有latencyStats选项。
$currentOpReturns an error if the operation is associated with a causally consistent client session.如果操作与原因一致的客户端会话相关联，则返回错误。
createIndexes
dbHashStarting in MongoDB 4.2在MongoDB 4.2中启动
dbStats
getMoreReturns an error if the operation is associated with a causally consistent client session.如果操作与原因一致的客户端会话相关联，则返回错误。
$indexStats
mapReduceStarting in MongoDB 4.2在MongoDB 4.2中启动
pingReturns an error if the operation is associated with a causally consistent client session.如果操作与原因一致的客户端会话相关联，则返回错误。
serverStatusReturns an error if the operation is associated with a causally consistent client session.如果操作与原因一致的客户端会话相关联，则返回错误。
validateStarting in MongoDB 4.2在MongoDB 4.2中启动