[[348385]]

本文轉(zhuǎn)載自微信公眾號「IT界農(nóng)民工」，作者萊烏  。轉(zhuǎn)載本文請聯(lián)系IT界農(nóng)民工公眾號。 

Redis是單線程的，這話擱以前，是橫著走的，誰都知道的真理?，F(xiàn)在不一樣，Redis 變了。再說這句話，多少得有質(zhì)疑的語氣來跟你辯駁一番。意志不堅(jiān)定的，可能就繳械投降，順著別人走了。

到底是什么樣的，各位看官請跟小萊一起往下看：

- 思維導(dǎo)圖 -

Reactor模式

反應(yīng)器模式，你可能不太認(rèn)識，如果看過上篇文章的話應(yīng)該會有點(diǎn)印象。涉及到 Redis 線程它是一個(gè)繞不過去的話題。

1、傳統(tǒng)阻塞IO模型

在講反應(yīng)器模式前，這里有必要提一下傳統(tǒng)阻塞IO模型的處理方式。

在傳統(tǒng)阻塞IO模型中，由一個(gè)獨(dú)立的 Acceptor 線程來監(jiān)聽客戶端的連接，每當(dāng)有客戶端請求過來時(shí)，它就會為客戶端分配一個(gè)新的線程來進(jìn)行處理。當(dāng)同時(shí)有多個(gè)請求過來，服務(wù)端對應(yīng)的就會分配相應(yīng)數(shù)量的線程。這就會導(dǎo)致CPU頻繁切換，浪費(fèi)資源。

有的連接請求過來不做任何事情，但服務(wù)端還會分配對應(yīng)的線程，這樣就會造成不必要的線程開銷。這就好比你去餐廳吃飯，你拿著菜單看了半天發(fā)現(xiàn)真他娘的貴，然后你就走人了。這段時(shí)間等你點(diǎn)菜的服務(wù)員就相當(dāng)于一個(gè)對應(yīng)的線程，你要點(diǎn)菜可以看作一個(gè)連接請求。

同時(shí)，每次建立連接后，當(dāng)線程調(diào)用讀寫方法時(shí)，線程會被阻塞，直到有數(shù)據(jù)可讀可寫， 在此期間線程不能做其它事情。還是上邊餐廳吃飯的例子，你出去轉(zhuǎn)了一圈發(fā)現(xiàn)還是這家性價(jià)比最高。回到這家餐廳又拿著菜單看了半天，服務(wù)員也在旁邊等你點(diǎn)完菜為止。這個(gè)過程中服務(wù)員什么也不能做，只能這么干等著，這個(gè)過程相當(dāng)于阻塞。

你看這樣的方式，每來一個(gè)請求就要分配一個(gè)線程，并且還得阻塞地等線程處理完。有的請求還只是過來連接下，什么操作也不干，還得為它分配一個(gè)線程，對服務(wù)器資源要求那得多高啊。遇到高并發(fā)場景，不敢想象。對于連接數(shù)目比較小的的固定架構(gòu)倒是可以考慮。

2、偽異步IO模型

你可能了解過一種通過線程池優(yōu)化的解決方案，采用線程池和任務(wù)隊(duì)列的方式。這種被稱作偽異步IO模型。

當(dāng)有客戶端接入時(shí)，將客戶端的請求封裝成一個(gè) task 投遞到后端線程池中來處理。線程池維護(hù)一個(gè)消息隊(duì)列和多個(gè)活躍線程，對消息隊(duì)列中的任務(wù)進(jìn)行處理。

這種解決方案，避免了為每個(gè)請求創(chuàng)建一個(gè)線程導(dǎo)致的線程資源耗盡問題。但是底層仍然是同步阻塞模型。如果線程池內(nèi)的所有線程都阻塞了，那么對于更多請求就無法響應(yīng)了。因此這種模式會限制最大連接數(shù)，并不能從根本上解決問題。

我們繼續(xù)用上邊的餐廳來舉例，餐廳老板在經(jīng)營了一段時(shí)間后，顧客多了起來，原本店里的5個(gè)服務(wù)員一對一服務(wù)的話根本對付不過來。于是老板采用5個(gè)人線程池的方式。服務(wù)員服務(wù)完一個(gè)客人后立刻去服務(wù)另一個(gè)。

這時(shí)問題出現(xiàn)了，有的客人點(diǎn)菜特別慢，服務(wù)員就得等待很長時(shí)間，直到客人點(diǎn)完為止。如果5個(gè)客人都點(diǎn)的特別慢的話，這5個(gè)服務(wù)員就得一直等下去，就會導(dǎo)致其余的顧客沒有人服務(wù)的狀態(tài)。這就是我們上邊所說的線程池所有線程都被阻塞的情況。

那么這種問題該如何解決呢?別急， Reactor 模式就要出場了。

3、Reactor設(shè)計(jì)模式

Reactor 模式的基本設(shè)計(jì)思想是基于I/O復(fù)用模型來實(shí)現(xiàn)的。

