這篇文章主要介紹“Redis的線程模型詳細介紹”,在日常操作中,相信很多人在Redis的線程模型詳細介紹問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”Redis的線程模型詳細介紹”的疑惑有所幫助!接下來,請跟著小編一起來學習吧!
1、文件事件處理器
Redis基于Reactor模式開發了網絡事件處理器,這個處理器被稱為文件事件處理器。它的組成結構為4部分:多個套接字、IO多路復用程序、文件事件分派器、事件處理器。因為文件事件分派器隊列的消費是單線程的,所以Redis才叫單線程模型。
2、消息處理流程
文件事件處理器使用I/O多路復用(multiplexing)程序來同時監聽多個套接字,并根據套接字目前執行的任務來為套接字關聯不同的事件處理器。
當被監聽的套接字準備好執行連接應答(accept)、讀取(read)、寫入(write)、關閉(close)等操作時,與操作相對應的文件事件就會產生,這時文件事件處理器就會調用套接字之前關聯好的事件處理器來處理這些事件。
盡管多個文件事件可能會并發地出現,但I/O多路復用程序總是會將所有產生事件的套接字都推到一個隊列里面,然后通過這個隊列,以有序(sequentially)、同步(synchronously)、每次一個套接字的方式向文件事件分派器傳送套接字:當上一個套接字產生的事件被處理完畢之后(該套接字為事件所關聯的事件處理器執行完畢), I/O多路復用程序才會繼續向文件事件分派器傳送下一個套接字。
3、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多路復用程序的底層實現是可以互換的。
4、文件事件的類型
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 事件。這也就是說,如果一個套接字又可讀又可寫的話,那么服務器將先讀套接字,后寫套接字。
5、文件事件的處理器
Redis為文件事件編寫了多個處理器,這些事件處理器分別用于實現不同的網絡通訊需求,常用的處理器如下:
為了對連接服務器的各個客戶端進行應答, 服務器要為監聽套接字關聯連接應答處理器。
為了接收客戶端傳來的命令請求, 服務器要為客戶端套接字關聯命令請求處理器。
為了向客戶端返回命令的執行結果, 服務器要為客戶端套接字關聯命令回復處理器。
6、連接應答處理器
networking.c中acceptTcpHandler函數是Redis的連接應答處理器,這個處理器用于對連接服務器監聽套接字的客戶端進行應答,具體實現為sys/socket.h/accept函數的包裝。
當Redis服務器進行初始化的時候,程序會將這個連接應答處理器和服務器監聽套接字的AE_READABLE事件關聯起來,當有客戶端用sys/socket.h/connect函數連接服務器監聽套接字的時候, 套接字就會產生AE_READABLE 事件, 引發連接應答處理器執行, 并執行相應的套接字應答操作。
7、命令請求處理器
networking.c中readQueryFromClient函數是Redis的命令請求處理器,這個處理器負責從套接字中讀入客戶端發送的命令請求內容, 具體實現為unistd.h/read函數的包裝。
當一個客戶端通過連接應答處理器成功連接到服務器之后, 服務器會將客戶端套接字的AE_READABLE事件和命令請求處理器關聯起來,當客戶端向服務器發送命令請求的時候,套接字就會產生 AE_READABLE事件,引發命令請求處理器執行,并執行相應的套接字讀入操作。
在客戶端連接服務器的整個過程中,服務器都會一直為客戶端套接字的AE_READABLE事件關聯命令請求處理器。
8、命令回復處理器
networking.c中sendReplyToClient函數是Redis的命令回復處理器,這個處理器負責將服務器執行命令后得到的命令回復通過套接字返回給客戶端,具體實現為unistd.h/write函數的包裝。
當服務器有命令回復需要傳送給客戶端的時候,服務器會將客戶端套接字的AE_WRITABLE事件和命令回復處理器關聯起來,當客戶端準備好接收服務器傳回的命令回復時,就會產生AE_WRITABLE事件,引發命令回復處理器執行,并執行相應的套接字寫入操作。
當命令回復發送完畢之后, 服務器就會解除命令回復處理器與客戶端套接字的 AE_WRITABLE 事件之間的關聯。
9、一次完整的客戶端與服務器連接事件示例
假設Redis服務器正在運作,那么這個服務器的監聽套接字的AE_READABLE事件應該正處于監聽狀態之下,而該事件所對應的處理器為連接應答處理器。
如果這時有一個Redis客戶端向Redis服務器發起連接,那么監聽套接字將產生AE_READABLE事件, 觸發連接應答處理器執行:處理器會對客戶端的連接請求進行應答, 然后創建客戶端套接字,以及客戶端狀態,并將客戶端套接字的 AE_READABLE 事件與命令請求處理器進行關聯,使得客戶端可以向主服務器發送命令請求。
之后,客戶端向Redis服務器發送一個命令請求,那么客戶端套接字將產生 AE_READABLE事件,引發命令請求處理器執行,處理器讀取客戶端的命令內容, 然后傳給相關程序去執行。
執行命令將產生相應的命令回復,為了將這些命令回復傳送回客戶端,服務器會將客戶端套接字的AE_WRITABLE事件與命令回復處理器進行關聯:當客戶端嘗試讀取命令回復的時候,客戶端套接字將產生AE_WRITABLE事件, 觸發命令回復處理器執行, 當命令回復處理器將命令回復全部寫入到套接字之后, 服務器就會解除客戶端套接字的AE_WRITABLE事件與命令回復處理器之間的關聯。
到此,關于“Redis的線程模型詳細介紹”的學習就結束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續學習更多相關知識,請繼續關注億速云網站,小編會繼續努力為大家帶來更多實用的文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。