本文来自OPPO互联网基础技术团队，转载请注名作者。同时欢迎关注我们的公众号：OPPO_tech，与你分享OPPO前沿互联网技术及活动。

开源mongodb代码规模数百万行，本篇文章内容主要分析mongodb网络传输模块内部实现及其性能调优方法，学习网络IO处理流程，体验不同工作线程模型性能极致设计原理。另外一个目的就是引导大家快速进行百万级别规模源码阅读，做到不同大工程源码”举一反三”快速阅读的目的。

此外，mognodb网络工作线程模型设计非常好，不仅非常值得数据库相关研发人员学习，中间件、分布式、高并发、服务端等相关研发人员也可以借鉴，极力推荐大家学习。

1. 如何阅读数百万级大工程内核源码

Mongodb内核源码由第三方库third_party和mongodb服务层源码组成，其中mongodb服务层代码在不同模块实现中依赖不同的third_party库，第三方库是mongodb服务层代码实现的基础(例如:网络底层IO实现依赖asio-master库, 底层存储依赖wiredtiger存储引擎库)，其中第三方库也会依赖部分其他库(例如：wiredtiger库依赖snappy算法库，asio-master依赖boost库)。

虽然Mongodb内核源码数百万行，工程量巨大，但是mongodb服务层代码实现层次非常清晰，代码目录结构、类命名、函数命名、文件名命名都非常一目了然，充分体现了10gen团队的专业精神。

说明：mongodb内核除第三方库third_party外的代码，这里统称为mongodb服务层代码。

本文以mongodb服务层transport实现为例来说明如何快速阅读整个mongodb代码，我们在走读代码前，建议遵循如下准则：

1.1 熟悉mongodb基本功能和使用方法

首先，我们需要熟悉mongodb的基本功能，明白mongodb是做什么用的，用在什么地方，这样才能体现mongodb的真正价值。此外，我们需要提前搭建一个mongodb集群玩一玩，这样也可以进一步促使我们了解mongodb内部的一些常用基本功能。千万不要急于求成，如果连mongodb是做什么的都不知道，或者连mongodb的运维操作方法都没玩过，直接读取代码会非常不适合，没有目的的走读代码不利于分析整个代码，同时阅读代码过程会非常痛苦。

1.2 下载代码编译源码

熟悉了mongodb的基本功能，并搭建集群简单体验后，我们就可以从github下载源码，自己编译源码生成二进制文件，编译文档存放于docs/building.md 代码目录中，源码编译步骤如下:

下载对应releases中对应版本的源码
进入对于目录，参考docs/building.md文件内容进行相关依赖工具安装
执行buildscripts/scons.py编译出对应二进制文件，也可以直接scons mongod mongos这样编译。
编译成功后的生产可执行文件存放于./build/opt/mongo/目录

在正在编译代码并运行的过程中，发现以下两个问题：

1)编译出的二进制文件占用空间很大，如下图所示：

从上图可以看出，通过strip处理工具处理后，二进制文件大小已经和官方二进制包大小一样了。

2)在一些低版本操作系统运行的时候出错，找不到对应stdlib库，如下图所示：

如上图所示，当编译出的二进制文件拷贝到线上运行后，发现无法运行，提示libstdc库找不到。原因是我们编译代码时候依赖的stdc库版本比其他操作系统上面的stdc库版本更高，造成了不兼容。

解决办法： 编译的时候编译脚本中带上-static-libstdc++，把stdc库通过静态库的方式进行编译，而不是通过动态库方式。

1.3 了解代码日志模块使用方法，试着加打印调试

由于前期我们对代码整体实现不熟悉，不知道各个接口的调用流程，这时候就可以通过加日志打印进行调试。Mongodb的日志模块设计的比较完善，从日志中可以很明确的看出由那个功能模块打印日志，同时日志模块有多种打印级别。

1)日志打印级别设置

启动参数中verbose设置日志打印级别，日志打印级别设置方法如下：

Mongod -f ./mongo.conf -vvvv

这里的v越多，表明日志打印级别设置的越低，也就会打印更多的日志。一个v表示只会输出LOG(1)日志，-vv表示LOG(1) LOG(2)都会写日志。

2)如何在.cpp文件中使用日志模块记录日志

如果需要在一个新的.cpp文件中使用日志模块打印日志，需要进行如下步骤操作：

