這是一位同學今年秋招參加得物 Java 一面遇到的問題，完整面經(jīng)如下：

這個問題在面試中還是比較容易遇到的，尤其是在考察 Redis 性能優(yōu)化相關(guān)知識點的時候。

通常情況下，問了 bigkey（大 Key）還會繼續(xù)問 hotkey（熱 Key）。即使不準備面試也建議看看，實際開發(fā)中也能夠用到。

hotkey 相關(guān)的內(nèi)容會在下一篇文章中提問，同樣會收錄在 《Java 常見面試題詳解》 這個面試題專輯中。

什么是 bigkey？

簡單來說，如果一個 key 對應(yīng)的 value 所占用的內(nèi)存比較大，那這個 key 就可以看作是 bigkey。具體多大才算大呢？有一個不是特別精確的參考標準：

• String 類型的 value 超過 1MB
• 復合類型（List、Hash、Set、Sorted Set 等）的 value 包含的元素超過 5000 個（不過，對于復合類型的 value 來說，不一定包含的元素越多，占用的內(nèi)存就越多）。

bigkey 判定標準

bigkey 是怎么產(chǎn)生的？有什么危害？

bigkey 通常是由于下面這些原因產(chǎn)生的：

• 程序設(shè)計不當，比如直接使用 String 類型存儲較大的文件對應(yīng)的二進制數(shù)據(jù)。
• 對于業(yè)務(wù)的數(shù)據(jù)規(guī)?？紤]不周到，比如使用集合類型的時候沒有考慮到數(shù)據(jù)量的快速增長。
• 未及時清理垃圾數(shù)據(jù)，比如哈希中冗余了大量的無用鍵值對。

bigkey 除了會消耗更多的內(nèi)存空間和帶寬，還會對性能造成比較大的影響。

在 Redis 常見阻塞原因總結(jié)[1]這篇文章中我們提到：大 key 還會造成阻塞問題。具體來說，主要體現(xiàn)在下面三個方面：

1. 客戶端超時阻塞：由于 Redis 執(zhí)行命令是單線程處理，然后在操作大 key 時會比較耗時，那么就會阻塞 Redis，從客戶端這一視角看，就是很久很久都沒有響應(yīng)。
2. 網(wǎng)絡(luò)阻塞：每次獲取大 key 產(chǎn)生的網(wǎng)絡(luò)流量較大，如果一個 key 的大小是 1 MB，每秒訪問量為 1000，那么每秒會產(chǎn)生 1000MB 的流量，這對于普通千兆網(wǎng)卡的服務(wù)器來說是災(zāi)難性的。
3. 工作線程阻塞：如果使用 del 刪除大 key 時，會阻塞工作線程，這樣就沒辦法處理后續(xù)的命令。

大 key 造成的阻塞問題還會進一步影響到主從同步和集群擴容。

綜上，大 key 帶來的潛在問題是非常多的，我們應(yīng)該盡量避免 Redis 中存在 bigkey。

如何發(fā)現(xiàn) bigkey？

1、使用 Redis 自帶的 --bigkeys 參數(shù)來查找。

# redis-cli -p 6379 --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 '"ballcat:oauth:refresh_auth:f6cdb384-9a9d-4f2f-af01-dc3f28057c20"' with 4437 bytes
[00.00%] Biggest list   found so far '"my-list"' with 17 items

-------- summary -------

Sampled 5 keys in the keyspace!
Total key length in bytes is 264 (avg len 52.80)

Biggest   list found '"my-list"' has 17 items
Biggest string found '"ballcat:oauth:refresh_auth:f6cdb384-9a9d-4f2f-af01-dc3f28057c20"' has 4437 bytes

