Redis有多快

根據(jù)官方基準(zhǔn)測(cè)試，在具有平均硬件的Linux機(jī)器上運(yùn)行的單個(gè)Redis實(shí)例通?？梢詾楹?jiǎn)單命令 （O(N) 或 O(log(N))） 實(shí)現(xiàn)8w+的QPS，使用流水線批處理可以達(dá)到 100w 。

從性能角度來(lái)看，Redis可以稱為高性能的緩存解決方案。

Redis為什么這么快

面試時(shí)經(jīng)常被問(wèn)到Redis高性能的原因，典型回答是下面這些：

1. C語(yǔ)言實(shí)現(xiàn)，雖然C語(yǔ)言有助于Redis的性能，但語(yǔ)言并不是核心因素。

2. 基于內(nèi)存實(shí)現(xiàn)：僅內(nèi)存I/O，相對(duì)于其他基于磁盤(pán)的數(shù)據(jù)庫(kù)（MySQL等），Redis具有純內(nèi)存操作的自然性能優(yōu)勢(shì)。

3. I/O復(fù)用模型，基于epoll/select/kqueue等I/O多路復(fù)用技術(shù)實(shí)現(xiàn)高吞吐量網(wǎng)絡(luò)I/O。

4. 單線程模型，單線程無(wú)法充分利用多核，但另一方面，它避免了多線程的頻繁上下文切換以及鎖等同步機(jī)制的開(kāi)銷(xiāo)。

為什么Redis選擇單線程？

上面回答了是單線程的，接著會(huì)問(wèn)為啥采用單線程模型。

Redis的CPU通常不會(huì)成為性能瓶頸，因?yàn)橥ǔＧ闆r下Redis要么受到內(nèi)存限制，要么受到網(wǎng)絡(luò)限制。例如，使用流水線技術(shù)，在平均Linux系統(tǒng)上運(yùn)行的Redis甚至可以每秒處理100萬(wàn)個(gè)請(qǐng)求，因此，如果應(yīng)用程序主要使用 O(N) 或 O(log(N)) 命令，它幾乎不會(huì)使用太多CPU。

這基本上意味著CPU通常不是數(shù)據(jù)庫(kù)的瓶頸，因?yàn)榇蠖鄶?shù)請(qǐng)求不會(huì)占用太多CPU資源，而是占用I/O資源。特別是對(duì)于Redis來(lái)說(shuō)，如果不考慮像RDB/AOF這樣的持久性方案，Redis是完全的內(nèi)存操作，非常快速。Redis的真正性能瓶頸是網(wǎng)絡(luò)I/O，即客戶端和服務(wù)器之間的網(wǎng)絡(luò)傳輸延遲，因此Redis選擇了單線程的I/O多路復(fù)用來(lái)實(shí)現(xiàn)其核心網(wǎng)絡(luò)模型。

「實(shí)際上選擇單線程的更具體原因可以總結(jié)如下：」

1. 避免過(guò)多的上下文切換開(kāi)銷(xiāo)：在多線程調(diào)度過(guò)程中，需要在CPU之間切換線程上下文，并且上下文切換涉及一系列寄存器替換、程序堆棧重置，甚至包括程序計(jì)數(shù)器、堆棧指針和程序狀態(tài)字等快速表項(xiàng)的退休。因?yàn)閱蝹€(gè)進(jìn)程內(nèi)的多個(gè)線程共享進(jìn)程地址空間，線程上下文要比進(jìn)程上下文小得多，在跨進(jìn)程調(diào)度的情況下，需要切換整個(gè)進(jìn)程地址空間。

