Redis為什麼選擇單執行緒？Redis為什麼這麼快？_哪吒程式設計

大家好，我是哪吒。

上一篇分享了圖解Redis，Redis主從複製與Redis哨兵機制，今天搞一下經典面試題Redis為什麼選擇單執行緒？Redis為什麼這麼快？，實現快速入門，豐富個人簡歷，提高面試level，給自己增加一點談資，秒變面試小達人，BAT不是夢。

Redis2.6，支援lua指令碼；

Redis3.0，支援叢集；

Redis4.0，混合持久化，多執行緒非同步刪除；

Redis5.0，核心程式碼重構；

Redis6.0，多執行緒IO；

Redis7.0，Function、Multi-part-AOF；

1、Redis採用單執行緒模型方便開發和維護；

2、單執行緒模型也可以通過IO多路複用和非阻塞IO併發處理多客戶端請求；

3、對於Redis來說，主要的效能瓶頸是記憶體和網路，而不是CPU；

Redis6.0之前，Redis從網路IO處理到實際的讀寫命令處理，都是單執行緒的，只不過在資料刪除、資料持久化的時候使用的是多執行緒。

Redis的效能瓶頸主要是網路IO，因此，Redis6.0開始，採用多個IO執行緒來處理網路請求，提高網路請求處理的並行度。

主執行緒負責建立連線，並把socket放入全域性等待佇列，主執行緒通過輪詢的方法將socket連線分配給IO執行緒。

主執行緒一旦把socket分配給IO執行緒，就會進入阻塞狀態，等待IO執行緒完成客戶端請求，此時，採用多個IO執行緒並行處理。

IO執行緒解析完請求，主執行緒還是會以單執行緒的方式執行這些命令。

當主執行緒執行完請求命令後，會將結果寫入緩衝區，主執行緒進入阻塞狀態，等待IO執行緒將結果回寫到socket中，並返回給客戶端。

回寫socket完畢後，主執行緒清空全域性佇列。

IO多路複用，一種同步的IO模型，實現一個執行緒監視多個檔案控制代碼，一旦某個檔案控制代碼就緒就能夠通知到對用的應用程式進行對應的讀寫操作，沒有檔案控制代碼就緒時，程式就會進入阻塞狀態，釋放CPU資源。

1、IO，作業系統層面指資料在核心態和使用者態之間進行的讀寫操作；

2、多路，多個客戶端socket連線；

3、複用，複用執行緒；

4、IO多路複用，使用單執行緒就能夠同時處理多個客戶端socket連線；

客戶端socket對應的檔案描述符FileDescriptor註冊進epoll，epoll會監聽哪些socket有訊息，避免大量的無用操作。

此時socket採用非阻塞模式，整個過程只在呼叫select、poll、epoll時才會阻塞，收到客戶端訊息不會阻塞，這個程序就會被充分利用起來，這種模式一般被稱為事件驅動，也就是reactor反應模式。

採用epoll的方式，最終目的是提高伺服器的吞吐能力。

IO多路複用與epoll函式才是“Redis為什麼這麼快？”的直接原因。

Redis是一個基於記憶體操作、KV形式的資料庫，採取多路複用、非阻塞IO、避免了不必要的上下文切換等特性。

Redis一直存在BigKey問題，因此在Redis4.0引入了多執行緒非同步刪除，正式開啟Redis多執行緒新篇章。

Redis6.0引入IO多執行緒的讀寫，更高效的處理請求，Redis只是將IO讀寫變成了多執行緒，命令的執行還是由主執行緒單執行緒執行，因此，多執行緒下操作Redis不會出現執行緒安全的問題，不用像Java那樣加鎖，解鎖，這也是Redis為什麼這麼快的根本原因。