Redis 基于 Reactor 模式開發(fā)了自己的網(wǎng)絡(luò)事件處理器： 這個處理器被稱為文件事件處理器（file event handler）：

• 文件事件處理器使用 I/O 多路復(fù)用（multiplexing）程序來同時監(jiān)聽多個套接字， 并根據(jù)套接字目前執(zhí)行的任務(wù)來為套接字關(guān)聯(lián)不同的事件處理器。
• 當(dāng)被監(jiān)聽的套接字準(zhǔn)備好執(zhí)行連接應(yīng)答（accept）、讀?。╮ead）、寫入（write）、關(guān)閉（close）等操作時， 與操作相對應(yīng)的文件事件就會產(chǎn)生， 這時文件事件處理器就會調(diào)用套接字之前關(guān)聯(lián)好的事件處理器來處理這些事件。

雖然文件事件處理器以單線程方式運行， 但通過使用 I/O 多路復(fù)用程序來監(jiān)聽多個套接字， 文件事件處理器既實現(xiàn)了高性能的網(wǎng)絡(luò)通信模型， 又可以很好地與 Redis 服務(wù)器中其他同樣以單線程方式運行的模塊進行對接， 這保持了 Redis 內(nèi)部單線程設(shè)計的簡單性。

文件事件處理器的構(gòu)成

圖 IMAGE_CONSTRUCT_OF_FILE_EVENT_HANDLER 展示了文件事件處理器的四個組成部分， 它們分別是套接字、 I/O 多路復(fù)用程序、 文件事件分派器（dispatcher）、 以及事件處理器。

文件事件是對套接字操作的抽象， 每當(dāng)一個套接字準(zhǔn)備好執(zhí)行連接應(yīng)答（accept）、寫入、讀取、關(guān)閉等操作時， 就會產(chǎn)生一個文件事件。 因為一個服務(wù)器通常會連接多個套接字， 所以多個文件事件有可能會并發(fā)地出現(xiàn)。

I/O 多路復(fù)用程序負(fù)責(zé)監(jiān)聽多個套接字， 并向文件事件分派器傳送那些產(chǎn)生了事件的套接字。

盡管多個文件事件可能會并發(fā)地出現(xiàn)， 但 I/O 多路復(fù)用程序總是會將所有產(chǎn)生事件的套接字都入隊到一個隊列里面， 然后通過這個隊列， 以有序（sequentially）、同步（synchronously）、每次一個套接字的方式向文件事件分派器傳送套接字： 當(dāng)上一個套接字產(chǎn)生的事件被處理完畢之后（該套接字為事件所關(guān)聯(lián)的事件處理器執(zhí)行完畢）， I/O 多路復(fù)用程序才會繼續(xù)向文件事件分派器傳送下一個套接字， 如圖 IMAGE_DISPATCH_EVENT_VIA_QUEUE 。

文件事件分派器接收 I/O 多路復(fù)用程序傳來的套接字， 并根據(jù)套接字產(chǎn)生的事件的類型， 調(diào)用相應(yīng)的事件處理器。

服務(wù)器會為執(zhí)行不同任務(wù)的套接字關(guān)聯(lián)不同的事件處理器， 這些處理器是一個個函數(shù)， 它們定義了某個事件發(fā)生時， 服務(wù)器應(yīng)該執(zhí)行的動作。

I/O 多路復(fù)用程序的實現(xiàn)

Redis 的 I/O 多路復(fù)用程序的所有功能都是通過包裝常見的 select 、 epoll 、 evport 和 kqueue 這些 I/O 多路復(fù)用函數(shù)庫來實現(xiàn)的， 每個 I/O 多路復(fù)用函數(shù)庫在 Redis 源碼中都對應(yīng)一個單獨的文件， 比如 ae_select.c 、 ae_epoll.c 、 ae_kqueue.c ， 諸如此類。

