本文件配合主要對如下demo進行配合說明: 藉助redis已有的網路相關.c和.h檔案，半小時快速實現一個epoll非同步網路框架，程式demo

0. 手把手教你做中介軟體、高效能伺服器、分散式儲存技術交流群

手把手教你做中介軟體、高效能伺服器、分散式儲存等(redis、memcache、nginx、大容量redis pika、rocksdb、mongodb、wiredtiger儲存引擎、高效能代理中介軟體)，git地址如下:

git地址:https://github.com/y123456yz/middleware_development_learning

 

1. epoll出現背景

    epoll 是 linux 核心為處理大批量檔案描述符(網路檔案描述符主要是socket返回的套接字fd和accept處理的新連線fd)而作了改進的 poll，是 linux 下多路複用 io介面 select/poll 的增強版本。在 linux 的網路程式設計中，很長時間都在使用 select 來做事件觸發。在 2.6 核心中，有一種替換它的機制，就是 epoll。epoll替換select和poll的主要原因如下:

1. select最多處理1024(核心程式碼fd_setsize巨集定義)個連線。
2. select和poll採用輪訓方式檢測核心網路事件，演算法事件複雜度為o（n），n為連線數，效率低下。

    epoll克服了select和poll的缺點，採用回撥方式來檢測就緒事件，演算法時間複雜度o(1)，相比於select和poll，效率得到了很大的提升。

    藉助epoll的事件回撥通知機制，工作執行緒可以在沒有網路事件通知的時候做其他工作，這樣可以最大限度的利用系統cpu資源，服務端不用再阻塞等待客戶端網路事件，而是依賴epoll事件通知機制來避免同步等待。

 

2. epoll系統呼叫介面

2.1 epoll_create函式

函式宣告：int epoll_create(int size)

    該函式生成一個epoll專用的檔案描述符，其中的引數是指定生成描述符的最大範圍。在linux-2.4.32核心中根據size大小初始化雜湊表的大小，在linux2.6.10核心中該引數無用，使用紅黑樹管理所有的檔案描述符，而不是hash。

    重點:該函式返回的fd將作為其他epoll系統介面的引數。

2.2 epoll_ctl函式

函式宣告：int epoll_ctl(int epfd, int op, int fd, struct epoll_event event)

    該函式用於控制某個檔案描述符上的事件，可以註冊事件，修改事件，刪除事件。epoll_wait個引數說明如下：

     epfd: epoll事件集檔案描述符，也就是epoll_create返回值

   op: 對fd描述符進行的操作型別，可以是添加註冊事件、修改事件、刪除事件，分別對應巨集定義: EPOLL_CTL_ADD、EPOLL_CTL_MOD、EPOLL_CTL_DEL。

     fd: 操作的檔案描述符。

     event: 需要操作的fd對應的epoll_event事件物件，物件資料來源為fd和op。

2.3 epoll_wait函式

函式宣告:int epoll_wait(int epfd, struct epoll_event events, int maxevents, int timeout)，該函式用於輪詢i/o事件的發生，改函式引數說明如下:

    epfd: epoll事件集檔案描述符，也就是epoll_create返回值。

    Events：該epoll時間集上的所有epoll_event資訊，每個fd對應的epoll_event都存入到該陣列中，陣列每個成員對應一個fd描述符。

    Maxevents: 也就是events陣列長度。

    Timeout: 超時時間，如果在這個超時時間內核心沒有I/O網路事件通知，則會超時返回，如果在超時時間內有時間通知，則立馬返回

 

3. epoll I/O對路複用主要程式碼實現流程

程式碼實現主要由以下幾個階段組成：

1. 建立套接字獲取sd，bind然後listen該套接字sd。
2. 把步驟1中的sd新增到epoll事件集中，epoll只關注sd套接字上的新連線請求，新連線對應的事件為讀事件AE_READABLE (EPOLLIN)。並設定新連線事件到來時對應的回撥函式為MainAcceptTcpHandler。
3. 在新連接回調函式MainAcceptTcpHandler中，獲取新連線，並返回該新連線對應的檔案描述符fd，同時把新連線的fd新增到epoll事件集中，該fd開始關注epoll讀事件，如果檢測到該fd對應的讀事件(客戶端傳送的資料服務端收到後，核心會觸發該fd對應的epoll讀事件)，則觸發讀資料回撥函式MainReadFromClient。多個連線，每個連線有各自的檔案描述符事件結構(該結構記錄了各自的私有資料、讀寫回調函式等)，並且每個連線fd有各自的已就緒事件結構。不同連線有不同的結構資訊，最終藉助epoll實現I/O多路複用。
4. 進入aeMain事件迴圈函式中，迴圈檢測步驟2中的新連線事件和步驟3中的資料讀事件。如果有對應的epoll事件，則觸發epoll_wait返回，並執行對應事件的回撥。
5.  