添加宏定义 #define MONGO_LOG_DEFAULT_COMPONENT ::mongo::logger::LogComponent::kExecutor
使用LOG(N)或者log()来记录想要输出的日志内容，其中LOG(N)的N代表日志打印级别，log()对应的日志全记录到文件。

例如: LogComponent::kExecutor代表executor模块相关的日志，参考log_component.cpp日志模块文件实现，对应到日志文件内容如下：

1.4 学会用gdb调试mongodb代码

Gdb是linux系统环境下优秀的代码调试工具，支持设置断点、单步调试、打印变量信息、获取函数调用栈信息等功能。gdb工具可以绑定某个线程进行线程级调试，由于mongodb是多线程环境，因此在用gdb调试前，我们需要确定调试的线程号，mongod进程包含的线程号及其对应线程名查看方法如下:

注意： 在调试mongod工作线程处理流程的时候，不要选择adaptive动态线程池模式，因为线程可能因为流量低引起工作线程不饱和而被销毁，从而造成调试过程因为线程销毁而中断，synchronous线程模式是一个链接一个线程，只要我们不关闭这个链接，线程就会一直存在，不会影响我们理解mongodb服务层代码实现逻辑。 synchronous线程模式调试的时候可以通过mongo shell链接mongod服务端端口来模拟一个链接，因此调试过程相对比较可控。

在对工作线程调试的时候，发现gdb无法查找到mongod进程的符号表，无法进行各种gdb功能调试，如下图所示：

上述gdb无法attach到指定线程调试的原因是无法加载二进制文件符号表，这是因为编译的时候没有加上-g选项引起，mongodb通过SConstruct脚本来进行scons编译，要启编译出新的二进制文件后，就可以gdb调试了，如下图所示，可以很方便的定位到某个函数之前的调用栈信息，并进行单步、打印变量信息等调试：

1.5 熟悉代码目录结构、模块细化拆分

在进行代码阅读前还有很重要的一步就是熟悉代码目录及文件命名实现，mongodb服务层代码目录结构及文件命名都有很严格的规范。下面以truansport网络传输模块为例，transport模块的具体目录文件结构：

从上面的文件分布内容，可以清晰的看出，整个目录中的源码实现文件大体可以分为如下几个部分：

message_compressor_*网络传输数据压缩子模块
service_entry_point*服务入口点子模块
service_executor*服务运行子模块，即线程模型子模块
service_state_machine*服务状态机处理子模块
Session*回话信息子模块
Ticket*数据分发子模块
transport_layer*套接字处理及传输层模式管理子模块

通过上面的拆分，整个大的transport模块实现就被拆分成了7个小模块，这7个小的子模块各自负责对应功能实现，同时各个模块相互衔接，整体实现网络传输处理过程的整体实现，下面的章节将就这些子模块进行简单功能说明。

1.6 从main入口开始大体走读代码

前面5个步骤过后，我们已经熟悉了mongodb编译调试以及transport模块的各个子模块的相关代码文件实现及大体子模块作用。至此，我们可以开始走读代码了，mongos和mongod的代码入口分别在mongoSMain()和mongoDbMain()，从这两个入口就可以一步一步了解mongodb服务层代码的整体实现。

注意： 走读代码前期不要深入各种细节实现，大体了解代码实现即可，先大体弄明白代码中各个模块功能由那些子模块实现，千万不要深究细节。

1.7 总结

本章节主要给出了数百万级mongodb内核代码阅读的一些建议，整个过程可以总结为如下几点：

提前了解mongodb的作用及工作原理。
自己搭建集群提前学习下mongodb集群的常用运维操作，可以进一步帮助理解mongodb的功能特性，提升后期代码阅读的效率。
自己下载源码编译二进制可执行文件，同时学会使用日志模块，通过加日志打印的方式逐步开始调试。
学习使用gdb代码调试工具调试线程的运行流程，这样可以更进一步的促使快速学习代码处理流程，特别是一些复杂逻辑，可以大大提升走读代码的效率。
正式走读代码前，提前了解各个模块的代码目录结构，把一个大模块拆分成各个小模块，先大体浏览各个模块的代码实现。
前期走读代码千万不要深入细节，捋清楚各个模块的大体功能作用后再开始一步一步的深入细节，了解深层次的内部实现。
从main()入口逐步开始走读代码，结合log日志打印和gdb调试。
跳过整体流程中不熟悉的模块代码，只走读本次想弄明白的模块代码实现。

2. mongodb内核网络传输transport模块实现原理

