读取关注点`"linearizable"`

"可线性化"

查询返回的数据反映所有在读取操作开始之前成功完成的多数确认写入。查询可能在返回结果之前等待并发执行的写入传播到副本集成员的大多数。

如果您的副本集成员的大多数在读取操作之后崩溃并重新启动，则读取操作返回的文档是持久的，如果writeConcernMajorityJournalDefault 设置为默认状态 true。

将 writeConcernMajorityJournalDefault 设置为 false，MongoDB 在确认写入之前不会等待 w: "majority" 写入写入磁盘日志。因此，在给定副本集中的多数节点发生瞬态丢失（例如，崩溃和重新启动）的情况下，"majority" 写入操作可能会回滚。

您只能为 primary 上的读取操作指定可线性化读取关注。

提示

如果大多数数据承载成员不可用，请始终与可线性化读取关注一起使用 maxTimeMS。 maxTimeMS 确保操作不会无限期地阻塞，而是在读取关注无法满足的情况下返回错误。

要求

可线性化读取关注度仅适用于读取操作指定了唯一标识单个文档的查询过滤器。此外，如果以下任何条件不满足，线性化读取关注度可能不会从一致的快照中读取，从而导致匹配过滤器的文档无法返回。

查询使用不可变字段作为查询的搜索键。例如，在 _id 字段上搜索或使用 $natural。
没有并发更新会修改查询的搜索键。
搜索键具有唯一索引，并且查询使用了该索引。

如果满足上述任何条件，则查询将从一致快照中读取，以返回单个匹配的文档。

因果一致性会话

读取关注度"linearizable" 在因果一致性会话中不可用。

聚合限制

您不能在读取关注度 "linearizable" 时使用 $out 或 $merge 阶段。也就是说，如果您为 db.collection.aggregate() 指定了读取关注度 "linearizable"，则无法在管道中包含这些阶段。

实时订单

结合"majority"写关注，"linearizable"读关注使得多个线程可以像单个线程一样实时地执行单个文档的读写操作；即，这些读写对应的调度被认为是可线性化的。

读取自己的写入

如果写入请求已确认，可以使用因果一致会话来读取自己的写入。

性能比较

与 "majority" 不同，"linearizable" 读取关注点会与二级成员确认读取操作是否从能够与 { w: "majority" } 写关注点确认写入的主节点读取。 [1] 因此，具有线性可读关注点的读取可能比具有 "majority" 或 "local" 读取关注点的读取速度要慢得多。

例如

db.restaurants.find( { _id: 5 } ).readConcern("linearizable").maxTimeMS(10000)
db.runCommand( {
     find: "restaurants",
     filter: { _id: 5 },
     readConcern: { level: "linearizable" },
     maxTimeMS: 10000
} )

[1]	在某些情况下，副本集中的两个节点可能暂时认为自己是主节点，但最多只有一个节点能够使用 `{ w: "majority" }` 写关注点完成写入。能够完成 `{ w: "majority" }` 写入的节点是当前主节点，而另一个节点是尚未承认其降级的旧主节点，这通常是由于网络分区。在这种情况下，连接到旧主节点的客户端可能会观察到过时数据，尽管它们请求了 `primary` 读取偏好，而旧主节点的新的写入最终将回滚。

"majority"

"snapshot"