Redis有多快

根據(jù)官方基準(zhǔn)測試，在具有平均硬件的Linux機器上運行的單個Redis實例通常可以為簡單命令（O(N)或O(log(N))）實現(xiàn)8w+的QPS，使用流水線批處理可以達到100w。

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

Redis為什么這么快

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

1. C語言實現(xiàn)，雖然C語言有助于Redis的性能，但語言并不是核心因素。
2. 基于內(nèi)存實現(xiàn)：僅內(nèi)存I/O，相對于其他基于磁盤的數(shù)據(jù)庫（MySQL等），Redis具有純內(nèi)存操作的自然性能優(yōu)勢。
3. I/O復(fù)用模型，基于epoll/select/kqueue等I/O多路復(fù)用技術(shù)實現(xiàn)高吞吐量網(wǎng)絡(luò)I/O。
4. 單線程模型，單線程無法充分利用多核，但另一方面，它避免了多線程的頻繁上下文切換以及鎖等同步機制的開銷。

為什么Redis選擇單線程？

上面回答了是單線程的，接著會問為啥采用單線程模型。

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

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

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

1. 避免過多的上下文切換開銷：在多線程調(diào)度過程中，需要在CPU之間切換線程上下文，并且上下文切換涉及一系列寄存器替換、程序堆棧重置，甚至包括程序計數(shù)器、堆棧指針和程序狀態(tài)字等快速表項的退休。因為單個進程內(nèi)的多個線程共享進程地址空間，線程上下文要比進程上下文小得多，在跨進程調(diào)度的情況下，需要切換整個進程地址空間。
2. 避免同步機制的開銷：如果Redis選擇多線程模型，因為Redis是一個數(shù)據(jù)庫，不可避免地涉及底層數(shù)據(jù)同步問題，這必然會引入一些同步機制，如鎖。我們知道Redis不僅提供簡單的鍵值數(shù)據(jù)結(jié)構(gòu)，還提供列表、集合、哈希等豐富的數(shù)據(jù)結(jié)構(gòu)。不同的數(shù)據(jù)結(jié)構(gòu)對于同步訪問的鎖定具有不同的粒度，這可能會在數(shù)據(jù)操作期間引入大量的鎖定和解鎖開銷，增加了程序的復(fù)雜性并降低了性能。
3. 簡單和可維護性：Redis的作者Salvatore Sanfilippo（化名antirez）在Redis的設(shè)計和代碼中有一種近乎偏執(zhí)的簡單哲學(xué)，當(dāng)您閱讀Redis源代碼或向Redis提交PR時，您可以感受到這種偏執(zhí)。因此，簡單且可維護的代碼必然是Redis在早期的核心準(zhǔn)則之一，引入多線程不可避免地導(dǎo)致了代碼復(fù)雜性的增加和可維護性的降低。

Redis真的是單線程的嗎？

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

• Redis v4.0（引入多線程進行異步任務(wù)）
• Redis v6.0（正式在網(wǎng)絡(luò)模型中實現(xiàn)I/O多線程）

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

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

redis-io模型

在這里有幾個核心概念需要了解。

• 客戶端：客戶端對象，Redis是典型的CS架構(gòu)（客戶端<-->服務(wù)器），客戶端通過套接字與服務(wù)器建立網(wǎng)絡(luò)通道，然后發(fā)送請求的命令，服務(wù)器執(zhí)行請求的命令并回復(fù)。Redis使用client結(jié)構(gòu)來存儲與客戶端相關(guān)的所有信息，包括但不限于包裝套接字連接 -- *conn，當(dāng)前選擇的數(shù)據(jù)庫指針--*db，讀緩沖區(qū)--querybuf，寫緩沖區(qū)--buf，寫數(shù)據(jù)鏈接列表--reply等。
• aeApiPoll：I/O多路復(fù)用API，基于epoll_wait/select/kevent等系統(tǒng)調(diào)用封裝，監(jiān)聽讀寫事件以觸發(fā)，然后進行處理，這是事件循環(huán)（Event Loop）中的核心函數(shù)，是事件驅(qū)動器運行的基礎(chǔ)。
• acceptTcpHandler：連接響應(yīng)處理器，底層使用系統(tǒng)調(diào)用accept接受來自客戶端的新連接，并將新連接注冊綁定命令讀取處理器以進行后續(xù)的新客戶端TCP連接處理；除了此處理器外，還有相應(yīng)的acceptUnixHandler用于處理Unix域套接字和acceptTLSHandler用于處理TLS加密連接。
• readQueryFromClient：命令讀取處理器，用于解析并執(zhí)行客戶端請求的命令。
• beforeSleep：在事件循環(huán)進入aeApiPoll并等待事件到達之前執(zhí)行的函數(shù)。它包含一些常規(guī)任務(wù)，如將來自client->buf或client->reply的響應(yīng)寫回客戶端、將AOF緩沖區(qū)中的數(shù)據(jù)持久化到磁盤等。還有一個afterSleep函數(shù)，在aeApiPoll之后執(zhí)行。
• sendReplyToClient：命令回復(fù)處理器，當(dāng)事件循環(huán)后仍然在寫緩沖區(qū)中有數(shù)據(jù)時，將注冊并綁定到相應(yīng)連接的sendReplyToClient命令，當(dāng)連接觸發(fā)寫就緒事件時，將剩余的寫緩沖區(qū)中的數(shù)據(jù)寫回客戶端。

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