2. 避免同步機(jī)制的開(kāi)銷(xiāo)：如果Redis選擇多線程模型，因?yàn)镽edis是一個(gè)數(shù)據(jù)庫(kù)，不可避免地涉及底層數(shù)據(jù)同步問(wèn)題，這必然會(huì)引入一些同步機(jī)制，如鎖。我們知道Redis不僅提供簡(jiǎn)單的鍵值數(shù)據(jù)結(jié)構(gòu)，還提供列表、集合、哈希等豐富的數(shù)據(jù)結(jié)構(gòu)。不同的數(shù)據(jù)結(jié)構(gòu)對(duì)于同步訪問(wèn)的鎖定具有不同的粒度，這可能會(huì)在數(shù)據(jù)操作期間引入大量的鎖定和解鎖開(kāi)銷(xiāo)，增加了程序的復(fù)雜性并降低了性能。

3. 簡(jiǎn)單和可維護(hù)性：Redis的作者 Salvatore Sanfilippo （化名 antirez ）在Redis的設(shè)計(jì)和代碼中有一種近乎偏執(zhí)的簡(jiǎn)單哲學(xué)，當(dāng)您閱讀Redis源代碼或向Redis提交PR時(shí)，您可以感受到這種偏執(zhí)。因此，簡(jiǎn)單且可維護(hù)的代碼必然是Redis在早期的核心準(zhǔn)則之一，引入多線程不可避免地導(dǎo)致了代碼復(fù)雜性的增加和可維護(hù)性的降低。

Redis真的是單線程的嗎？

在回答這個(gè)問(wèn)題之前，我們需要澄清“單線程”概念的范圍：它是否涵蓋了核心網(wǎng)絡(luò)模型或整個(gè)Redis？如果是前者，答案是肯定的。Redis的網(wǎng)絡(luò)模型在v6.0之前一直是單線程的；如果是后者，答案是不。Redis早在v4.0版本中就引入了多線程。

• Redis v4.0 （引入多線程進(jìn)行異步任務(wù)）

• Redis v6.0 （正式在網(wǎng)絡(luò)模型中實(shí)現(xiàn)I/O多線程）

從Redis v1.0到v6.0，Redis的核心網(wǎng)絡(luò)模型一直是典型的單Reactor模型：使用 epoll/select/kqueue 等多路復(fù)用技術(shù)來(lái)處理事件（客戶端請(qǐng)求）在單線程事件循環(huán)中，最后將響應(yīng)數(shù)據(jù)寫(xiě)回客戶端。

redis-io模型

在這里有幾個(gè)核心概念需要了解。

• 客戶端：客戶端對(duì)象，Redis是典型的CS架構(gòu)（客戶端<-->服務(wù)器），客戶端通過(guò)套接字與服務(wù)器建立網(wǎng)絡(luò)通道，然后發(fā)送請(qǐng)求的命令，服務(wù)器執(zhí)行請(qǐng)求的命令并回復(fù)。Redis使用client結(jié)構(gòu)來(lái)存儲(chǔ)與客戶端相關(guān)的所有信息，包括但不限于包裝套接字連接 -- *conn ，當(dāng)前選擇的數(shù)據(jù)庫(kù)指針 --*db ，讀緩沖區(qū) --querybuf ，寫(xiě)緩沖區(qū) --buf ，寫(xiě)數(shù)據(jù)鏈接列表 --reply 等。

• aeApiPoll ：I/O多路復(fù)用API，基于epoll_wait/select/kevent等系統(tǒng)調(diào)用封裝，監(jiān)聽(tīng)讀寫(xiě)事件以觸發(fā)，然后進(jìn)行處理，這是事件循環(huán)（Event Loop）中的核心函數(shù)，是事件驅(qū)動(dòng)器運(yùn)行的基礎(chǔ)。

• acceptTcpHandler ：連接響應(yīng)處理器，底層使用系統(tǒng)調(diào)用accept接受來(lái)自客戶端的新連接，并將新連接注冊(cè)綁定命令讀取處理器以進(jìn)行后續(xù)的新客戶端TCP連接處理；除了此處理器外，還有相應(yīng)的acceptUnixHandler用于處理Unix域套接字和acceptTLSHandler用于處理TLS加密連接。

• readQueryFromClient ：命令讀取處理器，用于解析并執(zhí)行客戶端請(qǐng)求的命令。

