[[411947]]

碼老濕，Redis 6.0 之前為什么不使用多線程?

官方答復(fù)：

• 使用 Redis 時(shí)，幾乎不存在 CPU 成為瓶頸的情況， Redis 主要受限于內(nèi)存和網(wǎng)絡(luò)。
• 在一個(gè)普通的 Linux 系統(tǒng)上，Redis 通過(guò)使用pipelining 每秒可以處理 100 萬(wàn)個(gè)請(qǐng)求，所以如果應(yīng)用程序主要使用 O(N) 或O(log(N)) 的命令，它幾乎不會(huì)占用太多 CPU。
• 使用了單線程后，可維護(hù)性高。多線程模型雖然在某些方面表現(xiàn)優(yōu)異，但是它卻引入了程序執(zhí)行順序的不確定性，帶來(lái)了并發(fā)讀寫的一系列問(wèn)題，增加了系統(tǒng)復(fù)雜度、同時(shí)可能存在線程切換、甚至加鎖解鎖、死鎖造成的性能損耗。

Redis 通過(guò) AE 事件模型以及 IO 多路復(fù)用等技術(shù)，處理性能非常高，因此沒(méi)有必要使用多線程。

單線程機(jī)制讓 Redis 內(nèi)部實(shí)現(xiàn)的復(fù)雜度大大降低，Hash 的惰性 Rehash、Lpush 等等『線程不安全』的命令都可以無(wú)鎖進(jìn)行。

在《Redis 為什么這么快?》碼哥有詳細(xì)介紹快的原理。

Redis 6.0 之前單線程指的是 Redis 只有一個(gè)線程干活么?

非也，Redis 在處理客戶端的請(qǐng)求時(shí)，包括獲取 (socket 讀)、解析、執(zhí)行、內(nèi)容返回 (socket 寫) 等都由一個(gè)順序串行的主線程處理，這就是所謂的「單線程」。

其中執(zhí)行命令階段，由于 Redis 是單線程來(lái)處理命令的，所有每一條到達(dá)服務(wù)端的命令不會(huì)立刻執(zhí)行，所有的命令都會(huì)進(jìn)入一個(gè) Socket 隊(duì)列中，當(dāng) socket 可讀則交給單線程事件分發(fā)器逐個(gè)被執(zhí)行。

此外，有些命令操作可以用后臺(tái)線程或子進(jìn)程執(zhí)行(比如數(shù)據(jù)刪除、快照生成、AOF 重寫)。

碼老濕，那 Redis 6.0 為啥要引入多線程呀?

隨著硬件性能提升，Redis 的性能瓶頸可能出現(xiàn)網(wǎng)絡(luò) IO 的讀寫，也就是：?jiǎn)蝹€(gè)線程處理網(wǎng)絡(luò)讀寫的速度跟不上底層網(wǎng)絡(luò)硬件的速度。

讀寫網(wǎng)絡(luò)的 read/write 系統(tǒng)調(diào)用占用了Redis 執(zhí)行期間大部分CPU 時(shí)間，瓶頸主要在于網(wǎng)絡(luò)的 IO 消耗, 優(yōu)化主要有兩個(gè)方向:

• 提高網(wǎng)絡(luò) IO 性能，典型的實(shí)現(xiàn)比如使用 DPDK來(lái)替代內(nèi)核網(wǎng)絡(luò)棧的方式。
• 使用多線程充分利用多核，提高網(wǎng)絡(luò)請(qǐng)求讀寫的并行度，典型的實(shí)現(xiàn)比如 Memcached。

添加對(duì)用戶態(tài)網(wǎng)絡(luò)協(xié)議棧的支持，需要修改 Redis 源碼中和網(wǎng)絡(luò)相關(guān)的部分(例如修改所有的網(wǎng)絡(luò)收發(fā)請(qǐng)求函數(shù))，這會(huì)帶來(lái)很多開發(fā)工作量。

而且新增代碼還可能引入新 Bug，導(dǎo)致系統(tǒng)不穩(wěn)定。

所以，Redis 采用多個(gè) IO 線程來(lái)處理網(wǎng)絡(luò)請(qǐng)求，提高網(wǎng)絡(luò)請(qǐng)求處理的并行度。

