Redis Big Key問題

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

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

帶來的問題

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

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

什么是 big key

• 字符串類型：一般認(rèn)為超過 10k 的就是 bigkey，但是這個(gè)值和具體的 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ù)庫中進(jìn)行分析統(tǒng)計(jì)，根據(jù)size_in_bytes統(tǒng)計(jì)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進(jìn)行類型判斷，例如：string長度大于10K，list長度大于10240認(rèn)為是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ù)量也很大，這個(gè)時(shí)候就要考慮這個(gè) key 使用的場景，存儲(chǔ)在redis集群中是否是合理的，是否使用其他組件來存儲(chǔ)更合適；如果堅(jiān)持要用 redis 來存儲(chǔ)，可能考慮遷移出集群，采用一主一備（或1主多備）的架構(gòu)來存儲(chǔ)。

單個(gè)簡單的key存儲(chǔ)的value很大

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

hash， set，zset，list 中存儲(chǔ)過多的元素

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

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

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

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

最新評論