上篇介紹了一個簡單的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+，在使用上，有一定的學習成本，但是適用面非常廣，可以說一個框架走天下，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/37754.html
標籤：架構設計