evpp網絡庫代碼分析（二）

        開局一張圖！

        上圖是盜用自《Linux多線程服務端編程,使用muduo C++網絡庫》一書6.6.2章節（以及下面的時序圖也是盜用該書的圖）。該圖列舉出大部分經常使用的網絡編程模型，固然了，這裏並無列出Boost.Asio的proactor模式。其中表中的「互通」是指多個客戶端（鏈接）間是否能方便地交換數據，如chat聊天程序。咱們的evpp庫其實是用到了「方案9」，方案9的時序圖以下：

        能夠看出，每個線程有一個EventLoop處理事件。這種方案是典型的「one loop per thread」流程，有一個「主EventLoop」負責accept鏈接，而後把鏈接經過round-robin（輪詢調度）掛到底下的多個「子EventLoop」中（EventLoopThreadPool），每一個鏈接都是由一個「子EventLoop」完成的，能保證請求的順序性，也能夠充分利用CPU，防止出現一個reactor的處理能力飽和，並且EventLoop線程池線程數量固定，不會由於鏈接數過多到達臨界點（線程太多致使操做系統線程調度不過來）而性能降低！

        另外還有一種網絡編程模型比較經常使用，就是「方案8」，這個模型在muduo中有現成方案，而在evpp中須要本身實現，時序圖以下：

        這種方案，只有一個EventLoop，但它把計算密集的部分（decode、compute、encode）分派到一個線程池中處理，處理完後再返回到EventLoop中，這樣即便decode、compute、encode這三部分是阻塞的也不影響併發鏈接，正由於是異步處理，致使打亂了返回的順序性，也即鏈接1比鏈接2先到，但有可能鏈接2先返回數據。若是處理的事情沒有優先級之分或者計算密集型（大部分時間都是處於計算中）能夠使用這種方案，若是有優先級之分，應該使用方案9，方案9算是一個各方面都比較均衡的網絡編程模式，evpp庫就優先使用這種模式。

        evpp中比較重要的基礎類有：

EventLoop
EventWatcher
Buffer等

        EventLoop相關的類包含EventLoop、EventLoopThread和EventLoopThreadPool等類，它們提供事件循環、事件分發、爲reactor網絡編程模式提供一個基礎框架。也提供了定時器，以及RunInLoop等接口，RunInLoop可在多線程環境下被調用，在本eventloop的IO線程內執行某個用戶任務回調。咱們提倡one loop per thread，顧名思義每一個線程只能有一個EventLoop對象，所以EventLoop的構造函數會檢查當前線程是否已經建立了其餘EventLoop對象，遇到錯誤就終止程序。

        EventWatcher相關的類包含PipeEventWatcher、TimerEventWatcher和SignalEventWatcher可以註冊管道、超時以及信號事件，底層是libevent2庫。

        Buffer類則是相似libevent2中的evbuffer，供應用層讀寫，底下的socket讀寫操做也會頻繁使用它。