redis-io多路復(fù)用

到這里，我們可以描述一個客戶端從Redis請求命令的工作方式。

1. Redis服務(wù)器啟動，打開主線程事件循環(huán)，將acceptTcpHandler連接響應(yīng)處理器注冊到用戶配置的監(jiān)聽端口的文件描述符上，等待新連接的到來。
2. 客戶端與服務(wù)器之間建立網(wǎng)絡(luò)連接。
3. 調(diào)用acceptTcpHandler，主線程使用AE的API將readQueryFromClient命令讀取處理器綁定到新連接的文件描述符上，并初始化一個client以綁定此客戶端連接。
4. 客戶端發(fā)送請求命令，觸發(fā)讀就緒事件，主線程調(diào)用readQueryFromClient將客戶端通過套接字發(fā)送的命令讀入客戶端->querybuf讀緩沖區(qū)。
5. 接下來調(diào)用processInputBuffer，在其中使用processInlineBuffer或processMultibulkBuffer來根據(jù)Redis協(xié)議解析命令，最后調(diào)用processCommand來執(zhí)行命令。
6. 根據(jù)請求命令的類型（SET、GET、DEL、EXEC等），分配適當(dāng)?shù)拿顖?zhí)行器來執(zhí)行，最后調(diào)用addReply系列函數(shù)中的一系列函數(shù)將響應(yīng)數(shù)據(jù)寫入到相應(yīng)客戶端的寫緩沖區(qū)中：client->buf或client->reply，client->buf是首選的寫出緩沖區(qū)，具有固定大小的16KB，通?？梢跃彌_足夠的響應(yīng)數(shù)據(jù)，但如果客戶端在時間窗口內(nèi)需要非常大的響應(yīng)，則它將自動切換到client->reply鏈接列表，理論上可以容納無限數(shù)量的數(shù)據(jù)（受機器物理內(nèi)存限制）最后，將client添加到LIFO隊列clients_pending_write。
7. 在事件循環(huán)中，主線程執(zhí)行beforeSleep -> handleClientsWithPendingWrites，遍歷clients_pending_write隊列，并調(diào)用writeToClient將客戶端寫緩沖區(qū)中的數(shù)據(jù)返回給客戶端，如果寫緩沖區(qū)中仍然有剩余數(shù)據(jù)，則注冊sendReplyToClient命令到連接的回復(fù)處理器，等待客戶端寫入后繼續(xù)在事件循環(huán)中寫回剩余的響應(yīng)數(shù)據(jù)。

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

多線程異步任務(wù)

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

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

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

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

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

1. 后臺線程：這些異步任務(wù)由一個或多個后臺線程負責(zé)執(zhí)行，不影響主線程的事件循環(huán)，因此主線程可以繼續(xù)處理其他請求。
2. 非阻塞：異步任務(wù)是非阻塞的，因此它們不會阻止其他命令的執(zhí)行，即使它們可能需要很長時間才能完成。
3. 高可用性：通過將某些耗時操作轉(zhuǎn)移到后臺線程，Redis可以更好地保持高可用性。

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

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

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

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

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

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

1. 優(yōu)化網(wǎng)絡(luò)I/O模塊
2. 提高機器內(nèi)存讀寫速度

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

1. 零拷貝技術(shù)或DPDK技術(shù)
2. 利用多核

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

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

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

圖片

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

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

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

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

圖片

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

多反應(yīng)器模式通?？梢缘韧贛aster-Workers模式，比如Nginx和Memcached使用這種多線程模型，盡管項目之間的實現(xiàn)細節(jié)略有不同，但總體模式基本一致。

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

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

圖片

