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為什麼這麼快的根本原因。