Redis 新特性篇：多線程模型解讀
碼老濕，Redis 6.0 之前為什么不使用多線程?
官方答復(fù)：
- 使用 Redis 時，幾乎不存在 CPU 成為瓶頸的情況， Redis 主要受限于內(nèi)存和網(wǎng)絡(luò)。
- 在一個普通的 Linux 系統(tǒng)上，Redis 通過使用pipelining 每秒可以處理 100 萬個請求，所以如果應(yīng)用程序主要使用 O(N) 或O(log(N)) 的命令，它幾乎不會占用太多 CPU。
- 使用了單線程后，可維護(hù)性高。多線程模型雖然在某些方面表現(xiàn)優(yōu)異，但是它卻引入了程序執(zhí)行順序的不確定性，帶來了并發(fā)讀寫的一系列問題，增加了系統(tǒng)復(fù)雜度、同時可能存在線程切換、甚至加鎖解鎖、死鎖造成的性能損耗。
Redis 通過 AE 事件模型以及 IO 多路復(fù)用等技術(shù)，處理性能非常高，因此沒有必要使用多線程。
單線程機(jī)制讓 Redis 內(nèi)部實(shí)現(xiàn)的復(fù)雜度大大降低，Hash 的惰性 Rehash、Lpush 等等『線程不安全』的命令都可以無鎖進(jìn)行。
在《Redis 為什么這么快?》碼哥有詳細(xì)介紹快的原理。
Redis 6.0 之前單線程指的是 Redis 只有一個線程干活么?
非也，Redis 在處理客戶端的請求時，包括獲取 (socket 讀)、解析、執(zhí)行、內(nèi)容返回 (socket 寫) 等都由一個順序串行的主線程處理，這就是所謂的「單線程」。
其中執(zhí)行命令階段，由于 Redis 是單線程來處理命令的，所有每一條到達(dá)服務(wù)端的命令不會立刻執(zhí)行，所有的命令都會進(jìn)入一個 Socket 隊(duì)列中，當(dāng) socket 可讀則交給單線程事件分發(fā)器逐個被執(zhí)行。
此外，有些命令操作可以用后臺線程或子進(jìn)程執(zhí)行(比如數(shù)據(jù)刪除、快照生成、AOF 重寫)。
碼老濕，那 Redis 6.0 為啥要引入多線程呀?
隨著硬件性能提升，Redis 的性能瓶頸可能出現(xiàn)網(wǎng)絡(luò) IO 的讀寫，也就是：單個線程處理網(wǎng)絡(luò)讀寫的速度跟不上底層網(wǎng)絡(luò)硬件的速度。
讀寫網(wǎng)絡(luò)的 read/write 系統(tǒng)調(diào)用占用了Redis 執(zhí)行期間大部分CPU 時間，瓶頸主要在于網(wǎng)絡(luò)的 IO 消耗, 優(yōu)化主要有兩個方向:
- 提高網(wǎng)絡(luò) IO 性能，典型的實(shí)現(xiàn)比如使用 DPDK來替代內(nèi)核網(wǎng)絡(luò)棧的方式。
- 使用多線程充分利用多核，提高網(wǎng)絡(luò)請求讀寫的并行度，典型的實(shí)現(xiàn)比如 Memcached。
添加對用戶態(tài)網(wǎng)絡(luò)協(xié)議棧的支持，需要修改 Redis 源碼中和網(wǎng)絡(luò)相關(guān)的部分(例如修改所有的網(wǎng)絡(luò)收發(fā)請求函數(shù))，這會帶來很多開發(fā)工作量。
而且新增代碼還可能引入新 Bug，導(dǎo)致系統(tǒng)不穩(wěn)定。
所以，Redis 采用多個 IO 線程來處理網(wǎng)絡(luò)請求，提高網(wǎng)絡(luò)請求處理的并行度。
需要注意的是，Redis 多 IO 線程模型只用來處理網(wǎng)絡(luò)讀寫請求，對于 Redis 的讀寫命令，依然是單線程處理。
這是因?yàn)?，網(wǎng)絡(luò)處理經(jīng)常是瓶頸，通過多線程并行處理可提高性能。
而繼續(xù)使用單線程執(zhí)行讀寫命令，不需要為了保證 Lua 腳本、事務(wù)、等開發(fā)多線程安全機(jī)制，實(shí)現(xiàn)更簡單。
架構(gòu)圖如下：
圖片來源：后端研究所
主線程與 IO 多線程是如何實(shí)現(xiàn)協(xié)作呢?
如下圖：
Redis多線程與IO線程
主要流程：
- 主線程負(fù)責(zé)接收建立連接請求，獲取 socket 放入全局等待讀處理隊(duì)列;
- 主線程通過輪詢將可讀 socket 分配給 IO 線程;
- 主線程阻塞等待 IO 線程讀取 socket 完成;
- 主線程執(zhí)行 IO 線程讀取和解析出來的 Redis 請求命令;
- 主線程阻塞等待 IO 線程將指令執(zhí)行結(jié)果回寫回 socket完畢;
- 主線程清空全局隊(duì)列，等待客戶端后續(xù)的請求。
思路：將主線程 IO 讀寫任務(wù)拆分出來給一組獨(dú)立的線程處理，使得多個 socket 讀寫可以并行化，但是 Redis 命令還是主線程串行執(zhí)行。
如何開啟多線程呢?
Redis 6.0 的多線程默認(rèn)是禁用的，只使用主線程。如需開啟需要修改 redis.conf 配置文件：io-threads-do-reads yes。
碼老濕，線程數(shù)是不是越多越好?
當(dāng)然不是，關(guān)于線程數(shù)的設(shè)置，官方有一個建議：4 核的機(jī)器建議設(shè)置為 2 或 3 個線程，8核的建議設(shè)置為 6 個線程，線程數(shù)一定要小于機(jī)器核數(shù)。
線程數(shù)并不是越大越好，官方認(rèn)為超過了 8 個基本就沒什么意義了。
另外，開啟多線程后，還需要設(shè)置線程數(shù)，否則是不生效的。
- io-threads 4
總結(jié)與思考
隨著互聯(lián)網(wǎng)的飛速發(fā)展，互聯(lián)網(wǎng)業(yè)務(wù)系統(tǒng)所要處理的線上流量越來越大，Redis 的單線程模式會導(dǎo)致系統(tǒng)消耗很多 CPU 時間在網(wǎng)絡(luò) I/O 上從而降低吞吐量，要提升 Redis 的性能有兩個方向：
- 優(yōu)化網(wǎng)絡(luò) I/O 模塊
- 提高機(jī)器內(nèi)存讀寫的速度
后者依賴于硬件的發(fā)展，暫時無解。所以只能從前者下手，網(wǎng)絡(luò) I/O 的優(yōu)化又可以分為兩個方向：
- 零拷貝技術(shù)或者 DPDK 技術(shù)
- 利用多核優(yōu)勢
模型缺陷
Redis 的多線程網(wǎng)絡(luò)模型實(shí)際上并不是一個標(biāo)準(zhǔn)的 Multi-Reactors/Master-Workers模型。
Redis 的多線程方案中，I/O 線程任務(wù)僅僅是通過 socket 讀取客戶端請求命令并解析，卻沒有真正去執(zhí)行命令。
所有客戶端命令最后還需要回到主線程去執(zhí)行，因此對多核的利用率并不算高，而且每次主線程都必須在分配完任務(wù)之后忙輪詢等待所有 I/O 線程完成任務(wù)之后才能繼續(xù)執(zhí)行其他邏輯。
在我看來，Redis 目前的多線程方案更像是一個折中的選擇：既保持了原系統(tǒng)的兼容性，又能利用多核提升 I/O 性能。
