Read Concern读关注
在本页面
读关注 选项允许你控制从复制集和分片集群读取数据的一致性和隔离性。
通过有效地使用写关注和读关注，你可以适当地调整一致性和可用性的保证级别，例如等待以保证更强的一致性，或放松一致性要求以提供更高的可用性。
将MongoDB驱动程序更新到MongoDB 3.2或更高版本以支持读关注。
以下为可用的读关注级别：
| Description |
| 查询并从实例返回数据，但不能保证该数据已被写入大多数副本集成员（即可能已经回滚）。
默认为：
针对主节点读。
如果读取与因果一致的会话相关联，则针对副节点读。
可用性：读关注 |
查询并从实例返回数据，但不能保证该数据已被写入大多数副本集成员（即可能已经回滚）。
默认为：如果读取与因果关系一致的会话没有关联，则针对副节点读
可用性：读关注 | |
为了满足读关注“majority”，副本集成员从其内存视图中返回多数提交点提交的数据。这样，读关注 | |
该查询返回的数据表示了这些数据在操作开始之前已成功在大多数节点确认写入。查询可能会等待并发执行的写操作传播到大多数副本集成员，然后返回结果。
如果大多数副本集成员崩溃并在读操作后重新启动，则如果将 | |
如果事务不是因果一致会话的一部分，写关注为 |
无论读关注级别如何，节点上的最新数据都可能无法反映系统中数据的最新版本
有关每个阅读关注级别的更多信息，请参见：
对于不在多文档事务中的操作，你可以将 readConcern 级别指定为一个命令和方法的选项：
readConcern: { level: <level> }
要为 mongo shell方法 db.collection.find() 指定阅读关注级别，请使用 cursor.readConcern() 方法：
db.collection.find().readConcern(<level>)
对于多文档事务，应在事务级别而不是在单个操作级别设置读关注。事务中的操作将使用事务级别的读关注。事务内部将忽略在集合和数据库级别设置的任何读关注。如果显式指定了事务级别的读关注点，则在事务内部也将忽略客户端级别的读关注点。
不要为各个操作明确设置读关注。要设置事务的读关注，请参阅读 Read Concern/Write Concern/Read Preference。
你可以在事务开始时设置读关注：
对于多文档事务，读关注级别
"snapshot","local"和"majority"是可用的。多文档事务中的写命令可以支持事务级别的读关注。
如果未在事务开始时指定，则事务将使用会话级的读关注，或者如果未设置，则使用客户端级的读关注。
有关等多信息，请参考 事务的读关注.
对于在因果一致的会话中的操作，"local" h和 "majority"级别可用。但是，为了保证因果一致性，你必须使用 "majority"。有关详细信息，请参见 因果一致性。
如果多文档事务与因果一致的会话相关联，则"snapshot" 也可用于该事务。
下列的操作支持读关注：
在为事务中的操作设置读关注时，请在事务级别而不是在单个操作级别设置读关注。不要在事务中明确的设置单独操作的读关注。更多信息，查看事务和读关注
| |
[1] | 你不能将 |
[2] | 读关注 |
下列的写操作页能接受读关注，但必须是多文档事务的一部分：
在为事务中的操作设置读关注时，请在事务级别而不是在单个操作级别设置读关注
[3] | (1, 2)读关注“SNAPSHOT”仅适用于多文档事务，并且对于事务，您可以在事务级别设置读关注。支持“SNAPSHOT”的操作对应于事务中可用的CRUD操作。有关更多信息，请参见事务和读关注 |
| |
在版本3.6中更改
从MongoDB 3.6版本开始，如果写请求确认，你可以使用因果一致的会话读你自己写入的内容。
在MongoDB 3.6之前，您必须使用 { w: "majority" } 写关注发出写操作，然后对读操作使用 "majority" 或者 "linearizable"读关注，以确保单个线程可以读取自己的写入内容
结合"majority" 写关注，"linearizable" 读关注使多个线程可以在单个文档上执行读写操作，就好像单个线程实时地执行了这些操作一样。 也就是说，这些读写的对应的计划被认为是线性的。
与"majority"不同，"linearizable" 的读关注通过从节点确认读操作正在从主节点读，该操作能够以{ w: "majority" }写关注来确认写入。 [4]因此，具有线性化读关注的读取可能比具有"majority" 或 "local"读关注的读慢得多。
为了避免万一大多数数据承载成员不可用，请始终将 maxTimeMS 与可线性化的读确认一起使用。maxTimeMS 确保操作不会无限期地阻塞，而是确保如果无法满足读取要求，则操作将返回错误。
例如：
db.restaurants.find( { _id: 5 } ).readConcern("linearizable").maxTimeMS(10000)db.runCommand( {find: "restaurants",filter: { _id: 5 },readConcern: { level: "linearizable" },maxTimeMS: 10000} )
[4] | 在某些情况下，副本集中的两个节点可能会短暂地认为它们是主节点，但至多，其中一个节点将能够以 |
| |
3.6 版本新加入
MongoDB 3.6引入了对因果一致会话的支持。 对于与因果一致的会话相关联的读操作，MongoDB 3.6引入了 afterClusterTime 读关注选项，驱动程序会自动将afterClusterTime 读关注选项设置为与因果一致的会话相关联的操作。
[warning] 重要
不要手动为读操作设置
afterClusterTime。 MongoDB驱动程序会针对与因果一致的会话相关联的操作自动设置此值。 但是，您可以提前会话的操作时间和群集时间，以便与另一个客户端会话的操作保持一致。 有关示例，请参见示例。
为了满足 afterClusterTime 值为T的读请求， mongod 必须在其oplog到达时间T之后执行请求。如果其oplog尚未达到时间T，则 mongod 必须等待服务该请求。
使用指定的 afterClusterTime 的读操作将返回满足读关注级别要求和指定的 afterClusterTime 要求的数据。
对于与因果一致会话无关的读操作，未设置 afterClusterTime。
从4.4版本开始，MongoDB跟踪阅读关注来源，表示某个特定读取关注点的来源。您可能会在getLastError指标、读取关注错误对象和MongoDB日志中看到出处。
下表显示了可能的阅读问题provenance值及其重要性:
出处 | 描述 |
| read关注点是在应用程序中指定的。 |
| 读取关注点源自自定义的默认值。 参见 |
| 在没有其他所有读取关注规范的情况下，读取关注源自服务器。 |
译者：杨帅 张琦
校对：杨帅
