這篇文章和大家一起了解下Redis6.0中的新功能。有一定的參考價值，有需要的朋友可以參考一下，希望對大家有幫助。
Redis 6.0 來了
Redis 6.0.0 穩定版（GA）終於發布，這個版本提供了許多令人心動的新特性及功能改進，例如新網路協定RESP3，新的叢集代理，ACL等，其中關注度最高的應該是“多執行緒”了，帶著眾多疑問，我們來一起開始“Redis 6.0 新特性” 。 【相關推薦：Redis影片教學】
1. Redis6.0之前的版本真的是單執行緒嗎？
Redis在處理客戶端的請求時，包括獲取(socket 讀)、解析、執行、內容返回(socket 寫) 等都由一個順序串行的主線程處理，這就是所謂的「單線程」。但如果嚴格來講從Redis4.0之後並不是單線程，除了主線程外，它也有後台線程在處理一些較為緩慢的操作，例如清理髒數據、無用連接的釋放、大 key 的刪除等等。
2. Redis6.0之前為什麼一直不使用多執行緒？
官方曾經做過類似問題的回應：使用Redis時，幾乎不存在CPU成為瓶頸的情況， Redis主要受限於記憶體和網路。例如在一個普通的Linux系統上，Redis透過使用pipelining每秒可以處理100萬個請求，所以如果應用程式主要使用O(N)或O(log(N))的命令，它幾乎不會佔用太多CPU。
使用了單執行緒後，可維護性高。多執行緒模型雖然在某些方面表現優異，但是它卻引入了程式執行順序的不確定性，帶來了並發讀寫的一系列問題，增加了系統複雜度、同時可能存在執行緒切換、甚至加鎖解鎖、死鎖造成的效能損耗。 Redis透過AE事件模型以及IO多路復用等技術，處理效能非常高，因此沒有必要使用多執行緒。單線程機制使得 Redis 內部實現的複雜度大大降低，Hash 的惰性 Rehash、Lpush 等等 “線程不安全” 的命令都可以無鎖進行。
3.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 讀寫負載
4.Redis6.0預設是否開啟了多執行緒？
Redis6.0的多執行緒預設是停用的，只使用主執行緒。如需開啟需要修改redis.conf設定檔：io-threads-do-reads yes
#5.Redis6.0多執行緒開啟時，執行緒數如何設定?
開啟多執行緒後，還需要設定執行緒數，否則是不生效的。同樣修改redis.conf配置文件
關於線程數的設置，官方有一個建議：4核的機器建議設置為2或3個線程，8核的建議設定為6個線程，線程數一定要小於機器核數。還要注意的是，線程數並不是越大越好，官方認為超過了8個基本就沒什麼意義了。
6.Redis6.0採用多執行緒後，效能的提升效果如何？
Redis 作者 antirez 在 RedisConf 2019分享時曾提到：Redis 6 引入的多執行緒 IO 特性對效能提升至少是一倍以上。國內也有大牛曾使用unstable版本在阿里雲esc進行過測試，GET/SET 命令在4線程 IO時性能相比單線程是幾乎是翻倍了。
測試環境：
Redis Server: 阿里雲Ubuntu 18.04，8 CPU 2.5 GHZ, 8G 內存，主機型號ecs.ic5.2xlarge
Redis Benchmark Client：阿里雲Ubuntu 18.04，8 2.5 GHZ CPU, 8G 內存，主機型號ecs.ic5.2xlarge
測試結果：
#詳見：https://zhuanlan.zhihu.com/p/76788470
說明1：這些效能驗證的測試並沒有針對嚴謹的延時控制和不同並發的場景進行壓測。數據僅供驗證參考而不能作為線上指標。
說明2：如果開啟多線程，至少要4核心的機器，且Redis實例已經佔用相當大的CPU耗時的時候才建議採用，否則使用多線程沒有意義。所以估計80%的公司開發人員看看就好。
7.Redis6.0多執行緒的實作機制？
流程簡述如下：
1、主執行緒負責接收建立連線請求，取得socket 放入全域等待讀取處理佇列
2、主執行緒處理完讀事件之後，透過RR(Round Robin) 將這些連線分配給這些IO 執行緒
3、主執行緒阻塞等待IO 執行緒讀取socket 完畢
4 、主執行緒透過單一執行緒的方式執行請求指令，請求資料讀取並解析完成，但不執行
5、主執行緒阻塞等待IO 執行緒將資料回寫socket 完畢
6、解除綁定，清空等待隊列
（圖片來源：https://ruby-china.org/topics/38957）
該設計有以下特點：
1、IO 線程要么同時在讀socket，要嘛同時寫，不會同時讀或寫
2、IO 執行緒只負責讀寫socket 解析指令，不負責指令處理
8.開啟多執行緒後，是否會存在線程並發安全性問題？
從上面的實作機制可以看出，Redis的多執行緒部分只是用來處理網路資料的讀寫和協定解析，執行指令仍然是單執行緒順序執行。所以我們不需要去考慮控制 key、lua、事務，LPUSH/LPOP 等等的並發及線程安全問題。
9.Linux環境上如何安裝Redis6.0.1（6.0的正式版是6.0.1）？
這個和安裝其他版本的redis沒有任何差別，整個流程跑下來也沒有任何的坑，所以這裡就不做描述了。唯一要注意的就是配置多執行緒數一定要小於cpu的核心數，查看核心數量指令：
[root@centos7.5 ~]# lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3
10.Redis6.0的多執行緒與Memcached多執行緒模型進行比較
前幾年memcached 是各大網路公司常用的快取方案，因此redis 和memcached 的區別基本上成了面試官快取方面必問的面試題，最近幾年memcached用的少了，基本都是redis。不過隨著Redis6.0加入了多執行緒特性，類似的問題可能還會出現，接下來我們只針對多執行緒模型來簡單比較一下。
如上圖所示：Memcached 伺服器採用 master-woker 模式進行工作，服務端採用 socket 與客戶端通訊。主線程、工作線程 採用 pipe管道進行通訊。主線程採用libevent 監聽listen、accept 的讀取事件，事件回應後將連接訊息的資料結構封裝起來，根據演算法選擇合適的工作線程，將連接任務攜帶連接訊息分發出去，相應的線程利用連接描述符建立與客戶端的socket連接並進行後續的存取資料操作。
Redis6.0與Memcached多執行緒模型比較：
相同點：都採用了master執行緒-worker 執行緒的模型
不同點：Memcached 執行主邏輯也是在worker 執行緒裡，模型更加簡單，實現了真正的執行緒隔離，符合我們對執行緒隔離的常規理解。而 Redis 把處理邏輯交還給 master 線程，雖然某種程度上增加了模型複雜度，但也解決了線程並發安全等問題。
11.Redis作者是如何點評 「多執行緒」這個新功能的？
關於多執行緒這個特性，在6.0 RC1時，Antirez曾經做過說明：
Redis支援多執行緒有2種可行的方式：第一種就是像「memcached」一樣，一個Redis實例開啟多個線程，從而提升GET/SET等簡單命令中每秒可以執行的操作。這涉及到I/O、命令解析等多線程處理，因此，我們將其稱之為“I/O threading”。另一種是允許在不同的執行緒中執行較耗時較慢的命令，以確保其它客戶端不會被阻塞，我們將這種執行緒模型稱為「Slow commands threading」。
經過深思熟慮，Redis不會採用“I/O threading”，redis在運行時主要受制於網絡和內存，所以提升redis性能主要是通過在多個redis實例，特別是redis集群。接下來我們主要會考慮改進兩個面向：
1.Redis叢集的多個實例透過編排能夠合理地使用本地實例的磁碟，避免同時重寫AOF。
2.提供一個Redis叢集代理，方便使用者在沒有較好的叢集協定客戶端時抽象化一個叢集。
補充說明一下，Redis和memcached一樣是記憶體系統，但不同於Memcached。多執行緒是複雜的，必須考慮使用簡單的資料模型，執行LPUSH的執行緒需要服務其他執行LPOP的執行緒。
我真正期望的實際上是“slow operations threading”，在redis6或redis7中，將提供“key-level locking”，使得線程可以完全獲得對鍵的控制以處理緩慢的操作。
詳見：http://antirez.com/news/126
12.Redis線程中經常提到IO多路復用，如何理解？
這是IO模型的一種，即經典的Reactor設計模式，有時也稱為非同步阻塞IO。 
多路指的是多個socket連接，複用指的是複用一個執行緒。多路復用主要有三種技術：select，poll，epoll。 epoll是最新的也是目前最好的多路復用技術。採用多路I/O 復用技術可以讓單一執行緒高效的處理多個連線請求（盡量減少網路IO的時間消耗），且Redis在記憶體中操作資料的速度非常快（記憶體內的操作不會成為這裡的效能瓶頸），主要以上兩點造就了Redis具有很高的吞吐量。
13.你知道Redis的彩蛋LOLWUT嗎？
這其實從Redis5.0就開始有了，但原諒我剛剛知道。作者是這麼描述這個功能的《LOLWUT: a piece of art inside a database command》，「資料庫指令中的一件藝術品」。你可以把它稱之為情懷，也可以稱之為彩蛋，具體是什麼，我就不透露了。和我一樣不清楚是什麼的小夥伴可以參考：http://antirez.com/news/123，每次運行都會隨機產生的噢。
更多程式相關知識，請造訪：程式設計入門！ ！
以上是Redis6.0中有哪些新特性？一起來看看吧！的詳細內容。更多資訊請關注PHP中文網其他相關文章！
