前言

前幾天元宵節(jié)，小黑準時下班回到家，吃著湯圓，看著電視，好生愜意!

忽然，手機叮咣叮咣響個不停報警，看了下是某個服務調(diào)用Redis異常了。

放下飯碗，小黑打開電腦一頓排查，最終定位到是Redis有大key問題。

尋思一時半會兒也解決不了，明天到公司再搞，先繼續(xù)看電視吧 哈哈哈。

什么是大key

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

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

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

設(shè)想一種場景：

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

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

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

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

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

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

大key有什么影響

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

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

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

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

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

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

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

如何找到大key

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

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

bigkeys命令

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

redis-rdb-tools

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

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

集成化可視化工具

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

如何解決大key問題

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

刪除大key

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

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

Redis UNLINK 命令類似與 DEL 命令，表示刪除指定的 key，如果指定 key 不存在，命令則忽略。

UNLINK 命令不同與 DEL 命令在于它是異步執(zhí)行的，因此它不會阻塞。

UNLINK 命令是非阻塞刪除，非阻塞刪除簡言之，就是將刪除操作放到另外一個線程去處理。

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

Redis Scan 命令用于迭代數(shù)據(jù)庫中的數(shù)據(jù)庫鍵。

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

壓縮和拆分key

當vaule是string時，比較難拆分，則使用序列化、壓縮算法將key的大小控制在合理范圍內(nèi)，但是序列化和反序列化都會帶來更多時間上的消耗。

當value是string，壓縮之后仍然是大key，則需要進行拆分，一個大key分為不同的部分，記錄每個部分的key，使用multiget等操作實現(xiàn)事務讀取。

當value是list/set等集合類型時，根據(jù)預估的數(shù)據(jù)規(guī)模來進行分片，不同的元素計算后分到不同的片。

小結(jié)

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

祝各位老鐵 深夜無報警，線上無bug!