4. epoll I/O多路複用主要資料結構及函式說明

4.1 主要資料結構

struct aeEventLoop結構用於記錄整個epoll事件的各種資訊，主要成員如下:

typedef struct aeEventLoop {

    // 目前已註冊的最大描述符

    int maxfd;   /* highest file descriptor currently registered */

    // 目前已追蹤的最大描述符

    int setsize; /* max number of file descriptors tracked */

    // 用於生成時間事件 id

    long long timeEventNextId;

    // 最後一次執行時間事件的時間

    time_t lastTime;     /* Used to detect system clock skew */

    // 已註冊的檔案事件，每個fd對應一個該結構，events實際上是一個數組

    aeFileEvent *events; /* Registered events */

    // 已就緒的檔案事件，參考aeApiPoll，陣列結構

    aeFiredEvent *fired; /* Fired events */

    // 時間事件，所有的定時器時間都新增到該連結串列中

aeTimeEvent *timeEventHead;

}

      該結構主要由檔案描述符事件(即網路I/O事件，包括socket/bind/listen對應的sd檔案描述符和accept獲取到的新連線檔案描述符)和定時器事件組成，其中檔案事件主要由events、fired、maxfd、setsize，其中events和fired為陣列型別，陣列大小為setsize。

      events陣列: 成員型別為aeFileEvent，每個成員代表一個註冊的檔案事件，檔案描述符與陣列遊標對應，例如如果fd=10，則該fd對應的檔案事件為event陣列的第十個成員Events[10]。

      fired陣列: 成員型別為aeFiredEvent，每個成員代表一個就緒的檔案事件，檔案描述符和陣列遊標對應，例如如果fd=10，則該fd對應的已就緒的檔案事件為fired陣列的第十個成員fired [10]。

    Setsize: 為events檔案事件陣列和fired就緒事件陣列的長度，初始值為REDIS_MAX_CLIENTS + REDIS_EVENTLOOP_FDSET_INCR。aeCreateEventLoop中提前分配好events和fired陣列空間。

      maxfd: 為所有檔案描述符中最大的檔案描述符，該描述符的作用是調整setsize大小來擴大events和fired陣列長度，從而保證儲存所有的事件，不會出現陣列越界。

何時擴大events和fireds陣列長度？

      例如redis最開始設定的預設最大連線數為REDIS_MAX_CLIENTS，如果程式執行一段時間後，我們想調大最大連線數，這時候就需要調整陣列長度。

為什麼events和fireds陣列長度需要加REDIS_EVENTLOOP_FDSET_INCR？

      因為redis程式中除了網路相關accept新連線的描述符外，程式中也會有普通檔案描述符，例如套接字socket描述符、日誌檔案、rdb檔案、aof檔案、syslog等檔案描述符，確保events和fireds陣列長度大於配置的最大連線數，從而避免陣列越界。

4.2 主要函式實現

主要函式功能請參考以下幾個函式:

aeCreateFileEvent

aeDeleteFileEvent

aeProcessEvents

aeApiAddEvent

aeApiDelEvent

aeApiPoll

 

5. 定時器實現原理

5.1 定時器主要程式碼流程

      Redis的定時器實際上是藉助epoll_wait實現的，epoll_wait的超時時間引數timeout是定時器連結串列中距離當前時間最少的時間差，例如現在是8點1分，我們有一個定時器需要8點1分5秒執行，那麼這裡epoll_wait的timeout引數就會設定為5s。

     epoll_wait函式預設等待網路I/O事件，如果8點1分到8點1分5秒這段時間內沒有網路I/O事件到來，那麼到了8點1分5秒的時候，epoll_wait就會超時返回。Epoll_wait返回後就會在aeMain迴圈體中遍歷定時器連結串列，獲取到定時器到達時間比當前時間少的定時器，執行該定時器的對應回撥函式。

      如果在8點1分3秒過程中有網路事件到達，epoll_wait會在3秒鐘返回，返回後處理完對應的網路事件回撥函式，然後繼續aeMain迴圈體中遍歷定時器連結串列，獲取離當前時間最近的定時器時間為5-3=2秒，也就是還有2秒該定時器才會到期，於是在下一個epoll_wait中，設定timeout超時時間為2秒，以此迴圈。

