Redis 新特性篇：100% 掌握多線程模型

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

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

主要特性如下：

1. 多線程處理網絡 IO；
2. 用戶端緩存；
3. 細粒度權限控制（ACL）；
4. RESP3 協定的使用；
5. 用于複制的 RDB 檔案不在有用，将立刻被删除；
6. RDB 檔案加載速度更快；

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

相關視訊推薦：

大廠秋招面試必備-從redis應用以及原理說起

redis如何實作分布式鎖延時隊列以及限流應用

90分鐘搞定redis存儲結構原理

LinuxC++背景伺服器開發架構師免費學習位址

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

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

官方答複：

• 使用 Redis 時，幾乎不存在 CPU 成為瓶頸的情況， Redis 主要受限于記憶體和網絡。
• 在一個普通的 Linux 系統上，Redis 通過使用pipelining 每秒可以處理 100 萬個請求，是以如果應用程式主要使用 O(N) 或O(log(N)) 的指令，它幾乎不會占用太多 CPU。
• 使用了單線程後，可維護性高。多線程模型雖然在某些方面表現優異，但是它卻引入了程式執行順序的不确定性，帶來了并發讀寫的一系列問題，增加了系統複雜度、同時可能存線上程切換、甚至加鎖解鎖、死鎖造成的性能損耗。

Redis 通過 AE 事件模型以及 IO 多路複用等技術，處理性能非常高，是以沒有必要使用多線程。

單線程機制讓 Redis 内部實作的複雜度大大降低，Hash 的惰性 Rehash、Lpush 等等『線程不安全』的指令都可以無鎖進行。

Redis 6.0 之前單線程指的是 Redis 隻有一個線程幹活麼？

非也，Redis 在處理用戶端的請求時，包括擷取 (socket 讀)、解析、執行、内容傳回 (socket 寫) 等都由一個順序串行的主線程處理，這就是所謂的「單線程」。

其中執行指令階段，由于 Redis 是單線程來處理指令的，所有每一條到達服務端的指令不會立刻執行，所有的指令都會進入一個 Socket 隊列中，當 socket 可讀則交給單線程事件分發器逐個被執行。

此外，有些指令操作可以用背景線程或子程序執行（比如資料删除、快照生成、AOF 重寫）。

【文章福利】：小編整理了一些個人覺得比較好的學習書籍、視訊資料共享在群檔案裡面，有需要的可以自行添加哦！~點選加入（需要自取）

那 Redis 6.0 為啥要引入多線程呀？

随着硬體性能提升，Redis 的性能瓶頸可能出現網絡 IO 的讀寫，也就是：單個線程處理網絡讀寫的速度跟不上底層網絡硬體的速度。

讀寫網絡的 read/write 系統調用占用了Redis 執行期間大部分CPU 時間，瓶頸主要在于網絡的 IO 消耗, 優化主要有兩個方向:

• 提高網絡 IO 性能，典型的實作比如使用 DPDK 來替代核心網絡棧的方式。
• 使用多線程充分利用多核，提高網絡請求讀寫的并行度，典型的實作比如 Memcached。

添加對使用者态網絡協定棧的支援，需要修改 Redis 源碼中和網絡相關的部分（例如修改所有的網絡收發請求函數），這會帶來很多開發工作量。

而且新增代碼還可能引入新 Bug，導緻系統不穩定。

是以，Redis 采用多個 IO 線程來處理網絡請求，提高網絡請求處理的并行度。

需要注意的是，Redis 多 IO 線程模型隻用來處理網絡讀寫請求，對于 Redis 的讀寫指令，依然是單線程處理。

這是因為，網絡處理經常是瓶頸，通過多線程并行處理可提高性能。

而繼續使用單線程執行讀寫指令，不需要為了保證 Lua 腳本、事務、等開發多線程安全機制，實作更簡單。

架構圖如下：

主線程與 IO 多線程是如何實作協作呢？

如下圖：

主要流程：

1. 主線程負責接收建立連接配接請求，擷取 socket 放入全局等待讀處理隊列；
2. 主線程通過輪詢将可讀 socket 配置設定給 IO 線程；
3. 主線程阻塞等待 IO 線程讀取 socket 完成；
4. 主線程執行 IO 線程讀取和解析出來的 Redis 請求指令；
5. 主線程阻塞等待 IO 線程将指令執行結果回寫回 socket完畢；
6. 主線程清空全局隊列，等待用戶端後續的請求。

思路：将主線程 IO 讀寫任務拆分出來給一組獨立的線程處理，使得多個 socket 讀寫可以并行化，但是 Redis 指令還是主線程串行執行。

如何開啟多線程呢？

Redis 6.0 的多線程預設是禁用的，隻使用主線程。如需開啟需要修改 redis.conf 配置檔案：io-threads-do-reads yes。

線程數是不是越多越好？

當然不是，關于線程數的設定，官方有一個建議：4 核的機器建議設定為 2 或 3 個線程，8核的建議設定為 6 個線程，線程數一定要小于機器核數。

線程數并不是越大越好，官方認為超過了 8 個基本就沒什麼意義了。

另外，開啟多線程後，還需要設定線程數，否則是不生效的。

io-threads 4

總結與思考

随着網際網路的飛速發展，網際網路業務系統所要處理的線上流量越來越大，Redis 的單線程模式會導緻系統消耗很多 CPU 時間在網絡 I/O 上進而降低吞吐量，要提升 Redis 的性能有兩個方向：

• 優化網絡 I/O 子產品
• 提高機器記憶體讀寫的速度

後者依賴于硬體的發展，暫時無解。是以隻能從前者下手，網絡 I/O 的優化又可以分為兩個方向：

• 零拷貝技術或者 DPDK 技術
• 利用多核優勢

模型缺陷

Redis 的多線程網絡模型實際上并不是一個标準的 Multi-Reactors/Master-Workers 模型。

Redis 的多線程方案中，I/O 線程任務僅僅是通過 socket 讀取用戶端請求指令并解析，卻沒有真正去執行指令。

所有用戶端指令最後還需要回到主線程去執行，是以對多核的使用率并不算高，而且每次主線程都必須在配置設定完任務之後忙輪詢等待所有 I/O 線程完成任務之後才能繼續執行其他邏輯。

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