為什么說redis是單線程的

這篇文章主要介紹為什么說redis是單線程的，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

Redis即遠程字典服務，是一個開源的使用ANSI C語言編寫、支持網絡、可基于內存亦可持久化的日志型、Key-Value數據庫，并提供多種語言的API。

文件事件處理器

Redis基于Reactor模式開發了網絡事件處理器，這個處理器被稱為文件事件處理器。它的組成結構為4部分：多個套接字、IO多路復用程序、文件事件分派器、事件處理器。因為文件事件分派器隊列的消費是單線程的，所以Redis才叫單線程模型。

消息處理流程

文件事件處理器使用I/O多路復用(multiplexing)程序來同時監聽多個套接字，并根據套接字目前執行的任務來為套接字關聯不同的事件處理器。

當被監聽的套接字準備好執行連接應答(accept)、讀取(read)、寫入(write)、關閉(close)等操作時，與操作相對應的文件事件就會產生，這時文件事件處理器就會調用套接字之前關聯好的事件處理器來處理這些事件。

盡管多個文件事件可能會并發地出現，但I/O多路復用程序總是會將所有產生事件的套接字都推到一個隊列里面，然后通過這個隊列，以有序（sequentially）、同步（synchronously）、每次一個套接字的方式向文件事件分派器傳送套接字：當上一個套接字產生的事件被處理完畢之后（該套接字為事件所關聯的事件處理器執行完畢）， I/O多路復用程序才會繼續向文件事件分派器傳送下一個套接字。

I/O 多路復用程序的實現

Redis的I/O多路復用程序的所有功能是通過包裝select、epoll、evport和kqueue這些I/O多路復用函數庫來實現的，每個I/O多路復用函數庫在Redis源碼中都對應一個單獨的文件，比如ae_select.c、ae_epoll.c、ae_kqueue.c等。

因為Redis為每個I/O多路復用函數庫都實現了相同的API，所以I/O多路復用程序的底層實現是可以互換的，如下圖所示。

有關epoll的詳細講解，可以點擊查看，徹底搞懂epoll高效運行的原理

Redis在I/O多路復用程序的實現源碼中用#include宏定義了相應的規則，程序會在編譯時自動選擇系統中性能最好的I/O多路復用函數庫來作為Redis的I/O多路復用程序的底層實現：

/* 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 多路復用程序可以監聽多個套接字的ae.h/AE_READABLE事件和ae.h/AE_WRITABLE事件，這兩類事件和套接字操作之間的對應關系如下：

當套接字變得可讀時（客戶端對套接字執行write操作，或者執行close操作），或者有新的可應答（acceptable）套接字出現時（客戶端對服務器的監聽套接字執行connect操作），套接字產生AE_READABLE 事件。

當套接字變得可寫時（客戶端對套接字執行read操作），套接字產生AE_WRITABLE事件。I/O多路復用程序允許服務器同時監聽套接字的AE_READABLE事件和AE_WRITABLE事件，如果一個套接字同時產生了這兩種事件，那么文件事件分派器會優先處理AE_READABLE事件，等到AE_READABLE事件處理完之后，才處理AE_WRITABLE 事件。這也就是說，如果一個套接字又可讀又可寫的話，那么服務器將先讀套接字，后寫套接字。

文件事件的處理器

Redis為文件事件編寫了多個處理器，這些事件處理器分別用于實現不同的網絡通訊需求，常用的處理器如下：

為了對連接服務器的各個客戶端進行應答， 服務器要為監聽套接字關聯連接應答處理器。

為了接收客戶端傳來的命令請求， 服務器要為客戶端套接字關聯命令請求處理器。

為了向客戶端返回命令的執行結果， 服務器要為客戶端套接字關聯命令回復處理器。

連接應答處理器

networking.c中acceptTcpHandler函數是Redis的連接應答處理器，這個處理器用于對連接服務器監聽套接字的客戶端進行應答，具體實現為sys/socket.h/accept函數的包裝。

當Redis服務器進行初始化的時候，程序會將這個連接應答處理器和服務器監聽套接字的AE_READABLE事件關聯起來，當有客戶端用sys/socket.h/connect函數連接服務器監聽套接字的時候， 套接字就會產生AE_READABLE 事件， 引發連接應答處理器執行， 并執行相應的套接字應答操作，如圖所示。

命令請求處理器

networking.c中readQueryFromClient函數是Redis的命令請求處理器，這個處理器負責從套接字中讀入客戶端發送的命令請求內容， 具體實現為unistd.h/read函數的包裝。

當一個客戶端通過連接應答處理器成功連接到服務器之后， 服務器會將客戶端套接字的AE_READABLE事件和命令請求處理器關聯起來，當客戶端向服務器發送命令請求的時候，套接字就會產生 AE_READABLE事件，引發命令請求處理器執行，并執行相應的套接字讀入操作，如圖所示。

在客戶端連接服務器的整個過程中，服務器都會一直為客戶端套接字的AE_READABLE事件關聯命令請求處理器。

命令回復處理器

networking.c中sendReplyToClient函數是Redis的命令回復處理器，這個處理器負責將服務器執行命令后得到的命令回復通過套接字返回給客戶端，具體實現為unistd.h/write函數的包裝。

當服務器有命令回復需要傳送給客戶端的時候，服務器會將客戶端套接字的AE_WRITABLE事件和命令回復處理器關聯起來，當客戶端準備好接收服務器傳回的命令回復時，就會產生AE_WRITABLE事件，引發命令回復處理器執行，并執行相應的套接字寫入操作， 如圖所示。

當命令回復發送完畢之后， 服務器就會解除命令回復處理器與客戶端套接字的 AE_WRITABLE 事件之間的關聯。

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

假設Redis服務器正在運作，那么這個服務器的監聽套接字的AE_READABLE事件應該正處于監聽狀態之下，而該事件所對應的處理器為連接應答處理器。

如果這時有一個Redis客戶端向Redis服務器發起連接，那么監聽套接字將產生AE_READABLE事件， 觸發連接應答處理器執行：處理器會對客戶端的連接請求進行應答， 然后創建客戶端套接字，以及客戶端狀態，并將客戶端套接字的 AE_READABLE 事件與命令請求處理器進行關聯，使得客戶端可以向主服務器發送命令請求。

之后，客戶端向Redis服務器發送一個命令請求，那么客戶端套接字將產生 AE_READABLE事件，引發命令請求處理器執行，處理器讀取客戶端的命令內容， 然后傳給相關程序去執行。

執行命令將產生相應的命令回復，為了將這些命令回復傳送回客戶端，服務器會將客戶端套接字的AE_WRITABLE事件與命令回復處理器進行關聯：當客戶端嘗試讀取命令回復的時候，客戶端套接字將產生AE_WRITABLE事件， 觸發命令回復處理器執行， 當命令回復處理器將命令回復全部寫入到套接字之后， 服務器就會解除客戶端套接字的AE_WRITABLE事件與命令回復處理器之間的關聯。

以上是“為什么說redis是單線程的”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！