因果一致性和读写问题

通过MongoDB的因果一致性客户端会话，读写问题的不同组合可提供不同的因果一致性保证。如果定义因果一致性以表示耐久性，则下表列出了各种组合提供的特定保证：

Read Concern	Write Concern	Read own writes	Monotonic reads	Monotonic writes	Writes follow reads
`"majority"`	`"majority"`	✅	✅	✅	✅
`"majority"`	`{ w: 1 }`		✅		✅
`"local"`	`{ w: 1 }`
`"local"`	`"majority"`			✅

如果因果一致性表示持久性，那么从表中可以看出，只有具有"majority"读关注度的读取操作和具有"majority"写关注度的写入操作才能保证所有四个因果一致性保证。也就是说，因果一致的客户端会话只能保证以下方面的因果一致性：

"majority"关注阅读操作；也就是说，读取操作将返回大多数复制集成员已确认且持久的数据。
"majority"关注写操作；也就是说，写操作要求确认该操作已应用于大多数复制集的有投票权的成员。

如果因果一致性并不意味着持久性(即，写操作可能会回滚)，则具有写顾虑的写操作也可以提供因果一致性。{ w: 1 }

[success] 注意

在某些情况下(但不一定在所有情况下)，读和写关注点的其他组合也可以满足所有四个因果一致性保证。

读关注点"majority"和写关注点 "majority"确保即使在复制集中的两个成员短暂地认为它们是主要的情况下(例如，使用网络分区)，这四个因果一致性保证也成立。尽管两个主数据库都可以完成写操作，但是只有一个主数据库能够完成写操作。{ w: 1 }"majority".

例如，考虑网络分区划分五个成员复制集的情况：

场景

为了说明读写关注点要求，在以下情况下，客户端向客户端发出了一系列操作，并对复制集进行了读写关注点的各种组合：

阅读关注“多数”并写关注“多数”
阅读关注“多数”并发表关注{w：1}
阅读关注“本地”，写关注“多数”
阅读关注“本地”并写关注{w：1}

阅读关注"majority"和写关注"majority"

在因果一致的会话中使用读取关注"majority"和写入关注 "majority"可提供以下因果一致性保证：

✅Read own writes ✅Monotonic reads ✅ Monotonic writes ✅ Writes follow reads

方案1（读关注"majority"和写关注"majority"）

在具有两个主操作的过渡期内，由于只有P_new操作才能满足写关注的写操作，因此客户机会话可以成功发出以下操作序列：{ w: "majority" }

序列	例
1.write₁`"majority"` 到新的关注P_new 2.read₁>与读关心`"majority"`到S₂ 3.write₂`"majority"`到新的关注P_new 4.read₂与读取关注`"majority"`到S₃	对于项目`A`，更新`qty`为`50`。阅读项目`A`。对于`qty`小于或等于的项目`50`，更新`restock`到`true`。阅读项目`A`。

✅ Read own writes	read₁从S₂读取数据，该数据反映了write₁之后的状态。read₂从S₁读取数据，该数据反映了write₁之后是write₂之后的状态。
✅ Monotonic reads	read₂从S₃中读取反映read₁之后状态的数据。
✅ Monotonic writes	write₂更新P_new数据，以反映write₁之后的状态。
✅ Writes follow reads	write₂更新P_new数据，以反映read₁之后的数据状态（即，较早的状态反映read₁读取的数据）。

方案2（读取关注“多数”和写入关注“多数”）

考虑一个替代序列，其中具有读关注的read₁"majority"路由到S1：

序列	例
1.write₁`"majority"` 到新的关注P_new 2.read₁>与读关心`"majority"`到S₂ 3.write₂`"majority"`到新的关注P_new 4.read₂与读取关注`"majority"`到S₃	对于项目`A`，更新`qty`为`50`。阅读项目`A`。对于`qty`小于或等于的项目`50`，更新`restock`到`true`。阅读项目`A`。

在这个序列中，read₁在P_old上的多数提交点提前之前不能返回。在P_old和S₁能够与复制集的其余部分通信之前，这是不可能发生的;此时，P_old已经退出(如果还没有)，两个成员从副本集中的其他成员同步(包括write₁)。