5.2 兩種不同的定時器(週期性定時器、一次性定時器)

    週期性定時器: 指的是定時器到期對應的回撥函式執行後，需要重新設定該定時器的超時時間，以備下一個週期繼續執行。

    一次性定時器: 本次定時時間到執行完對應的回撥函式後，把該定時器從定時器連結串列刪除。

    兩種定時器程式碼主要程式碼流程區別如下:

      

5.3 主要資料結構及函式實現

主要資料結構如下:

typedef struct aeEventLoop {

     // 時間事件，所有的定時器時間都新增到該連結串列中

   aeTimeEvent *timeEventHead;

}

主要函式實現參考:

aeCreateTimeEvent

aeDeleteTimeEvent

aeSearchNearestTimer

processTimeEvents

 

6. 常用套接字選項設定

套接字選項可以通過setsockopt函式進行設定，函式宣告如下:

 int setsockopt( int socket, int level, int option_name, const void *option_value, size_t option_len);

setsockopt引數說明如下:

    socket: 可以是bind/listen對應的sd，也可以是accept獲取到的新連線fd。

    level: 引數level是被設定的選項的級別，套接字級別對應 SOL_SOCKET，tcp網路設定級別對應SOL_SOCKET.

    option_name: 選項型別。

    optval：指標，指向存放選項待設定的新值的緩衝區。

    optlen：optval緩衝區長度。

6.1 SOL_SOCKET級別套接字選項

    Level級別為SOL_SOCKET的option_name常用型別如下（說明:網路I/O的檔案描述符控制代碼有兩類，一類是針對socket()/bind/listen對應的sd，一類是新連線到來後accept返回的新的連線控制代碼fd）:

    SO_REUSEADDR: 複用地址，針對socket()/bind/listen對應的sd，避免服務端程序退出再重啟後出現error:98，Address already in use。

    SO_RECVBUF: 設定連線fd對應的核心網路協議棧接收緩衝區buf大小，每個連線都會有一個recv buf來接收客戶端傳送的資料。實際應用中，使用預設值就可以，但如果連線過多，負載過大，記憶體可能吃不消，這時候可以調小該值。

    SO_SNDBUF：設定連線fd對應的核心網路協議棧傳送緩衝區buf大小，每個連線都會有一個send buf來快取需要傳送的連線資料。實際應用中，使用預設值就可以，但如果連線過多，負載過大，記憶體可能吃不消，這時候可以調小該值。

    SO_KEEPALIVE：針對socket()/bind/listen對應的sd，設定TCP的keepalive機制，由核心網路協議棧實現連線保活。通過該設定可以判斷對端異常斷電、網路不通的連線問題(如網線鬆動)。因為客戶端異常斷電或者網線鬆動，服務端是不會有epoll異常事件通知的。如果沒有設計應用層保活超時報文，則可以依賴協議棧keepalive來檢測連線是否異常。

    SO_LINGER：決定關閉連線fd的方式，因為關閉連線的時候，該fd對應的核心協議棧buf可能資料還沒有傳送出去，如果強制立即關閉可能會出現丟資料的情況。可以根據傳入optval引數決定立即關閉連線(可能丟資料)，還是等待資料傳送完畢後關閉釋放連線或者超時關閉連線。

    SO_RCVTIMEO：針對sd和新連線fd，接收資料超時時間，這個針對阻塞讀方式。如果read超過這麼多時間還沒有獲取到核心協議棧資料，則超時返回。

    SO_SNDTIMEO：針對sd和新連線fd，傳送資料超時時間，這個針對阻塞寫方式。如果write超過這麼多時間還沒有把資料成功寫入到核心協議棧，則超時返回。

6.2 IPPROTO_TCP級別套接字選項

Level級別為IPPROTO_TCP的option_name常用型別如下：

    TCP_NODELAY：針對連線fd，是否啟用naggle演算法，一般禁用，這樣可以保證服務端快速回包，降低時延。

 

7. 阻塞、非阻塞