因為 Redis 為每個 I/O 多路復(fù)用函數(shù)庫都實現(xiàn)了相同的 API ， 所以 I/O 多路復(fù)用程序的底層實現(xiàn)是可以互換的， 如圖 IMAGE_MULTI_LIB 所示。

Redis 在 I/O 多路復(fù)用程序的實現(xiàn)源碼中用 #include 宏定義了相應(yīng)的規(guī)則， 程序會在編譯時自動選擇系統(tǒng)中性能最高的 I/O 多路復(fù)用函數(shù)庫來作為 Redis 的 I/O 多路復(fù)用程序的底層實現(xiàn)：

/* Include the best multiplexing layer supported by this system.
 * The following should be ordered by performances, descending. */
#ifdef HAVE_EVPORT
#include "ae_evport.c"
#else
    #ifdef HAVE_EPOLL
    #include "ae_epoll.c"
    #else
        #ifdef HAVE_KQUEUE
        #include "ae_kqueue.c"
        #else
        #include "ae_select.c"
        #endif
    #endif
#endif

事件的類型

I/O 多路復(fù)用程序可以監(jiān)聽多個套接字的 ae.h/AE_READABLE 事件和 ae.h/AE_WRITABLE 事件， 這兩類事件和套接字操作之間的對應(yīng)關(guān)系如下：

• 當(dāng)套接字變得可讀時（客戶端對套接字執(zhí)行 write 操作，或者執(zhí)行 close 操作）， 或者有新的可應(yīng)答（acceptable）套接字出現(xiàn)時（客戶端對服務(wù)器的監(jiān)聽套接字執(zhí)行 connect 操作）， 套接字產(chǎn)生 AE_READABLE 事件。
• 當(dāng)套接字變得可寫時（客戶端對套接字執(zhí)行 read 操作）， 套接字產(chǎn)生 AE_WRITABLE 事件。

I/O 多路復(fù)用程序允許服務(wù)器同時監(jiān)聽套接字的 AE_READABLE 事件和 AE_WRITABLE 事件， 如果一個套接字同時產(chǎn)生了這兩種事件， 那么文件事件分派器會優(yōu)先處理 AE_READABLE 事件， 等到 AE_READABLE 事件處理完之后， 才處理 AE_WRITABLE 事件。

這也就是說， 如果一個套接字又可讀又可寫的話， 那么服務(wù)器將先讀套接字， 后寫套接字。

API

ae.c/aeCreateFileEvent 函數(shù)接受一個套接字描述符、 一個事件類型、 以及一個事件處理器作為參數(shù)， 將給定套接字的給定事件加入到 I/O 多路復(fù)用程序的監(jiān)聽范圍之內(nèi)， 并對事件和事件處理器進行關(guān)聯(lián)。

ae.c/aeDeleteFileEvent 函數(shù)接受一個套接字描述符和一個監(jiān)聽事件類型作為參數(shù)， 讓 I/O 多路復(fù)用程序取消對給定套接字的給定事件的監(jiān)聽， 并取消事件和事件處理器之間的關(guān)聯(lián)。

ae.c/aeGetFileEvents 函數(shù)接受一個套接字描述符， 返回該套接字正在被監(jiān)聽的事件類型：

• 如果套接字沒有任何事件被監(jiān)聽， 那么函數(shù)返回 AE_NONE 。
• 如果套接字的讀事件正在被監(jiān)聽， 那么函數(shù)返回 AE_READABLE 。
• 如果套接字的寫事件正在被監(jiān)聽， 那么函數(shù)返回 AE_WRITABLE 。
• 如果套接字的讀事件和寫事件正在被監(jiān)聽， 那么函數(shù)返回 AE_READABLE | AE_WRITABLE 。

ae.c/aeWait 函數(shù)接受一個套接字描述符、一個事件類型和一個毫秒數(shù)為參數(shù)， 在給定的時間內(nèi)阻塞并等待套接字的給定類型事件產(chǎn)生， 當(dāng)事件成功產(chǎn)生， 或者等待超時之后， 函數(shù)返回。

