Mongo 的最终一致性如何处理大量数据写入？答案

【问题标题】：How does Mongo's eventual consistency work with a large number of data writes?Mongo 的最终一致性如何处理大量数据写入？
【发布时间】：2015-11-08 00:24:39
【问题描述】：

我有这样的流程：我有一个 Worker 正在处理“大”批次（比如 1M 条记录）并将结果存储在 Mongo 中。

批处理完成后，会向 Publish 发送通知消息，然后从 Mongo 中提取所有记录以进行最终发布。

假设 Worker 写入过程已完成，即它已通过驱动程序将所有 1M 记录发送到 Mongo。 Mongo 是“最终一致的”，所以我不能 100% 保证在通知发布发生时所有记录都写入物理存储。

当 Publish 执行“查找”并在包含批处理记录的集合上获取游标时，游标是否足够聪明以处理最终的一致性？

因此，实际上，让我们假设当 Notify Publish 发生并且 Publish 进行查找时，Mongo 实际写入了 750,000 条记录。游标会遍历 750,000 条记录并停止，还是会阻塞或以其他方式处理剩余的 250,000 条记录，因为它们最终被写入磁盘（这很可能在发布前 750K 时发生）？

【问题讨论】：

您确实意识到“最终一致性”是指主节点和辅助节点之间的复制过程，这也是为什么应该首选主读取的原因，除非您的应用程序可以“忍受”读取可能无法读取的数据成为最新的。不过，您似乎在谈论外部工作进程，因此并没有真正相关。
你在 mongo 配置中使用了 shardind、replication 还是两者兼有
我不太清楚这些关系。我们确实有复制但没有分片。在我的用例中，我确实需要发布者读取整个批次。如果需要，他可以阻止，但需要这一切。我可以做初级读物。所以我想我理解这意味着如果我读小学，那么我没有问题。

标签： mongodb

【解决方案1】：

正如@BlakesSeven 在 cmets 中已经指出的那样，“最终一致性”是指在复制环境中，当主节点上的写入完成时，它只会写入辅助节点最终。您可以通过将write concern 设置为 > 1 以降低写入性能为代价来修改此行为。将其设置为“多数”基本上可以保证写入操作即使在故障转移的情况下也是持久的——尽管在（在某些情况下） ) 大大降低了性能。

一般来说，当您在启用日志的情况下进行写入（简化）时会发生以下情况：

检查操作是否在语法上正确。
查询优化器启动并完成他的工作。（与这个问题无关，所以我省略了细节）。
写入操作应用于数据集的内存表示，称为“私有视图”。
每个commitIntervalMs，私有视图都会同步到日志，中位数为 15 或 50 毫秒，具体取决于写入问题。
在同步时，操作将应用于共享视图。 Iirc，这就是 new 连接将与新数据一起提供的点。

因此，为了确保新连接可以读取数据，只需将发布通知延迟commitIntervalMs + 1，考虑到您的批量大小，这几乎不会引起注意。

【讨论】：