1. Redis服務(wù)器啟動，打開主線程事件循環(huán)，將acceptTcpHandler連接答復(fù)處理器注冊到與用戶配置的監(jiān)聽端口對應(yīng)的文件描述符，并等待新連接的到來。
2. 客戶端與服務(wù)器之間建立網(wǎng)絡(luò)連接。
3. 調(diào)用acceptTcpHandler，主線程使用AE的API將readQueryFromClient命令讀取處理器綁定到與新連接對應(yīng)的文件描述符上，并初始化一個客戶端以綁定這個客戶端連接。
4. 客戶端發(fā)送一個請求命令，觸發(fā)一個讀就緒事件。但不是通過套接字讀取客戶端的請求命令，而是服務(wù)器的主線程首先將客戶端放入LIFO隊列clients_pending_read中。
5. 在事件循環(huán)中，主線程執(zhí)行beforeSleep –> handleClientsWithPendingReadsUsingThreads，使用輪詢的負載均衡策略將clients_pending_read隊列中的連接均勻地分配給I/O線程。I/O線程通過套接字讀取客戶端的請求命令，將其存儲在client->querybuf中并解析第一個命令，但不執(zhí)行它，同時主線程忙于輪詢并等待所有I/O線程完成讀取任務(wù)。
6. 當(dāng)主線程和所有I/O線程都完成讀取時，主線程結(jié)束忙碌的輪詢，遍歷clients_pending_read隊列，執(zhí)行所有已連接客戶端的請求命令，首先調(diào)用processCommandResetClient來執(zhí)行已解析的第一個命令，然后調(diào)用processInputBuffer來解析和執(zhí)行客戶端連接的所有命令，使用processInlineBuffer或processMultibulkBuffer根據(jù)Redis協(xié)議解析命令，最后調(diào)用processCommand來執(zhí)行命令。
7. 根據(jù)所請求命令的類型（SET、GET、DEL、EXEC等），分配相應(yīng)的命令執(zhí)行器來執(zhí)行它，最后調(diào)用addReply系列函數(shù)中的一系列函數(shù)將響應(yīng)數(shù)據(jù)寫入相應(yīng)的客戶端寫出緩沖區(qū)：client->buf或client->reply，client->buf是首選的寫出緩沖區(qū)，大小固定為16KB，通常足夠緩沖足夠的響應(yīng)數(shù)據(jù)，但如果客戶端需要在時間窗口內(nèi)響應(yīng)大量數(shù)據(jù)，則會自動切換到client->reply鏈表，理論上可以容納無限量的數(shù)據(jù)（受到機器物理內(nèi)存的限制），最后將客戶端添加到LIFO隊列clients_pending_write中。
8. 在事件循環(huán)中，主線程執(zhí)行beforeSleep –> handleClientsWithPendingWritesUsingThreads，使用輪詢的負載均衡策略將clients_pending_write隊列中的連接均勻地分配給I/O線程和主線程本身。I/O線程通過調(diào)用writeToClient將客戶端寫緩沖區(qū)中的數(shù)據(jù)寫回客戶端，而主線程則忙于輪詢，等待所有I/O線程完成寫入任務(wù)。
9. 當(dāng)主線程和所有I/O線程都完成寫入時，主線程結(jié)束忙碌的輪詢，遍歷clients_pending_write隊列。如果客戶端寫緩沖區(qū)中還有數(shù)據(jù)，它將注冊sendReplyToClient以等待連接的寫準(zhǔn)備就緒事件，并等待客戶端寫入，然后繼續(xù)在事件循環(huán)中寫回剩余的響應(yīng)數(shù)據(jù)。

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

總結(jié)

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

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

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

• Redis多線程模型包括一個主線程（Main Reactor）和多個I/O線程（Sub Reactors）。
• 主線程負責(zé)接受新的連接，并將其分發(fā)到I/O線程進行獨立處理。
• I/O線程負責(zé)讀取客戶端的請求命令，但不執(zhí)行它們。
• 主線程負責(zé)執(zhí)行客戶端的請求命令，包括解析和執(zhí)行。
• 響應(yīng)數(shù)據(jù)由I/O線程寫回客戶端。

2.「異步讀寫」：Redis的多線程模型異步化了讀取客戶端請求和寫回響應(yīng)數(shù)據(jù)的過程?？蛻舳苏埱笫紫缺环湃氪x取隊列，然后由I/O線程讀取。執(zhí)行命令仍然在主線程上進行，但這種異步化提高了系統(tǒng)的并發(fā)性和吞吐量。