【轉】後臺伺服器框架中的瑞士軍刀——MCP
【轉】後臺伺服器框架中的瑞士軍刀——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+。在使用上，有一定的學習成本，但是適用面非常廣，可以說一個框架走天下。
原文連結：