后台服务器框架中的瑞士军刀——MCP

上篇介绍了一个简单的UDP服务框架，可是面对海量的请求，同步框架显然有点力不从心。因而在我接手好友系统的接口服务的时候，就采用了一个强大的异步框架——MCP框架。

MCP框架是一个多进程异步框架，支持UDP、TCP和http，结构很灵活，能够根据须要将各组件像搭积木同样组装。下面是MCP最基础的进程结构。分为3种进程：CCD、MCD和DCC。

CCD是面向客户端的进程，是服务的入口，负责处理前端的请求，维护链接，收发数据，并向MCD转发。其内部使用线程池实现对TCP请求的listen和accept。服务器内部进程之间使用flow（其实是一个数字）来表示链接，所以CCD负责维护前端请求句柄和flow之间的映射关系。CCD通常根据端口和协议设置多个。

DCC是面向后端的进程，负责向其余服务发出请求。使用跟CCD相似实现方法，只是面向的是服务器。在通过协程改造的MCP框架中，DCC被去掉了，由于MCD经过协程就能够实现与后端的交互了。DCC跟后端的链接通常采用长链接，避免频繁建立和释放链接致使大量TIME_WAIT的状况。

MCD是服务器的核心进程，负责处理业务逻辑，经过epoll和回调函数实现异步。

进程之间经过MQ进行通讯，MQ采用共享内存队列传输数据，而经过管道传输读写信号。以下图所示，进程首先把数据写入队列，当队列中的数据达到必定长度（避免每一个请求都读取数据）时，MQ会经过管道传输一个字符。MQ的使用者只要经过epoll监听管道句柄，就能够及时地得到读写信号。

了解了MCP的基本原理，就能够根据业务的须要进程个性化的定制。例如由于MCD单进程可能有性能瓶颈，咱们对其进行了扩展，改形成多MCD进程版本。如图所示，MCD后端派生出多个SUBMCD进程，SUBMCD进程负责处理真正的业务逻辑；而MCD进程退化成一个业务分发的程序，同时负责一些公共的业务逻辑，例如负责管理全局哈希表数据的超时清理（按期扫描超时节点，表太大的状况能够分次扫描，只要保持好扫描位置信息便可）。

SUBMCD直接跟CCD和DCC通讯（图中省略了SUBMCD和CCD之间的MQ），经过配置文件设置，在服务初始化的时候就在各个须要通讯的进程间建立好共享内存MQ。这样能够避免MCD成为通讯瓶颈。

另外还派生出一个MONITOR进程，负责日志的收集和输出，还能够作其余一些耗时的操做，避免业务进程阻塞。

MCP框架兼有功能强大和性能卓越的优势。具体压测数据不太记得，在一个数据包转发服务中，QPS也在30W+。在使用上，有必定的学习成本，可是适用面很是广，能够说一个框架走天下。