Redis6.0 與之前版本的變化

多線程IO

Redis 6引入多線程IO，但多線程部分隻是用來處理網絡資料的讀寫和協定解析，執行指令仍然是單線程。之是以這麼設計是不想因為多線程而變得複雜，需要去控制 key、lua、事務，LPUSH/LPOP 等等的并發問題。

靈魂拷問

Redis6.0之前的版本真的是單線程嗎？

Redis在處理用戶端的請求時，包括擷取 (socket 讀)、解析、執行、内容傳回 (socket 寫) 等都由一個順序串行的主線程處理，這就是所謂的“單線程”。但如果嚴格來講從Redis4.0之後并不是單線程，除了主線程外，它也有背景線程在處理一些較為緩慢的操作，例如清理髒資料、無用連接配接的釋放、大 key 的删除等等。

Redis6.0之前為什麼一直不使用多線程？

​官方曾做過類似問題的回複：使用Redis時，幾乎不存在CPU成為瓶頸的情況， Redis主要受限于記憶體和網絡。例如在一個普通的Linux系統上，Redis通過使用pipelining每秒可以處理100萬個請求，是以如果應用程式主要使用O(N)或O(log(N))的指令，它幾乎不會占用太多CPU。

使用了單線程後，可維護性高。多線程模型雖然在某些方面表現優異，但是它卻引入了程式執行順序的不确定性，帶來了并發讀寫的一系列問題，增加了系統複雜度、同時可能存線上程切換、甚至加鎖解鎖、死鎖造成的性能損耗。Redis通過AE事件模型以及IO多路複用等技術，處理性能非常高，是以沒有必要使用多線程。單線程機制使得 Redis 内部實作的複雜度大大降低，Hash 的惰性 Rehash、Lpush 等等 “線程不安全” 的指令都可以無鎖進行。

Redis6.0為什麼要引入多線程呢？

​Redis将所有資料放在記憶體中，記憶體的響應時長大約為100納秒，對于小資料包，Redis伺服器可以處理80,000到100,000 QPS，這也是Redis處理的極限了，對于80%的公司來說，單線程的Redis已經足夠使用了。

但随着越來越複雜的業務場景，有些公司動不動就上億的交易量，是以需要更大的QPS。常見的解決方案是在分布式架構中對資料進行分區并采用多個伺服器，但該方案有非常大的缺點，例如要管理的Redis伺服器太多，維護代價大；某些适用于單個Redis伺服器的指令不适用于資料分區；資料分區無法解決熱點讀/寫問題；資料偏斜，重新配置設定和放大/縮小變得更加複雜等等。

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

• 提高網絡 IO 性能，典型的實作比如使用 DPDK 來替代核心網絡棧的方式

• 使用多線程充分利用多核，典型的實作比如 Memcached。

協定棧優化的這種方式跟 Redis 關系不大，支援多線程是一種最有效最便捷的操作方式。是以總結起來，redis支援多線程主要就是兩個原因：

• 可以充分利用伺服器 CPU 資源，目前主線程隻能利用一個核

• 多線程任務可以分攤 Redis 同步 IO 讀寫負荷

Redis6.0預設是否開啟了多線程？

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

Redis6.0多線程開啟時，線程數如何設定？

開啟多線程後，還需要設定線程數，否則是不生效的。同樣修改redis.conf配置檔案

​關于線程數的設定，官方有一個建議：4核的機器建議設定為2或3個線程，8核的建議設定為6個線程，線程數一定要小于機器核數。還需要注意的是，線程數并不是越大越好，官方認為超過了8個基本就沒什麼意義了。

重新設計了用戶端緩存功能

支援SSL

ACL權限控制

1. 支援對用戶端的權限控制，實作對不同的key授予不同的操作權限。
2. 有一個新的ACL日志指令，允許檢視所有違反ACL的客戶機、通路不應該通路的指令、通路不應該通路的密鑰，或者驗證嘗試失敗。這對于調試ACL問題非常有用。

提升了RDB日志加載速度