Redis Value過大問題 鍵值過大

Redis Big Key問題

數據量大的 key ，由於其數據大小遠大於其他key，導致經過分片之後，某個具體存儲這個 big key 的實例內存使用量遠大於其他實例，造成內存不足，拖累整個集羣的使用。big key 在不同業務上，通常體現爲不同的數據，比如：

1. 論壇中的大型持久蓋樓活動；
2. 聊天室系統中熱門聊天室的消息列表；

帶來的問題

bigkey 通常會導致內存空間不平衡，超時阻塞，如果 key 較大，redis 又是單線程，操作 bigkey 比較耗時，那麼阻塞 redis 的可能性增大。每次獲取 bigKey 的網絡流量較大，假設一個 bigkey 爲 1MB,每秒訪問量爲 1000，那麼每秒產生 1000MB 的流量，對於普通千兆網卡，按照字節算 128M/S 的服務器來說可能扛不住。而且一般服務器採用單機多實例方式來部署，所以還可能對其他實例造成影響。

1. 如果是集羣模式下，無法做到負載均衡，導致請求傾斜到某個實例上，而這個實例的QPS會比較大，內存佔用也較多；對於Redis單線程模型又容易出現CPU瓶頸，當內存出現瓶頸時，只能進行縱向庫容，使用更牛逼的服務器。
2. 涉及到大key的操作，尤其是使用hgetall、lrange、get、hmget 等操作時，網卡可能會成爲瓶頸，也會到導致堵塞其它操作，qps 就有可能出現突降或者突升的情況，趨勢上看起來十分不平滑，嚴重時會導致應用程序連不上，實例或者集羣在某些時間段內不可用的狀態。
3. 假如這個key需要進行刪除操作，如果直接進行DEL 操作，被操作的實例會被Block住，導致無法響應應用的請求，而這個Block的時間會隨着key的變大而變長。

什麼是 big key

1. 字符串類型：一般認爲超過 10k 的就是 bigkey，但是這個值和具體的 OPS 相關。
2. 非字符串類型：體現在哈希，列表，集合類型元素過多。

尋找big key

1. redis-cli自帶--bigkeys。

   1 2	$ 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).

2. 獲取生產Redis的rdb文件，通過rdbtools分析rdb生成csv文件，再導入MySQL或其他數據庫中進行分析統計，根據size_in_bytes統計bigkey

   1 2 3 4

   $ 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

3. 通過python腳本，迭代scan key，每次scan 1000，對掃描出來的key進行類型判斷，例如：string長度大於10K，list長度大於10240認爲是big bigkeys

4. 其他第三方工具，例如：redis-rdb-cli

優化big key

優化big key的原則就是string減少字符串長度，list、hash、set、zset等減少成員數。

1. string類型的big key，建議不要存入redis，用文檔型數據庫MongoDB代替或者直接緩存到CDN上等方式優化。有些 key 不只是訪問量大，數據量也很大，這個時候就要考慮這個 key 使用的場景，存儲在redis集羣中是否是合理的，是否使用其他組件來存儲更合適；如果堅持要用 redis 來存儲，可能考慮遷移出集羣，採用一主一備（或1主多備）的架構來存儲。

2. 單個簡單的key存儲的value很大

   該對象需要每次都整存整取: 可以嘗試將對象分拆成幾個key-value， 使用multiGet獲取值，這樣分拆的意義在於分拆單次操作的壓力，將操作壓力平攤到多個redis實例中，降低對單個redis的IO影響；
   該對象每次只需要存取部分數據: 可以像第一種做法一樣，分拆成幾個key-value，也可以將這個存儲在一個hash中，每個field代表一個具體的屬性，使用hget,hmget來獲取部分的value，使用hset，hmset來更新部分屬性。

3. hash， set，zset，list 中存儲過多的元素

   可以將這些元素分拆。以hash爲例，原先的正常存取流程是 hget(hashKey, field) ; hset(hashKey, field, value)
   現在，固定一個桶的數量，比如 10000， 每次存取的時候，先在本地計算field的hash值，模除 10000，確定了該field落在哪個key上。

1 2 3

newHashKey = hashKey + (hash(field) % 10000）; hset(newHashKey, field, value) ; hget(newHashKey, field)

set, zset, list 也可以類似上述做法。但有些不適合的場景，比如，要保證 lpop 的數據的確是最早push到list中去的，這個就需要一些附加的屬性，或者是在 key的拼接上做一些工作（比如list按照時間來分拆）。