• beforeSleep ：在事件循環(huán)進(jìn)入aeApiPoll并等待事件到達(dá)之前執(zhí)行的函數(shù)。它包含一些常規(guī)任務(wù)，如將來(lái)自client->buf或client->reply的響應(yīng)寫(xiě)回客戶端、將AOF緩沖區(qū)中的數(shù)據(jù)持久化到磁盤(pán)等。還有一個(gè)afterSleep函數(shù)，在aeApiPoll之后執(zhí)行。

• sendReplyToClient ：命令回復(fù)處理器，當(dāng)事件循環(huán)后仍然在寫(xiě)緩沖區(qū)中有數(shù)據(jù)時(shí)，將注冊(cè)并綁定到相應(yīng)連接的 sendReplyToClient 命令，當(dāng)連接觸發(fā)寫(xiě)就緒事件時(shí)，將剩余的寫(xiě)緩沖區(qū)中的數(shù)據(jù)寫(xiě)回客戶端。

Redis內(nèi)部實(shí)現(xiàn)了一個(gè)高性能事件庫(kù)AE，基于 epoll/select/kqueue/evport ，用于為 Linux/MacOS/FreeBSD/Solaris 實(shí)現(xiàn)高性能事件循環(huán)模型。Redis的核心網(wǎng)絡(luò)模型正式構(gòu)建在AE之上，包括I/O多路復(fù)用和各種處理器綁定的注冊(cè)，所有這些都是基于它實(shí)現(xiàn)的。

redis-io多路復(fù)用

到這里，我們可以描述一個(gè)客戶端從Redis請(qǐng)求命令的工作方式。

1. Redis服務(wù)器啟動(dòng)，打開(kāi)主線程事件循環(huán)，將 acceptTcpHandler 連接響應(yīng)處理器注冊(cè)到用戶配置的監(jiān)聽(tīng)端口的文件描述符上，等待新連接的到來(lái)。

2. 客戶端與服務(wù)器之間建立網(wǎng)絡(luò)連接。

3. 調(diào)用 acceptTcpHandler ，主線程使用AE的API將 readQueryFromClient 命令讀取處理器綁定到新連接的文件描述符上，并初始化一個(gè) client 以綁定此客戶端連接。

4. 客戶端發(fā)送請(qǐng)求命令，觸發(fā)讀就緒事件，主線程調(diào)用 readQueryFromClient 將客戶端通過(guò)套接字發(fā)送的命令讀入客戶端-> querybuf 讀緩沖區(qū)。

5. 接下來(lái)調(diào)用 processInputBuffer ，在其中使用 processInlineBuffer 或 processMultibulkBuffer 來(lái)根據(jù)Redis協(xié)議解析命令，最后調(diào)用processCommand來(lái)執(zhí)行命令。

6. 根據(jù)請(qǐng)求命令的類(lèi)型（SET、GET、DEL、EXEC等），分配適當(dāng)?shù)拿顖?zhí)行器來(lái)執(zhí)行，最后調(diào)用 addReply 系列函數(shù)中的一系列函數(shù)將響應(yīng)數(shù)據(jù)寫(xiě)入到相應(yīng)客戶端的寫(xiě)緩沖區(qū)中：client->buf或client->reply，client->buf是首選的寫(xiě)出緩沖區(qū)，具有固定大小的16KB，通?？梢跃彌_足夠的響應(yīng)數(shù)據(jù)，但如果客戶端在時(shí)間窗口內(nèi)需要非常大的響應(yīng)，則它將自動(dòng)切換到client->reply鏈接列表，理論上可以容納無(wú)限數(shù)量的數(shù)據(jù)（受機(jī)器物理內(nèi)存限制）最后，將client添加到LIFO隊(duì)列 clients_pending_write 。

