不同版本的Redis是不同的，在Redis4.0之前，Redis是單線程運行的，但單線程並不代表效率低，像Nginx、Nodejs也是單線程程序，但是它們的效率並不低。
原因是Redis是基於內存的，它的瓶頸在於機器的內存、網絡帶寬，而不是CPU，在CPU還沒達到瓶頸時機器內存可能就滿了、或者帶寬達到瓶頸了。因此CPU不是主要原因，那么自然就采用單線程了，況且使用多線程比較麻煩。
但是在Redis4.0的時候，已經開始支持多線程了，比如后台刪除等功能。
簡單來說，Redis在4.0之前使用單線程的模式是因為以下三個原因：
1.使用單線程模式的Redis，其開發和維護更簡單，因為單線程模式方便開發和調試。
2.即使使用單線程模型也能夠並發地處理多客戶端的請求，主要是因為Redis內部使用了基於epoll的多路復用。
3.對於Redis來說，主要的性能瓶頸是內存或網絡帶寬，而非CPU。
但Redis在4.0以及之后的版本中引入了惰性刪除（也叫異步刪除），意思就是我們可以使用異步的方式對Redis中的數據進行刪除操作，例如：
1.unlink key：和del key類似，刪除指定的key，若key不存在則key被跳過。但是del會產生阻塞，而unlink命令會在另一個線程中回收內存，即它是非阻塞的【http://www.redis.cn/commands/unlink.html】；
2.flushdb async：刪除當前數據庫的所有數據【http://www.redis.cn/commands/flushdb.html】；
3.flushall async：刪除所有庫中的數據【http://www.redis.cn/commands/flushall.html】。
這樣處理的好處是不會使Redis的主線程卡頓，會把這些操作交給后台線程來執行。
【通常情況下使用del指令可以很快的刪除數據，但是當被刪除的key是一個非常大的對象時，例如：刪除的時包含成千上萬個元素的hash集合時，那么del指令就會造成Redis主線程卡頓，因此使用惰性刪除可以有效避免Redis卡頓問題。】
考點分析：
關於Redis線程模型的問題（單線程或多線程）幾乎是Redis必問的問題之一，但回答好的人卻不多，大部分只能回答上來Redis是單線程的以及說出來單線程的眾多好處，但對於Redis4.0和Redis6.0中，尤其是Redis6.0中多線程的特點，能夠准確回答上來的人非常少。關於單線程和多線程的相關知識，還有以下面試題。
1.Redis主線程既然是單線程，為什么還這個快？
2.介紹一下Redis中的IO多路復用？
3.介紹一下Redis6.0中的多線程？
1.Redis為什么這么快？
原因有以下幾點：
a.基於內存操作：Redis的所有數據都存在內存中，因此所有的運算都是內存級別的，所以它的性能比較高。
b.數據結構簡單：Redis的數據結構比較簡單，是為Redis專門設計的，而這些簡單的數據結構的查找和操作的時間復雜度都是O(1)。
c.多路復用和非阻塞IO：Redis使用IO多路復用功能來監聽多個socket連接的客戶端，這樣就可以使用一個線程來處理多個情況，從而減少線程切換帶來的開銷，同時也避免了IO阻塞操作，從而大大提高了Redis的性能。
d.避免上下文切換：因為是單線程模型，因此就避免了不必要的上下文切換和多線程競爭，這就省去了多線程切換帶來的時間和性能上的開銷，而且單線程不會導致死鎖的問題發生。
官方使用的基准測試結果表明，單線程的Redis可以達到10W/S的吞吐量。
2.IO多路復用是什么？
套接字的讀寫方法默認是阻塞的，例如當調用讀取操作read方法時，緩沖區沒有任何數據，那么這個線程會卡在這里，直到緩沖區有數據或者連接被關閉時，read方法才會返回，該線程才能繼續處理其他業務。
但這樣顯然就降低了程序的執行效率，而Redis使用的時非阻塞的IO，這就意味着IO的讀寫流程不再是阻塞的，讀寫方法都是瞬間完成並且返回的，也就是它會采用能讀多少就讀多少、能寫多少就寫多少的策略來執行IO操作，這顯然更符合我們對性能的追求。
但這種非阻塞的IO也面臨一個問題，那就是當我們執行讀取操作時，有可能只讀取了一部分數據；同理寫數據也是這種情況，當緩沖區滿了，而我們的數據還沒有寫完，那么生效的數據何時寫就成了一個問題。
而IO的多路復用就是解決上面的這個問題的，使用IO多路復用最簡單的方式就是使用select函數，此函數是操作系統提供給用戶程序的API接口，用於監控多個文件描述符的可讀和可寫情況的，這樣就可以監控到文件描述符的讀寫事件了。當監控到相應的時間之后就可以通知線程處理相應的業務了，這樣就保證了Redis讀寫功能的正常執行。
【不過現在的操作系統已經基本上不適用select函數了，改為調用epoll函數（Linux）了，macOS則是使用Kqueue（繼承與Unix），因為select函數在文件描述符非常多的時候性能非常差。】
3.Redis6.0中的多線程？
Redis單線程的優點非常，不但降低了Redis內部實現的負責性，也讓所有操作都可以在無鎖的情況下進行，並且不存在死鎖和線程切換帶來的性能以及時間上的消耗；但是其缺點也很明顯，單線程機制導致Redis的QPS（Query Per Second，每秒查詢數）很難得到有效的提高（雖然夠快了，但人畢竟還是要有更高的追求的）。
Redis在4.0版本中雖然引入了多線程，但是此版本的多線程只能用於大數據量的異步刪除，對於非刪除操作的意義並不是很大。
如果我們使用Redis多線程就可以分攤Redis同步讀寫IO的壓力，以及充分利用多核CPU資源，並且可以有效的提升Redis的QPS。在Redis中雖然使用了IO多路復用，並且是基於非阻塞的IO進行操作的，但是IO的讀寫本身是阻塞的。比如當socket中有數據時，Redis會先將數據從內核態空間拷貝到用戶態空間，然后再進行相關操作，而這個拷貝過程是阻塞的，並且當數據量越大時拷貝所需要的的時間就越多，而這些操作都是基於單線程完成的。
因此在Redis6.0中新增了多線程的功能來提高IO的讀寫性能，它的主要實現思路是將主線程的IO讀寫任務拆分給一組獨立的線程去執行，這樣就可以使用多個socket的讀寫並行化了，但Redis的命令依舊是主線程串行執行的。
但是注意：Redis6.0是默認禁用多線程的，但可以通過配置文件redis.conf中的io-threads-do-reads 等於 true 來開啟。但是還不夠，除此之外我們還需要設置線程的數量才能正確地開啟多線程的功能，同樣是修改Redis的配置，例如設置 io-threads 4，表示開啟4個線程。
【關於線程數的設置，官方的建議是如果為4核CPU，那么設置線程數為2或3；如果為8核CPU，那么設置線程數為6.總之線程數一定要小於機器的CPU核數，線程數並不是越大越好。】
關於Redis的性能，Redis的作者在2019年的RedisConf大會上提到，Redis6.0引入的多線程IO特性對性能的提升至少是一倍以上。國人也有在阿里雲使用4個線程的Redis版本和單線程的Redis進行比較測試，發現測試結果和Redis作者說的一致，性能基本可以提高一倍。
總結：
本文介紹了Redis在4.0之前單線程依然快的原因：基於內存操作、數據結構簡單、IO多路復用和非阻塞IO、避免了不必要的線程上下文切換。並且在Redis4.0開始支持多線程，主要體現在大數據的異步刪除方面，例如：unlink key、flushdb async、flushall async等。而Redis6.0的多線程則增加了對IO讀寫的並發能力，用於更好的提升Redis的性能。