相信你一定不止一次見過Redis是單線程模式，不過說實話那只是個老版本，這個問題是一位老哥的大廠面試題，跟我分享了一下。想著自己就知道redis6.0以前一直都是單線程，到了6的版本才加入了多線程，還不是很清楚，在多方打聽並且搜索之下總結了這篇文章。
一、問題概述
Redis 6.0 之後的版本拋棄了單線程模型這一設計，原本使用單線程運行的 Redis 也開始選擇性使用多線程模型，乍一看Redis的作者這麼牛，也逃不過“真香定律”，
仔細想想，這個問題其實可以拆分，拆分為兩個主要的問題：
（1）為什麼 Redis 一開始選擇單線程模型（單線程的好處）？
（2）為什麼 Redis 在 6.0 之後加入了多線程（在某些情況下，單線程出現了缺點，多線程可以解決）？
其實，作者並不是沒有逃脫真香定理，而是隨著時間的推移，出現的問題也越來越多，原來的設計肯定就有些不合時宜，該做出改變就做出改變。OK，帶著倆問題，我們就來好好地分析一下。
二、為什麼Redis一開始使用單線程
不管是單線程或者是多線程都是為了提升Redis的開發效率，因為Redis是一個基於內存的數據庫，還要處理大量的外部的網絡請求，這就不可避免的要進行多次IO。好在Redis使用了很多優秀的機制來保證了它的高效率。那麼為什麼Redis要設計成單線程模式的呢？可以總結如下：
（1）IO多路複用
我們來看一下Redis頂層設計。
FD是一個文件描述符，意思是表示當前文件處於可讀、可寫還是異常狀態。使用 I/O 多路複用機制同時監聽多個文件描述符的可讀和可寫狀態。你可以理解為具有了多線程的特點。
一旦受到網絡請求就會在內存中快速處理，由於絕大多數的操作都是純內存的，所以處理的速度會非常地快。也就是說在單線程模式下，即使連接的網絡處理很多，因為有IO多路複用，依然可以在高速的內存處理中得到忽略。
（2）可維護性高
多線程模型雖然在某些方面表現優異，但是它卻引入了程序執行順序的不確定性，帶來了併發讀寫的一系列問題。單線程模式下，可以方便地進行調試和測試。
（3）基於內存，單線程狀態下效率依然高
多線程能夠充分利用CPU的資源，但對於Redis來說，由於基於內存速度那是相當的高，能達到在一秒內處理10萬個用戶請求，如果一秒十萬還不能滿足，那我們就可以使用Redis分片的技術來交給不同的Redis服務器。這樣的做飯避免了在同一個 Redis 服務中引入大量的多線程操作。
而且基於內存，除非是要進行AOF備份，否則基本上不會涉及任何的 I/O 操作。這些數據的讀寫由於只發生在內存中，所以處理速度是非常快的；用多線程模型處理全部的外部請求可能不是一個好的方案。
現在我們知道了基本上可以總結成兩句話，基於內存而且使用多路複用技術，單線程速度很快，又保證了多線程的特點。因為沒有必要使用多線程。
三、為什麼引入多線程？
剛剛說了一堆使用單線程的好處，現在話鋒一轉，又要說為什麼要引入多線程，別不適應。引入多線程說明Redis在有些方面，單線程已經不具有優勢了。
因為讀寫網絡的read/write系統調用在Redis執行期間佔用了大部分CPU時間，如果把網絡讀寫做成多線程的方式對性能會有很大提升。
Redis 的多線程部分只是用來處理網絡數據的讀寫和協議解析，執行命令仍然是單線程。之所以這麼設計是不想 Redis 因為多線程而變得複雜，需要去控制 key、lua、事務，LPUSH/LPOP 等等的併發問題。
Redis 在最新的幾個版本中加入了一些可以被其他線程異步處理的刪除操作，也就是我們在上面提到的 UNLINK、FLUSHALL ASYNC 和 FLUSHDB ASYNC，我們為什麼會需要這些刪除操作，而它們為什麼需要通過多線程的方式異步處理？
我們知道Redis可以使用del命令刪除一個元素，如果這個元素非常大，可能佔據了幾十兆或者是幾百兆，那麼在短時間內是不能完成的，這樣一來就需要多線程的異步支持。
現在刪除工作可以在後臺進行。
四、總結
Redis 選擇使用單線程模型處理客戶端的請求主要還是因為 CPU 不是 Redis 服務器的瓶頸，所以使用多線程模型帶來的性能提升並不能抵消它帶來的開發成本和維護成本，系統的性能瓶頸也主要在網絡 I/O 操作上；而 Redis 引入多線程操作也是出於性能上的考慮，對於一些大鍵值對的刪除操作，通過多線程非阻塞地釋放內存空間也能減少對 Redis 主線程阻塞的時間，提高執行的效率。
一句話講完：之前用單線程是因為基於內存速度快，而且多路複用有多路複用的作用，也就是足夠了，現在引入是因為在某些操作要優化，比如刪除操作，因此引入了多線程。