7. 在事件循環(huán)中，主線程執(zhí)行 beforeSleep -> handleClientsWithPendingWrites ，遍歷 clients_pending_write 隊(duì)列，并調(diào)用 writeToClient 將客戶端寫(xiě)緩沖區(qū)中的數(shù)據(jù)返回給客戶端，如果寫(xiě)緩沖區(qū)中仍然有剩余數(shù)據(jù)，則注冊(cè) sendReplyToClient 命令到連接的回復(fù)處理器，等待客戶端寫(xiě)入后繼續(xù)在事件循環(huán)中寫(xiě)回剩余的響應(yīng)數(shù)據(jù)。

對(duì)于那些希望利用多核性能的人來(lái)說(shuō)，官方的Redis解決方案簡(jiǎn)單而直接：在同一臺(tái)機(jī)器上運(yùn)行更多的Redis實(shí)例。事實(shí)上，為了保證高可用性，一個(gè)在線業(yè)務(wù)不太可能以獨(dú)立運(yùn)行的方式存在。更常見(jiàn)的是使用Redis分布式集群，具有多個(gè)節(jié)點(diǎn)和數(shù)據(jù)分片，以提高性能和確保高可用性。

多線程異步任務(wù)

如前所述，Redis在v4.0版本中引入了多線程來(lái)執(zhí)行一些異步操作，主要用于非常耗時(shí)的命令。通過(guò)將這些命令的執(zhí)行設(shè)置為異步，可以避免阻塞單線程事件循環(huán)。

我們知道Redis的DEL命令用于刪除一個(gè)或多個(gè)鍵的存儲(chǔ)值，它是一個(gè)阻塞命令。在大多數(shù)情況下，要?jiǎng)h除的鍵不會(huì)存儲(chǔ)太多值，最多幾十個(gè)或幾百個(gè)對(duì)象，因此可以快速執(zhí)行。但如果要?jiǎng)h除具有數(shù)百萬(wàn)個(gè)對(duì)象的非常大的鍵值對(duì)，則此命令可能會(huì)阻塞至少幾秒鐘，由于事件循環(huán)是單線程的，它會(huì)阻塞隨后的其他事件，從而降低吞吐量。

Redis的作者 antirez 對(duì)解決這個(gè)問(wèn)題進(jìn)行了深思熟慮。起初，他提出了一個(gè)漸進(jìn)式的解決方案：使用定時(shí)器和數(shù)據(jù)游標(biāo)，他將逐步刪除少量數(shù)據(jù)，例如1000個(gè)對(duì)象，最終清除所有數(shù)據(jù)。但這個(gè)解決方案存在一個(gè)致命的缺陷：如果其他客戶端繼續(xù)寫(xiě)入正在逐步刪除的鍵，而且刪除速度跟不上寫(xiě)入的數(shù)據(jù)，那么內(nèi)存將無(wú)休止地被消耗，這個(gè)問(wèn)題通過(guò)一個(gè)巧妙的解決方案得以解決，但這個(gè)實(shí)現(xiàn)使Redis更加復(fù)雜。多線程似乎是一個(gè)牢不可破的解決方案：簡(jiǎn)單且容易理解。因此，最終，antirez選擇引入多線程來(lái)執(zhí)行這類(lèi)非阻塞命令。 antirez 在他的博客中更多地思考了這個(gè)問(wèn)題：懶惰的Redis是更好的Redis。

因此，在Redis v4.0之后，已添加了一些非阻塞命令，如 UNLINK、FLUSHALL ASYNC、FLUSHDB ASYNC 等，它們會(huì)在后臺(tái)線程中執(zhí)行，不會(huì)阻塞主線程事件循環(huán)。這使得Redis可以更好地應(yīng)對(duì)一些特定情況下的命令處理。

多線程異步任務(wù)的主要特點(diǎn)：

1. 后臺(tái)線程：這些異步任務(wù)由一個(gè)或多個(gè)后臺(tái)線程負(fù)責(zé)執(zhí)行，不影響主線程的事件循環(huán)，因此主線程可以繼續(xù)處理其他請(qǐng)求。