✅ Read own writes	read₁反映了write1₁之后的数据状态，尽管在网络分区已修复并且该成员已与副本集的其他成员进行同步之后。read₂从S₃读取数据，该数据反映了write1₁之后是write₂之后的状态。
✅ Monotonic reads	read₂从S₃读取数据，该数据反映read₁之后的状态（即，较早的状态反映在read₁读取的数据中）。
✅ Monotonic writes	write₂更新P_new数据，以反映write₁之后的状态。
✅ Writes follow reads	write₂更新P_new数据，以反映read₁之后的数据状态（即，较早的状态反映read₁读取的数据）。

读关注"majority"和写关注{w: 1}

如果因果一致性暗示持久性，则在因果一致性会话中使用读关注"majority"和写关注可提供以下因果一致性保证：{ w: 1 }

❌ Read own writes ✅ Monotonic reads ❌ Monotonic writes ✅ Writes follow reads

如果因果一致性并不意味着持久性：

✅ Read own writes ✅ Monotonic reads ✅ Monotonic writes ✅ Writes follow reads

方案3（“关注多数”和“关注关注” ）{w: 1}

在过渡期内有两个初选，因为无论P_old与P_new能满足与写入的写入关注，一个客户端会话可以成功地发出以下的操作序列，但不是因果关系一致，如果一致因果意味着耐久性：{ w: 1 }

序列	例
1.write₁与写入关注到 `{ w: 1 }`P_old 2.read₁1与读关心`"majority"`到S₂ 3.write₂到新的关注`{ w: 1 }`P_new 4.read₂与读取关注`"majority"`到S₃	对于项目`A`，更新`qty`为`50`。阅读项目`A`。对于`qty`小于或等于的项目`50`，更新`restock`到`true`。阅读项目`A`。

按照这个顺序

直到P_new上的大多数提交点超过了write₁的时间，read₁才会返回。
直到P_new上的大多数提交点超过了write₂的时间，read₂才能返回。
当网络分区恢复时，write₁将回滚。

➤ 如果因果一致性意味着持久性

❌ Read own writes	read₁从S₂读取的数据不反映write₁之后的状态。
✅ Monotonic reads	read₂从S₃读取数据，该数据反映read₁之后的状态（即，较早的状态反映在read₁读取的数据中）。
❌ Monotonic writes	write₂更新了P_new数据，而不会反映write₁之后的状态。
✅ Writes follow reads	write₂更新P_new数据，以反映read₁之后的状态（即，较早的状态反映read₁读取的数据）。

➤ 如果因果一致性并不意味着持久性

✅ Read own writes	read₁从S₂读取数据，返回反映与write₁等效的状态的数据，然后回退write₁。
✅ Monotonic reads	read₂从S₃读取数据，该数据反映read₁之后的状态（即，较早的状态反映在read₁读取的数据中）。
✅ Monotonic writes	write₂更新了P_new的数据，这等效于write₁之后回退写1的数据。
✅ Writes follow reads	write₂更新P_new数据，以反映read₁之后的状态（即，较早的状态反映read₁读取的数据）。

方案4（“关注多数”和“关注关注” ）{w: 1}

考虑一个替代序列，其中具有读关注的读1"majority"路由到S1：

序列	例
1.write₁与写入关注到 `{ w: 1 }`P_old 2.read₁1与读关心`"majority"`到S₁ 3.write₂到新的关注`{ w: 1 }`P_new 4.read₂与读取关注`"majority"`到S₃	对于项目`A`，更新`qty`为`50`。阅读项目`A`。对于`qty`小于或等于的项目`50`，更新`restock`到`true`。阅读项目`A`。

按此顺序：

直到S₁上的大多数提交点提高，read₁才能返回。在P_old和S₁能够与复制集的其他成员进行通信之前，这是不可能发生的。此时，P_old已经退出(如果还没有)，write₁将从P_old和S₁回滚，两个成员将与复制集的其他成员同步。

➤ 如果因果一致性意味着持久性

