1. 程式人生 > >Redis命令之效能問題解決方案

Redis命令之效能問題解決方案

使用規範
在這裡插入圖片描述
一、Hgetall 命令

應用介面中使用了大量的Hgetall命令從Redis中查詢資料資訊,導致Redis單例項OPS達到秒鐘7W次,Redis伺服器CPU使用率達到上限,遇到效能問題。
HGETALL key
時間複雜度:O(N)
返回 key 指定的雜湊集中所有的欄位和值。返回值中,每個欄位名的下一個是它的值,所以返回值的長度是雜湊集大小的兩倍
返回值
array-reply:雜湊集中欄位和值的列表。當 key 指定的雜湊集不存在時返回空列表。
在這裡插入圖片描述
通過官方文件,可以瞭解到命令HgetAll的時間複雜度為O(n)。這意味著Hash的field越多,當使用HgetAll獲取全量資料時,效能越差,該命令的效能與field欄位的數量成正比。
遇到問題後,上網查詢資料,解決方案大致兩種:

  1. 藉助MemCached
  2. 新增一個field欄位,將原Redis key對應的所有資料資訊全部儲存在該filed中,然後使用Hmget命令代替HgetAll
    但是以上兩種方案,均存在各種弊端,並沒有從根本上解決問題。找公司其他部門技術大拿交流,最終討論出以下方案解決問題:
    通過使用Redis dump命令獲取到Redis序列化後的值,獲取到的是位元組陣列。在應用中將該位元組陣列按照Redis協議自行解析成需要的HashMap資料。
    方案優點:
  3. dump命令的時間複雜度為O(1),效能優於HgetAll
  4. 將位元組陣列的解析由Redis伺服器轉移到了應用伺服器,減輕了Redis 伺服器CPU的運算壓力
  5. 充分利用了應用伺服器的CPU,並且應用伺服器方便擴容。
    DUMP key
    時間複雜度:O(1)
    序列化給定 key ,並返回被序列化的值,使用 RESTORE 命令可以將這個值反序列化為 Redis 鍵。
    序列化生成的值有以下幾個特點:
    它帶有 64 位的校驗和,用於檢測錯誤,RESTORE 在進行反序列化之前會先檢查校驗和。
    值的編碼格式和 RDB 檔案保持一致。
    RDB 版本會被編碼在序列化值當中,如果因為 Redis 的版本不同造成 RDB 格式不相容,那麼 Redis 會拒絕對這個值進行反序列化操作。
    序列化的值不包括任何生存時間資訊。
    返回值
    如果 key 不存在,那麼返回 nil。 否則,返回序列化之後的值。
    在這裡插入圖片描述

二、smembers 命令

SMEMBERS 命令是從一個 Set 結構獲取集合,但這個集合資料量已經很大,當這個結合被頻繁的呼叫,會極大的佔用網路 IO,當網路被佔滿時,其餘的操作也變得慢下來!
同時,查看了 Redis 的連線情況,發現連線數 1000 左右,保持的比較高,又重新檢視 Redis 的配置檔案!
配置檔案中 timeout = 0,這表明 Redis 預設不會斷開客戶端的連線,這造成的問題:已經無效的連線會造成網路 IO 的浪費!