从1.5章节中，我们把transport功能模块细化拆分成了网络传输数据压缩子模块、服务入口子模块、线程模型子模块、状态机处理子模块、session会话信息子模块、数据分发子模块、套接字处理和传输管理子模块，总共七个子模块。

实际上mongodb服务层代码的底层网络IO实现依赖asio库完成，因此transport功能模块应该是7+1个子模块构成，也就是服务层代码实现由8个子模块支持。

2.1 asio网络IO库实现原理

Asio是一个优秀网络库，依赖于boost库的部分实现，支持linux、windos、unix等多平台，mongodb基于asio库来实现网络IO及定时器处理。asio库由于为了支持多平台，在代码实现中用了很多C++的模板，同时用了很多C++的新语法特性，因此整体代码可读性相比mongodb服务层代码差很多。

服务端网络IO异步处理流程大体如下：

调用socket()创建一个套接字，获取一个socket描述符。
调用bind()绑定套接字，同时通过listen()来监听客户端链接，注册该socket描述符到epoll事件集列表，等待accept对应的新连接读事件到来。
通过epoll_wait获取到accept对应的读事件信息，然后调用accept()来接受客户的连接，并获取一个新的链接描述符new_fd。
注册新的new_fd到epoll事件集列表，当该new_fd描述符上有读事件到来，于是通过epoll_wait获取该事件，开始该fd上的数据读取。
读取数据完毕后，开始内部处理，处理完后发送对应数据到客户端。如果一次write数据到内核协议栈写太多，造成协议栈写满，则添加写事件到epoll事件列表。

服务端网络IO同步方式处理流程和异步流程大同小异，少了epoll注册和epoll事件通知过程，直接同步调用accept()、recv()、send()进行IO处理。

同步IO处理方式相对比较简单，下面仅分析和mongodb服务层transport模块结合比较紧密的asio异步IO实现原理。

Mongodb服务层用到的Asio库功能中最重要的几个结构有io_context、scheduler、epoll_reactor。Asio把网络IO处理任务、状态机调度任务做为2种不同操作，分别由两个继承自operation的类结构管理，每种类型的操作也就是一个任务task。io_context、scheduler、epoll_reactor最重要的功能就是管理和调度这些task有序并且高效的运行。

2.1.1 io_context类实现及其作用

io_context 上下文类是mongodb服务层和asio网络库交互的枢纽，是mongodb服务层和asio库进行operation任务交互的入口。该类负责mongodb相关任务的入队、出队，并与scheduler调度处理类配合实现各种任务的高效率运行。Mongodb服务层在实现的时候，accept新连接任务使用_acceptorIOContext这个IO上下文成员实现，数据分发及其相应回调处理由_workerIOContext上下文成员实现。

该类的几个核心接口功能如下表所示：

Io_context类成员/函数名	功能	备注说明
impl_type& impl_;	Mongodb对应的type类型为scheduler	通过该成员来调用scheduler调度类的接口
io_context::run()	负责accept对应异步回调处理	1.mongodb中该接口只针对accept对应IO异步处理 2.调用scheduler::run()进行accept异步读操作
io_context::stop()	停止IO调度处理	调用scheduler::stop()接口
io_context::run_one_until()	1. 从全局队列上获取一个任务执行 2. 如果全局队列为空，则调用epoll_wait()获取网络IO事件处理	调用schedule::wait_one()
io_context::post()	任务入队到全局队列	调用scheduler::post_immediate_completion()
io_context::dispatch()	1.如果调用该接口的线程已经运行过全局队列中的任务，则直接继续由本线程运行该入队的任务 2.如果不满足条件1条件，则直接入队到全局队列，等待调度执行	如果条件1满足，则直接由本线程执行如果条件1不满足，则调用scheduler::do_dispatch ()

总结：

从上表的分析可以看出，和mongodb直接相关的几个接口最终都是调用schedule类的相关接口，整个实现过程参考下一节scheduler调度实现模块。
上表中的几个接口按照功能不同，可以分为入队型接口(poll、dispatch)和出队型接口(run_for、run、run_one_for)。
按照和io_context的关联性不同，可以分为accept相关io(_acceptorIOContext)处理的接口(run、stop)和新链接fd对应Io(_workerIOContext)数据分发相关处理及回调处理的接口(run_for、run_one_for、poll、dispatch)。
io_context上下文的上述接口，除了dispatch在某些情况下直接运行handler外，其他接口最终都会间接调用scheduler调度类接口。

