MongoDB技术分析（2）- Mongos 请求处理逻辑

前面介绍了TransportLayer作为MongoDB的网络服务端处理模块，负责和客户端的网络请求交互。那么当TransportLayer接收到客户请求后，MongoDB怎么进一步进行业务处理呢？本文以查询请求为例介绍mongos怎么把请求转发到shard server，并正确处理查询结果的。

请求处理状态机

TransportLayer接收到新连接后，会创建专门的conn线程负责处理该连接的后续所有请求，具体逻辑在ServiceEntryPointMongos类的_sessionloop函数中，根据请求的类型循环“收包，处理，回响应”三个步骤，总结状态机转换关系如下：

具体到Process业务处理里面，会进一步区分消息类型并走不同处理逻辑，主要分为：查询类（queryop/getmore）, 更新类（insert/update/delete），killcursors，以及其他ClientCommand这几种类型。

这几类命令的前半段处理流程基本类似，包括鉴权，语法判断，根据分区视图查找本次操作涉及哪些shardserver，以及错误重试机制。后半段则和具体业务逻辑相关，存在较大差异。

查询请求处理逻辑

因为是Sharding集群模式下的查询，根据查询条件的不同，可能会涉及到多个Shard Server的数据，根据分区视图确认涉及的Shard Server后，针对每个ShardServer生成一个查询任务交由TaskExecutorPool执行。TaskExecutorPool负责维护mongos到ShardServer的长连接，并包含一个network线程池负责执行和ShardServer的网络交互。

Conn线程将查询任务交由TaskExecutorPool任务队列后，会wait到信号量上阻塞等待，TaskExecutorPool里的network线程完成查询请求后，唤醒Conn线程进一步处理查询结果。

Mongos为每一个Shard Server维护一个查询结果缓存队列，并按照Merge、Skip、Limit、RemoveSortKey的顺序对查询结果进行逐级处理后返回。其中Merge操作负责合并来自多个Shard Server的查询结果，根据查询条件是否要求排序有不同的处理逻辑：

• 需要排序：根据SortKey在多个队列中找排最前面的，保证全局有序返回，缓存结果处理完了就触发到对应ShardServer查询数据；

• 不需要排序：一个Shard Server查询结果返回完了再返回下一个ShardServer的查询结果；

Mongos还会为每次查询创建一个ClusterCursor，并维护和每个远程Shard Server游标的对应关系，用于后续getmore操作进一步获取数据。

总    结

Mongos作为Sharding集群的路由节点，负责根据查询条件及分区视图将查询请求路由到对应的ShardServer，并正确处理来自多个ShardServer的查询结果。对于查询请求来说，使用pipeline的线程模型，conn线程负责和客户端的交互，并把查询请求交给network线程，network线程再负责和ShardServer的网络交互。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31556448/viewspace-2219247/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/31556448/viewspace-2219247/