Redis中的BigKey問題排查與解決思路詳解
摘要
Redis是一款性能強(qiáng)勁的內(nèi)存數(shù)據(jù)庫(kù),但是在使用過程中,我們可能會(huì)遇到Big Key問題,這個(gè)問題就是Redis中某個(gè)key的value過大,所以Big Key問題本質(zhì)是Big Value問題,導(dǎo)致Redis的性能下降或者崩潰。本文將向大家介紹如何排查和解決這個(gè)問題。
Big Key問題介紹
在Redis中,每個(gè)key都有一個(gè)對(duì)應(yīng)的value,如果某個(gè)key的value過大,就會(huì)導(dǎo)致Redis的性能下降或者崩潰,比玄學(xué)更玄學(xué),因?yàn)镽edis需要將大key全部加載到內(nèi)存中,這會(huì)占用大量的內(nèi)存空間,會(huì)降低Redis的響應(yīng)速度,這個(gè)問題被稱為Big Key問題。不要小看這個(gè)問題,它可是能讓你的Redis瞬間變成“烏龜”,由于Redis單線程的特性,操作Big Key的通常比較耗時(shí),也就意味著阻塞Redis可能性越大,這樣會(huì)造成客戶端阻塞或者引起故障切換,有可能導(dǎo)致“慢查詢”。
一般而言,下面這兩種情況被稱為大 key:
- String 類型的 key 對(duì)應(yīng)的value超過 10 MB。
- list、set、hash、zset等集合類型,集合元素個(gè)數(shù)超過 5000個(gè)。
以上對(duì) Big Key 的判斷標(biāo)準(zhǔn)并不是唯一,只是一個(gè)大體的標(biāo)準(zhǔn)。在實(shí)際業(yè)務(wù)開發(fā)中,對(duì) Big Key的判斷是需要根據(jù)具體的使用場(chǎng)景做不同的判斷。比如操作某個(gè) key 導(dǎo)致請(qǐng)求響應(yīng)時(shí)間變慢,那么這個(gè) key 就可以判定成 Big Key。
在Redis中,大key通常是由以下幾種原因?qū)е碌?/strong>:
- 對(duì)象序列化后的大小過大
- 存儲(chǔ)大量數(shù)據(jù)的容器,如set、list等
- 大型數(shù)據(jù)結(jié)構(gòu),如bitmap、hyperloglog等
如果不及時(shí)處理這些大key,它們會(huì)逐漸消耗Redis服務(wù)器的內(nèi)存資源,最終導(dǎo)致Redis崩潰。
Big Key問題排查
當(dāng)出現(xiàn)Redis性能急劇下降的情況時(shí),很可能是由于存在大key導(dǎo)致的。在排除大key問題時(shí),可以考慮采取以下幾種方法:
使用BIGKEYS命令
Redis自帶的 BIGKEYS 命令可以查詢當(dāng)前Redis中所有key的信息,對(duì)整個(gè)數(shù)據(jù)庫(kù)中的鍵值對(duì)大小情況進(jìn)行統(tǒng)計(jì)分析,比如說,統(tǒng)計(jì)每種數(shù)據(jù)類型的鍵值對(duì)個(gè)數(shù)以及平均大小。此外,這個(gè)命令執(zhí)行后,會(huì)輸出每種數(shù)據(jù)類型中最大的 bigkey 的信息,對(duì)于 String 類型來說,會(huì)輸出最大 bigkey 的字節(jié)長(zhǎng)度,對(duì)于集合類型來說,會(huì)輸出最大 bigkey 的元素個(gè)數(shù)
BIGKEYS
命令會(huì)掃描整個(gè)數(shù)據(jù)庫(kù),這個(gè)命令本身會(huì)阻塞Redis,找出所有的大鍵,并將其以一個(gè)列表的形式返回給客戶端。
命令格式如下:
$ redis-cli --bigkeys
返回示例如下:
# 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). [00.00%] Biggest string found so far 'a' with 3 bytes [05.14%] Biggest list found so far 'b' with 100004 items [35.77%] Biggest string found so far 'c' with 6 bytes [73.91%] Biggest hash found so far 'd' with 3 fields -------- summary ------- Sampled 506 keys in the keyspace! Total key length in bytes is 3452 (avg len 6.82) Biggest string found 'c' has 6 bytes Biggest list found 'b' has 100004 items Biggest hash found 'd' has 3 fields 504 strings with 1403 bytes (99.60% of keys, avg size 2.78) 1 lists with 100004 items (00.20% of keys, avg size 100004.00) 0 sets with 0 members (00.00% of keys, avg size 0.00) 1 hashs with 3 fields (00.20% of keys, avg size 3.00) 0 zsets with 0 members (00.00% of keys, avg size 0.00)
需要注意的是,由于BIGKEYS
命令需要掃描整個(gè)數(shù)據(jù)庫(kù),所以它可能會(huì)對(duì)Redis實(shí)例造成一定的負(fù)擔(dān)。在執(zhí)行這個(gè)命令之前,請(qǐng)確保您的Redis實(shí)例有足夠的資源來處理它,建議在從節(jié)點(diǎn)執(zhí)行。
Debug Object
如果我們找到了Big Key,就需要對(duì)其進(jìn)行進(jìn)一步的分析。我們可以使用命令debug object key
查看某個(gè)key的詳細(xì)信息,包括該key的value大小等。這時(shí)候你就可以“窺探”Redis的內(nèi)部,看看到底是哪個(gè)key太大了。
Debug Object 命令是一個(gè)調(diào)試命令,當(dāng) key 存在時(shí),返回有關(guān)信息。 當(dāng) key 不存在時(shí),返回一個(gè)錯(cuò)誤。
redis 127.0.0.1:6379> DEBUG OBJECT key Value at:0xb6838d20 refcount:1 encoding:raw serializedlength:9 lru:283790 lru_seconds_idle:150 redis 127.0.0.1:6379> DEBUG OBJECT key (error) ERR no such key
serializedlength表示key對(duì)應(yīng)的value序列化之后的字節(jié)數(shù)
memory usage
在Redis4.0之前,只能通過DEBUG OBJECT命令估算key的內(nèi)存使用(字段serializedlength),但DEBUG OBJECT命令是有誤差的。
4.0版本及以上,我們可以使用memory usag命令。
memory usage命令使用非常簡(jiǎn)單,直接按memory usage key名字;如果當(dāng)前key存在,則返回key的value實(shí)際使用內(nèi)存估算值;如果key不存在,則返回nil。
127.0.0.1:6379> set k1 value1 OK 127.0.0.1:6379> memory usage k1 //這里k1 value占用57字節(jié)內(nèi)存 (integer) 57 127.0.0.1:6379> memory usage aaa // aaa鍵不存在,返回nil. (nil)
對(duì)于除String類型之外的類型,memory usage命令采用抽樣的方式,默認(rèn)抽樣5個(gè)元素,所以計(jì)算是近似值,我們也可以指定抽樣的個(gè)數(shù)。
示例說明:生成一個(gè)100w個(gè)字段的hash鍵:hkey,每字段的value長(zhǎng)度是從1~1024字節(jié)的隨機(jī)值。
127.0.0.1:6379> hlen hkey // hkey有100w個(gè)字段,每個(gè)字段的value長(zhǎng)度介于1~1024個(gè)字節(jié) (integer) 1000000 127.0.0.1:6379> MEMORY usage hkey //默認(rèn)SAMPLES為5,分析hkey鍵內(nèi)存占用521588753字節(jié) (integer) 521588753 127.0.0.1:6379> MEMORY usage hkey SAMPLES 1000 //指定SAMPLES為1000,分析hkey鍵內(nèi)存占用617977753字節(jié) (integer) 617977753 127.0.0.1:6379> MEMORY usage hkey SAMPLES 10000 //指定SAMPLES為10000,分析hkey鍵內(nèi)存占用624950853字節(jié) (integer) 624950853
要想獲取key較精確的內(nèi)存值,就指定更大抽樣個(gè)數(shù)。但是抽樣個(gè)數(shù)越大,占用cpu時(shí)間分片就越大。
redis-rdb-tools
redis-rdb-tools 是一個(gè) python 的解析 rdb 文件的工具,在分析內(nèi)存的時(shí)候,我們主要用它生成內(nèi)存快照??梢园?rdb 快照文件生成 CSV 或 JSON 文件,也可以導(dǎo)入到 MySQL 生成報(bào)表來分析。
使用 PYPI 安裝
pip install rdbtools
生成內(nèi)存快照
rdb -c memory dump.rdb > memory.csv
在生成的 CSV 文件中有以下幾列:
database
key在Redis的dbtype
key類型key
key值size_in_bytes
key的內(nèi)存大小encoding
value的存儲(chǔ)編碼形式num_elements
key中的value的個(gè)數(shù)len_largest_element
key中的value的長(zhǎng)度
可以在MySQL中新建表然后導(dǎo)入進(jìn)行分析,然后可以直接通過SQL語句進(jìn)行查詢分析。
CREATE TABLE `memory` ( `database` int(128) DEFAULT NULL, `type` varchar(128) DEFAULT NULL, `KEY` varchar(128), `size_in_bytes` bigint(20) DEFAULT NULL, `encoding` varchar(128) DEFAULT NULL, `num_elements` bigint(20) DEFAULT NULL, `len_largest_element` varchar(128) DEFAULT NULL, PRIMARY KEY (`KEY`) );
例子:查詢內(nèi)存占用最高的3個(gè) key
mysql> SELECT * FROM memory ORDER BY size_in_bytes DESC LIMIT 3; +----------+------+-----+---------------+-----------+--------------+---------------------+ | database | type | key | size_in_bytes | encoding | num_elements | len_largest_element | +----------+------+-----+---------------+-----------+--------------+---------------------+ | 0 | set | k1 | 624550 | hashtable | 50000 | 10 | | 0 | set | k2 | 420191 | hashtable | 46000 | 10 | | 0 | set | k3 | 325465 | hashtable | 38000 | 10 | +----------+------+-----+---------------+-----------+--------------+---------------------+ 3 rows in set (0.12 sec)
Big Key問題解決思路
當(dāng)發(fā)現(xiàn)存在大key問題時(shí),我們需要及時(shí)采取措施來解決這個(gè)問題。下面列出幾種可行的解決思路:
分割大key
將Big Key拆分成多個(gè)小的key。這個(gè)方法比較簡(jiǎn)單,但是需要修改應(yīng)用程序的代碼。就像是把一個(gè)大蛋糕切成小蛋糕一樣,有點(diǎn)費(fèi)力,但是可以解決問題。
或者嘗試將Big Key轉(zhuǎn)換成Redis的數(shù)據(jù)結(jié)構(gòu)。例如,將Big Key轉(zhuǎn)換成Hash,List或者Set等數(shù)據(jù)結(jié)構(gòu)。
對(duì)象壓縮
如果大key的大小主要是由于對(duì)象序列化后的體積過大,我們可以考慮使用壓縮算法來減小對(duì)象的大小。Redis自身支持多種壓縮算法,例如LZF、Snappy等。
直接刪除
如果你使用的是Redis 4.0+的版本,可以直接使用 unlink命令去異步刪除。4.0以下的版本 可以考慮使用 scan ,分批次刪除。
無論采用哪種方法,都需要注意以下幾點(diǎn):
避免使用過大的value。如果需要存儲(chǔ)大量的數(shù)據(jù),可以將其拆分成多個(gè)小的value。就像是吃飯一樣,一口一口的吃,不要貪多嚼不爛。
避免使用不必要的數(shù)據(jù)結(jié)構(gòu)。例如,如果只需要存儲(chǔ)一個(gè)字符串,就不要使用Hash或者List等數(shù)據(jù)結(jié)構(gòu)。
定期清理過期的key。如果Redis中存在大量的過期key,就會(huì)導(dǎo)致Redis的性能下降。就像是家里的垃圾,需要定期清理。
對(duì)象壓縮
總結(jié)
Big Key問題是Redis中常見的問題之一,但是通過合理的排查和解決思路,我們可以有效地避免這個(gè)問題。在使用Redis時(shí),需要注意避免使用過大的value和不必要的數(shù)據(jù)結(jié)構(gòu),以及定期清理過期的key。
到此這篇關(guān)于Redis中的BigKey問題排查與解決思路詳解的文章就介紹到這了,更多相關(guān)Redis BigKey問題內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
為什么RedisCluster設(shè)計(jì)成16384個(gè)槽
本文主要介紹了為什么RedisCluster設(shè)計(jì)成16384個(gè)槽,文中通過示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2021-09-09Redis分布式鎖如何實(shí)現(xiàn)續(xù)期
這篇文章主要介紹了Redis分布式鎖如何實(shí)現(xiàn)續(xù)期的操作,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2022-01-01websocket+redis動(dòng)態(tài)訂閱和動(dòng)態(tài)取消訂閱的實(shí)現(xiàn)示例
本文主要介紹了websocket+redis動(dòng)態(tài)訂閱和動(dòng)態(tài)取消訂閱,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2022-05-05關(guān)于Redis數(shù)據(jù)庫(kù)三種持久化方案介紹
大家好,本篇文章主要講的是關(guān)于Redis數(shù)據(jù)庫(kù)三種持久化方案介紹,感興趣的同學(xué)趕快來看一看吧,對(duì)你有幫助的話記得收藏一下2022-01-01Redis數(shù)據(jù)結(jié)構(gòu)類型示例解析
這篇文章主要為大家介紹了Redis數(shù)據(jù)結(jié)構(gòu)類型示例解析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-02-02如何自定義redis工具jar包供其他SpringBoot項(xiàng)目直接使用
這篇文章主要介紹了如何自定義redis工具jar包供其他SpringBoot項(xiàng)目直接使用,本文通過實(shí)例代碼給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2021-03-03搭建單機(jī)Redis緩存服務(wù)的實(shí)現(xiàn)
本文主要介紹了搭建單機(jī)Redis緩存服務(wù)的實(shí)現(xiàn),文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-04-04