2.1.2 asio调度模块scheduler实现

上一节的io_context上下文中提到mongodb操作的io上下文最终都会调用scheduler的几个核心接口，io_context只是起衔接mongodb和asio库的链接桥梁。scheduler类主要工作在于完成任务调度，该类和mongodb相关的几个主要成员变量及接口如下表：

scheduler类主要成员/接口	功能	备注说明
mutable mutex mutex_;	互斥锁，全局队列访问保护	多线程从全局队列获取任务的时候加锁保护
op_queue op_queue_;	全局任务队列，全局任务和网络事件相关任务都添加到该队列	3.1.1中的5种类型的任务都入队到了该全局队列
bool stopped_;	线程是否可调度标识	为true后，将不再处理epoll相关事件，参考scheduler::do_run_one
event wakeup_event_;	唤醒等待锁得线程	实际event由信号量封装
task_operation task_operation_;	特殊的operation	在链表中没进行一次epoll获取到IO任务加入全局队列后，都会紧接着添加一个特殊operation
reactor* task_;	也就是epoll_reactor	借助epoll实现网络事件异步处理
atomic_count outstanding_work_;	套接字描述符个数	accept获取到的链接数fd个数+1(定时器fd)
scheduler::run()	循环处理epoll获取到的accept事件信息	循环调用scheduler::do_run_one()接口
scheduler::do_dispatch()	任务入队	任务入队到全局队列op_queue_
scheduler::do_wait_one()	任务出队执行	如果队列为空则获取epoll事件集对应的网络IO任务放入全局op_queue_队列
scheduler::restart()	重新启用调度	实际上就是修改stopped_标识为false
scheduler::stop_all_threads()	停止调度	实际上就是修改stopped_标识为true

2.1.3 operation任务队列

从前面的分析可以看出，一个任务对应一个operation类结构，asio异步实现中schduler调度的任务分为IO处理任务(accept处理、读io处理、写io处理、网络IO处理回调处理)和全局状态机任务，总共2种任务小类。

此外，asio还有一种特殊的operation，该Operastion什么也不做，只是一个特殊标记。网络IO处理任务、状态机处理任务、特殊任务这三类任务分别对应三个类结构，分别是：reactor_op、completion_handler、task_operation_，这三个类都会继承基类operation。

1. operation基类实现

operation基类实际上就是scheduler_operation类，通过typedef scheduler_operation operation指定，是其他三个任务的父类，其主要实现接口如下：

operation类主要成员/接口	功能	备注说明
unsigned int task_result_	Epoll_wait获取到的事件位图信息记录到该结构中	在descriptor_state::do_complete中取出位图上的事件信息做底层IO读写处理
func_type func_;	需要执行的任务
scheduler_operation::complete()	执行func_()	任务的内容在func()中运行

2. completion_handler状态机任务

当mongodb通过listener线程接受到一个新链接后，会生成一个状态机调度任务，然后入队到全局队列op_queue_，worker线程从全局队列获取到该任务后调度执行，从而进入状态机调度流程，在该流程中会触发epoll相关得网络IO注册及异步IO处理。一个全局状态机任务对应一个completion_handler类，该类主要成员及接口说明如下表所示：

completion_handler类主要成员/接口	功能	备注说明
Handler handler_;	全局状态机任务函数	这个handler就相当于一个任务，实际上是一个函数
completion_handler(Handler& h)	构造初始化	启用该任务，等待调度
completion_handler::do_complete()	执行handler_回调	任务的内容在handler_()中运行

completion_handler状态机任务类实现过程比较简单，就是初始化和运行两个接口。全局任务入队的时候有两种方式，一种是io_context::dispatch方式，另一种是io_context::post。从前面章节对这两个接口的代码分析可以看出，任务直接入队到全局队列op_queue_中，然后工作线程通过scheduler::do_wait_one从队列获取该任务执行。

注意： 状态机任务入队由Listener线程(新链接到来的初始状态机任务)和工作线程(状态转换任务)共同完成，任务出队调度执行由mongodb工作线程执行，状态机具体任务内容在后面《状态机实现》章节实现。

3. 网络IO事件处理任务

网络IO事件对应的Opration任务最终由reactor_op类实现，该类主要成员及接口如下：

