redis版本升級

參考：

https://www.cnblogs.com/vansky/p/9293961.html

https://www.cnblogs.com/gz666666/p/12901507.html

 

 

 

 

Redis4.0新特性

redis 4.0 新特性

Redis 4.0在2017年7月發布為GA。包含幾個重大改進：更好的復制（PSYNC2），線程DEL / FLUSH，混合RDB + AOF格式，活動內存碎片整理，內存使用和性能改進。目前小版本更新到4.0.6

一、主從數據同步機制

PSYNC2: 新的一種主從復制同步機制。

PSYNC1:2.8~4.0之前版本的同步為PSYNC1

1、psync1因為網絡中斷或者阻塞導致主從中斷，恢復后必須重新到主節點dump一份全量數據同步到從節點。psync2再中斷恢復后只需要同步復制延遲的那部分數據。

2、psync1在重啟從節點需要重新全量同步數據。psync2只部分同步增量數據。

3、在PSYNC1 當復制為鏈式復制的時候，如 A>B>C 主節點為A。當A出現問題，C節點不能正常復制B節點的數據。當提升B為主節點，C需要全量同步B的數據。在PSYNC2：PSYNC2解決了鏈式復制之間的關聯性。A出現問題不影響C節點，B提升為主C不需要全量同步。

4、在使用星形復制。如一主兩從。A>B , A>C  主節點為A。當A出現問題，B提升為主節點，C 重新指向主節點B。使用同步機制PSYNC2，C節點只做增量同步即可。在使用sentinel故障轉移可以較少數據重新同步的延遲時間，避免大redis同步出現的網絡帶寬占滿。

二、命令優化

線程DEL / FLUSH 優化

Redis現在可以在不同的線程中刪除后台的key而不會阻塞服務器。 新的`UNLINK`命令與`DEL`相同，但是以非阻塞的方式工作。但是在key過期的內部依然使用了DEL。 類似地，為了讓整個數據集或單個數據庫異步釋放，在“FLUSHALL”和“FLUSHDB”中添加了“ASYNC”選項。(手動清除大的key 可以使用unlink，不阻塞)

三、慢日志記錄客戶端來源IP地址，這個小功能對於故障排查很有用處。

四、混合RDB + AOF格式

混合RDB + AOF格式: 混合的RDB-AOF格式。 如果啟用，則在重寫AOF文件時使用新格式：重寫使用更緊湊和更快的方式來生成RDB格式，並將AOF流附加到文件。 這允許在使用AOF持久性時更快地重寫和重新加載。(目前相對於2.8沒啥用)

五、新的管理命令

1、MEMORY 能夠執行不同類型的內存分析：內存問題的故障排除（使用MEMORY DOCTOR，類似於LATENCY DOCTOR）,報告單個鍵使用的內存量，更深入地報告Redis內存使用情況 。

查看鍵值 使用 memory MEMORY USAGE key

memory統計分析 MEMORY STATS

MEMORY MALLOC-STATS

MEMORY PURGE

2、SWAPDB 能夠完全立即（無延遲）替換同實例下的兩個Redis數據庫(目前我們業務沒啥用)

六、

內存使用和性能改進:

1、Redis現在使用更少的內存來存儲相同數量的數據。

2、Redis現在可以對使用的內存進行碎片整理，並逐漸回收空間(這個功能依然是試用階段，可以通過參數不開啟即可)

 

以上列舉功能為4.0的重要更新，也是對我們目前redis大有改善，所列舉的功能已經和亞運測試過。業務上還沒有預發測試。

更多4.0版本信息  https://raw.githubusercontent.com/antirez/redis/4.0/00-RELEASENOTES

 

建議：新的邊緣業務redis上線使用redis4.0 。先進行預發功能連通測試。一段時間后，根據實際使用情況推進redis4.0更新。

 

 

 

 

 

 

 

 

Redis 6.0 多線程重磅發布！！！

Redis 6.0在5.2號這個美好的日子里悄無聲息的發布了，這次發布在IT圈猶如一顆驚雷一般，因為這是redis最大的一次改版，首次加入了多線程。

作者Antirez在RC1版本發布時在他的博客寫下：

the most “enterprise” Redis version to date // 最”企業級”的

the largest release of Redis ever as far as I can tell // 最大的

the one where the biggest amount of people participated // 參與人數最多的

這次改變，性能有個飛速的提升~

先po出新版和舊版性能圖

 

 

 

 

