后台服务器框架中的瑞士军刀——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+。在使用上,有一定的学习成本,但是适用面非常广,可以说一个框架走天下。

posted @ 2019-11-20 23:23  后台开发拾遗  阅读(...)  评论(... 编辑 收藏