Redis爲何又引入了多線程？

相信你必定不止一次見過Redis是單線程模式，不過說實話那只是個老版本，這個問題是一位老哥的大廠面試題，跟我分享了一下。想着本身就知道redis6.0之前一直都是單線程，到了6的版本才加入了多線程，還不是很清楚，在多方打聽而且搜索之下總結了這篇文章。

1、問題概述 Redis 6.0 以後的版本拋棄了單線程模型這一設計，本來使用單線程運行的 Redis 也開始選擇性使用多線程模型，乍一看Redis的做者這麼牛，也逃不過「真香定律」，

Redis爲何又引入了多線程？做者也逃不過「真香定理」？ 仔細想一想，這個問題其實能夠拆分，拆分爲兩個主要的問題：

（1）爲何 Redis 一開始選擇單線程模型（單線程的好處）？

（2）爲何 Redis 在 6.0 以後加入了多線程（在某些狀況下，單線程出現了缺點，多線程能夠解決）？

其實，做者並非沒有逃脫真香定理，而是隨着時間的推移，出現的問題也愈來愈多，原來的設計確定就有些不合時宜，該作出改變就作出改變。OK，帶着倆問題，咱們就來好好地分析一下。

2、爲何Redis一開始使用單線程 不論是單線程或者是多線程都是爲了提高Redis的開發效率，由於Redis是一個基於內存的數據庫，還要處理大量的外部的網絡請求，這就不可避免的要進行屢次IO。好在Redis使用了不少優秀的機制來保證了它的高效率。那麼爲何Redis要設計成單線程模式的呢？能夠總結以下：

（1）IO多路複用

咱們來看一下Redis頂層設計。

Redis爲何又引入了多線程？做者也逃不過「真香定理」？ FD是一個文件描述符，意思是表示當前文件處於可讀、可寫仍是異常狀態。使用 I/O 多路複用機制同時監聽多個文件描述符的可讀和可寫狀態。你能夠理解爲具備了多線程的特色。

一旦受到網絡請求就會在內存中快速處理，因爲絕大多數的操做都是純內存的，因此處理的速度會很是地快。也就是說在單線程模式下，即便鏈接的網絡處理不少，由於有IO多路複用，依然能夠在高速的內存處理中獲得忽略。

（2）可維護性高

多線程模型雖然在某些方面表現優異，可是它卻引入了程序執行順序的不肯定性，帶來了併發讀寫的一系列問題。單線程模式下，能夠方便地進行調試和測試。

（3）基於內存，單線程狀態下效率依然高

多線程可以充分利用CPU的資源，但對於Redis來講，因爲基於內存速度那是至關的高，能達到在一秒內處理10萬個用戶請求，若是一秒十萬還不能知足，那咱們就可使用Redis分片的技術來交給不一樣的Redis服務器。這樣的作飯避免了在同一個 Redis 服務中引入大量的多線程操做。

並且基於內存，除非是要進行AOF備份，不然基本上不會涉及任何的 I/O 操做。這些數據的讀寫因爲只發生在內存中，因此處理速度是很是快的；用多線程模型處理所有的外部請求可能不是一個好的方案。

如今咱們知道了基本上能夠總結成兩句話，基於內存並且使用多路複用技術，單線程速度很快，又保證了多線程的特色。由於沒有必要使用多線程。

3、爲何引入多線程？ 剛剛說了一堆使用單線程的好處，如今話鋒一轉，又要說爲何要引入多線程，別不適應。引入多線程說明Redis在有些方面，單線程已經不具備優點了。

由於讀寫網絡的read/write系統調用在Redis執行期間佔用了大部分CPU時間，若是把網絡讀寫作成多線程的方式對性能會有很大提高。

Redis 的多線程部分只是用來處理網絡數據的讀寫和協議解析，執行命令仍然是單線程。之因此這麼設計是不想 Redis 由於多線程而變得複雜，須要去控制 key、lua、事務，LPUSH/LPOP 等等的併發問題。

Redis 在最新的幾個版本中加入了一些能夠被其餘線程異步處理的刪除操做，也就是咱們在上面提到的 UNLINK、FLUSHALL ASYNC 和 FLUSHDB ASYNC，咱們爲何會須要這些刪除操做，而它們爲何須要經過多線程的方式異步處理？

咱們知道Redis可使用del命令刪除一個元素，若是這個元素很是大，可能佔據了幾十兆或者是幾百兆，那麼在短期內是不能完成的，這樣一來就須要多線程的異步支持。

如今刪除工做能夠在後臺進行。

4、總結 Redis 選擇使用單線程模型處理客戶端的請求主要仍是由於 CPU 不是 Redis 服務器的瓶頸，因此使用多線程模型帶來的性能提高並不能抵消它帶來的開發成本和維護成本，系統的性能瓶頸也主要在網絡 I/O 操做上；而 Redis 引入多線程操做也是出於性能上的考慮，對於一些大鍵值對的刪除操做，經過多線程非阻塞地釋放內存空間也能減小對 Redis 主線程阻塞的時間，提升執行的效率。

一句話講完：以前用單線程是由於基於內存速度快，並且多路複用有多路複用的做用，也就是足夠了，如今引入是由於在某些操做要優化，好比刪除操做，所以引入了多線程。