保证MongoDB中微服务访问共享集群数据的一致性

Question

我的应用程序本质上是一堆跨Node.js实例部署的微服务。一个服务可能会写入一些数据，而另一个服务将读取这些更新。（具体的例子是，我正在使用处理管道处理入站到解决方案中的数据。阶段1对相同的数据执行某些操作，阶段2对相同的数据执行其他操作，等等。这是一个相当常见的模式）

因此，我有一个很大的数据集（现在大约250GB，我读到过，一旦数据库变得比这个大得多，就不可能在数据库中引入分片，至少不是没有一些大的跳圈）。我想有一个高可用的数据库，所以我计划在一个副本集，至少有一个辅助和仲裁器。

我仍然在研究我的“分片”选项，但我认为我可以通过它所属的“客户端”分片我的数据，所以我认为有3个分片是有意义的。

第三个问题...我假设，只要我在“多数”认可的情况下写，并从所有初选中读，我就不需要担心因果一致的数据？我读到过，从“次要”节点执行读操作是不值得的。如果从第二级读取，您必须担心“最终的一致性”，由于写入是同步的，第二级基本上看到的流量与第一级相同。所以从二年级开始阅读没有任何好处。如果是这种情况，我可以从原稿中执行所有的读取（使用“多数”读关注），并确保我总是得到一致的数据，并且我正在执行的分片给了我一些好处，因为我在分片中分配了负载。这是正确的吗？

第四个（也是最后一个）问题...什么时候因果一致的会议是值得的？如果我理解正确，但我不确定我是否理解正确，那么我认为是当我有一个典型的web应用程序（而不是一些分布式应用程序，如我当前的应用程序）时，只有一个（或两个）节点执行读写操作。在这种情况下，我将使用因果一致的会话，并对主服务器执行写操作，从次服务器执行读操作。但是，在这种情况下，从中学阅读有什么好处呢？我错过了什么？因果一致会话的用例是什么？

Answer 1

如果我有3个碎片，并且我的副本集是Primary/secondary/Arbiter（在Primary上运行仲裁器），我将有6个MongoDB实例在运行。将有三个初选和三个次要（仲裁器在每个初选上运行）。这是正确的吗？

副本集仲裁器仍然是mongod的html" target="_blank">实例。只是仲裁者没有数据的副本，不能成为主要的。每个碎片应该有3个实例，这意味着总共有9个实例。

既然您提到您希望有一个高可用的数据库部署，请注意生产部署的最小推荐副本集成员将是一个主要成员和两个次要成员。

null

这是因为仲裁器不携带数据，不能确认写入，但仍被计算为投票成员。另请参见编写副本集的关注点。

我可以从原稿进行所有读取（使用“多数”读关注），并确保我总是得到一致的数据，我正在做的分片给了我一些好处，因为在分片上分配负载

正确的，MongoDB Sharding是水平伸缩，以在碎片之间分配负载。而MongoDB复制是为了提供高可用性。