分片集群Mongos到Shard请求管理

MongoDB Sharded Cluster 原理

如果你还不了解 MongoDB Sharded cluster，可以先看文档认识一下

• 中文简介：MongoDB Sharded cluster架构原理
• 英文汇总：https://docs.mongodb.com/manual/sharding/

Mongos 到 Shard请求管理

Mongos 是 MongoDB 分片集群的访问入口，Mongos 收到 Client 访问请求，会根据从 Config Server 获取的路由表将请求转发到后端对应的 Shard 上。

MongoDB-3.2 版本里，Mongos 到 Shard 的请求由一组 TaskExecutor 来执行，TaskExecutor 可以简单理解为一个任务调度器，当Mongos 需要向 Shard 发送请求时，会将调用 TaskExecutor::scheduleRemoteCommand 将请求扔给调度器，然后等待任务执行完成。

关于 TaskExecutor

Mongos 会根据请求的类型来选择 TaskExecutor，写请求为了保证顺序，每次都会选择一个特定的 TaskExecutor 来执行任务。对于读请求 Mongos 会采用 RoundRobin 的方式从一组TaskExecutor 中来选择一个执行（默认会初始化CPU核数个 TaskExecutor）。

TaskExecutor 包含2个重要的组成部分，负责调度逻辑的的 NetworkInterfaceThreadPool， 以及负责实际IO操作的 NetworkInterfaceASIO，使用了 boost::ASIO，将所有IO操作都异步化，它包含一个连接池（ConnectionPool），用于管理 Mongos 到 Shard 的网络连接。

当 Mongos 需要向 Shard 发请求时，就会从连接池里获取一个新的网络连接，当没有空闲的网络连接时，则会创建新的网络连接，所以当客户端到 Mongos 并发请求很多时，Mongos 到 后端 Shard 的网络连接也会很多。

关于连接池

ConnectionPool 针对每 个Shard 机器维护一个连接池，这个连接池包含4个小的池子，用于管理连接的生命周期。

• processingPool： 正在建立的连接
• readyPool：已经建立并且可用的连接
• checkoutPool： 正在使用的连接
• droppedProcessingPool：失败的连接，需要释放

连接池管理规则

1. 连接池的总连接会控制在[minConnections, maxConnections]之间，默认为1和无穷大
2. 当需要新建连接时，会发起一个新建连接的异步请求，并把请求放到 processingPool
3. 当连接建立成功后，会把请求转移到readyPool，readyPool 里的连接可以直接用于服务新的请求
4. 服务某个请求时会从 readyPool 里取出连接后，会将连接转移到 checkOutPool，标识为正在使用
5. 连接使用完后，会归还到 readyPool；
6. 当遇到请求失败 或 一个网络连接空闲超过1分钟时，会释放连接

总结

Mongos 里 TaskExecutor 的个数默认为机器的 CPU 核数，也可以在启动时指定；如果一个机器上部署多个 MongoDB 进程，最好调整该值，可以一定程度上降低到后端 Shard 的连接数量。
修改 TaskExecutor 的方法如下

1. 启动命令行指定

mongos --setParameter taskExecutorPoolSize=16  

2. 配置文件指定

setParameter: 
   taskExecutorPoolSize: 16

如果 Client 访问 Mongos 的并发特别高，修改 TaskExecutor 也无法有效的控制 Mongos 到 Shard 的连接数，因为一旦没有了空闲的连接，就会创建新的。目前 Mongos 到 Shard 最大连接数还不支持配置，如果确实有需要，可以修改源码。

src/mongo/executor/connection_pool.h

- size_t maxConnections = std::numeric_limits::max();
+ size_t maxConnections = 10000；

作者简介

张友东，阿里云技术专家，主要关注分布式存储、NoSQL数据库等技术领域，先后参与TFS（淘宝分布式文件系统)、Redis云数据库等项目，目前主要从事MongoDB云数据库的研发工作，致力于让开发者用上最好的MongoDB云服务。