後臺服務器框架中的瑞士軍刀——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+。在使用上，有必定的學習成本，可是適用面很是廣，能夠說一個框架走天下。