Redis 官方在 2020 年 5 月正式推出 6.0 版本职员，提供很多振奮人心的新特性造锅，所以備受關(guān)注。
碼老濕廉邑，提供了啥特性呀？知道了我能加薪么倒谷？
主要特性如下：
- 多線程處理網(wǎng)絡(luò) IO蛛蒙；
- 客戶端緩存；
- 細(xì)粒度權(quán)限控制（ACL）渤愁；
- RESP3 協(xié)議的使用牵祟；
- 用于復(fù)制的 RDB 文件<typo id="typo-152" data-origin="不在" ignoretag="true">不在</typo>有用，將立刻被刪除抖格；
- RDB 文件加載速度更快诺苹；
其中備受關(guān)注的就是「多線程模型 + 客戶端緩存」咕晋，我們只有掌握了新特性原理，才能判斷什么時(shí)候使用 6.0 版本收奔，如何用<typo id="typo-241" data-origin="的" ignoretag="true">的</typo>更好更快掌呜，不踩坑。
本篇先從 Redis 多線程模型開始坪哄，至于客戶端緩存质蕉、等且聽下回分解。
碼老濕翩肌，Redis 6.0 之前為什么不使用多線程模暗？
官方答復(fù)：
- 使用 Redis 時(shí)，幾乎不存在 CPU 成為瓶頸的情況念祭， Redis 主要受限于內(nèi)存和網(wǎng)絡(luò)兑宇。
- 在一個(gè)普通的 Linux 系統(tǒng)上，Redis 通過使用pipelining 每秒可以處理 100 萬個(gè)請求粱坤，所以如果應(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 6.0 之前單線程指的是 Redis 只有一個(gè)線程干活么贷岸？
非也壹士，Redis 在處理客戶端的請求時(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í)行。
此外凡泣，有些命令操作可以用后臺線程或子進(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ò)請求讀寫的并行度乖杠，典型的實(shí)現(xiàn)比如 Memcached。
添加對用戶態(tài)網(wǎng)絡(luò)協(xié)議棧的支持澄成，需要修改 Redis 源碼中和網(wǎng)絡(luò)相關(guān)的部分（例如修改所有的網(wǎng)絡(luò)收發(fā)請求函數(shù)）胧洒，這會(huì)帶來很多開發(fā)工作量。
而且新增代碼還可能引入新 Bug墨状，導(dǎo)致系統(tǒng)不穩(wěn)定卫漫。
所以，Redis 采用多個(gè) IO 線程來處理網(wǎng)絡(luò)請求肾砂，提高網(wǎng)絡(luò)請求處理的并行度列赎。
需要注意的是，Redis 多 IO 線程模型只用來處理網(wǎng)絡(luò)讀寫請求镐确，對于 Redis 的讀寫命令包吝，依然是單線程處理。
這是因?yàn)樵春W(wǎng)絡(luò)處理經(jīng)常是瓶頸诗越，通過多線程并行處理可提高性能。
而繼續(xù)使用單線程執(zhí)行讀寫命令臼氨，不需要為了保證 Lua 腳本、事務(wù)芭届、等開發(fā)多線程安全機(jī)制储矩，實(shí)現(xiàn)更簡單感耙。
架構(gòu)圖如下：
主線程與 IO 多線程是如何實(shí)現(xiàn)協(xié)作呢？
如下圖：
主要流程：
- 主線程負(fù)責(zé)接收建立連接請求持隧，獲取 socket 放入全局等待讀處理隊(duì)列即硼；
- 主線程通過輪詢將可讀 socket 分配給 IO 線程；
- 主線程阻塞等待 IO 線程讀取 socket 完成屡拨；
- 主線程執(zhí)行 IO 線程讀取和解析出來的 Redis 請求命令只酥；
- 主線程阻塞等待 IO 線程將指令執(zhí)行結(jié)果回寫回 socket完畢；
- 主線程清空全局隊(duì)列呀狼，等待客戶端后續(xù)的請求裂允。
思路：將主線程 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 讀取客戶端請求命令并解析，卻沒有真正去執(zhí)行命令欧穴。
所有客戶端命令最后還需要回到主線程去執(zhí)行民逼，因此對多核的利用率并不算高，而且每次主線程都必須在分配完任務(wù)之后忙輪詢等待所有 I/O 線程完成任務(wù)之后才能繼續(xù)執(zhí)行其他邏輯涮帘。
在我看來拼苍，Redis 目前的多線程方案更像是一個(gè)折中的選擇：既保持了原系統(tǒng)的兼容性，又能利用多核提升 I/O 性能调缨。
