本文主要分兩部分。首先我們先聊一下Redis6.0之前為什麼採用單執行緒模型。然後再詳細解釋Redis6.0的多執行緒。

Redis6.0之前為什麼採用單執行緒模型

嚴格地說，從Redis 4.0之後並不是單執行緒。除了主執行緒外，還有一些後臺執行緒處理一些較為緩慢的操作，例如無用連線的釋放、大 key 的刪除等等。

單執行緒模型，為何效能那麼高？

Redis作者從設計之初，進行了多方面的考慮。最終選擇使用單執行緒模型來處理命令。之所以選擇單執行緒模型，主要有如下幾個重要原因：

1. Redis操作基於記憶體，絕大多數操作的效能瓶頸不在CPU
2. 單執行緒模型，避免了執行緒間切換帶來的效能開銷
3. 使用單執行緒模型也能併發的處理客戶端的請求（多路複用I/O）
4. 使用單執行緒模型，可維護性更高，開發，除錯和維護的成本更低

上述第三個原因是Redis最終採用單執行緒模型的決定性因素，其他的兩個原因都是使用單執行緒模型額外帶來的好處，在這裡我們會按順序介紹上述的幾個原因。

效能瓶頸不在CPU

下圖是Redis官網對單執行緒模型的說明。大概意思是：Redis的瓶頸並不在CPU，它的主要瓶頸在於記憶體和網路。在Linux環境中，Redis每秒甚至可以提交100萬次請求。

為什麼說Redis的瓶頸不在CPU？

首先，Redis絕大部分操作是基於記憶體的，而且是純kv（key-value）操作，所以命令執行速度非常快。我們可以大概理解成，redis中的資料儲存在一張大HashMap中，HashMap的優勢就是查詢和寫入的時間複雜度都是O(1)。Redis內部採用這種結構儲存資料，就奠定了Redis高效能的基礎。根據Redis官網描述，在理想情況下Redis每秒可以提交一百萬次請求，每次請求提交所需的時間在納秒的時間量級。既然每次的Redis操作都這麼快，單執行緒就可以完全搞定了，那還何必要用多執行緒呢！

執行緒上下文切換問題

另外，多執行緒場景下會發生執行緒上下文切換。執行緒是由CPU排程的，CPU的一個核在一個時間片內只能同時執行一個執行緒，在CPU由執行緒A切換到執行緒B的過程中會發生一系列的操作，主要過程包括儲存執行緒A的執行現場，然後載入執行緒B的執行現場，這個過程就是“執行緒上下文切換”。其中涉及執行緒相關指令的儲存和恢復。

頻繁的執行緒上下文切換可能會導致效能急劇下降，這會導致我們不僅沒有提升處理請求的速度，反而降低了效能，這也是 Redis 對於多執行緒技術持謹慎態度的原因之一。

在Linux系統中可以使用vmstat命令來檢視上下文切換的次數，下面是vmstat檢視上下文切換次數的示例：

vmstat 1 表示每秒統計一次, 其中cs列就是指上下文切換的數目. 一般情況下, 空閒系統的上下文切換每秒在1500以下。

並行處理客戶端的請求（I/O多路複用）

如上所述：Redis的瓶頸並不在CPU，它的主要瓶頸在於記憶體和網路。所謂記憶體瓶頸很好理解，Redis做為快取使用時很多場景需要快取大量資料，所以需要大量記憶體空間，這可以通過叢集分片去解決，例如Redis自身的無中心叢集分片方案以及Codis這種基於代理的叢集分片方案。

對於網路瓶頸，Redis在網路I/O模型上採用了多路複用技術，來減少網路瓶頸帶來的影響。很多場景中使用單執行緒模型並不意味著程式不能併發的處理任務。Redis 雖然使用單執行緒模型處理使用者的請求，但是它卻使用 I/O 多路複用技術“並行”處理來自客戶端的多個連線，同時等待多個連線傳送的請求。使用 I/O多路複用技術能極大地減少系統的開銷，系統不再需要為每個連線建立專門的監聽執行緒，避免了由於大量的執行緒建立帶來的巨大效能開銷。

下面我們詳細解釋一下多路複用I/O模型。為了能更充分理解，我們先了解幾個基本概念。

Socket（套接字）：Socket可以理解成，在兩個應用程式進行網路通訊時，分別在兩個應用程式中的通訊端點。通訊時，一個應用程式將資料寫入Socket，然後通過網絡卡把資料傳送到另外一個應用程式的Socket中。我們平常所說的HTTP和TCP協議的遠端通訊，底層都是基於Socket實現的。5種網路IO模型也都要基於Socket實現網路通訊。

阻塞與非阻塞：所謂阻塞，就是發出一個請求不能立刻返回響應，要等所有的邏輯全處理完才能返回響應。非阻塞反之，發出一個請求立刻返回應答，不用等處理完所有邏輯。

核心空間與使用者空間：在Linux中，應用程式穩定性遠遠比不上作業系統程式，為了保證作業系統的穩定性，Linux區分了核心空間和使用者空間。可以這樣理解，核心空間執行作業系統程式和驅動程式，使用者空間執行應用程式。Linux以這種方式隔離了作業系統程式和應用程式，避免了應用程式影響到作業系統自身的穩定性。這也是Linux系統超級穩定的主要原因。所有的系統資源操作都在核心空間進行，比如讀寫磁碟檔案，記憶體分配和回收，網路介面呼叫等。所以在一次網路IO讀取過程中，資料並不是直接從網絡卡讀取到使用者空間中的應用程式緩衝區，而是先從網絡卡拷貝到核心空間緩衝區，然後再從核心拷貝到使用者空間中的應用程式緩衝區。對於網路IO寫入過程，過程則相反，先將資料從使用者空間中的應用程式緩衝區拷貝到核心緩衝區，再從核心緩衝區把資料通過網絡卡傳送出去。

