Redis的線程模型詳細介紹

這篇文章主要介紹“Redis的線程模型詳細介紹”，在日常操作中，相信很多人在Redis的線程模型詳細介紹問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Redis的線程模型詳細介紹”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

1、文件事件處理器

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

2、消息處理流程

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

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

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

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

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

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

4、文件事件的類型

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

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

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

5、文件事件的處理器

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

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

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

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

6、連接應答處理器

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

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

7、命令請求處理器

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

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

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

8、命令回復處理器

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

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

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

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

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

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

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

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

到此，關于“Redis的線程模型詳細介紹”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>