從上面可以看到 GET/SET 命令在 4 線程 IO 時性能相比單線程是幾乎是翻倍了。另外，這些數據只是為了簡單驗證多線程 IO 是否真正帶來性能優化，並沒有針對嚴謹的延時控制和不同並發的場景進行壓測。數據僅供驗證參考而不能作為線上指標，且只是目前的 unstble分支的性能，不排除后續發布的正式版本的性能會更好。

Redis 6.0 之前的版本真的是單線程嗎？

Redis基於Reactor模式開發了網絡事件處理器，這個處理器被稱為文件事件處理器。它的組成結構為4部分：多個套接字、IO多路復用程序、文件事件分派器、事件處理器。因為文件事件分派器隊列的消費是單線程的，所以Redis才叫單線程模型。

 

 

 

一般來說 Redis 的瓶頸並不在 CPU，而在內存和網絡。如果要使用 CPU 多核，可以搭建多個 Redis 實例來解決。

其實，Redis 4.0 開始就有多線程的概念了，比如 Redis 通過多線程方式在后台刪除對象、以及通過 Redis 模塊實現的阻塞命令等。

 

Redis 6.0 之前為什么一直不使用多線程？

使用了單線程后，可維護性高。多線程模型雖然在某些方面表現優異，但是它卻引入了程序執行順序的不確定性，帶來了並發讀寫的一系列問題，增加了系統復雜度、同時可能存在線程切換、甚至加鎖解鎖、死鎖造成的性能損耗。

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

單線程機制使得 Redis 內部實現的復雜度大大降低，Hash 的惰性 Rehash、Lpush 等等 “線程不安全” 的命令都可以無鎖進行。

Redis 6.0 為什么要引入多線程呢？

之前的段落說了，Redis 的瓶頸並不在 CPU，而在內存和網絡。

內存不夠的話，可以加內存或者做數據結構優化和其他優化等，但網絡的性能優化才是大頭，網絡 IO 的讀寫在 Redis 整個執行期間占用了大部分的 CPU 時間，如果把網絡處理這部分做成多線程處理方式，那對整個 Redis 的性能會有很大的提升。

優化方向：

• 提高網絡 IO 性能，典型的實現比如使用 DPDK 來替代內核網絡棧的方式。
• 使用多線程充分利用多核，典型的實現比如 Memcached。

所以總結起來，Redis 支持多線程主要就是兩個原因：

• 可以充分利用服務器 CPU 資源，目前主線程只能利用一個核。
• 多線程任務可以分攤 Redis 同步 IO 讀寫負荷。

Redis 6.0 默認是否開啟了多線程？

否，在conf文件進行配置

io-threads-do-reads yes

io-threads 線程數

官方建議：4 核的機器建議設置為 2 或 3 個線程，8 核的建議設置為 6 個線程，線程數一定要小於機器核數，盡量不超過8個。

Redis 6.0 多線程的實現機制？

 

 

流程簡述如下：

• 主線程負責接收建立連接請求，獲取 Socket 放入全局等待讀處理隊列。
• 主線程處理完讀事件之后，通過 RR（Round Robin）將這些連接分配給這些 IO 線程。
• 主線程阻塞等待 IO 線程讀取 Socket 完畢。
• 主線程通過單線程的方式執行請求命令，請求數據讀取並解析完成，但並不執行。
• 主線程阻塞等待 IO 線程將數據回寫 Socket 完畢。
• 解除綁定，清空等待隊列。

 

 

該設計有如下特點：

• IO 線程要么同時在讀 Socket，要么同時在寫，不會同時讀或寫。
• IO 線程只負責讀寫 Socket 解析命令，不負責命令處理。

開啟多線程后，是否會存在線程並發安全問題？

不會，Redis 的多線程部分只是用來處理網絡數據的讀寫和協議解析，執行命令仍然是單線程順序執行。

Redis 線程中經常提到 IO 多路復用，如何理解？

這是 IO 模型的一種，即經典的 Reactor 設計模式，有時也稱為異步阻塞 IO。

 

 

多路指的是多個 Socket 連接，復用指的是復用一個線程。多路復用主要有三種技術：Select，Poll，Epoll。

Epoll 是最新的也是目前最好的多路復用技術。采用多路 I/O 復用技術可以讓單個線程高效的處理多個連接請求（盡量減少網絡 IO 的時間消耗），且 Redis 在內存中操作數據的速度非常快（內存內的操作不會成為這里的性能瓶頸），主要以上兩點造就了 Redis 具有很高的吞吐量。