ae.c/aeApiPoll 函數(shù)接受一個 sys/time.h/struct timeval 結(jié)構(gòu)為參數(shù)， 并在指定的時間內(nèi)， 阻塞并等待所有被 aeCreateFileEvent 函數(shù)設(shè)置為監(jiān)聽狀態(tài)的套接字產(chǎn)生文件事件， 當(dāng)有至少一個事件產(chǎn)生， 或者等待超時后， 函數(shù)返回。

ae.c/aeProcessEvents 函數(shù)是文件事件分派器， 它先調(diào)用 aeApiPoll 函數(shù)來等待事件產(chǎn)生， 然后遍歷所有已產(chǎn)生的事件， 并調(diào)用相應(yīng)的事件處理器來處理這些事件。

ae.c/aeGetApiName 函數(shù)返回 I/O 多路復(fù)用程序底層所使用的 I/O 多路復(fù)用函數(shù)庫的名稱： 返回 "epoll" 表示底層為 epoll 函數(shù)庫， 返回"select" 表示底層為 select 函數(shù)庫， 諸如此類。

文件事件的處理器

Redis 為文件事件編寫了多個處理器， 這些事件處理器分別用于實現(xiàn)不同的網(wǎng)絡(luò)通訊需求， 比如說：

• 為了對連接服務(wù)器的各個客戶端進行應(yīng)答， 服務(wù)器要為監(jiān)聽套接字關(guān)聯(lián)連接應(yīng)答處理器。
• 為了接收客戶端傳來的命令請求， 服務(wù)器要為客戶端套接字關(guān)聯(lián)命令請求處理器。
• 為了向客戶端返回命令的執(zhí)行結(jié)果， 服務(wù)器要為客戶端套接字關(guān)聯(lián)命令回復(fù)處理器。
• 當(dāng)主服務(wù)器和從服務(wù)器進行復(fù)制操作時， 主從服務(wù)器都需要關(guān)聯(lián)特別為復(fù)制功能編寫的復(fù)制處理器。
• 等等。

在這些事件處理器里面， 服務(wù)器最常用的要數(shù)與客戶端進行通信的連接應(yīng)答處理器、 命令請求處理器和命令回復(fù)處理器。

連接應(yīng)答處理器

networking.c/acceptTcpHandler 函數(shù)是 Redis 的連接應(yīng)答處理器， 這個處理器用于對連接服務(wù)器監(jiān)聽套接字的客戶端進行應(yīng)答， 具體實現(xiàn)為sys/socket.h/accept 函數(shù)的包裝。

當(dāng) Redis 服務(wù)器進行初始化的時候， 程序會將這個連接應(yīng)答處理器和服務(wù)器監(jiān)聽套接字的 AE_READABLE 事件關(guān)聯(lián)起來， 當(dāng)有客戶端用sys/socket.h/connect 函數(shù)連接服務(wù)器監(jiān)聽套接字的時候， 套接字就會產(chǎn)生 AE_READABLE 事件， 引發(fā)連接應(yīng)答處理器執(zhí)行， 并執(zhí)行相應(yīng)的套接字應(yīng)答操作， 如圖 IMAGE_SERVER_ACCEPT_CONNECT 所示。

命令請求處理器

networking.c/readQueryFromClient 函數(shù)是 Redis 的命令請求處理器， 這個處理器負(fù)責(zé)從套接字中讀入客戶端發(fā)送的命令請求內(nèi)容， 具體實現(xiàn)為 unistd.h/read 函數(shù)的包裝。

當(dāng)一個客戶端通過連接應(yīng)答處理器成功連接到服務(wù)器之后， 服務(wù)器會將客戶端套接字的 AE_READABLE 事件和命令請求處理器關(guān)聯(lián)起來， 當(dāng)客戶端向服務(wù)器發(fā)送命令請求的時候， 套接字就會產(chǎn)生 AE_READABLE 事件， 引發(fā)命令請求處理器執(zhí)行， 并執(zhí)行相應(yīng)的套接字讀入操作， 如圖 IMAGE_SERVER_RECIVE_COMMAND_REQUEST 所示。

