共計 4124 個字符，預計需要花費 11 分鐘才能閱讀完成。

這篇文章主要講解了“Redis 線程模型是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學習“Redis 線程模型是什么”吧！

Redis 它是一個單線程的，這一點需要去注意的。

首先我們呢會有一個客戶端，這個客戶端在我們之前其實使用的是一個 redis client 這樣的一個工具去連接的 redis server。
如果說我們后續再整合到 java 里面去的話，在 java 里面其實也會提供相應的客戶端的。

隨后我們會有一個 redis server，這個其實就是我們的一個 redis，它整個服務在啟動以后，它是會有一個進程的。
在我們的 release 里面，在內部它其實會有兩個東西。

首先一個它會有一個多路復用器，這個我們上節課已經是介紹過了，它是非阻塞的一個模型。
隨后它其實還會有一個文件事件分配器，它專門是用于去分配一些事件的。

在這個下面，它會分為三個不同的處理器，分別來看一下。

首先呢有一個連接應答處理器，最后的是一個命令請求處理器，還有是一個命令回復處理器。

如何去理解呢？首先我們先來看一個連接應答處理器。

連接應答處理器的話，它的一個主要作用是要和我們的客戶端去保持一個鏈接。
像我們的一個 redis server 一旦啟動了以后，其實呢我們就會有 read 的這樣的一個事件和我們的連接應答器會捆綁到一起。
它的全稱其實叫做 AE_readable。你就可以把它理解為是一種標志啊，它會有這樣的一個事件, 這個事件是會和我們的連接應答處理器捆綁到一起的。

最后當我們的一個客戶端和咱們的 server 要去建立連接的時候，這個其實也就是我們在一開始在命令行工具里面敲下了一個 redis client，一開始的話肯定是需要和我們的 server 去建立連接嘛。建立連接的時候，他其實就會發送一個 read 標志，其實就是一個 read 的時間，這個時候的話，在我們的 redis server 里面，它其實會有一個叫做 server socket。

server socket 和我們的一個客戶端 socket 其實是對應的，他們是屬于網絡編程里面的一塊內容，他們之間是一個 socket 的通信。在我們接觸到 read 這樣的一個事件了以后，隨后我們呢就會交由咱們的多路復用器去進行處理吧。
交給他去處理以后的話，其實他是一個非阻塞的，拿到了以后一旦接收，他就會把它放到我們這樣的一個箭頭里面去。

這個箭頭的話在這邊其實我們可以稱之為它是一個管道 pipeline，或者我們也可以把它稱之為是一個隊列。它會往這里面丟，丟進去以后，這個世界呢其實就會到達我們的文件事件分配器。這個分配器當它識別到它是一個 read 這樣的事件以后，它就會和我們的這個連接應答處理器去做到一個匹配，也就是交由它去進行一個處理。
它是一個 read 相互進行一個匹配。
這個時候的話其實就可以表明咱們的 client 和 server 這兩端就是建立了一個連接。建立好連接了以后這個 read 標識的話，這個事件它其實就會交由給我們的命令請求處理器。這個命令請求處理器的話，你就可以認為它是專門去處理請求的，也就是一個 request。然后命令回復處理器，你可以把它理解為是一個 response，也就是一個響應。

隨后我們在客戶端可能要去，比方說我們要去 set 一個值，對吧？set 一個值的話，比方說 set name *** 這樣子的話，其實它是一個命令嘛。
這個命令的話它的一個世界類型其實也是一個 read。隨后呢經過 server socket 再丟給多路復用器，拿到以后放到咱們的隊列里面去再交由文件事件分配器。

這個文件事件分配器拿到以后，它會進行一個判斷吧，它會判斷匹配是 read 的事件。它這個時候是一個 read 的事件的時候，就會讓我們的命令請求處理器去處理咱們的命令。他就會去識別了呀，他會去識別當前就是一個 set name ***，所以他就要去做一個處理。他要把我們用戶所設置的一個內容，把這個鍵值做一個存儲，存儲到咱們的內存里面去。這個其實就是一個命令請求的處理，就是一個 request。

當它處理完畢以后，隨后的話它會分配一個 white，也就是寫的一個標識。這個寫的標識的話，在這邊的話，其實呢我們就可以把它作為響應。因為我們的一個請求其實在處理完畢之后，在我們輸入完畢一個命令以后，可能會看到一個 ok 對吧？這個 ok 的話其實就相當于是我們的一個命令回復處理器回寫給我們的一個內容。所以他會用到一個 write 寫的一個標記。這樣子我們的一個寫的標記其實是會和我們命令回復處理器是捆在一起的。write 的話，其實它的全稱是叫做 AE_writable 這樣的一個事件類型的。

好，隨后在我們的客戶端這個地方，其實我們就需要去做一個回寫也。就是 ok 或者說我們在查詢 list，我們要展示 list 里面所有的內容的時候，它其實是回寫的一個情況。我們要把內容顯示在控制臺的下方，它是一個 write 這樣的一個事件類型。隨后交由我們的多路復用器再丟給咱們的一個隊列，讓這個隊列分配給我們的一個文件事件分配器的。這個時候會匹配咱們的 web 事件。web 事件是匹配到了。