需要注意的是，Redis 多 IO 線程模型只用來(lái)處理網(wǎng)絡(luò)讀寫請(qǐng)求，對(duì)于 Redis 的讀寫命令，依然是單線程處理。

這是因?yàn)椋W(wǎng)絡(luò)處理經(jīng)常是瓶頸，通過(guò)多線程并行處理可提高性能。

而繼續(xù)使用單線程執(zhí)行讀寫命令，不需要為了保證 Lua 腳本、事務(wù)、等開發(fā)多線程安全機(jī)制，實(shí)現(xiàn)更簡(jiǎn)單。

架構(gòu)圖如下：

圖片來(lái)源：后端研究所

主線程與 IO 多線程是如何實(shí)現(xiàn)協(xié)作呢?

如下圖：

Redis多線程與IO線程

主要流程：

1. 主線程負(fù)責(zé)接收建立連接請(qǐng)求，獲取 socket 放入全局等待讀處理隊(duì)列;
2. 主線程通過(guò)輪詢將可讀 socket 分配給 IO 線程;
3. 主線程阻塞等待 IO 線程讀取 socket 完成;
4. 主線程執(zhí)行 IO 線程讀取和解析出來(lái)的 Redis 請(qǐng)求命令;
5. 主線程阻塞等待 IO 線程將指令執(zhí)行結(jié)果回寫回 socket完畢;
6. 主線程清空全局隊(duì)列，等待客戶端后續(xù)的請(qǐng)求。

思路：將主線程 IO 讀寫任務(wù)拆分出來(lái)給一組獨(dú)立的線程處理，使得多個(gè) socket 讀寫可以并行化，但是 Redis 命令還是主線程串行執(zhí)行。

如何開啟多線程呢?

Redis 6.0 的多線程默認(rèn)是禁用的，只使用主線程。如需開啟需要修改 redis.conf 配置文件：io-threads-do-reads yes。

碼老濕，線程數(shù)是不是越多越好?

當(dāng)然不是，關(guān)于線程數(shù)的設(shè)置，官方有一個(gè)建議：4 核的機(jī)器建議設(shè)置為 2 或 3 個(gè)線程，8核的建議設(shè)置為 6 個(gè)線程，線程數(shù)一定要小于機(jī)器核數(shù)。

線程數(shù)并不是越大越好，官方認(rèn)為超過(guò)了 8 個(gè)基本就沒(méi)什么意義了。

另外，開啟多線程后，還需要設(shè)置線程數(shù)，否則是不生效的。

io-threads 4 

總結(jié)與思考

隨著互聯(lián)網(wǎng)的飛速發(fā)展，互聯(lián)網(wǎng)業(yè)務(wù)系統(tǒng)所要處理的線上流量越來(lái)越大，Redis 的單線程模式會(huì)導(dǎo)致系統(tǒng)消耗很多 CPU 時(shí)間在網(wǎng)絡(luò) I/O 上從而降低吞吐量，要提升 Redis 的性能有兩個(gè)方向：

• 優(yōu)化網(wǎng)絡(luò) I/O 模塊
• 提高機(jī)器內(nèi)存讀寫的速度

后者依賴于硬件的發(fā)展，暫時(shí)無(wú)解。所以只能從前者下手，網(wǎng)絡(luò) I/O 的優(yōu)化又可以分為兩個(gè)方向：

• 零拷貝技術(shù)或者 DPDK 技術(shù)
• 利用多核優(yōu)勢(shì)

模型缺陷

Redis 的多線程網(wǎng)絡(luò)模型實(shí)際上并不是一個(gè)標(biāo)準(zhǔn)的 Multi-Reactors/Master-Workers模型。

Redis 的多線程方案中，I/O 線程任務(wù)僅僅是通過(guò) socket 讀取客戶端請(qǐng)求命令并解析，卻沒(méi)有真正去執(zhí)行命令。

所有客戶端命令最后還需要回到主線程去執(zhí)行，因此對(duì)多核的利用率并不算高，而且每次主線程都必須在分配完任務(wù)之后忙輪詢等待所有 I/O 線程完成任務(wù)之后才能繼續(xù)執(zhí)行其他邏輯。

在我看來(lái)，Redis 目前的多線程方案更像是一個(gè)折中的選擇：既保持了原系統(tǒng)的兼容性，又能利用多核提升 I/O 性能。