MongoDB Sharded Cluster 原理
如果你还不了解 MongoDB Sharded cluster，可以先看文档认识一下
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：失败的连接，需要释放
连接池管理规则
- 连接池的总连接会控制在[minConnections, maxConnections]之间，默认为1和无穷大
- 当需要新建连接时，会发起一个新建连接的异步请求，并把请求放到
processingPool - 当连接建立成功后，会把请求转移到
readyPool，readyPool 里的连接可以直接用于服务新的请求 - 服务某个请求时会从
readyPool里取出连接后，会将连接转移到checkOutPool，标识为正在使用 - 连接使用完后，会归还到
readyPool； - 当遇到请求失败 或 一个网络连接空闲超过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<size_t>::max();
+ size_t maxConnections = 10000；
