Docs 主页 → 开发应用程序 → MongoDB Manual
因果一致性以及读关注和写关注
通过 MongoDB 的因果一致性客户端会话，读写关注的不同组合可提供不同的因果一致性保证。
下表列出了不同组合可以提供的具体保证：
读关注 (read concern) | 写关注 | 读取自己的写入 | 单调读取 | 单调写入 | 读取后写入 |
|---|---|---|---|---|---|
✅ | ✅ | ✅ | ✅ | ||
✅ | ✅ | ||||
✅ |
如果您希望在数据持久性方面实现因果一致性，那么，从表中可以看出，只有具有 "majority" 读关注的读操作和具有 "majority" 写关注的写操作才能确保实现所有四种因果一致性保证。也就是说，因果一致的客户端会话只能在以下情况下保证因果一致性：
具有
"majority"读关注的读取操作；换句话说，读取操作返回的数据已被大多数副本集成员确认并且具持久性。具有
"majority"写关注的写入操作；换句话说，请求确认该操作已应用于大多数副本集投票成员的写入操作。
如果要实现因果一致性而无需数据持久性（这意味着写入可能会回滚），那么带有 { w: 1 } 写关注的写入操作也可提供因果一致性。
注意
在某些情况下，读关注和写关注的其他组合也可能满足所有四种因果一致性保证，但并非在所有情况下都是必需的。
读关注"majority"和写关注"majority"确保即使在副本集中的两个成员暂时认为自己是主节点的情况下（例如网络分区），这四个因果一致性保证仍然有效。虽然两个主节点都可以完成具有{ w: 1 }写关注的写入，但只有一个主节点能够完成具有"majority"写关注的写入。
例如，假设网络分区将一个包含五个成员的副本集进行了分隔：
例子
通过上述分区
具有
"majority"写关注的写入可以在Pnew 上完成，但无法在Pold 上完成。具有
{ w: 1 }写关注的写入操作可在Pold 或Pnew 上完成。但是，一旦这些成员与副本集的其余部分重新建立通信，对Pold 的写入（以及复制到S1 的写入）便会进行回滚。"majority"写关注在Pnew 上成功写入后，带有"majority"读关注的因果一致性读取可以观察到Pnew 、S2 和S3 上的写入。一旦Pold和S1 可与副本集的其余部分通信并与副本集的其他成员同步，读取同样可以观察到这两个成员上的写入。分区时对Pold 进行的任何写入和/或到S1 的任何复制都会回滚。
场景
为了说明读关注和写关注要求，以下场景让客户端向副本集发出一系列具有各种读关注和写关注组合的操作：
读关注"majority"和写关注"majority"
在因果一致性会话中使用读关注 "majority" 和写关注 "majority" 可提供以下因果一致性保证：
✅ 读取自己的写入 ✅ 单调读取 ✅ 单调写入 ✅ 写入跟随读取
注意
场景 1（读关注“majority”和写关注“majority”）
在具有两个主节点的过渡期内，由于只有 P new 可以完成写入（写关注为 { w: "majority" }）写关注，因此客户端会话可以成功发出以下操作序列：
顺序 | 例子 |
|---|---|
对于项目 A，将 qty 更新为 50。读取项目 A。对于 qty 小于或等于 50 的列项，将 restock 更新为 true 。读取项目 A。 |
✅读取自己的写入 | 读取 1 会从反映写入 1 之后状态的 S 2 读取数据。读取 2 会从 S 3 读取数据，该数据反映写入 1（写入 2 紧接其后）之后的状态。 |
✅单调读取 | 读取 2 会从 S 3 读取数据，该数据反映读取 1 之后的状态。 |
✅ 单调写入 | 写入 2 会更新有关 P new 的数据，而该数据反映写入 1 之后的状态。 |
✅ 读取后写入 | 写入 2 会更新有关 P new（可反映读取 1 之后的数据状态）的数据（即，较早的状态可反映读取 1 所读取的数据）。 |
注意
场景 2（读关注“majority”和写关注“majority”）
假设有一备用序列，其中带读关注 "majority" 的读取 1 会路由到 S 1：
顺序 | 例子 |
|---|---|
对于项目 A，将 qty 更新为 50。读取项目 A。对于 qty 小于或等于 50 的列项，将 restock 更新为 true 。读取项目 A。 |
在此序列中，仅当多数提交点在 P old 上前进后，读取 1 才能返回。在 P old 和 S 1 可与副本集的其余部分通信之前，不会出现此情况；此时，P old 已退出（如果还没有），且这两个成员会与副本集的其他成员同步（包括写入 1）。
✅读取自己的写入 | 读取 1 反映写入 1 之后的数据状态，尽管在网络分区已修复并且该成员已从副本集的其他成员同步之后。 读取 2 会从 S 3 读取数据，而该数据反映了写入 1（写入 2 紧接其后）之后的状态。 |
✅单调读取 | 读取 2 会从 S 3 读取数据，而该数据反映了读取 1 之后的状态（即，较早的状态会反映在读取 1 所读取的数据中）。 |
✅ 单调写入 | 写入 2 会更新有关 P new 的数据，而该数据反映写入 1 之后的状态。 |
✅ 读取后写入 | 写入 2 会更新有关 P new（可反映读取 1 之后的数据状态）的数据（即，较早的状态可反映读取 1 所读取的数据）。 |
读关注"majority"和写关注{w: 1}
在因果一致性会话中使用读关注 "majority" 和写关注 { w: 1 } 可提供以下因果一致性保证（如果要实现因果一致性和数据持久性）：
❌ 读取自己的写入 ✅ 单调读取 ❌ 单调写入 ✅ 写入跟随读取
如果要实现因果一致性而无需数据持久性：
✅ 读取自己的写入 ✅ 单调读取 ✅ 单调写入 ✅ 写入跟随读取
注意
场景 3（读关注“majority”和写关注 {w: 1}）
在有两个主节点的过渡时期，由于 P old 和 P new 都可以完成写入（写关注 { w: 1 }），因此客户端会话可以成功发出以下操作序列，但无法实现因果一致性（如果您希望实现因果一致性和数据持久性）：
顺序 | 例子 |
|---|---|
对于项目 A，将 qty 更新为 50。读取项目 A。对于 qty 小于或等于 50 的列项，将 restock 更新为 true 。读取项目 A。 |
在该序列中，
直到多数提交点在
Pnew 上前进到写入 1 的时间之后，读取P1 才能返回。直到多数提交点在
Pnew 上前进到 Write 2 的时间之后，ReadP2 才能返回。当网络分区恢复后，写入 1 将回滚。
➤如果想要实现因果一致性和数据持久性
❌读取自己的写入 | 读取 1 从 S 1 读取数据，该数据不反映写入 1 之后的状态。 |
✅单调读取 | 读取 2 会从 S 3 读取数据，而该数据反映了读取 1 之后的状态（即，较早的状态会反映在读取 1 所读取的数据中）。 |
❌ 单调写入 | 写入 2 会更新有关 P new 的数据，而该数据不反映写入 1 之后的状态。 |
✅ 读取后写入 | 写入 2 会更新有关 P new 的数据，而该数据反映了读取 1 之后的状态（即，其较早的状态可反映读取 1 所读取的数据）。 |
➤如果想要实现因果一致性而无需数据持久性
✅读取自己的写入 | 读取1会从 S 2 读取数据，返回反映与写入1 等效状态的数据，然后回滚写入1 。 |
✅单调读取 | 读取 2 会从 S 3 读取数据，而该数据反映了读取 1 之后的状态（即，较早的状态会反映在读取 1 所读取的数据中）。 |
✅ 单调写入 | 写入2会更新有关 P 新的数据，这相当于在写入1之后回滚写入1。 |
✅ 读取后写入 | 写入 2 会更新有关 P new 的数据，而该数据反映了读取 1 之后的状态（即，其较早的状态可反映读取 1 所读取的数据）。 |
注意
场景 4（读关注“majority”和写关注 {w: 1}）
假设有一备用序列，其中带读关注 "majority" 的读取 1 会路由到 S 1：
顺序 | 例子 |
|---|---|
对于项目 A，将 qty 更新为 50。读取项目 A。对于 qty 小于或等于 50 的列项，将 restock 更新为 true 。读取项目 A。 |
在该序列中，
在
S1 多数提交点前进之前，Read 1 无法返回。在Pold 和S1 可以与副本集的其余部分通信之前，这种情况不会发生。此时，Pold 已退出（如果尚未退出），Write 1 从Pold 和S1 回滚，并且两个成员与副本集的其他成员同步。
➤如果想要实现因果一致性和数据持久性
❌读取自己的写入 | 读取 1 所读取的数据不反映写入 1（已回滚）的结果。 |
✅单调读取 | 读取 2 会从 S 3 读取数据，而该数据反映了读取 1 之后的状态（即，其较早的状态可反映读取 1 所读取的数据）。 |
❌ 单调写入 | 写入 2 会更新有关 P new 的数据，而该数据不反映写入 1（先于写入 2，但已回滚）之后的状态。 |
✅ 读取后写入 | 写入 2 会更新有关 P new 的数据，而该数据反映了读取 1 之后的状态（即，其较早的状态可反映读取 1 所读取的数据）。 |
➤如果想要实现因果一致性而无需数据持久性
✅读取自己的写入 | 读取 1 返回的数据反映了写入 1 的最终结果，因为写入 1 最终会回滚。 |
✅单调读取 | 读取 2 会从 S 3 读取数据，而该数据反映了读取 1 之后的状态（即，其较早的状态可反映读取 1 所读取的数据）。 |
✅ 单调写入 | 写入2会更新有关 P 新的数据，这相当于在写入1之后回滚写入1。 |
✅ 读取后写入 | 写入 2 会更新有关 P new 的数据，而该数据反映了读取 1 之后的状态（即，其较早的状态可反映读取 1 所读取的数据）。 |
读关注"local"和写关注{w: 1}
在因果一致会话中使用读关注 "local" 和写关注 { w: 1 } 无法保证因果一致性。
❌ 读取自己的写入 ❌ 单调读取 ❌ 单调写入 ❌ 写入跟随读取
在某些情况下，这一组合可能满足所有四种因果一致性保证，但并非在所有情况下都是必需的。
注意
场景 5（读关注“local”和写关注 {w: 1}）
在此过渡期内，由于 P old 和 P new 均可以完成具有 { w: 1 } 写关注的写入，因此客户端会话可以成功发出以下操作序列，但在因果关系上不一致：
❌ 读取自己的写入 | 读取 2 会从 S 3 读取数据，而该数据仅反映写入 2 之后的状态，而不反映写入 1（写入 2 紧随其后）之后的状态。 |
❌ 单调读取 | 读取 2 会从 S 3（不反映读取 1 之后的状态）读取数据（即，较早的状态不反映读取 1 所读取的数据）。 |
❌ 单调写入 | 写入 2 会更新有关 P new 的数据，而该数据不反映写入 1 之后的状态。 |
❌ 读取后写入 | 写入 2 会更新有关 P new 的数据，而该数据不会反映了读取 1 之后的状态（即，其较早的状态不会反映读取 1 所读取的数据）。 |
读关注"local"和写关注"majority"
在因果一致性会话中使用读关注 "local" 和写关注 "majority" 可提供以下因果一致性保证：
❌ 读取自己的写入 ❌ 单调读取 ✅ 单调写入 ❌ 读取后写入
在某些情况下，这一组合可能满足所有四种因果一致性保证，但并非在所有情况下都是必需的。
注意
场景 6（读关注“local”和写关注“majority”）
在此过渡期内，由于只有 P new 可以完成具有 { w: "majority" } 写关注的写入，因此客户端会话可以成功发出以下操作序列，但在因果关系上不一致：
顺序 | 例子 |
|---|---|
对于项目 A，将 qty 更新为 50。读取项目 A。对于 qty 小于或等于 50 的列项，将 restock 更新为 true 。读取项目 A。 |
❌ 读取自己的写入。 | Read 1 从 S 1 读取数据，该数据不反映 Write1 1 之后的状态。 |
❌单调读取。 | 读取 2 会从 S 3（不反映读取 1 之后的状态）读取数据（即，较早的状态不反映读取 1 所读取的数据）。 |
✅ 单调写入 | 写入 2 会更新有关 P new 的数据，而该数据反映写入 1 之后的状态。 |
读取后写入。 | 写入 2 会更新有关 P new 的数据，而该数据不会反映了读取 1 之后的状态（即，其较早的状态不会反映读取 1 所读取的数据）。 |