Read Concern 读取关注"linearizable"

Causally Consistent Sessions因果一致会话

Read concern "linearizable" is unavailable for use with causally consistent sessions.读关注点"linearizable"不可用于因果一致的会话。

Aggregation Restriction聚合限制

You cannot use the $out or the $merge stage in conjunction with read concern "linearizable". 不能将$out或$merge阶段与读取关注点"linearizable"结合使用。That is, if you specify "linearizable" read concern for db.collection.aggregate(), you cannot include either stages in the pipeline.也就是说，如果为db.collection.aggregate()指定"linearizable"读取关注点，则不能在管道中包含任何一个阶段。

Real Time Order实时订单

Combined with "majority" write concern, "linearizable" read 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.与"majority"写关注点相结合，"linearizable"读关注点使多个线程能够对单个文档执行读写操作，就像单个线程实时执行这些操作一样；也就是说，这些读写的相应调度被认为是可线性化的。

Read Your Own Writes读你自己写的

Starting in MongoDB 3.6, you can use causally consistent sessions to read your own writes, if the writes request acknowledgement.从MongoDB 3.6开始，如果写入请求确认，您可以使用因果一致的会话来读取自己的写入。

Prior to MongoDB 3.6, in order to read your own writes you must issue your write operation with { w: "majority" } write concern, and then issue your read operation with primary read preference, and either "majority" or "linearizable" read concern.在MongoDB 3.6之前，为了读取您自己的写入操作，您必须使用{ w: "majority" }写入关注点发出写入操作，然后使用primary读取首选项发出读取操作，以及"majority"或"linearizable"读取关注点。

Performance Comparisons性能比较

Unlike "majority", "linearizable" read concern confirms with secondary members that the read operation is reading from a primary that is capable of confirming writes with { w: "majority" } write concern. 与"majority"不同，"linearizable"”读关注点通过二级成员确认读操作是从能够通过{ w: "majority" }写关注点确认写的主成员读取。[1] As such, reads with linearizable read concern may be significantly slower than reads with "majority" or "local" read concerns.因此，具有线性化读取关注点的读取可能比具有"majority"或"local"读取关注点时的读取慢得多。

Always use maxTimeMS with linearizable read concern in case a majority of data bearing members are unavailable. 在大多数数据承载成员不可用的情况下，始终使用具有线性化读取关注点的maxTimeMS。maxTimeMS ensures that the operation does not block indefinitely and instead ensures that the operation returns an error if the read concern cannot be fulfilled.确保操作不会无限期阻塞，相反，如果无法满足读取要求，则确保操作返回错误。

For example:例如：

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