Redis 官方在 2020 年 5 月正式推出 6.0 版本，提供很多振奮人心的新特性，所以備受關注。
碼老溼，提供了啥特性呀？知道了我能加薪麼？
主要特性如下：
- 多執行緒處理網路 IO；
- 客戶端快取；
- 細粒度許可權控制（ACL）；
RESP3協議的使用；- 用於複製的 RDB 檔案不在有用，將立刻被刪除；
- RDB 檔案載入速度更快；
其中備受關注的就是「多執行緒模型 + 客戶端快取」，我們只有掌握了新特性原理，才能判斷什麼時候使用 6.0 版本，如何用的更好更快，不踩坑。
本篇先從 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 為什麼這麼快？》碼哥有詳細介紹快的原理。
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 多執行緒是如何實現協作呢？
如下圖：
主要流程：
- 主執行緒負責接收建立連線請求，獲取
socket放入全域性等待讀處理佇列； - 主執行緒通過輪詢將可讀
socket分配給 IO 執行緒； - 主執行緒阻塞等待 IO 執行緒讀取
socket完成； - 主執行緒執行 IO 執行緒讀取和解析出來的 Redis 請求命令；
- 主執行緒阻塞等待 IO 執行緒將指令執行結果回寫回
socket完畢； - 主執行緒清空全域性佇列，等待客戶端後續的請求。
思路：將主執行緒 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 效能。