2. 非阻塞：異步任務(wù)是非阻塞的，因此它們不會(huì)阻止其他命令的執(zhí)行，即使它們可能需要很長(zhǎng)時(shí)間才能完成。

3. 高可用性：通過(guò)將某些耗時(shí)操作轉(zhuǎn)移到后臺(tái)線程，Redis可以更好地保持高可用性。

總結(jié) Redis的網(wǎng)絡(luò)模型是單線程的，這意味著它使用單個(gè)事件循環(huán)來(lái)處理所有客戶端請(qǐng)求。這個(gè)設(shè)計(jì)的優(yōu)點(diǎn)是簡(jiǎn)單性和可維護(hù)性，但需要謹(jǐn)慎處理一些可能導(dǎo)致事件循環(huán)阻塞的命令。

為了處理一些非常耗時(shí)的命令，Redis v4.0引入了多線程異步任務(wù)。這些異步任務(wù)在后臺(tái)線程中執(zhí)行，不會(huì)阻塞主線程的事件循環(huán)，從而提高了Redis的吞吐量和可用性。

總而言之，Redis的單線程事件循環(huán)和多線程異步任務(wù)的設(shè)計(jì)是為了在性能和簡(jiǎn)單性之間取得平衡，以滿足各種不同用例的需求。理解Redis的這些基本原理對(duì)于使用Redis進(jìn)行高性能數(shù)據(jù)存儲(chǔ)和緩存非常重要。

多線程網(wǎng)絡(luò)模型

正如前面提到的，Redis最初選擇了單線程的網(wǎng)絡(luò)模型，原因是CPU通常不是性能瓶頸，瓶頸往往是內(nèi)存和網(wǎng)絡(luò)，因此單線程足夠了。那么為什么Redis現(xiàn)在引入了多線程呢？簡(jiǎn)單的事實(shí)是Redis的網(wǎng)絡(luò)I/O瓶頸變得越來(lái)越明顯。

隨著互聯(lián)網(wǎng)的快速增長(zhǎng)，互聯(lián)網(wǎng)業(yè)務(wù)系統(tǒng)處理越來(lái)越多的在線流量，而Redis的單線程模式導(dǎo)致系統(tǒng)在網(wǎng)絡(luò)I/O上消耗了大量CPU時(shí)間，從而降低了吞吐量。提高Redis性能有兩種方式：

1. 優(yōu)化網(wǎng)絡(luò)I/O模塊

2. 提高機(jī)器內(nèi)存讀寫(xiě)速度

后者依賴于硬件的發(fā)展，目前尚無(wú)法解決。因此，我們只能從前者入手，網(wǎng)絡(luò)I/O的優(yōu)化可以分為兩個(gè)方向：

1. 零拷貝技術(shù)或DPDK技術(shù)

2. 利用多核

零拷貝技術(shù)存在局限性，無(wú)法完全適應(yīng)像Redis這樣的復(fù)雜網(wǎng)絡(luò)I/O場(chǎng)景。DPDK技術(shù)通過(guò)繞過(guò)內(nèi)核棧來(lái)繞過(guò)NIC I/O，過(guò)于復(fù)雜，需要內(nèi)核甚至硬件的支持。

因此，充分利用多個(gè)核心是優(yōu)化網(wǎng)絡(luò)I/O最具成本效益的方式。

在6.0版本之后，Redis正式將多線程引入核心網(wǎng)絡(luò)模型中，也稱為I/O線程，現(xiàn)在Redis具有真正的多線程模型。在前面的部分中，我們了解了Redis 6.0之前的單線程事件循環(huán)模型，實(shí)際上是一個(gè)非常經(jīng)典的反應(yīng)器模型。

反應(yīng)器模式在Linux平臺(tái)上的大多數(shù)主流高性能網(wǎng)絡(luò)庫(kù)/框架中都有應(yīng)用，比如 netty、libevent、libuv、POE（Perl）、Twisted（Python） 等。

反應(yīng)器模式實(shí)際上是指使用I/O多路復(fù)用（ I/O multiplexing ）+非阻塞I/O（ non-blocking I/O ）模式。

