Redis 新特性篇：多線程模型解讀
點(diǎn)擊下方“IT牧場”，選擇“設(shè)為星標(biāo)”
Redis 官方在 2020 年 5 月正式推出 6.0 版本，提供很多振奮人心的新特性，所以備受關(guān)注。
?Redis 6.0提供了啥特性呀？知道了我能加薪么？
主要特性如下：
多線程處理網(wǎng)絡(luò) IO； 客戶端緩存； 細(xì)粒度權(quán)限控制（ACL）； RESP3協(xié)議的使用；用于復(fù)制的 RDB 文件不在有用，將立刻被刪除； RDB 文件加載速度更快；
其中備受關(guān)注的就是「多線程模型 + 客戶端緩存」，我們只有掌握了新特性原理，才能判斷什么時(shí)候使用 6.0 版本，如何用的更好更快，不踩坑。
本篇先從 Redis 多線程模型開始，至于客戶端緩存、等且聽下回分解。
最后，點(diǎn)擊下方卡片關(guān)注「碼哥字節(jié)」能加薪。
?碼老濕，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)?，網(wǎng)絡(luò)處理經(jīng)常是瓶頸，通過多線程并行處理可提高性能。
而繼續(xù)使用單線程執(zhí)行讀寫命令，不需要為了保證 Lua 腳本、事務(wù)、等開發(fā)多線程安全機(jī)制，實(shí)現(xià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)勢
模型缺陷
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 性能。
大家覺得有所幫助希望可以動(dòng)動(dòng)手指點(diǎn)贊、分享、收藏、留言呀。
干貨分享
最近將個(gè)人學(xué)習(xí)筆記整理成冊(cè)，使用PDF分享。關(guān)注我，回復(fù)如下代碼，即可獲得百度盤地址，無套路領(lǐng)??！
?001：《Java并發(fā)與高并發(fā)解決方案》學(xué)習(xí)筆記；?002：《深入JVM內(nèi)核——原理、診斷與優(yōu)化》學(xué)習(xí)筆記；?003：《Java面試寶典》?004：《Docker開源書》?005：《Kubernetes開源書》?006：《DDD速成（領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)速成）》?007：全部?008：加技術(shù)群討論
加個(gè)關(guān)注不迷路
喜歡就點(diǎn)個(gè)"在看"唄^_^