這里說下I/O復(fù)用模型。和傳統(tǒng)IO多線程阻塞不同，I/O復(fù)用模型中多個(gè)連接共用一個(gè)阻塞對象，應(yīng)用程序只需要在一個(gè)阻塞對象等待。當(dāng)某個(gè)連接有新的數(shù)據(jù)可以處理時(shí)，操作系統(tǒng)通知應(yīng)用程序，線程從阻塞狀態(tài)返回，開始進(jìn)行業(yè)務(wù)處理。

什么意思呢?餐廳老板也發(fā)現(xiàn)了顧客點(diǎn)餐慢的問題，于是他采用了一種大膽的方式，只留了一個(gè)服務(wù)員。當(dāng)客人點(diǎn)餐的時(shí)候，這個(gè)服務(wù)員就去招待別的客人，客人點(diǎn)好餐后直接喊服務(wù)員來進(jìn)行服務(wù)。這里的顧客和服務(wù)員可以分別看作多個(gè)連接和一個(gè)線程。服務(wù)員阻塞在一個(gè)顧客那里，當(dāng)有別的顧客點(diǎn)好餐后，她就立刻去服務(wù)其他的顧客。

了解了 reactor 的設(shè)計(jì)思想后，我們再來看下今天的主角單 reactor 單線程的實(shí)現(xiàn)方案：

Reactor 通過 I/O復(fù)用程序監(jiān)控客戶端請求事件，收到事件后通過任務(wù)分派器進(jìn)行分發(fā)。

針對建立連接請求事件，通過 Acceptor 處理，并建立對應(yīng)的 handler 負(fù)責(zé)后續(xù)業(yè)務(wù)處理。

針對非連接事件，Reactor 會調(diào)用對應(yīng)的 handler 完成 read->業(yè)務(wù)處理->write 處理流程，并將結(jié)果返回給客戶端。

整個(gè)過程都在一個(gè)線程里完成。

單線程時(shí)代

了解了 Reactor 模式后，你可能會有一個(gè)疑問，這個(gè)和我們今天的主題有什么關(guān)系呢?？赡苣悴恢赖氖?，Redis 是基于 Reactor 單線程模式來實(shí)現(xiàn)的。

IO多路復(fù)用程序接收到用戶的請求后，全部推送到一個(gè)隊(duì)列里，交給文件分派器。對于后續(xù)的操作，和在 reactor 單線程實(shí)現(xiàn)方案里看到的一樣，整個(gè)過程都在一個(gè)線程里完成，因此 Redis 被稱為是單線程的操作。

對于單線程的 Redis 來說，基于內(nèi)存，且命令操作時(shí)間復(fù)雜度低，因此讀寫速率是非?？斓摹?/p>

多線程時(shí)代

Redis6 版本中引入了多線程。上邊已經(jīng)提到過 Redis 單線程處理有著很快的速度，那為什么還要引入多線程呢?單線程的瓶頸在什么地方?

我們先來看第二個(gè)問題，在 Redis 中，單線程的性能瓶頸主要在網(wǎng)絡(luò)IO操作上。也就是在讀寫網(wǎng)絡(luò) read/write 系統(tǒng)調(diào)用執(zhí)行期間會占用大部分 CPU 時(shí)間。如果你要對一些大的鍵值對進(jìn)行刪除操作的話，在短時(shí)間內(nèi)是刪不完的，那么對于單線程來說就會阻塞后邊的操作。

回想下上邊講得 Reactor 模式中單線程的處理方式。針對非連接事件，Reactor 會調(diào)用對應(yīng)的 handler 完成 read->業(yè)務(wù)處理->write 處理流程，也就是說這一步會造成性能上的瓶頸。

Redis 在設(shè)計(jì)上采用將網(wǎng)絡(luò)數(shù)據(jù)讀寫和協(xié)議解析通過多線程的方式來處理，對于命令執(zhí)行來說，仍然使用單線程操作。

總結(jié)

Reactor模式

• 傳統(tǒng)阻塞IO模型客戶端與服務(wù)端線程1:1分配，不利于進(jìn)行擴(kuò)展。
• 偽異步IO模型采用線程池方式，但是底層仍然使用同步阻塞方式，限制了最大連接數(shù)。
• Reactor 通過 I/O復(fù)用程序監(jiān)控客戶端請求事件，通過任務(wù)分派器進(jìn)行分發(fā)。

單線程時(shí)代

基于 Reactor 單線程模式實(shí)現(xiàn)，通過IO多路復(fù)用程序接收到用戶的請求后，全部推送到一個(gè)隊(duì)列里，交給文件分派器進(jìn)行處理。

多線程時(shí)代 

• 單線程性能瓶頸主要在網(wǎng)絡(luò)IO上。
• 將網(wǎng)絡(luò)數(shù)據(jù)讀寫和協(xié)議解析通過多線程的方式來處理 ，對于命令執(zhí)行來說，仍然使用單線程操作。