Mongo的最终一致性如何与大量数据写入一起工作？

Question

我有这样的流程： 我有一个工人正在处理一个＆＃34;大＆＃34;批处理（比方说，1M记录）并将结果存储在Mongo中。

批次完成后，会向Publish发送一条通知消息，然后从Mongo中提取所有记录以供最终发布。

让我们说工作者写入过程已完成，即它已通过驱动程序将所有1M记录发送到Mongo。 Mongo是＆＃34;最终是一致的＆＃34;所以我并非100％保证在Notify Publish发生时所有记录都写入物理存储。

发布时，发现＆＃39;并获取持有批记录的集合上的游标，光标是否足够智能以处理最终的一致性？

因此，实际上，让我们想象当Notify Publish发生并且Publish找到它时，Mongo实际上会编写750,000条记录。光标是否会遍历750,000条记录并停止或将阻止或以其他方式处理剩余的250,000条，因为它们最终会写入磁盘（这可能是在发布第一个750K时很可能发生的）？

Answer 1

正如@BlakesSeven在评论中已经指出的那样，“最终一致性”指的是在复制环境中，当在主服务器上完成写入时，它只会被写入辅助服务器最终。您可以通过将write concern设置为＆gt;来降低写入性能，从而修改此行为。 1.将其设置为“多数”基本上保证了即使在故障转移的情况下写入操作也是持久的 - 尽管在（在某些情况下）性能急剧下降。

一般情况下，当您使用日记功能进行写入（简化）时会发生什么：

1. 检查操作在语法上是否正确。
2. 查询优化器启动并完成他的工作。 （与此问题无关，所以我不再详述）。
3. 写入操作应用于名为“私有视图”的数据集的内存表示。
4. 每个commitIntervalMs，私人视图会同步到期刊，中位数为15或50毫秒，具体取决于写作问题。
5. 同步时，操作将应用于共享视图。 Iirc，这是新数据提供新连接的点。

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