Redis 官方在 2020 年 5 月正式推出 6.0 版本，提供很多振奮人心的新特性，所以備受關(guān)注。

提供了啥特性呀？知道了我能加薪么？

主要特性如下：

多線程處理網(wǎng)絡(luò) IO；

客戶端緩存；

細(xì)粒度權(quán)限控制（ACL）；

RESP3?協(xié)議的使用；

用于復(fù)制的 RDB 文件不在有用，將立刻被刪除；

RDB 文件加載速度更快；

其中備受關(guān)注的就是「多線程模型 + 客戶端緩存」，我們只有掌握了新特性原理，才能判斷什么時(shí)候使用 6.0 版本，如何用的更好更快，不踩坑。

本篇先從?Redis 多線程模型開始，至于客戶端緩存、等且聽下回分解。

Redis 6.0 之前為什么不使用多線程？

官方答復(fù)：

• 使用 Redis 時(shí)，幾乎不存在 CPU 成為瓶頸的情況， Redis 主要受限于內(nèi)存和網(wǎng)絡(luò)。

• 在一個(gè)普通的 Linux 系統(tǒng)上，Redis 通過使用pipelining?每秒可以處理 100 萬個(gè)請(qǐng)求，所以如果應(yīng)用程序主要使用 O(N) 或O(log(N)) 的命令，它幾乎不會(huì)占用太多 CPU。

• 使用了單線程后，可維護(hù)性高。多線程模型雖然在某些方面表現(xiàn)優(yōu)異，但是它卻引入了程序執(zhí)行順序的不確定性，帶來了并發(fā)讀寫的一系列問題，增加了系統(tǒng)復(fù)雜度、同時(shí)可能存在線程切換、甚至加鎖解鎖、死鎖造成的性能損耗。

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

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

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

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

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

其中執(zhí)行命令階段，由于 Redis 是單線程來處理命令的，所有每一條到達(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 的讀寫，也就是：單個(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?來替代內(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ì)帶來很多開發(fā)工作量。

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

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

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

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

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

架構(gòu)圖如下：

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

如下圖：

主要流程：

主線程負(fù)責(zé)接收建立連接請(qǐng)求，獲取?socket?放入全局等待讀處理隊(duì)列；

主線程通過輪詢將可讀?socket?分配給 IO 線程；

主線程阻塞等待 IO 線程讀取?socket?完成；

主線程執(zhí)行 IO 線程讀取和解析出來的 Redis 請(qǐng)求命令；

主線程阻塞等待 IO 線程將指令執(zhí)行結(jié)果回寫回?socket完畢；

主線程清空全局隊(duì)列，等待客戶端后續(xù)的請(qǐng)求。

思路：將主線程 IO 讀寫任務(wù)拆分出來給一組獨(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)為超過了 8 個(gè)基本就沒什么意義了。

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

io-threads 4

總結(jié)與思考

隨著互聯(lián)網(wǎng)的飛速發(fā)展，互聯(lián)網(wǎng)業(yè)務(wù)系統(tǒng)所要處理的線上流量越來越大，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ǎ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ù)僅僅是通過 socket 讀取客戶端請(qǐng)求命令并解析，卻沒有真正去執(zhí)行命令。

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

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

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的Redis 新特性篇：100% 掌握多线程模型的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。