多路複用I/O模型，建立在多路事件分離函式select，poll，epoll之上。以Redis採用的epoll為例，在發起read請求前，先更新epoll的socket監控列表，然後等待epoll函式返回（此過程是阻塞的，所以說多路複用IO本質上也是阻塞IO模型）。當某個socket有資料到達時，epoll函式返回。此時使用者執行緒才正式發起read請求，讀取並處理資料。這種模式用一個專門的監視執行緒去檢查多個socket，如果某個socket有資料到達就交給工作執行緒處理。由於等待Socket資料到達過程非常耗時，所以這種方式解決了阻塞IO模型一個Socket連線就需要一個執行緒的問題，也不存在非阻塞IO模型忙輪詢帶來的CPU效能損耗的問題。多路複用IO模型的實際應用場景很多，大家耳熟能詳的Redis，Java NIO，以及Dubbo採用的通訊框架Netty都採用了這種模型。

下圖是基於epoll函式Socket程式設計的詳細流程。

可維護性

我們知道，多執行緒可以充分利用多核CPU，在高併發場景下，能夠減少因I/O等待帶來的CPU損耗，帶來很好的效能表現。不過多執行緒卻是一把雙刃劍，帶來好處的同時，還會帶來程式碼維護困難，線上問題難於定位和除錯，死鎖等問題。多執行緒模型中程式碼的執行過程不再是序列的，多個執行緒同時訪問的共享變數如果處理不當也會帶來詭異的問題。

我們通過一個例子，看一下多執行緒場景下發生的詭異現象。看下面的程式碼：

flag為true時，cal() 方法返回值是多少？很多人會說：這還用問嗎！肯定返回2

結果可能會讓你大吃一驚！上面的這段程式碼，由於語句1和語句2沒有資料依賴性，可能會發生指令重排序，有可能編譯器會把flag=true放到num=1的前面。此時set和cal方法分別在不同執行緒中執行，沒有先後關係。cal方法，只要flag為true，就會進入if的程式碼塊執行相加的操作。可能的順序是：

• 語句1先於語句2執行，這時的執行順序可能是：語句1->語句2->語句3->語句4。執行語句4前，num = 1，所以cal的返回值是2
• 語句2先於語句1執行，這時的執行順序可能是：語句2->語句3->語句4->語句1。執行語句4前，num = 0，所以cal的返回值是0

我們可以看到，在多執行緒環境下如果發生了指令重排序，會對結果造成嚴重影響。

當然可以在第三行處，給flag加上關鍵字volatile來避免指令重排。即在flag處加上了記憶體柵欄，來阻隔flag（柵欄）前後的程式碼的重排序。當然多執行緒還會帶來可見性問題，死鎖問題以及共享資源安全等問題。

boolean volatile flag = false;

Redis6.0為何引入多執行緒？

Redis6.0引入的多執行緒部分，實際上只是用來處理網路資料的讀寫和協議解析，執行命令仍然是單一工作執行緒。

從上圖我們可以看到Redis在處理網路資料時，呼叫epoll的過程是阻塞的，也就是說這個過程會阻塞執行緒，如果併發量很高，達到幾萬的QPS，此處可能會成為瓶頸。一般我們遇到此類網路IO瓶頸的問題，可以增加執行緒數來解決。開啟多執行緒除了可以減少由於網路I/O等待造成的影響，還可以充分利用CPU的多核優勢。Redis6.0也不例外，在此處增加了多執行緒來處理網路資料，以此來提高Redis的吞吐量。當然相關的命令處理還是單執行緒執行，不存在多執行緒下併發訪問帶來的種種問題。

效能對比

壓測配置:

Redis Server: 阿里雲 Ubuntu 18.04，8 CPU 2.5 GHZ, 8G 記憶體，主機型號 ecs.ic5.2xlarge
Redis Benchmark Client: 阿里雲 Ubuntu 18.04，8 2.5 GHZ CPU, 8G 記憶體，主機型號 ecs.ic5.2xlarge

多執行緒版本Redis 6.0，單執行緒版本是 Redis 5.0.5。多執行緒版本需要新增以下配置:

io-threads 4 # 開啟 4 個 IO 執行緒
io-threads-do-reads yes # 請求解析也是用 IO 執行緒

壓測命令: redis-benchmark -h 192.168.0.49 -a foobared -t set,get -n 1000000 -r 100000000 --threads 4 -d ${datasize} -c 256

從上面可以看到 GET/SET 命令在多執行緒版本中效能相比單執行緒幾乎翻了一倍。另外，這些資料只是為了簡單驗證多執行緒 I/O 是否真正帶來效能優化，並沒有針對具體的場景進行壓測，資料僅供參考。本次效能測試基於 unstble 分支，不排除後續釋出的正式版本的效能會更好。

最後

可見單執行緒有單執行緒的好處，多執行緒有多執行緒的優勢，只有充分理解其中的本質原理，才能靈活運用於生產實踐當中。