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;