服務端和網路I/O相關相關的幾個系統函式主要是:accept()接收客戶端連線、read()從核心網路協議棧讀取客戶端傳送來的資料、write()寫資料到核心協議棧buf，然後由核心排程傳送出去。請參考阻塞demo和非阻塞demo。

7.1阻塞及其demo程式驗證說明

      網上相關說明很多，但是都比較抽象。這裡以服務端呼叫accept為例說明：accept()函式會進行系統呼叫，從應用層走到核心空間，最終呼叫核心函式SYSCALL_DEFINE3()，如果accept對應的sd(socket/bind/listen對應的檔案描述符)是阻塞呼叫(如果不進行設定，預設就是阻塞呼叫)，SYSCALL_DEFINE3()對應的函式會判斷核心是否收到客戶端新連線，如果沒有則一直等待，直到有新連線到來或者超時才會返回。

      從上面的描述可以看出，如果是阻塞方式，accept()所在的現場會一直等待，整個執行緒不能做其他事情，這就是阻塞。Accept()阻塞超時時間可以通過上面的SO_RCVTIMEO設定。

      Read()和write()阻塞操作過程和acept()類似，只有在接收到資料和寫資料到協議棧成功才會返回，或者超時返回，超時時間分別可以通過SO_RCVTIMEO和SO_SNDTIMEO設定。

      下面以如下demo為例，來體驗阻塞和非阻塞，以下是阻塞操作例子，分別對應服務端和客戶端程式碼:

      服務端阻塞操作程式demo github地址

      對應客戶端程式demo github地址

        

        

      從上面的程式，服務端建立套接字後，繫結地址後開始監聽，然後阻塞accept()等待客戶端連線。如果客戶端有連線，則開始阻塞等待read()讀客戶端傳送來的資料，讀到資料後列印返回，程式執行結束。

      客戶端程式建立好套接字，設定好需要連線的伺服器Ip和埠，先延時10秒鐘才開始連線伺服器，連線成功後再次延時10秒，然後傳送”block test message”字串給服務端。

      通過CRT開兩個視窗，同時啟動服務端和客戶端程式，服務端列印資訊如下:

        [root@localhost block_noblock_demo]# gcc block_server.c -o block_server

        [root@localhost block_noblock_demo]#

        [root@localhost block_noblock_demo]# ./block_server 1234

        begin accept //在這裡阻塞等待客戶端連線

        accept successful from client

 

        begin recv message //這裡阻塞等待客戶端傳送資料過來

        recv message:block test message from client

        [root@localhost block_noblock_demo]#

        客戶端列印資訊如下:

         [root@localhost block_noblock_demo]# gcc block_client.c -o block_client

         [root@localhost block_noblock_demo]# ./block_client 127.0.0.1 1234

         begin connect  //begin和end見有10s延時

         end connect

 

         begin send message //begin和end間有10s延時

         end send message:block test message to server

      從執行服務端程式和客戶端程式的列印可以看出，如果客戶端不發起連線，服務端accept()函式會阻塞等待，知道有新連線到來才會返回。同時啟用服務端和客戶端程式，服務端accept()函式10s才會返回，因為客戶端我故意做了10s延時。Read()阻塞讀函式過程和accept()類似。

       Write()阻塞驗證過程，服務端設定好該連結對應的核心網路協議棧傳送快取區大小，然後傳遞很大的一個數據給write函式，期望把這個大資料通過write函式寫入到核心協議棧傳送快取區。如果核心協議棧快取區可用buf空間比需要write的資料大，則資料通過write函式拷貝到核心傳送快取區後會立馬返回。為了驗證write的阻塞過程，我這裡故意讓客戶端不去讀資料，這樣服務端write的資料就會緩衝到協議棧傳送緩衝區，如果緩衝區空間沒那麼大。Write就會一直等待核心排程把傳送緩衝區資料通過網絡卡傳送出去，這樣就會騰出空間，繼續拷貝使用者態write需要寫的資料。由於這裡我故意讓客戶端不讀資料，該連結對應的傳送緩衝區很快就會寫滿，由於我想要寫的資料比這個buf緩衝區大很多，那麼write函式就需要阻塞等待，直到把期望傳送的資料全部寫入到該傳送快取區才會返回，或者超過系統預設的write超時時間才會返回。

