Redis Value過大問題(鍵值過大)
Redis Big Key問題
資料量大的 key ，由於其資料大小遠大於其他key，導致經過分片之後，某個具體儲存這個 big key 的例項記憶體使用量遠大於其他例項，造成記憶體不足，拖累整個叢集的使用。big key 在不同業務上，通常體現為不同的資料，比如：
- 論壇中的大型持久蓋樓活動；
- 聊天室系統中熱門聊天室的訊息列表；
帶來的問題
bigkey 通常會導致記憶體空間不平衡，超時阻塞，如果 key 較大，redis 又是單執行緒，操作 bigkey 比較耗時，那麼阻塞 redis 的可能性增大。每次獲取 bigKey 的網路流量較大，假設一個 bigkey 為 1MB,每秒訪問量為 1000，那麼每秒產生 1000MB 的流量，對於普通千兆網絡卡，按照位元組算 128M/S 的伺服器來說可能扛不住。而且一般伺服器採用單機多例項方式來部署，所以還可能對其他例項造成影響。
- 如果是叢集模式下，無法做到負載均衡，導致請求傾斜到某個例項上，而這個例項的QPS會比較大，記憶體佔用也較多；對於Redis單執行緒模型又容易出現CPU瓶頸，當記憶體出現瓶頸時，只能進行縱向庫容，使用更牛逼的伺服器。
- 涉及到大key的操作，尤其是使用hgetall、lrange、get、hmget 等操作時，網絡卡可能會成為瓶頸，也會到導致堵塞其它操作，qps 就有可能出現突降或者突升的情況，趨勢上看起來十分不平滑，嚴重時會導致應用程式連不上，例項或者叢集在某些時間段內不可用的狀態。
- 假如這個key需要進行刪除操作，如果直接進行DEL 操作，被操作的例項會被Block住，導致無法響應應用的請求，而這個Block的時間會隨著key的變大而變長。
什麼是 big key
- 字串型別：一般認為超過 10k 的就是 bigkey，但是這個值和具體的 OPS 相關。
- 非字串型別：體現在雜湊，列表，集合型別元素過多。
尋找big key
redis-cli自帶--bigkeys。
$ redis-cli -p 999 --bigkeys -i 0.1 #Scanning the entire keyspace to find biggest keys as well as average sizes per key type. You can use -i 0.1 to sleep 0.1 sec per 100 SCAN commands (not usually needed).
獲取生產Redis的rdb檔案，通過rdbtools分析rdb生成csv檔案，再匯入MySQL或其他資料庫中進行分析統計，根據size_in_bytes統計bigkey
$ git clone https://github.com/sripathikrishnan/redis-rdb-tools $ cd redis-rdb-tools $ sudo python setup.py install $ rdb -c memory dump-10030.rdb > memory.csv
通過python指令碼，迭代scan key，每次scan 1000，對掃描出來的key進行型別判斷，例如：string長度大於10K，list長度大於10240認為是big bigkeys
其他第三方工具，例如：redis-rdb-cli
優化big key
優化big key的原則就是string減少字串長度，list、hash、set、zset等減少成員數。
string型別的big key，建議不要存入redis，用文件型資料庫MongoDB代替或者直接快取到CDN上等方式優化。有些 key 不只是訪問量大，資料量也很大，這個時候就要考慮這個 key 使用的場景，儲存在redis叢集中是否是合理的，是否使用其他元件來儲存更合適；如果堅持要用 redis 來儲存，可能考慮遷移出叢集，採用一主一備（或1主多備）的架構來儲存。
單個簡單的key儲存的value很大
該物件需要每次都整存整取: 可以嘗試將物件分拆成幾個key-value， 使用multiGet獲取值，這樣分拆的意義在於分拆單次操作的壓力，將操作壓力平攤到多個redis例項中，降低對單個redis的IO影響；
該物件每次只需要存取部分資料: 可以像第一種做法一樣，分拆成幾個key-value，也可以將這個儲存在一個hash中，每個field代表一個具體的屬性，使用hget,hmget來獲取部分的value，使用hset，hmset來更新部分屬性。
hash， set，zset，list 中儲存過多的元素
可以將這些元素分拆。以hash為例，原先的正常存取流程是 hget(hashKey,field) ; hset(hashKey,field,value)
現在，固定一個桶的數量，比如 10000， 每次存取的時候，先在本地計算field的hash值，模除 10000，確定了該field落在哪個key上。
newHashKey = hashKey + (hash(field) % 10000）; hset(newHashKey,value) ; hget(newHashKey,field)
set,zset,list 也可以類似上述做法。但有些不適合的場景，比如，要保證 lpop 的資料的確是最早push到list中去的，這個就需要一些附加的屬性，或者是在 key的拼接上做一些工作（比如list按照時間來分拆）。
到此這篇關於Redis Value過大問題(鍵值過大)的文章就介紹到這了,更多相關Redis 鍵值過大內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！