Redis進行相關優化詳解

前言

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優化內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!

推薦閱讀: