读策略linearizable

进入MongoDB中文手册（4.2版本）目录

3.4版的新功能。
查询返回的数据反映了，在读取操作开始之前完成的，所有的多数确认并成功写入的数据。查询可能会等待并发执行的写操作的数据复制到大多数副本集成员之后，再返回结果。
如果大多数副本集成员崩溃并在读取操作后重新启动，如果将writeConcernMajorityJournalDefault设置为默认状态true，则读取操作返回的文档将是持久化。
随着writeConcernMajorityJournalDefault设置为false，MongoDB不会在写确认之前，等待w: "majority"写操作将数据写入到磁盘上的日志。这样，在给定副本集中的大多数节点发生瞬时丢失（例如崩溃和重新启动）的情况下，majority写操作可能会回滚。
您可以仅对在主节点上的读取操作指定读策略linearizable。
线性化读策略保证（Linearizable read concern guarantees）仅在读取操作指定唯一标识单个文档的查询过滤器时适用。

提示
万一大多数数据承载成员不可用，总是将maxTimeMS与读策略linearizable一起使用。maxTimeMS确保操作不会无限期地阻塞，而是确保如果无法满足读策略，则该操作将返回错误。

1 因果一致会话（Causally Consistent Sessions）

读策略linearizable不适用于因果一致的会话。

2 聚合限制

您不能将$out或$merge阶段与读策略"linearizable"结合使用。也就是说，如果您为 db.collection.aggregate()指定了读策略"linearizable"，则不能在管道中包括任何一个阶段。

3 实时排序

结合写策略"majority"， 读策略"linearizable"使多个线程可以在单个文档上执行读写操作，就好像单个线程实时执行了这些操作一样。也就是说，这些读写的相当于是顺序执行的。

4 读取自己写入的数据

在版本3.6中更改。
从MongoDB 3.6开始，如果写请求确认，则可以使用因果一致的会话来读取自己的写入数据。
在MongoDB 3.6之前，您必须发出具有写策略{ w: “majority” }的写入操作， 然后 对读取操作使用"majority"或"linearizable"的读策略，以确保单个线程可以读取自己写入的数据。

5 性能比较

不同于读策略"majority"，"linearizable"会与次节点成员确认读操作正在从主节点进行读取，主节点能够用写策略{ w: “majority” }确认写操作。因此，使用读策略"linearizable"的读操作可能比使用读策略"majority"或"local"的读慢得多 。
万一大多数数据承载成员不可用，总是将maxTimeMS与读策略"linearizable"一起使用。maxTimeMS确保操作不会无限期地阻塞，而是确保如果无法执行读策略，则该操作将返回错误。

例如：

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

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

• 在某些情况下，副本集中的两个节点可能会短暂地认为它们是主要节点，但至多其中一个节点将能够完成写策略{ w: “majority” }的写操作。可以完成{ w: “majority” }的写操作的节点是当前主节点，另一个节点是以前的主节点，由于网络分区，该主节点尚未意识到其降级。发生这种情况时，尽管请求读取新的主节点，但连接到原来的主节点的客户端可能仍会观察到过时的数据 ，并且最终将回滚原来主节点的新写入数据。
  
  进入MongoDB中文手册（4.2版本）目录