Redis是單線程的，這話擱以前，是橫着走的，誰都知道的真理。現在不一樣，Redis 變了。再說這句話，多少得有質疑的語氣來跟你辯駁一番。意志不堅定的，可能就繳械投降，順着别人走了。
到底是什麼樣的，各位看官請跟小萊一起往下：
Reactor模式
反應器模式，你可能不太認識，如果看過上篇文章的話應該會有點印象。涉及到 Redis 線程它是一個繞不過去的話題。
1、傳統阻塞IO模型
在講反應器模式前，這裡有必要提一下傳統阻塞IO模型的處理方式。
在傳統阻塞IO模型中，由一個獨立的 Acceptor 線程來監聽用戶端的連接配接，每當有用戶端請求過來時，它就會為用戶端配置設定一個新的線程來進行處理。當同時有多個請求過來，服務端對應的就會配置設定相應數量的線程。這就會導緻CPU頻繁切換，浪費資源。
有的連接配接請求過來不做任何事情，但服務端還會配置設定對應的線程，這樣就會造成不必要的線程開銷。這就好比你去餐廳吃飯，你拿着菜單看了半天發現真他娘的貴，然後你就走人了。這段時間等你點菜的服務員就相當于一個對應的線程，你要點菜可以看作一個連接配接請求。
同時，每次建立連接配接後，當線程調用讀寫方法時，線程會被阻塞，直到有資料可讀可寫， 在此期間線程不能做其它事情。還是上邊餐廳吃飯的例子，你出去轉了一圈發現還是這家成本效益最高。回到這家餐廳又拿着菜單看了半天，服務員也在旁邊等你點完菜為止。這個過程中服務員什麼也不能做，隻能這麼幹等着，這個過程相當于阻塞。
你看這樣的方式，每來一個請求就要配置設定一個線程，并且還得阻塞地等線程處理完。有的請求還隻是過來連接配接下，什麼操作也不幹，還得為它配置設定一個線程，對伺服器資源要求那得多高啊。遇到高并發場景，不敢想象。對于連接配接數目比較小的的固定架構倒是可以考慮。
2、僞異步IO模型
你可能了解過一種通過線程池優化的解決方案，采用線程池和任務隊列的方式。這種被稱作僞異步IO模型。
當有用戶端接入時，将用戶端的請求封裝成一個 task 投遞到後端線程池中來處理。線程池維護一個消息隊列和多個活躍線程，對消息隊列中的任務進行處理。
這種解決方案，避免了為每個請求建立一個線程導緻的線程資源耗盡問題。但是底層仍然是同步阻塞模型。如果線程池内的所有線程都阻塞了，那麼對于更多請求就無法響應了。是以這種模式會限制最大連接配接數，并不能從根本上解決問題。
我們繼續用上邊的餐廳來舉例，餐廳老闆在經營了一段時間後，顧客多了起來，原本店裡的5個服務員一對一服務的話根本對付不過來。于是老闆采用5個人線程池的方式。服務員服務完一個客人後立刻去服務另一個。
這時問題出現了，有的客人點菜特别慢，服務員就得等待很長時間，直到客人點完為止。如果5個客人都點的特别慢的話，這5個服務員就得一直等下去，就會導緻其餘的顧客沒有人服務的狀态。這就是我們上邊所說的線程池所有線程都被阻塞的情況。
那麼這種問題該如何解決呢？别急， Reactor 模式就要出場了。
3、Reactor設計模式
Reactor 模式的基本設計思想是基于I/O複用模型來實作的。
這裡說下I/O複用模型。和傳統IO多線程阻塞不同，I/O複用模型中多個連接配接共用一個阻塞對象，應用程式隻需要在一個阻塞對象等待。當某個連接配接有新的資料可以處理時，作業系統通知應用程式，線程從阻塞狀态傳回，開始進行業務處理。
什麼意思呢？餐廳老闆也發現了顧客點餐慢的問題，于是他采用了一種大膽的方式，隻留了一個服務員。當客人點餐的時候，這個服務員就去招待别的客人，客人點好餐後直接喊服務員來進行服務。這裡的顧客和服務員可以分别看作多個連接配接和一個線程。服務員阻塞在一個顧客那裡，當有别的顧客點好餐後，她就立刻去服務其他的顧客。
了解了 reactor 的設計思想後，我們再來看下今天的主角單 reactor 單線程的實作方案：
Reactor 通過 I/O複用程式監控用戶端請求事件，收到事件後通過任務分派器進行分發。
針對建立連接配接請求事件，通過 Acceptor 處理，并建立對應的 handler 負責後續業務處理。
針對非連接配接事件，Reactor 會調用對應的 handler 完成 read->業務處理->write 處理流程，并将結果傳回給用戶端。
整個過程都在一個線程裡完成。
單線程時代
了解了 Reactor 模式後，你可能會有一個疑問，這個和我們今天的主題有什麼關系呢。可能你不知道的是，Redis 是基于 Reactor 單線程模式來實作的。
IO多路複用程式接收到使用者的請求後，全部推送到一個隊列裡，交給檔案分派器。對于後續的操作，和在 reactor 單線程實作方案裡看到的一樣，整個過程都在一個線程裡完成，是以 Redis 被稱為是單線程的操作。
對于單線程的 Redis 來說，基于記憶體，且指令操作時間複雜度低，是以讀寫速率是非常快的。
多線程時代
Redis6 版本中引入了多線程。上邊已經提到過 Redis 單線程處理有着很快的速度，那為什麼還要引入多線程呢？單線程的瓶頸在什麼地方？
我們先來看第二個問題，在 Redis 中，單線程的性能瓶頸主要在網絡IO操作上。也就是在讀寫網絡 read/write 系統調用執行期間會占用大部分 CPU 時間。如果你要對一些大的鍵值對進行删除操作的話，在短時間内是删不完的，那麼對于單線程來說就會阻塞後邊的操作。
回想下上邊講得 Reactor 模式中單線程的處理方式。針對非連接配接事件，Reactor 會調用對應的 handler 完成 read->業務處理->write 處理流程，也就是說這一步會造成性能上的瓶頸。
Redis 在設計上采用将網絡資料讀寫和協定解析通過多線程的方式來處理，對于指令執行來說，仍然使用單線程操作。
總結
Reactor模式
- 傳統阻塞IO模型用戶端與服務端線程1:1配置設定，不利于進行擴充。
- 僞異步IO模型采用線程池方式，但是底層仍然使用同步阻塞方式，限制了最大連接配接數。
- Reactor 通過 I/O複用程式監控用戶端請求事件，通過任務分派器進行分發。
- 基于 Reactor 單線程模式實作，通過IO多路複用程式接收到使用者的請求後，全部推送到一個隊列裡，交給檔案分派器進行處理。
- 單線程性能瓶頸主要在網絡IO上。
- 将網絡資料讀寫和協定解析通過多線程的方式來處理 ，對于指令執行來說，仍然使用單線程操作。
關于作者
作者：大家好，我是萊烏，BAT搬磚工一枚。從小公司進入大廠，一路走來收獲良多，想将這些經驗分享給有需要的人，是以建立了公衆号「IT界農民工」。定時更新，希望能幫助到你
面試時說Redis是單線程的，被噴慘了！