在客戶端連接服務(wù)器的整個過程中， 服務(wù)器都會一直為客戶端套接字的 AE_READABLE 事件關(guān)聯(lián)命令請求處理器。

命令回復(fù)處理器

networking.c/sendReplyToClient 函數(shù)是 Redis 的命令回復(fù)處理器， 這個處理器負(fù)責(zé)將服務(wù)器執(zhí)行命令后得到的命令回復(fù)通過套接字返回給客戶端， 具體實現(xiàn)為 unistd.h/write 函數(shù)的包裝。

當(dāng)服務(wù)器有命令回復(fù)需要傳送給客戶端的時候， 服務(wù)器會將客戶端套接字的 AE_WRITABLE 事件和命令回復(fù)處理器關(guān)聯(lián)起來， 當(dāng)客戶端準(zhǔn)備好接收服務(wù)器傳回的命令回復(fù)時， 就會產(chǎn)生 AE_WRITABLE 事件， 引發(fā)命令回復(fù)處理器執(zhí)行， 并執(zhí)行相應(yīng)的套接字寫入操作， 如圖 IMAGE_SERVER_SEND_REPLY 所示。

當(dāng)命令回復(fù)發(fā)送完畢之后， 服務(wù)器就會解除命令回復(fù)處理器與客戶端套接字的 AE_WRITABLE 事件之間的關(guān)聯(lián)。

一次完整的客戶端與服務(wù)器連接事件示例

讓我們來追蹤一次 Redis 客戶端與服務(wù)器進行連接并發(fā)送命令的整個過程， 看看在過程中會產(chǎn)生什么事件， 而這些事件又是如何被處理的。

假設(shè)一個 Redis 服務(wù)器正在運作， 那么這個服務(wù)器的監(jiān)聽套接字的 AE_READABLE 事件應(yīng)該正處于監(jiān)聽狀態(tài)之下， 而該事件所對應(yīng)的處理器為連接應(yīng)答處理器。

如果這時有一個 Redis 客戶端向服務(wù)器發(fā)起連接， 那么監(jiān)聽套接字將產(chǎn)生 AE_READABLE 事件， 觸發(fā)連接應(yīng)答處理器執(zhí)行： 處理器會對客戶端的連接請求進行應(yīng)答， 然后創(chuàng)建客戶端套接字， 以及客戶端狀態(tài)， 并將客戶端套接字的 AE_READABLE 事件與命令請求處理器進行關(guān)聯(lián)， 使得客戶端可以向主服務(wù)器發(fā)送命令請求。

之后， 假設(shè)客戶端向主服務(wù)器發(fā)送一個命令請求， 那么客戶端套接字將產(chǎn)生 AE_READABLE 事件， 引發(fā)命令請求處理器執(zhí)行， 處理器讀取客戶端的命令內(nèi)容， 然后傳給相關(guān)程序去執(zhí)行。

執(zhí)行命令將產(chǎn)生相應(yīng)的命令回復(fù)， 為了將這些命令回復(fù)傳送回客戶端， 服務(wù)器會將客戶端套接字的 AE_WRITABLE 事件與命令回復(fù)處理器進行關(guān)聯(lián)： 當(dāng)客戶端嘗試讀取命令回復(fù)的時候， 客戶端套接字將產(chǎn)生 AE_WRITABLE 事件， 觸發(fā)命令回復(fù)處理器執(zhí)行， 當(dāng)命令回復(fù)處理器將命令回復(fù)全部寫入到套接字之后， 服務(wù)器就會解除客戶端套接字的 AE_WRITABLE 事件與命令回復(fù)處理器之間的關(guān)聯(lián)。

圖 IMAGE_COMMAND_PROGRESS 總結(jié)了上面描述的整個通訊過程， 以及通訊時用到的事件處理器。