因果一致性和读写关注
通过MongoDB的因果一致性客户端会话，读写问题的不同组合可提供不同的 因果一致性保证。如果定义因果一致性以表示耐久性，则下表列出了各种组合提供的特定保证：
| 阅读关注 | 写关注 | 阅读自己的文章 | 单调读 | 单调写 | 写跟读 |
|---|---|---|---|---|---|
✅ | ✅ | ✅ | ✅ | ||
✅ | ✅ | ||||
✅ |
如果因果一致性表示持久性，那么从表中可以看出，只有具有["majority"](https://docs.mongodb.com/manual/reference/read-concern-majority/#readconcern."majority")读关注度的读取操作和具有[`"majority"`](https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority")写关注度的写入操作才能保证所有四个因果一致性保证。也就是说， 因果一致的客户端会话只能保证以下方面的因果一致性：
如果因果一致性并不意味着持久性(即，写操作可能会回滚)，则具有写顾虑的写操作也可以提供因果一致性。{ w: 1 }
[success] 注意
在某些情况下(但不一定在所有情况下)，读和写关注点的其他组合也可以满足所有四个因果一致性保证。
读关注点["majority"](https://docs.mongodb.com/manual/reference/read-concern-majority/#readconcern."majority")和写关注点 ["majority"](https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority")确保即使在复制集中的两个成员*短暂地*认为它们是主要的[情况下(例如，使用网络分区)](https://docs.mongodb.com/manual/core/read-preference-use-cases/#edge-cases)，这四个因果一致性保证也成立 。尽管两个主数据库都可以完成写操作，但是只有一个主数据库能够完成写操作。{ w: 1 }["majority"](https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority").
例如，考虑网络分区划分五个成员复制集的情况：
场景
为了说明读写关注点要求，在以下情况下，客户端向客户端发出了一系列操作，并对复制集进行了读写关注点的各种组合：
阅读关注"majority"和写关注"majority"
"majority"和写关注"majority"在因果一致的会话中使用读取关注["majority"](https://docs.mongodb.com/manual/reference/read-concern-majority/#readconcern."majority")和写入关注 ["majority"](https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority")可提供以下因果一致性保证：
✅自己读✅单调读read单调写✅写跟随读
方案1（读关注"majority"和写关注"majority"）
在具有两个主操作的过渡期内，由于只有Pnew操作才能满足写关注的写操作，因此客户机会话可以成功发出以下操作序列：[{ w: "majority" }](https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority")
| 序列 | 例 |
|---|---|
1.write1[ | 对于项目 |
✅ 自己写 | read1从S2读取数据，该数据反映了write1之后的状态。read2从S1读取数据，该数据反映了write1之后是write2之后的状态。 |
✅ 单调读 | read2从S3中读取反映read1之后状态的数据。 |
✅ 单调写 | write2更新Pnew数据，以反映write1之后的状态。 |
✅ 写跟随读 | write2更新Pnew数据，以反映read1之后的数据状态（即，较早的状态反映read1读取的数据）。 |
方案2（读取关注“多数”和写入关注“多数”）
考虑一个替代序列，其中具有读关注的read1["majority"](https://docs.mongodb.com/manual/reference/read-concern-majority/#readconcern."majority")路由到`S`1：
| 序列 | 例 |
|---|---|
1.write1[ | 对于项目 |
在这个序列中，read1在Pold上的多数提交点提前之前不能返回。在Pold和S1能够与复制集的其余部分通信之前，这是不可能发生的;此时，Pold已经退出(如果还没有)，两个成员从副本集中的其他成员同步(包括write1)。
✅ 自己写 | read1反映了write11之后的数据状态，尽管在网络分区已修复并且该成员已与副本集的其他成员进行同步之后。read2从S3读取数据，该数据反映了write11之后是write2之后的状态。 |
✅ 单调读 | read2从S3读取数据，该数据反映read1之后的状态（即，较早的状态反映在read1读取的数据中）。 |
✅ 单调写 | write2更新Pnew数据，以反映write1之后的状态。 |
✅ 写跟随读 | write2更新Pnew数据，以反映read1之后的数据状态（即，较早的状态反映read1读取的数据）。 |
读关注"majority"和写关注{w: 1}
"majority"和写关注{w: 1}_如果因果一致性暗示持久性，则_在因果一致性会话中使用读关注["majority"](https://docs.mongodb.com/manual/reference/read-concern-majority/#readconcern."majority")和写关注 可提供以下因果一致性保证：{ w: 1 }
❌自己读 ✅单调读read单调写. ✅写跟随读
如果因果一致性并不意味着持久性：
✅自己读. ✅单调读read单调写. ✅写跟随读
方案3（“关注多数”和“关注关注” ）{w: 1}
在过渡期内有两个初选，因为无论Pold与Pnew能满足与写入 的写入关注，一个客户端会话可以成功地发出以下的操作序列，但不是因果关系一致**，如果一致因果意味着耐久性**：{ w: 1 }
| 序列 | 例 |
|---|---|
1.write1与写入关注 到 | 对于项目 |
按照这个顺序
直到Pnew上的大多数提交点超过了write1的时间，read1才会返回。
直到Pnew上的大多数提交点超过了write2的时间，read2才能返回。
当网络分区恢复时，write1将回滚。
➤ 如果因果一致性意味着持久性
❌ 自己写 | read1从S2读取的数据不反映write1之后的状态。 |
✅ 单调读 | read2从S3读取数据，该数据反映read1之后的状态（即，较早的状态反映在read1读取的数据中）。 |
❌ 单调写 | write2更新了Pnew数据，而不会反映write1之后的状态。 |
✅ 写跟随读 | write2更新Pnew数据，以反映read1之后的状态（即，较早的状态反映read1读取的数据）。 |
➤ 如果因果一致性并不意味着持久性
✅ 自己写 | read1从S2读取数据，返回反映与write1等效的状态的数据，然后回退write1。 |
✅ 单调读 | read2从S3读取数据，该数据反映read1之后的状态（即，较早的状态反映在read1读取的数据中）。 |
✅ 单调写 | write2更新了Pnew的数据，这等效于write1之后回退写1的数据。 |
✅ 写跟随读 | write2更新Pnew数据，以反映read1之后的状态（即，较早的状态反映read1读取的数据）。 |
方案4（“关注多数”和“关注关注” ）{w: 1}
考虑一个替代序列，其中具有读关注的读1["majority"](https://docs.mongodb.com/manual/reference/read-concern-majority/#readconcern."majority")路由到`S`1：
| 序列 | 例 |
|---|---|
1.write1与写入关注 到 | 对于项目 |
按此顺序：
直到S1上的大多数提交点提高，read1才能返回。在Pold和S1能够与复制集的其他成员进行通信之前，这是不可能发生的。此时，Pold已经退出(如果还没有)，write1将从Pold和S1回滚，两个成员将与复制集的其他成员同步。
➤ 如果因果一致性意味着持久性
❌ 自己写 | read1读取的数据不反映已回退的write1的结果。 |
✅ 单调读 | read2从S3读取数据，该数据反映read1之后的状态（即，其较早的状态反映read1读取的数据）。 |
❌ 单调写 | write2更新关于Pnew的数据，该数据不反映write1之后的状态，该write1在write2之前但已回滚。 |
✅ 写跟随读 | write2更新Pnew数据，以反映read1之后的状态（即，其较早的状态反映read1读取的数据）。 |
➤ 如果因果一致性并不意味着持久性
✅ 自己写 | read1返回反映write1最终结果的数据，因为write1最终会回滚。 |
✅ 单调读 | read2从S3读取数据，该数据反映read1之后的状态（即，其较早的状态反映read1读取的数据）。 |
✅ 单调写 | write2更新Pnew上的数据，这等效于write1之后回退write1的数据。 |
✅ 写跟随读 | write2更新Pnew数据，以反映read1之后的状态（即，其较早的状态反映read1读取的数据）。 |
读关注"local"和写关注{w: 1}
"local"和写关注{w: 1}在因果一致的会话中使用读关注["local"](https://docs.mongodb.com/manual/reference/read-concern-local/#readconcern."local")和写关注 不能保证因果一致性。{ w: 1 }
❌自己读. ❌单调读read单调写. ❌写跟随读
在某些情况下（但不一定在所有情况下），此组合可以满足所有四个因果一致性保证。
方案5（“本地关注”和“关注关注” ）{w: 1}
在这个短暂的时期，因为无论Pold与 Pnew能满足与写入的写入关注，一个客户端会话可以发出以下的操作序列成功，但不是因果关系是一致的：{ w: 1 }
| 序列 | 例 |
|---|---|
1.write1与写入关注到 | 对于项目 |
❌自己写 | read2从S3读取数据，该数据仅反映write2之后的状态，而不反映write1 之后是write2的状态。 |
❌单调读 | read2从S3读取数据，该数据不反映read1之后的状态（即，较早的状态不反映read1读取的数据）。 |
❌单调写 | write2更新了Pnew数据，而不会反映write1之后的状态。 |
❌写跟随读 | write2更新Pnew的数据，该数据不反映read1之后的状态（即，较早的状态不反映read1读取的数据）。 |
读关注"local"和写关注"majority"
"local"和写关注"majority"在因果一致的会话中使用读取关注["local"](https://docs.mongodb.com/manual/reference/read-concern-local/#readconcern."local")和写入关注 ["majority"](https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority")可提供以下因果一致性保证：
❌自己读 ❌单调读read单调写 ❌写跟随读
在某些情况下（但不一定在所有情况下），此组合可以满足所有四个因果一致性保证。
方案6（“关注本地”和“关注多数”）
在此过渡期间，因为只有Pnew才能完成与 写入有关的写入，所以客户机会话可以成功发出以下操作序列，但因果关系不一致：[{ w: "majority" }](https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority")
| 序列 | 例 |
|---|---|
1.write1[ | 对于项目 |
❌阅读自己的文章。 | read1从S1读取不反映write11后状态的数据。 |
❌单调读。 | read2从S3读取数据，该数据不反映read1之后的状态（即，较早的状态不反映read1读取的数据）。 |
✅单调写 | write2更新Pnew数据，以反映write1之后的状态。 |
❌写跟随阅读。 | write2更新Pnew的数据，该数据不反映read1之后的状态（即，较早的状态不反映read1读取的数据）。 |
译者：杨帅
校对：杨帅
最后更新于