1 lists with 17 items (20.00% of keys, avg size 17.00)
0 hashs with 0 fields (00.00% of keys, avg size 0.00)
4 strings with 4831 bytes (80.00% of keys, avg size 1207.75)
0 streams with 0 entries (00.00% of keys, avg size 0.00)
0 sets with 0 members (00.00% of keys, avg size 0.00)
0 zsets with 0 members (00.00% of keys, avg size 0.00

從這個命令的運行結(jié)果，我們可以看出：這個命令會掃描(Scan) Redis 中的所有 key ，會對 Redis 的性能有一點影響。并且，這種方式只能找出每種數(shù)據(jù)結(jié)構(gòu) top 1 bigkey（占用內(nèi)存最大的 String 數(shù)據(jù)類型，包含元素最多的復合數(shù)據(jù)類型）。然而，一個 key 的元素多并不代表占用內(nèi)存也多，需要我們根據(jù)具體的業(yè)務(wù)情況來進一步判斷。

在線上執(zhí)行該命令時，為了降低對 Redis 的影響，需要指定 -i 參數(shù)控制掃描的頻率。redis-cli -p 6379 --bigkeys -i 3 表示掃描過程中每次掃描后休息的時間間隔為 3 秒。

2、使用 Redis 自帶的 SCAN 命令

SCAN 命令可以按照一定的模式和數(shù)量返回匹配的 key。獲取了 key 之后，可以利用 STRLEN、HLEN、LLEN等命令返回其長度或成員數(shù)量。

數(shù)據(jù)結(jié)構(gòu)命令復雜度結(jié)果（對應(yīng) key）StringSTRLENO(1)字符串值的長度HashHLENO(1)哈希表中字段的數(shù)量ListLLENO(1)列表元素數(shù)量SetSCARDO(1)集合元素數(shù)量Sorted SetZCARDO(1)有序集合的元素數(shù)量

對于集合類型還可以使用 MEMORY USAGE 命令（Redis 4.0+），這個命令會返回鍵值對占用的內(nèi)存空間。

3、借助開源工具分析 RDB 文件。

通過分析 RDB 文件來找出 big key。這種方案的前提是你的 Redis 采用的是 RDB 持久化。

網(wǎng)上有現(xiàn)成的代碼/工具可以直接拿來使用：

• redis-rdb-tools[2]：Python 語言寫的用來分析 Redis 的 RDB 快照文件用的工具
• rdb_bigkeys[3] : Go 語言寫的用來分析 Redis 的 RDB 快照文件用的工具，性能更好。

4、借助公有云的 Redis 分析服務(wù)。

如果你用的是公有云的 Redis 服務(wù)的話，可以看看其是否提供了 key 分析功能（一般都提供了）。

這里以阿里云 Redis 為例說明，它支持 bigkey 實時分析、發(fā)現(xiàn)，文檔地址：https://www.alibabacloud.com/help/zh/apsaradb-for-redis/latest/use-the-real-time-key-statistics-feature 。

阿里云Key分析

如何處理 bigkey？

bigkey 的常見處理以及優(yōu)化辦法如下（這些方法可以配合起來使用）：

• 分割 bigkey：將一個 bigkey 分割為多個小 key。例如，將一個含有上萬字段數(shù)量的 Hash 按照一定策略（比如二次哈希）拆分為多個 Hash。
• 手動清理：Redis 4.0+ 可以使用 UNLINK 命令來異步刪除一個或多個指定的 key。Redis 4.0 以下可以考慮使用 SCAN 命令結(jié)合 DEL 命令來分批次刪除。
• 采用合適的數(shù)據(jù)結(jié)構(gòu)：例如，文件二進制數(shù)據(jù)不使用 String 保存、使用 HyperLogLog 統(tǒng)計頁面 UV、Bitmap 保存狀態(tài)信息（0/1）。
• 開啟 lazy-free（惰性刪除/延遲釋放） ：lazy-free 特性是 Redis 4.0 開始引入的，指的是讓 Redis 采用異步方式延遲釋放 key 使用的內(nèi)存，將該操作交給單獨的子線程處理，避免阻塞主線程。