ten*_*shi 12 mongodb best-practices deployment sharding docker
我想问一个关于本文档中描述的最佳实践的问题：
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在此架构中定位和部署流程的更好方法是什么？
Nei*_*unn 12
由于已经提交了答案，并且是有用且有效的答案，因此我不想分散其自身的实用性，但确实有几点要提出，而不仅仅是简短的评论。所以考虑一下这个“扩充”，它希望是有效的，但主要是对已经说过的内容的补充。
事实是要真正考虑“您的应用程序如何使用数据”，并且还要注意“分片环境”以及您提议的“容器环境”中影响这一点的因素。
将mongos进程与应用程序实例并置在一起的实践建议的一般做法是避免应用程序与该mongos进程通信所需的任何网络开销。当然，mongos在“最近的”节点由于某种原因不可用的情况下，在应用程序连接字符串中指定多个实例也是“推荐的做法”，然后可以选择另一个节点，尽管可能会产生联系远程节点。
您提到的“docker”案例似乎有些武断。虽然容器的主要目标之一（在此之前，像 BSD jails 甚至 chroot ）通常是实现某种程度的“进程隔离”，但运行多个进程并没有什么错，只要你了解其中的含义。
在这种特殊情况下，mongos它意味着“轻量级”并作为应用程序进程的“附加功能”运行，它几乎是应用程序本身的“配对”部分。所以 docker 镜像本身没有类似“initd”的进程，但是运行像supervisord这样的进程控制器（例如）作为容器的主进程并没有什么问题，然后给你一个进程控制点那个容器也是。这种“配对进程”的情况是一个合理的情况，也是一个足够常见的问题，有官方文档说明。
如果您选择这种“配对”操作进行部署，那么它确实解决了mongos在同一网络连接上维护实例的主要问题，并且确实解决了与应用程序服务器本身相同的“服务器实例”问题。也可以以某种方式将其视为“整个容器”失败的情况，然后该节点本身将完全无效。并不是说我会推荐它，实际上您可能仍然应该配置连接以查找其他mongos实例，即使这些只能通过增加延迟的网络连接访问。
既然已经提出了这一点，这里的另一个考虑因素又回到了最初考虑将mongos进程与应用程序放在一起以实现网络延迟的目的。在 2.6 之前的 MongoDB 版本中，特别是在聚合框架等操作方面，会出现更多的网络流量和后续处理工作，由mongos处理来自不同分片的数据的进程执行. 现在情况并非如此，因为现在可以在“蒸馏”到“路由器”之前对这些分片本身执行大量处理工作量。
另一种情况是您的应用程序使用模式本身与分片有关。这意味着主要工作负载是在多个分片之间“分配写入”，还是实际上是整合读取请求的“分散-聚集”方法。在那些场景中
所以这里的最后一点真的是不言自明的，归结为对你的问题的任何理智回应的基本共识。这对于 MongoDB 或任何其他存储解决方案来说并不是什么新鲜事，但是您的实际部署环境需要根据它的“使用模式”进行测试，就像对核心组件的预期功能的任何“单元测试”一样接近实际情况或整体结果需要测试。
除了按预期测试什么对您的应用程序性能和可靠性“实际上最有效”之外，实际上没有“确定性”声明说“以这种方式配置”或“以这种方式使用”实际上是有意义的。
当然，“最好的情况”始终是不要mongos用来自“许多”应用服务器源的请求“挤满”实例。但是，为了让他们有一些自然的“奇偶校验”，可以通过可用的资源工作负载来分配“至少”一个可以选择的“资源池”，并且确实在许多情况下是理想的，但不需要引起额外的“网络传输开销”。
这是目标，但理想情况下，您可以“实验室测试”不同的感知配置，以便为您的最终部署解决方案找到“最适合”的解决方案。
我还强烈推荐前面提到的“免费”（如啤酒）课程，无论您的知识水平如何。我发现各种课程材料来源通常提供“隐藏的宝石”，让您更深入地了解您可能没有考虑或以其他方式忽视的事情。前面提到的M102 课程是由Adam Commerford构建和指导的，我可以证明他在 MongoDB 和其他数据架构的大规模部署方面具有很高的知识水平。值得花时间至少考虑一下您可能认为自己已经知道的新观点。
由于最佳实践还表明“适当数量的 mongos 进程将取决于应用程序和部署的性质”，因此我开始怀疑我们对 mongos 的使用是否真的合适
我认为这是一个最终只有你才能回答的问题，正如文档所指的那样。
推荐的策略之一是mongos在每个应用程序节点上都有一个服务，甚至可能有一个额外的专用节点，以获得额外的可用性。正如您目前拥有的那样，我认为您当前的部署没有任何问题。如果您的架构没有任何变化，那么您目前就处于最佳实践之中。然而...
如果我们使用 Docker，那么通常不鼓励在容器内运行多个进程的做法。
由于该mongos过程不是非常耗费资源，因此您还可以将它的一个实例放在每个分片上，并让每个mongod节点也充当mongos节点。如果您使应用程序服务器架构稍微复杂一些，这可能更有意义。
我个人对这些产品不太熟悉，但我也会向供应商咨询他们的建议，因为mongos与您可以并行运行的大多数其他流程相比，它们的强度可能较低。
最后，您始终可以mongos根据您的规模、资源等，为流程使用专用节点，这也完全符合最佳实践。这里真正的收获是，只要你在某处有一堆mongos流程那么您就做得很好。
不过，有多少真正取决于您的部署规模和 SLA 要求。如果您使用分片，您将拥有足够多的资源，但如果您要使用专用节点，我会尝试尽可能匹配应用程序节点的数量。
您可以从 MongoDB M102 在线课程中查看此视频，该课程讨论了这些主题，并且可能想在下次开课时尝试注册M102 for DBA 课程（免费、在线）。