Redis進行相關優化詳解

2022-08-08 14:02:24

前言

Redis在專案中進行廣泛使用，那麼在日常的開發過程中，我們在使用Redis的過程中需要注意那些呢？本文將從三個維度來講解如何進行Redis的優化。

記憶體維度

控制key的長度

key的一般都是採用字串，而字串的底層資料結構為SDS，SDS 結構中會包含字串長度、分配空間大小等後設資料資訊，當key字串的長度增加時，SDS中的後設資料也會佔用更多記憶體空間，為了減少key的佔用空間，我們可用根據業務名來使用相應的英文縮寫來表示。例如user用u表示，message 用m來表示。

避免儲存bigkey

我們既要注意key的長度，同時也需要關注value的大小，Redis是使用單執行緒讀寫資料，bigkey 的讀寫操作會阻塞執行緒，降低Redis的處理效率。

如何查詢bigkey

我們可以通過--bigkey的命令來檢視Redis中所佔用的bigkey的資訊，具體的命令如下：

redis-cli -h 127.0.0.1 -p 6379 -a 'xxx' --bigkeys

從上述圖所示，我們可以檢視到Redis中的key佔用了32098個bytes，需要進行相關優化的。

建議：

如果key為string型別，建議value的存放值的大小為10KB左右。
如果key為List/Hash/Set/ZSet型別，建議存放元素的的數量控制在1萬以下。

選擇合適的資料型別

Redis提供了豐富的資料型別，對於存放的記憶體也做了相關優化。關乎資料結果的相關知識，可以參考之前的文章。

例如：String和set在儲存int資料時，會採用整數編碼儲存。Hash、ZSet在元素數量比較少時，會採用壓縮列表（ziplist）儲存，在儲存比較多的資料時，才會轉換為雜湊表和跳錶。

採用高效的序列化和壓縮方法

Redis中的字串都是使用二進位制安全的位元組陣列來儲存的，所以我們可以把業務的序列化成二進位制寫入Redis，但是採用不同的序列化，所佔用的空間大少不一樣。比如使用protostuff的序列化比java內建的序列化效率更高，佔用空間更少。針對json和xml資料格式的，可以採用gzip或者snappy演演算法對資料進行壓縮儲存，從而節省空間。

設定Redis最大記憶體和淘汰策略

我們根據業務的資料量提前預估記憶體大小，從而避免Redis的記憶體持續膨脹，導致佔用過多資源。

關於如何設定淘汰策略，需要集合實際的業務特性來選擇：

volatile-lru / allkeys-lru：優先保留最近存取過的資料
volatile-lfu / allkeys-lfu：優先保留存取次數最頻繁的資料
volatile-ttl ：優先淘汰即將過期的資料
volatile-random / allkeys-random：隨機淘汰資料

控制Redis範例的大小

Redis單範例的記憶體大小建議設定在2~6GB之間。因為無論是RDB快照，還是主從叢集進行資料同步，都能很快完成，不會阻塞正常請求的處理。

定時清除記憶體碎片

頻繁的新增修改會導致記憶體碎片的增多，因此需要及時清理記憶體碎片。

Redis提供了Info memory命令可以檢視記憶體使用資訊，具體如下：

說明：

used_memory_rss是作業系統實際分配給 Redis的實體記憶體空間。
used_memory 是 Redis 為了儲存資料實際申請使用的空間。
mem_fragmentation_ratio=used_memory_rss/ used_memory
mem_fragmentation_ratio 大於1但小於1.5。這種情況是合理的。
mem_fragmentation_ratio大於1.5 這表明記憶體碎片率已經超過了50%。一般情況下，這個時候，我們就需要採取一些措施來降低記憶體碎片率了。具體的記憶體清理措施，將在後續的文章中進行講解。

效能維度

禁止使用KEYS、FLUSHALL、FLUSHDB命令

KEYS 按照key內容進行匹配，返回符合匹配條件的鍵值對，該命令需要對Redis的全域性雜湊表進行全表掃描，嚴重阻塞 Redis主執行緒。
FLUSHALL 刪除Redis範例上的所有資料，如果資料量很大，會嚴重阻塞Redis主執行緒。
FLUSHDB，刪除當前資料庫中的資料，如果資料量很大，會阻塞Redis主執行緒。

優化建議

我們需要線上上要禁用這些命令。具體的做法是，管理員採用rename-command命令在組態檔中對這些命令進行重新命名，讓使用者端無法使用這些命令。

慎用全量操作的命令

對於集合型別的來說，在未清楚集合資料大小的情況下，慎用查詢集合中的全量資料，例如Hash的HetALL、Set的SMEMBERS命令、LRANGE key 0 -1 或者ZRANGE key 0 -1等命令，因為這些命令會對Hash或者Set型別的底層資料進行全量掃描，當集合資料量比較大時，會阻塞Redis的主執行緒。

優化建議：

當元素資料量較多時，可以用SSCAN、HSCAN 命令分批返回集合中的資料，減少對主執行緒的阻塞。

慎用複雜度過高命令

Redis執行復雜度過高的命令，會消耗更多的 CPU 資源，導致主執行緒中的其它請求只能等待。常見的複雜命令如下：SORT、SINTER、SINTERSTORE、ZUNIONSTORE、ZINTERSTORE 等聚合類命令。

優化建議：

當需要執行排序、交集、並集操作時，可以在使用者端完成，避免讓Redis進行過多計算，從而影響Redis效能。

設定合適的過期時間

Redis通常用於儲存熱資料。熱資料一般都有使用的時效性。所以，在資料儲存時，根據業務使用資料的時長，合理的設定資料的過期時間。否則寫入Redis的資料會一直佔用記憶體，如果資料持續增增長，會達到機器的記憶體上限，造成記憶體溢位，導致服務崩潰。

採用批次命令代替個命令

當我們需要一次性操作多個key時，可以使用批次命令來處理，批次命令可以減少使用者端與伺服器端的來回網路IO次數。

String或者Hash型別可以使用 MGET/MSET替代 GET/SET，HMGET/HMSET替代HGET/HSET
其它資料型別使用Pipeline命令，一次性打包傳送多個命令到伺服器端執行。

Pipeline具體使用：

redisTemplate.executePipelined(new RedisCallback<String>() {
            @Override
            public String doInRedis(RedisConnection connection) throws DataAccessException {
                for (int i = 0; i < 5; i++) 
                {
                    connection.set(("test:" + i).getBytes(), "test".getBytes());
                }
                return null;
            }
        });

高可用維度

按照業務部署不同的範例

不同的業務線來部署 Redis 範例，這樣當其中一個範例發生故障時，不會影響到其它業務。

避免單點問題

業務上根據實際情況採用主從、哨兵、叢集方案，避免單點故障，影響業務的正常使用。

合理的設定相關引數

針對主從環境，我們需要合理設定相關引數，具體內容如下：

合理的設定repl-backlog引數：如果repl-backlog設定過小，當寫流量比較大的場景下，主從複製中斷可能會引發全量複製資料的風險。
合理設定slave client-output-buffer-limit：當從庫複製發生問題時，過小的 buffer會導致從庫緩衝區溢位，從而導致複製中斷。

總結

本文對於Redis的如何優化從記憶體、效能、高可用等三個維度進行了詳細的講解，如有大家還有什麼優化建議歡迎提出，大家共同學習，共同進步。

到此這篇關於Redis進行相關優化的文章就介紹到這了,更多相關Redis優化內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！