reactor_op类主要成员/接口	功能	备注说明
asio::error_code ec_;	全局状态机任务函数	这个handler就相当于一个任务，实际上是一个函数
std::size_t bytes_transferred_;	读取或者发送的数据字节数	Epoll_wait返回后获取到对应的读写事件，然后进行数据分发操作
enum status;	底层数据读写状态	标识读写数据的状态
perform_func_type perform_func_;	底层IO操作的函数指针	perform()中运行
status perform()；	运行perform_func_函数	perform实际上就是数据读写的底层实现
reactor_op(perform_func_type perform_func, func_type complete_func)	类初始化	这里有两个func: 1. 底层数据读写实现的接口，也就是perform_func 2. 读取或者发送一个完整mongodb报文的回调接口，也就是complete_func

从reactor_op类可以看出，该类的主要两个函数成员：perform_func_和complete_func。其中perform_func_函数主要负责异步网络IO底层处理，complete_func用于获取到一个新链接、接收或者发送一个完整mongodb报文后的后续回调处理逻辑。

perform_func_具体功能包含如下三种如下：

通过epoll事件集处理底层accept获取新连接fd。
fd上的数据异步接收
fd上的数据异步发送

针对上面的三个网络IO处理功能，ASIO在实现的时候，分别通过三个不同的类(reactive_socket_accept_op_base、reactive_socket_recv_op_base、reactive_socket_send_op_base)实现，这三个类都继承父类reactor_op。

这三个类的功能总结如下表所示：

类名	功能	说明
reactive_socket_accept_op_base	1. Accept()系统调用获取新fd 2. 获取到一个新fd后的mongodb层逻辑回调处理	Accept()系统调用由perform_func()函数处理获取到新链接后的逻辑回调由complete_func执行
reactive_socket_recv_op_base	1. 读取一个完整mongodb报文读取 2. 读取完整报文后的mongodb服务层逻辑回调处理	从一个链接上读取一个完整mongodb报文读取由perform_func()函数处理读取完整报文后的mongodb服务层逻辑回调处理由complete_func执行
reactive_socket_send_op_base	1. 发送一个完整的mongodb报文 2. 发送完一个完整mongodb报文后的mongodb服务层逻辑回调处理	Accept()系统调用由perform_func()函数处理获取到新链接后的逻辑回调由complete_func执行

总结： asio在实现的时候，把accept处理、数据读、数据写分开处理，都继承自公共基类reactor_op，该类由两个操作组成：底层IO操作和回调处理。其中，asio的底层IO操作最终由epoll_reactor类实现，回调操作最终由mongodb服务层指定，底层IO操作的回调映射表如下：

底层IO操作类型	Mongodb服务层回调	说明
Accept(reactive_socket_accept_op_base)	ServiceEntryPointImpl::startSession，回调中进入状态机任务流程	Listener线程获取到一个新链接后mongodb的回调处理
Recv(reactive_socket_recv_op_base)	ServiceStateMachine::_sourceCallback，回调中进入状态机任务流程	接收一个完整mongodb报文的回调处理
Send(reactive_socket_send_op_base)	ServiceStateMachine::_sinkCallback，回调中进入状态机任务流程	发送一个完整mongodb报文的回调处理

说明： 网络IO事件处理任务实际上在状态机任务内运行，也就是状态机任务中调用asio库进行底层IO事件运行处理。

4. 特殊任务task_operation

前面提到，ASIO库中还包含一种特殊的task_operation任务，asio通过epoll_wait获取到一批IO事件后，会添加到op_queue_全局队列，工作线程从队列取出任务有序执行。每次通过epoll_wait获取到IO事件信息后，除了添加这些读写事件对应的底层IO处理任务到全局队列外，每次还会额外生成一个特殊task_operation任务添加到队列中。

为何引入一个特殊任务的Opration？

工作线程变量全局op_queue_队列取出任务执行，如果从队列头部取出的是特殊Op操作，就会立马触发获取epoll网络事件信息，避免底层网络IO任务长时间不被处理引起的"饥饿"状态，保证状态机任务和底层IO任务都能”平衡”运行。

asio库底层处理实际上由epoll_reactor类实现，该类主要负责epoll相关异步IO实现处理，鉴于篇幅epoll reactor相关实现将在后续《mongodb内核源码实现及调优系列》相关章节详细分析。

2.2 message_compressor网络传输数据压缩子模块

网络传输数据压缩子模块主要用于减少网络带宽占用，通过CPU来换取IO消耗，也就是以更多CPU消耗来减少网络IO压力。

鉴于篇幅，该模块的详细源码实现过程将在《mongodb内核源码实现及调优系列》相关章节分享。