Redis Big Key問題

數(shù)據(jù)量大的 key ，由于其數(shù)據(jù)大小遠大于其他key，導(dǎo)致經(jīng)過分片之后，某個具體存儲這個 big key 的實例內(nèi)存使用量遠大于其他實例，造成內(nèi)存不足，拖累整個集群的使用。big key 在不同業(yè)務(wù)上，通常體現(xiàn)為不同的數(shù)據(jù)，比如：

• 論壇中的大型持久蓋樓活動；
• 聊天室系統(tǒng)中熱門聊天室的消息列表；

帶來的問題

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

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

什么是 big key

• 字符串類型：一般認為超過 10k 的就是 bigkey，但是這個值和具體的 OPS 相關(guān)。
• 非字符串類型：體現(xiàn)在哈希，列表，集合類型元素過多。

尋找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).

獲取生產(chǎn)Redis的rdb文件，通過rdbtools分析rdb生成csv文件，再導(dǎo)入MySQL或其他數(shù)據(jù)庫中進行分析統(tǒng)計，根據(jù)size_in_bytes統(tǒng)計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

優(yōu)化big key

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

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

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

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

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

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

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

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

到此這篇關(guān)于Redis Value過大問題(鍵值過大)的文章就介紹到這了,更多相關(guān)Redis 鍵值過大內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！