Redis的核心網(wǎng)絡(luò)模型，直到6.0版本，都是單一的反應(yīng)器模型：所有事件都在單一線程中處理，盡管在4.0版本中引入了多線程，但更多是用于特定場(chǎng)景的補(bǔ)?。▌h除超大鍵值等），不能被視為核心網(wǎng)絡(luò)模型的多線程。

一般來(lái)說(shuō)，單一反應(yīng)器模型，在引入多線程后，會(huì)演變?yōu)槎喾磻?yīng)器模型，具有以下基本工作模型。

與單一線程事件循環(huán)不同，這種模式有多個(gè)線程（子反應(yīng)器），每個(gè)線程維護(hù)一個(gè)獨(dú)立的事件循環(huán)，主反應(yīng)器接收新連接并將其分發(fā)給子反應(yīng)器進(jìn)行獨(dú)立處理，而子反應(yīng)器則將響應(yīng)寫(xiě)回客戶端。

多反應(yīng)器模式通常可以等同于 Master-Workers 模式，比如 Nginx 和 Memcached 使用這種多線程模型，盡管項(xiàng)目之間的實(shí)現(xiàn)細(xì)節(jié)略有不同，但總體模式基本一致。

Redis多線程網(wǎng)絡(luò)模型設(shè)計(jì)

Redis也實(shí)現(xiàn)了多線程，但不是標(biāo)準(zhǔn)的多反應(yīng)器/主工作模式。讓我們先看一下Redis多線程網(wǎng)絡(luò)模型的一般設(shè)計(jì)。

1. Redis服務(wù)器啟動(dòng)，打開(kāi)主線程事件循環(huán)，將 acceptTcpHandler 連接答復(fù)處理器注冊(cè)到與用戶配置的監(jiān)聽(tīng)端口對(duì)應(yīng)的文件描述符，并等待新連接的到來(lái)。

2. 客戶端與服務(wù)器之間建立網(wǎng)絡(luò)連接。

3. 調(diào)用 acceptTcpHandler ，主線程使用AE的API將 readQueryFromClient 命令讀取處理器綁定到與新連接對(duì)應(yīng)的文件描述符上，并初始化一個(gè)客戶端以綁定這個(gè)客戶端連接。

4. 客戶端發(fā)送一個(gè)請(qǐng)求命令，觸發(fā)一個(gè)讀就緒事件。但不是通過(guò)套接字讀取客戶端的請(qǐng)求命令，而是服務(wù)器的主線程首先將客戶端放入LIFO隊(duì)列 clients_pending_read 中。

5. 在事件循環(huán)中，主線程執(zhí)行beforeSleep –> handleClientsWithPendingReadsUsingThreads ，使用輪詢的負(fù)載均衡策略將clients_pending_read隊(duì)列中的連接均勻地分配給I/O線程。I/O線程通過(guò)套接字讀取客戶端的請(qǐng)求命令，將其存儲(chǔ)在client->querybuf中并解析第一個(gè)命令，但不執(zhí)行它，同時(shí)主線程忙于輪詢并等待所有I/O線程完成讀取任務(wù)。

6. 當(dāng)主線程和所有I/O線程都完成讀取時(shí)，主線程結(jié)束忙碌的輪詢，遍歷 clients_pending_read 隊(duì)列，執(zhí)行所有已連接客戶端的請(qǐng)求命令，首先調(diào)用processCommandResetClient來(lái)執(zhí)行已解析的第一個(gè)命令，然后調(diào)用 processInputBuffer 來(lái)解析和執(zhí)行客戶端連接的所有命令，使用 processInlineBuffer 或 processMultibulkBuffer 根據(jù)Redis協(xié)議解析命令，最后調(diào)用 processCommand 來(lái)執(zhí)行命令。

