Redis 6.0 之後的版本拋棄了單執行緒模型這項設計，原本使用單執行緒運行的Redis 也開始選擇性使用多執行緒模型，乍看Redis的作者這麼牛，也逃不過“真香定律”，
仔細想想，這個問題其實可以拆分，拆分為兩個主要的問題：
#（1）為什麼Redis 一開始選擇單線程模型（單線程的好處）？
（2）為什麼 Redis 在 6.0 之後加入了多執行緒（在某些情況下，單執行緒出現了缺點，多執行緒可以解決）？
其實，作者並不是沒有逃脫真香定理，而是隨著時間的推移，出現的問題也越來越多，原來的設計肯定就有些不合時宜，該做出改變就做出改變。 OK，帶著倆問題，我們就來好好分析。
不管是單執行緒或是多執行緒都是為了提升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為什麼要引入多線程的詳細內容。更多資訊請關注PHP中文網其他相關文章！
