解決了 Redis 大 key 問題，同事們都說牛皮！

今天跟大家分享下，線上如何解決 Redis 中大 key 的方問題。

什么是大key

很多朋友肯定在想redis的key能有多大呀？

這里就有個(gè)誤區(qū)了，所謂的大key問題是某個(gè)key的value比較大，所以本質(zhì)上是大value問題。

“

這樣就對上了，key往往是程序可以自行設(shè)置的，value往往不受程序控制，因此可能導(dǎo)致value很大。

設(shè)想一種場景：

“

在線音樂app中，某個(gè)歌單有很多用戶收藏，假如有這樣的數(shù)據(jù)結(jié)構(gòu)：

• 歌單和用戶之間的映射關(guān)系采用redis存儲(chǔ)
• redis的key是歌單ID，長度可控且很小
• redis的value是個(gè)list，list包含了用戶ID
• 用戶可能很多，就導(dǎo)致list長度不可控

這下明白啥是大key問題了吧！

redis中有常見的幾種數(shù)據(jù)結(jié)構(gòu)，每種結(jié)構(gòu)對大key的定義不同，比如：

• value是String類型時(shí)，size超過10KB
• value是ZSET、Hash、List、Set等集合類型時(shí)，它的成員數(shù)量超過1w個(gè)

上述的定義并不絕對，主要是根據(jù)value的成員數(shù)量和字節(jié)數(shù)來確定，業(yè)務(wù)可以根據(jù)自己的場景也確定標(biāo)準(zhǔn)。

大key有什么影響

我們都知道，redis的一個(gè)典型特征就是：核心工作線程是單線程。

單線程中請求任務(wù)的處理是串行的，前面完不成，后面處理不了，同時(shí)也導(dǎo)致分布式架構(gòu)中內(nèi)存數(shù)據(jù)和CPU的不平衡。

• 執(zhí)行大key命令的客戶端本身，耗時(shí)明顯增加，甚至超時(shí)
• 執(zhí)行大key相關(guān)讀取或者刪除操作時(shí)，會(huì)嚴(yán)重占用帶寬和CPU，影響其他客戶端
• 大key本身的存儲(chǔ)帶來分布式系統(tǒng)中分片數(shù)據(jù)不平衡，CPU使用率也不平衡
• 大key有時(shí)候也是熱key，讀取操作頻繁，影響面會(huì)很大
• 執(zhí)行大key刪除時(shí)，在低版本redis中可能阻塞線程

這樣看來大key的影響還是很明顯的，最典型的就是阻塞線程，并發(fā)量下降，導(dǎo)致客戶端超時(shí)，服務(wù)端業(yè)務(wù)成功率下降。

大key是如何產(chǎn)生的

大key的產(chǎn)生往往是業(yè)務(wù)方設(shè)計(jì)不合理，沒有預(yù)見vaule的動(dòng)態(tài)增長問題：

• 一直往value塞數(shù)據(jù)，沒有刪除機(jī)制，遲早要爆炸
• 數(shù)據(jù)沒有合理做分片，將大key變成小key

如何找到大key

• 增加內(nèi)存&流量&超時(shí)等指標(biāo)監(jiān)控

由于大key的value很大，執(zhí)行讀取時(shí)可能阻塞線程，這樣Redis整體的qps會(huì)下降，并且客戶端超時(shí)會(huì)增加，網(wǎng)絡(luò)帶寬會(huì)上漲，配置這些報(bào)警可以讓我們發(fā)現(xiàn)大key的存在。

• bigkeys命令

使用bigkeys命令以遍歷的方式分析Redis實(shí)例中的所有Key，并返回整體統(tǒng)計(jì)信息與每個(gè)數(shù)據(jù)類型中Top1的大Key

• redis-rdb-tools

使用redis-rdb-tools離線分析工具來掃描RDB持久化文件，雖然實(shí)時(shí)性略差，但是完全離線對性能無影響。

“

redis-rdb-tools是由Python寫的用來分析Redis的rdb快照文件用的工具，它可以把rdb快照文件生成json文件或者生成報(bào)表用來分析Redis的使用詳情。

• 集成化可視化工具

基于某些公有云或者公司內(nèi)部架構(gòu)的redis一般都會(huì)有可視化的頁面和分析工具，來幫助我們定位大key，當(dāng)然頁面底層也可能是基于bigkeys或者rdb文件離線分析的結(jié)果。

如何解決大key問題

根據(jù)大key的實(shí)際用途可以分為兩種情況：可刪除和不可刪除。

刪除大key

如果發(fā)現(xiàn)某些大key并非熱key就可以在DB中查詢使用，則可以在Redis中刪掉：

• 當(dāng)Redis版本大于4.0時(shí)，可使用UNLINK命令安全地刪除大Key，該命令能夠以非阻塞的方式，逐步地清理傳入的Key。

“

Redis UNLINK 命令類似與 DEL 命令，表示刪除指定的 key，如果指定 key 不存在，命令則忽略。 UNLINK 命令不同與 DEL 命令在于它是異步執(zhí)行的，因此它不會(huì)阻塞。 UNLINK 命令是非阻塞刪除，非阻塞刪除簡言之，就是將刪除操作放到另外一個(gè)線程去處理。

• 當(dāng)Redis版本小于4.0時(shí)，避免使用阻塞式命令KEYS，而是建議通過SCAN命令執(zhí)行增量迭代掃描key，然后判斷進(jìn)行刪除。

“

Redis Scan 命令用于迭代數(shù)據(jù)庫中的數(shù)據(jù)庫鍵。 SCAN 命令是一個(gè)基于游標(biāo)的迭代器，每次被調(diào)用之后， 都會(huì)向用戶返回一個(gè)新的游標(biāo)， 用戶在下次迭代時(shí)需要使用這個(gè)新游標(biāo)作為 SCAN 命令的游標(biāo)參數(shù)， 以此來延續(xù)之前的迭代過程。

壓縮和拆分key

• 當(dāng)vaule是string時(shí)，比較難拆分，則使用序列化、壓縮算法將key的大小控制在合理范圍內(nèi)，但是序列化和反序列化都會(huì)帶來更多時(shí)間上的消耗。
• 當(dāng)value是string，壓縮之后仍然是大key，則需要進(jìn)行拆分，一個(gè)大key分為不同的部分，記錄每個(gè)部分的key，使用multiget等操作實(shí)現(xiàn)事務(wù)讀取。
• 當(dāng)value是list/set等集合類型時(shí)，根據(jù)預(yù)估的數(shù)據(jù)規(guī)模來進(jìn)行分片，不同的元素計(jì)算后分到不同的片。

小結(jié)

Redis的大key問題，無論在面試還是工作中都很常見，好好理解一波，非常值得。

祝各位老鐵 深夜無報(bào)警，線上無bug！