7. 根據(jù)所請(qǐng)求命令的類(lèi)型（ SET、GET、DEL、EXEC 等），分配相應(yīng)的命令執(zhí)行器來(lái)執(zhí)行它，最后調(diào)用addReply系列函數(shù)中的一系列函數(shù)將響應(yīng)數(shù)據(jù)寫(xiě)入相應(yīng)的客戶端寫(xiě)出緩沖區(qū)： client->buf 或 client->reply ， client->buf 是首選的寫(xiě)出緩沖區(qū)，大小固定為16KB，通常足夠緩沖足夠的響應(yīng)數(shù)據(jù)，但如果客戶端需要在時(shí)間窗口內(nèi)響應(yīng)大量數(shù)據(jù)，則會(huì)自動(dòng)切換到client->reply鏈表，理論上可以容納無(wú)限量的數(shù)據(jù)（受到機(jī)器物理內(nèi)存的限制），最后將客戶端添加到LIFO隊(duì)列 clients_pending_write 中。

8. 在事件循環(huán)中，主線程執(zhí)行 beforeSleep –> handleClientsWithPendingWritesUsingThreads ，使用輪詢的負(fù)載均衡策略將 clients_pending_write 隊(duì)列中的連接均勻地分配給I/O線程和主線程本身。I/O線程通過(guò)調(diào)用 writeToClient 將客戶端寫(xiě)緩沖區(qū)中的數(shù)據(jù)寫(xiě)回客戶端，而主線程則忙于輪詢，等待所有I/O線程完成寫(xiě)入任務(wù)。

9. 當(dāng)主線程和所有I/O線程都完成寫(xiě)入時(shí)，主線程結(jié)束忙碌的輪詢，遍歷 clients_pending_write 隊(duì)列。如果客戶端寫(xiě)緩沖區(qū)中還有數(shù)據(jù)，它將注冊(cè) sendReplyToClient 以等待連接的寫(xiě)準(zhǔn)備就緒事件，并等待客戶端寫(xiě)入，然后繼續(xù)在事件循環(huán)中寫(xiě)回剩余的響應(yīng)數(shù)據(jù)。

大部分邏輯與之前的單線程模型相同，唯一的改變是將讀取客戶端請(qǐng)求和寫(xiě)回響應(yīng)數(shù)據(jù)的邏輯異步化到I/O線程中。這里需要特別注意的是，I/O線程只負(fù)責(zé)讀取和解析客戶端命令，實(shí)際的命令執(zhí)行最終是在主線程上完成的。

總結(jié)

當(dāng)面試官再問(wèn)Redis為啥這么快時(shí)別傻傻再回答Redis是單線程了，否則只能回去等通知了。

Redis的多線程網(wǎng)絡(luò)模型通過(guò)將讀取和寫(xiě)回?cái)?shù)據(jù)的任務(wù)異步化，以及更好地利用多核CPU，從而提高了Redis在處理大量在線流量時(shí)的性能表現(xiàn)。

1.「多線程設(shè)計(jì)」：

• Redis多線程模型包括一個(gè)主線程（Main Reactor）和多個(gè)I/O線程（Sub Reactors）。

• 主線程負(fù)責(zé)接受新的連接，并將其分發(fā)到I/O線程進(jìn)行獨(dú)立處理。

• I/O線程負(fù)責(zé)讀取客戶端的請(qǐng)求命令，但不執(zhí)行它們。

• 主線程負(fù)責(zé)執(zhí)行客戶端的請(qǐng)求命令，包括解析和執(zhí)行。

• 響應(yīng)數(shù)據(jù)由I/O線程寫(xiě)回客戶端。

2.「異步讀寫(xiě)」：Redis的多線程模型異步化了讀取客戶端請(qǐng)求和寫(xiě)回響應(yīng)數(shù)據(jù)的過(guò)程?？蛻舳苏?qǐng)求首先被放入待讀取隊(duì)列，然后由I/O線程讀取。執(zhí)行命令仍然在主線程上進(jìn)行，但這種異步化提高了系統(tǒng)的并發(fā)性和吞吐量。