7.2 非阻塞及其demo程式驗證說明

    非阻塞通過系統呼叫fcntl設定，函式程式碼如下:

      

    函式中的fd檔案描述符可以是socket/bind/listen對應的sd，也可以是accept獲取到的新連線fd。非阻塞程式demo github地址如下:

    服務端非阻塞程式demo github地址

    對應客戶端非阻塞程式demo github地址

    編譯程式，先啟動服務端程式，然後啟動客戶端程式，驗證方法如下：

       

    對應客戶端:

      

      客戶端啟動後，延遲10秒向服務端發起連線，連線建立成功後，延遲10秒向服務端傳送資料。服務端啟動後，設定sd為非阻塞，開始accept等待接收客戶端連線，如果accept系統呼叫沒有獲取到客戶端連線，則延時1秒鐘，然後繼續accept。由於客戶端啟動後要延遲10s鍾才發起連線，因此accept會有十次accept return列印。read過程和accept類似，可以檢視demo程式碼。

      我們知道write操作是把使用者態向要傳送的資料拷貝到核心態連線對應的send buf緩衝區，如果是阻塞方式，如果核心快取區空間不夠，則write會阻塞等待。但是如果我們把新連線的fd設定為非阻塞，及時核心傳送緩衝區空間不夠，write也會立馬返回，並返回本次寫入到核心空間的資料量，不會阻塞等待。可以通過執行demo自己來體驗這個過程。

     大家應該注意到，則非阻塞操作服務端demo中，accept(),read()如果沒有返回我們想要的連線或者資料，demo中做了sleep延時，為什麼這裡要做點延時呢？

      原因是如果不做延時，這裡會不停的進行accept read系統呼叫，系統呼叫過程是個非常消耗效能的過程，會造成CPU的大量浪費。假設我們不加sleep延時，通過top可以檢視到如下現象:

      

 

8. 同步、非同步

    同步和非同步是比較抽象的概念，還是用程式demo來說明。

8.1 同步

    上面的服務端阻塞操作程式demo github地址和服務端非阻塞操作程式demo github地址實際上都是同步呼叫的過程。這兩個demo都是單執行緒的，以accept()呼叫為例，不管是阻塞操作還是非阻塞操作，由於服務端不知道客戶端合適發起連線，因此只能阻塞等待，或者非阻塞輪訓查詢。不管是阻塞等待還是輪訓查詢，效率都非常低下，整個執行緒不能做其他工作，CPU完全利用不起來。

8.2 非同步

       藉助redis已有的網路相關.c和.h檔案，半小時快速實現一個epoll非同步網路框架，程式demo，這個demo是非同步操作。還是以該demo的accept為例說明，從這個demo可以看出，sd設定為非阻塞，藉助epoll機制，當有新的連線事件到來後，觸發epoll_wait返回，並返回所有的檔案描述符對應的讀寫事件，這樣就觸發執行對應的新連接回調函式MainAcceptTcpHandler。藉助epoll事件通知機制，就避免了前面兩個demo的阻塞等待過程和輪訓查詢過程，整個accept()操作由事件觸發，不必輪訓等待。本非同步網路框架demo也是單執行緒，就不存在前面兩個demo只能做accept這一件事，如果沒有accept事件到來，本非同步網路框架demo執行緒還可以處理其他已有連線的讀寫事件，這樣執行緒CPU資源也就充分利用起來了。

      打個形象的比喻，假設我們每年單位都有福利體檢，體檢後一到兩週出體檢結果，想要獲取體檢結果有兩種方式。第一種方式: 體檢結束一週後，你就坐在醫院一直等，直到體檢結果出來，整個過程你是無法正常去單位上班的(這就相當於前面的服務端阻塞demo方式)。第二種方式:你每天都跑去體檢醫院詢問，我的體檢結果出了嗎，如果沒有，第二天有去體檢醫院，以此重複，直到有一天你去體檢醫院拿到體檢結果。在你每天去醫院詢問是否已經出體檢結果的過程中，你是不能正常上班的(這種方式類似於前面的服務端非阻塞demo方式)。第三種方式：你每天正常上班，等體檢醫院打電話通知你拿體檢結果，你再去拿，電話通知你拿體檢結果的過程就相當於非同步事件通知，這樣你就可以正常上班了。第一、二種方式就是同步操作，第三種方式就是非同步操作。

    總結: 同步和非同步的區別就是非同步操作藉助epoll的事件通知機制，從而可以充分利用