❌ Read own writes	read₁读取的数据不反映已回退的write₁的结果。
✅ Monotonic reads	read₂从S₃读取数据，该数据反映read₁之后的状态（即，其较早的状态反映read₁读取的数据）。
❌ Monotonic writes	write₂更新关于P_new的数据，该数据不反映write₁之后的状态，该write₁在write₂之前但已回滚。
✅ Writes follow reads	write₂更新P_new数据，以反映read₁之后的状态（即，其较早的状态反映read₁读取的数据）。

➤ 如果因果一致性并不意味着持久性

✅ Read own writes	read₁返回反映write₁最终结果的数据，因为write₁最终会回滚。
✅ Monotonic reads	read₂从S₃读取数据，该数据反映read₁之后的状态（即，其较早的状态反映read₁读取的数据）。
✅ Monotonic writes	write₂更新P_new上的数据，这等效于write₁之后回退write₁的数据。
✅ Writes follow reads	write₂更新P_new数据，以反映read₁之后的状态（即，其较早的状态反映read₁读取的数据）。

读关注"local"和写关注{w: 1}

在因果一致的会话中使用读关注"local"和写关注不能保证因果一致性。{ w: 1 }

❌ Read own writes ❌ Monotonic reads ❌ Monotonic writes ❌ Writes follow reads

在某些情况下（但不一定在所有情况下），此组合可以满足所有四个因果一致性保证。

方案5（“本地关注”和“关注关注” ）{w: 1}

在这个短暂的时期，因为无论P_old与 P_new能满足与写入的写入关注，一个客户端会话可以发出以下的操作序列成功，但不是因果关系是一致的：{ w: 1 }

序列	例
1.write₁与写入关注到 `{ w: 1 }`P_old 2.read₁1与读关心`"majority"`到S₁ 3.write₂到新的关注`{ w: 1 }`P_new 4.read₂与读取关注`"majority"`到S₃	对于项目`A`，更新`qty`为`50`。阅读项目`A`。对于`qty`小于或等于的项目`50`，更新`restock`到`true`。阅读项目`A`。

❌ Read own writes	read₂从S₃读取数据，该数据仅反映write₂之后的状态，而不反映write₁ 之后是write₂的状态。
❌ Monotonic reads	read₂从S₃读取数据，该数据不反映read₁之后的状态（即，较早的状态不反映read₁读取的数据）。
❌ Monotonic writes	write₂更新了P_new数据，而不会反映write₁之后的状态。
❌ Write follow read	write₂更新P_new的数据，该数据不反映read₁之后的状态（即，较早的状态不反映read₁读取的数据）。

读关注"local"和写关注"majority"

在因果一致的会话中使用读取关注"local"和写入关注 "majority"可提供以下因果一致性保证：

❌ Read own writes ❌ Monotonic reads ✅ Monotonic writes ❌ Writes follow reads

在某些情况下（但不一定在所有情况下），此组合可以满足所有四个因果一致性保证。

方案6（“关注本地”和“关注多数”）

在此过渡期间，因为只有Pnew才能完成与写入有关的写入，所以客户机会话可以成功发出以下操作序列，但因果关系不一致：{ w: "majority" }

序列	例
1.write₁`"majority"` 到新的关注P_new 2.read₁>与读关心`"majority"`到S₁ 3.write₂`"majority"`到新的关注P_new 4.read₂与读取关注`"majority"`到S₃	对于项目`A`，更新`qty`为`50`。阅读项目`A`。对于`qty`小于或等于的项目`50`，更新`restock`到`true`。阅读项目`A`。

❌ Read own writes.	read₁从S₁读取不反映write1₁后状态的数据。
❌ Monotonic reads.	read₂从S₃读取数据，该数据不反映read₁之后的状态（即，较早的状态不反映read₁读取的数据）。
✅ Monotonic writes	write₂更新P_new数据，以反映write₁之后的状态。
❌ Write follow read.	write₂更新P_new的数据，该数据不反映read₁之后的状态（即，较早的状态不反映read₁读取的数据）。

译者：杨帅

校对：杨帅

参见

原文 - Causal Consistency and Read and Write Concerns

因果一致性和读写问题

results matching ""

No results matching ""