我想问一个有关本文档中描述的最佳实践的问题：

http://info.mongodb.com/rs/mongodb/images/MongoDB-Performance-Best-Practices.pdf

使用多个查询路由器。使用跨多个服务器的多个mongos进程。常见的部署是将mongos进程共定位在应用程序服务器上，从而允许应用程序和mongos进程之间进行本地通信。mongos进程的适当数量将取决于应用程序和部署的性质。

有关我们的部署的背景知识。我们有很多应用服务器节点。它们每个都使用无状态RESTful WS运行一个基于JVM的进程。正如最佳实践所建议的那样，每个单个应用程序服务器节点都运行自己的mongos进程，这意味着JVM进程的数量始终等于进程的数量mongos。

所有mongos进程都连接到3台配置服务器和几个mongo分片（每个分片内都有副本集）。即使我们使用分片部署，也没有真正分片集合。实际上，我们有大量的数据库，这些数据库在创建时就分布在所有分片上（这是目前分片的主要用例）。

由于最佳实践还表明“适当的mongos进程数量将取决于应用程序和部署的性质”，我开始怀疑我们的用法mongos实际上是否合适，或者让我们拥有几个专用mongos节点是否更好？我们的应用服务器无需mongos本地运行即可连接到它们。

您对决定mongos与应用程序服务器实例数量或MongoDB集群大小相关的多少个实例合适的最佳方法有何看法？

最近，我们开始研究无状态Web服务的集群管理，我的意思是指诸如Docker，Apache Mesos和Kubernetes之类的工具。如果我们使用的是Docker，那么通常不建议在容器内运行多个进程。考虑到这一事实，要确保应用程序服务器容器和mongos容器始终位于同一物理节点上并具有相同数量的进程，将变得非常困难。这使我想知道这种最佳实践是否仍然适用于我刚刚描述的集群体系结构。如果没有，您能否建议mongos在这种体系结构中定位和部署流程的更好方法是什么？

既然已经提交了答案，并且是一个有用且有效的答案，我不想分散其自身的用处，但确实有几点需要提出，而不仅仅是简短的评论。因此，请考虑这种“增强”，它是有效的，但主要是在已经说过的内容之外。

事实是要真正考虑“应用程序如何使用数据”，并要意识到“分片环境”以及提议的“容器环境”中影响该因素的因素。

背景案例

将mongos流程与应用程序实例共置一处的做法建议通常是消除应用程序与该mongos流程进行通信所需的任何网络开销。当然mongos，如果由于某种原因该“最近的”节点不可用，则可以选择另一个实例，尽管可能有联系联系人的开销，这也是“建议的做法”。远程节点。

您提到的“码头工人”案似乎有些武断。确实，容器的主要目标之一（并且在此之前，诸如BSD jails甚至是chroot之类的东西）通常是为了实现某种程度的“进程隔离”，但是只要您运行多个进程并没有错了解其中的含义。

在这种特殊情况下，mongos它应该是“轻量级”的，并作为应用程序过程的“附加功能”运行，其方式几乎就是应用程序本身的“配对”部分。因此，docker映像本身没有像“ initd”这样的进程，但是运行诸如supervisor之类的进程控制器（例如）作为容器的主要过程并没有什么错，然后您可以对容器进行一点过程控制该容器也是如此。这种“成对过程”的情况是一个合理的案例，并且也很常见，要求提供正式文档。

如果您选择那种“成对”的操作进行部署，那么它的确可以解决mongos在应用程序服务器本身和同一网络连接上维护实例以及“服务器实例”的主要问题。也可以某种方式将其视为“整个容器”发生故障，然后该节点本身将完全无效的情况。并非我建议这样做，实际上，mongos即使只能通过增加延迟的网络连接访问这些实例，您可能仍应配置连接以查找其他实例。

版本特定/用途特定

现在已经说明了这一点，这里的另一个考虑是回到最初考虑的mongos过程，即出于网络延迟的目的将进程与应用程序共存。在2.6之前的MongoDB版本中，尤其是在诸如聚合框架之类的操作方面，则存在这样的情况：将会有更多的网络流量，以及随后处理mongos由不同分片处理的数据所执行的处理工作。现在情况并非如此，因为现在可以在“分派”到“路由器”之前对那些分片本身执行大量的处理工作量。

另一种情况是与分片有关的应用程序使用模式本身。这意味着主要的工作负载是在多个分片之间“分配写入”，还是在整合读取请求时成为“分散收集”方法。在那些情况下

测试，然后再测试

因此，这里的最后一点是自我说明，可以归结为对您的问题做出任何明智回答的基本共识。对于MongoDB或任何其他存储解决方案而言，这不是新事物，但是您需要根据其“使用模式”对实际部署环境进行测试，使其接近实际情况，就像对核心组件或其他组件的预期功能进行任何“单元测试”一样总体结果需要测试。

确实没有“确定性”的说法要说“以这种方式配置”或“以这种方式使用”，除了测试对您的应用程序性能和可靠性所期望的“实际上最有效”之外，这实际上是有意义的。

当然，“最佳情况”将始终是不mongos使用来自“许多”应用程序服务器源的请求来“ 拥挤” 实例。但是，然后允许它们通过可用的资源工作负载来分配一些自然的“奇偶校验”，从而使“至少”具有一个可以选择的“资源池”，实际上在很多情况下，理想的是，但无需引入额外的资源“网络传输开销”。

这就是目标，但是理想情况下，您可以“实验室测试”不同的感知配置，以便为最终的部署解决方案提供“最合适”的解决方案。

我也强烈建议您已经提到的“免费”（如啤酒）课程，无论您的知识水平如何。我发现各种课程资料来源通常会提供“隐藏的宝石”，以使您对可能没有考虑或忽视的事物有更多的了解。前面提到的M102类是由Adam Commerford构造和进行的，我可以证明，M102类对MongoDB和其他数据架构的大规模部署具有很高的知识。值得花时间至少对您可能认为已经知道的内容有新的看法。

由于最佳实践还表明“适当的mongos进程数将取决于应用程序和部署的性质”，我开始怀疑我们对mongos的使用是否真正合适

我认为这是一个最终只能由您回答的问题，如文档所指。

推荐的策略之一是mongos在每个应用程序节点上提供服务，甚至可能在一个额外的专用节点上提供服务，以提高可用性。正如您当前所拥有的那样，我认为您当前的部署没有任何问题。如果您的体系结构没有任何变化，那么您目前处于最佳实践之内。然而...

如果我们使用的是Docker，那么通常不建议在容器内运行多个进程。

由于该mongos过程不是很耗资源，因此您也可以在每个分片上放置它的一个实例，并使每个mongod节点也充当一个mongos节点。如果您使应用程序服务器体系结构稍微复杂一点，则可能更有意义。

我个人不太熟悉这些产品，但我也会与供应商联系，以咨询他们的建议，因为它们mongos可能不如您可以并行运行的大多数其他过程那么密集。

最后，您可以mongos根据自己的规模，资源等，始终为该过程使用专用节点，这也完全属于最佳实践。真正的收获是，只要您在某处有很多mongos流程，那么您就可以做得很好。

不过，到底有多少真正取决于部署的大小和SLA要求。如果您使用分片，那么您将拥有更多的资源，但是如果您要使用专用节点，我将尝试尽可能地匹配应用程序节点的数量。

您可以从MongoDB M102在线课程中观看该视频，该视频涵盖了这些主题，并且可能希望在下一次会话（免费，在线）时尝试注册M102 for DBA课程。