隨后的話，我們的命令回復處理器就會做一個回寫。它會把我們的 ok 啊或者說是我們的一個獲得的一個 list 數量，list 里面的內容等等。只要是一些需要展示的內容，他都會是作為一個 response，就是把這個響應的內容回寫給我們的一個客戶端，在客戶端上進行一個展示。在我們當前這整個模型里面的話，其實主要就是兩個不同的事件，一個叫做 readable 的，一個叫做 writable。

當然我們現在設置的僅僅只是一個客戶端，如果說我們會有多個客戶端的話，他們的道理也都是一模一樣的。這個其實就是 release 的一個線程模型。初次接觸的話是可能會比較的難以去理解，但是沒有關系的。這張圖的話其實也是可以輔助大家去加深這個意向。

然后他整個處理的流程，也是可以跟著我所說的進行理解。為了便于大家的一個理解，我們在這里畫一個圖啊，來做一個舉例。

假設我們現在呢有一個 KTV，這個 KTV 就是 redis。

然后呢我們有很多的顧客要去唱歌，要去唱歌的話，我們 KTV 里面肯定會有員工嘛，員工的話我們會分為兩大類。
第一個大類是門口的接待員，第二個是大堂經理。
門口的接待員其實他就是一個多路復用器, 大堂經理的話其實就是一個文件分配器。

然后呢，我們的顧客肯定是有一些相應的請求吧，或者說是相應的需求，這個時候肯定是要詢問我們的門口的接待員，讓門口的接待員去做簡單的一些處理。
可能他要去看一下這個用戶想要去參加什么樣的活動，有沒有優惠券等等。

然后門口的接單員，如果說確定這個顧客要去唱歌的話，就可以說請往后面走，后面有一個通道。這個通道的話其實就是一個隊列，你們排著隊往這個通道走。走到里面的話，就是我們整個 KTV 的一個營業廳了。到營業廳里面它會有一個大堂經理，大堂經理的話會去處理我們的一個顧客真實的請求。

隨后在我們的一個 KTV 里面，其實我們的肯定會有一個包廂，每一個包廂的話是會去處理用戶，去處理顧客不同的請求的了。在我們的這個包廂的內部呢，會有三個小姐姐或者小哥哥，他們呢是會為用戶去處理不同的一些需求的。

比方說第一個的話，他就專門是為顧客去開門的。開門這個動作就相當于是我們的一個客戶端和 release 去建立了一個鏈接。門打開以后，你就可以進來了，對吧？進來以后的話，這個小姐姐就不負責他相應的一些工作了，他就會把他交給我們的下面的一個人，下面的一個小姐姐或者小哥哥，就是專門為用戶去處理一些請求的。

比方說某一個顧客要點歌的，這個時候就會讓點歌的人做一些相應的處理。這個處理的話就是打開電腦去點歌選歌。選完歌了以后，你得要響應給顧客吧。你有沒有點好，對吧？你還要把一些話筒麥克風遞給顧客，所以這個時候會有一個通知，有這樣的一個小姐姐，這個小姐姐會把這個麥克風給到顧客。你現在可以去唱歌了，我們這個歌已經是為你點好了，你去唱吧。

這個時候其實就完成了一個顧客在 KTV 里面點歌唱歌這一整個動作。這個其實也就是對應在我們之前，我們在 release 這個線程模型里面所提及的某一個客戶端執行的一個操作吧。首先是建立連接，然后呢去處理請求，隨后呢去響應他的一個請求。這個總共這里是有三步操作。

在我們這一塊里面的話，整個大堂經理以及是他們點歌通知這一系列的操作的話，其實都是在我們的內部去做處理的。也就是基于我們的一個包廂。包廂的話，在我們的 redis 里面，咱們是不是可以把它作為是一個內存啊，因為 redis 一個存儲讀取等等的操作，其實都是基于內存的。所以在內存里面的話它是非常的快的。

在我們的包廂里面的話，包廂里面你不管是去唱歌還是點一些水果啊，喝一些啤酒啊等等。其實都是基于我們內部的一個包廂去做操作的話，它的一系列的動作等等的話，完成度其實也是非常的快的。

這個其實就可以為了我們的一個線程模型去做了樸素的理解。對于我們的 redis 來講的話，它其實是一個單線程模式。為什么使用單線程模型會非常的快呢？

其實主要是有兩點。
第一點的話是我們的一個門口的接待員，其實也就是一個多路復用器。這個多路復用器的話，它是基于一個非阻塞的模型，所以呢它處理起來是非常的快的。它不會因為以前的一種阻塞模式，而一個一個的去等待去響應。現在使用了一個 IO 多路復用器這樣的模型以后，其實它的一個處理效能是非常非常的快的。

另外一部分就是我們的大堂經理這一塊，這一塊其實它是基于內存去做操作的。純內存的操作的話，其實它是會非常非常的快的。

當然使用了單線程以后，其實它的一個作用也說了，使用單線程的話，它是可以避免在多線程的時候。因為你多線程的話，你有可能會使用到它的一個上下文的一個切換。一旦切換的話，有可能會引起一些問題。另外呢也是可以避免一些相應的損耗的。所以當我們在使用干線模型的時候，它的一個并發性，它的效率是非常非常的高的。

感謝各位的閱讀，以上就是“Redis 線程模型是什么”的內容了，經過本文的學習后，相信大家對 Redis 線程模型是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關知識點的文章，歡迎關注！