在两个文档上写入时，Mongodb在副本集上的最终一致性

我们有一个客户机，它在两个文档上连续写入（使用

{w:1}

）。 例如，原始文件可能是：

{u id:“a”，值：0}

,，

{u id:“b”，值：0}

客户端将文档“a”更新为

{u id:“a”，值：1}

，然后在更新完成后，客户端将文档“b”更新为

{u id:“b”，值：1}

第二个客户端随后调用

find（{}）

。第二个客户端从次客户端读取数据，而次客户端可能尚未收到所有更改。 显然，它可以读取以下状态：

• {u-id:“a”，值：0}

  ，

  {u-id:“b”，值：0}

• {u-id:“a”，值：1}

  ，

  {u-id:“b”，值：0}

• {u-id:“a”，值：1}

  ，

  {u-id:“b”，值：1}

这些都是初级阶段的“真实”状态（在过去的某个时刻）

第二个客户端是否可以看到如下状态：

{u id:“a”，值：0}

，

{u id:“b”，值：1}

？请注意，主服务器上从未存在此状态

附言。 解释说：

第二。。。按写入操作在oplog中出现的顺序应用写入操作

这是否意味着二级人员更改文档的顺序与他们在一级人员上更新的顺序相同

p.S.

查找

游标是否“冻结”它们正在读取的文档的状态（即忽略创建游标后所做的更改）？如果我使用

find（…）.sort（{u id:-1}）

或者如果文档“a”的id是“c”（即大于“b”），情况会有所不同吗

---

如果我们的documnet在master上按顺序更新，那就谢谢了

改变

更改B

更改C

然后，第二方将按照相同的顺序更新文档：

改变 可以在不应用其他更改的情况下读取documnet

更改B 可以在不应用其他更改的情况下读取documnet

更改C

---

用于锁定，因为mongo可以优化操作顺序，即使触发文档更新，也可以进行读取。

第一个问题：是的，辅助设备上的操作与主设备上的操作顺序相同。所有操作都记录在记录中。oplog本身不是所执行查询（即updateMany（））的日志，而是必须对实际文档执行的操作，从而使其操作成为幂等的

关于光标操作。在光标上迭代时，可能会移动或更新文档。如果同一文档的索引或存储位置在更新过程中发生更改，甚至可能会在光标上出现两次

---

有一种提供某种隔离的特殊模式，但它有一些限制，即它不能与切分一起使用

那么

查找

操作呢？如果

find

按该顺序找到两个文档“a”和“b”，它能在更改前返回文档“a”并在更改后返回文档“b”吗？@Oren-这是所有与

W:1

相关的时间，因此如果

find

将在secondary处理

change b

之前顺序失败，然后

change A

被发送回客户端。同样感谢您对光标的解释。