因果一致性和读写问题

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

阅读关注 写关注 阅读自己的文章 单调读 单调写 写跟读
"majority" "majority"
"majority" { w: 1 }
"local" { w: 1 }
"local" "majority"

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

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

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

[success] 注意

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

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

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

网络分区:一侧选择了新的主节点,而旧的主节点尚未卸任。

场景

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

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

✅自己读✅单调读read单调写✅写跟随读

方案1(读关注"majority"和写关注"majority"

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

序列
1.write1"majority" 到 新的关注Pnew
2.read1>与读关心"majority"S2
3.write2"majority"到新的关注Pnew
4.read2与读取关注"majority"S3
对于项目A,更新qty50
阅读项目A。对于qty小于或等于的项目50
更新restocktrue。阅读项目A

使用读关注多数和写关注多数的具有两个原语的数据状态

自己写 read1S2读取数据,该数据反映了write1之后的状态。read2S1读取数据,该数据反映了write1之后是write2之后的状态。
单调读 read2S3中读取反映read1之后状态的数据。
单调写 write2更新Pnew数据,以反映write1之后的状态。
写跟随读 write2更新Pnew数据,以反映read1之后的数据状态(即,较早的状态反映read1读取的数据)。

方案2(读取关注“多数”和写入关注“多数”)

考虑一个替代序列,其中具有读关注的read1"majority"路由到S1:

序列
1.write1"majority" 到 新的关注Pnew
2.read1>与读关心"majority"S2
3.write2"majority"到新的关注Pnew
4.read2与读取关注"majority"S3
对于项目A,更新qty50
阅读项目A。对于qty小于或等于的项目50
更新restocktrue。阅读项目A

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

自己写 read1反映了write11之后的数据状态,尽管在网络分区已修复并且该成员已与副本集的其他成员进行同步之后。read2S3读取数据,该数据反映了write11之后是write2之后的状态。
单调读 read2S3读取数据,该数据反映read1之后的状态(即,较早的状态反映在read1读取的数据中)。
单调写 write2更新Pnew数据,以反映write1之后的状态。
写跟随读 write2更新Pnew数据,以反映read1之后的数据状态(即,较早的状态反映read1读取的数据)。

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

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

❌自己读 ✅单调读read单调写. ✅写跟随读

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

✅自己读. ✅单调读read单调写. ✅写跟随读

方案3(“关注多数”和“关注关注” ){w: 1}

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

序列
1.write1与写入关注 到 { w: 1 }Pold
2.read11与读关心"majority"S2
3.write2到新的关注{ w: 1 }Pnew
4.read2与读取关注"majority"S3
对于项目A,更新qty50
阅读项目A。对于qty小于或等于的项目50
更新restocktrue。阅读项目A

使用读关注多数和写关注1的具有两个原语的数据状态

按照这个顺序

  • 直到Pnew上的大多数提交点超过了write1的时间,read1才会返回。
  • 直到Pnew上的大多数提交点超过了write2的时间,read2才能返回。
  • 当网络分区恢复时,write1将回滚。

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

自己写 read1S2读取的数据不反映write1之后的状态。
单调读 read2S3读取数据,该数据反映read1之后的状态(即,较早的状态反映在read1读取的数据中)。
单调写 write2更新了Pnew数据,而不会反映write1之后的状态。
写跟随读 write2更新Pnew数据,以反映read1之后的状态(即,较早的状态反映read1读取的数据)。

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

自己写 read1S2读取数据,返回反映与write1等效的状态的数据,然后回退write1
单调读 read2S3读取数据,该数据反映read1之后的状态(即,较早的状态反映在read1读取的数据中)。
单调写 write2更新了Pnew的数据,这等效于write1之后回退写1的数据。
写跟随读 write2更新Pnew数据,以反映read1之后的状态(即,较早的状态反映read1读取的数据)。

方案4(“关注多数”和“关注关注” ){w: 1}

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

序列
1.write1与写入关注 到 { w: 1 }Pold
2.read11与读关心"majority"S1
3.write2到新的关注{ w: 1 }Pnew
4.read2与读取关注"majority"S3
对于项目A,更新qty50
阅读项目A。对于qty小于或等于的项目50
更新restocktrue。阅读项目A

按此顺序:

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

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

自己写 read1读取的数据不反映已回退的write1的结果。
单调读 read2S3读取数据,该数据反映read1之后的状态(即,其较早的状态反映read1读取的数据)。
单调写 write2更新关于Pnew的数据,该数据不反映write1之后的状态,该write1在write2之前但已回滚。
写跟随读 write2更新Pnew数据,以反映read1之后的状态(即,其较早的状态反映read1读取的数据)。

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

自己写 read1返回反映write1最终结果的数据,因为write1最终会回滚。
单调读 read2S3读取数据,该数据反映read1之后的状态(即,其较早的状态反映read1读取的数据)。
单调写 write2更新Pnew上的数据,这等效于write1之后回退write1的数据。
写跟随读 write2更新Pnew数据,以反映read1之后的状态(即,其较早的状态反映read1读取的数据)。

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

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

❌自己读. ❌单调读read单调写. ❌写跟随读

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

方案5(“本地关注”和“关注关注” ){w: 1}

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

序列
1.write1与写入关注到 { w: 1 }Pold
2.read11与读关心"majority"S1
3.write2到新的关注{ w: 1 }Pnew
4.read2与读取关注"majority"S3
对于项目A,更新qty50
阅读项目A。对于qty小于或等于的项目50
更新restocktrue。阅读项目A

使用读关注本地和写关注1的具有两个主数据的数据状态

❌自己写 read2S3读取数据,该数据仅反映write2之后的状态,而不反映write1 之后是write2的状态。
❌单调读 read2S3读取数据,该数据不反映read1之后的状态(即,较早的状态不反映read1读取的数据)。
❌单调写 write2更新了Pnew数据,而不会反映write1之后的状态。
❌写跟随读 write2更新Pnew的数据,该数据不反映read1之后的状态(即,较早的状态不反映read1读取的数据)。

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

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

❌自己读 ❌单调读read单调写 ❌写跟随读

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

方案6(“关注本地”和“关注多数”)

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

序列
1.write1"majority" 到 新的关注Pnew
2.read1>与读关心"majority"S1
3.write2"majority"到新的关注Pnew
4.read2与读取关注"majority"S3
对于项目A,更新qty50
阅读项目A。对于qty小于或等于的项目50
更新restocktrue。阅读项目A

使用读关注本地和写关注多数的两个主数据的状态

❌阅读自己的文章。 read1S1读取不反映write11后状态的数据。
❌单调读。 read2S3读取数据,该数据不反映read1之后的状态(即,较早的状态不反映read1读取的数据)。
✅单调写 write2更新Pnew数据,以反映write1之后的状态。
❌写跟随阅读。 write2更新Pnew的数据,该数据不反映read1之后的状态(即,较早的状态不反映read1读取的数据)。

译者:杨帅

校对:杨帅

参见

原文 - Causal Consistency and Read and Write Concerns

Copyright © 上海锦木信息技术有限公司 all right reserved,powered by Gitbook文件修订时间: 2020-12-18 11:34:57

results matching ""

    No results matching ""