分片集群Mongos到Shard请求管理

MongoDB Sharded Cluster 原理

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

分片集群Mongos到Shard请求管理

Mongos 到 Shard请求管理

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

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

分片集群Mongos到Shard请求管理

关于 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<size_t>::max();
+ size_t maxConnections = 10000;
上一篇:nova分析(3)—— nova-api


下一篇:Replica Set副本集方式的mongodb集群搭建