Redis大key有什么危害？如何排查和處理？
這是一位同學今年秋招參加得物 Java 一面遇到的問題，完整面經如下：
這個問題在面試中還是比較容易遇到的，尤其是在考察 Redis 性能優化相關知識點的時候。
通常情況下，問了 bigkey（大 Key）還會繼續問 hotkey（熱 Key）。即使不準備面試也建議看看，實際開發中也能夠用到。
hotkey 相關的內容會在下一篇文章中提問，同樣會收錄在 《Java 常見面試題詳解》 這個面試題專輯中。
什么是 bigkey？
簡單來說，如果一個 key 對應的 value 所占用的內存比較大，那這個 key 就可以看作是 bigkey。具體多大才算大呢？有一個不是特別精確的參考標準：
- String 類型的 value 超過 1MB
- 復合類型（List、Hash、Set、Sorted Set 等）的 value 包含的元素超過 5000 個（不過，對于復合類型的 value 來說，不一定包含的元素越多，占用的內存就越多）。
bigkey 判定標準
bigkey 是怎么產生的？有什么危害？
bigkey 通常是由于下面這些原因產生的：
- 程序設計不當，比如直接使用 String 類型存儲較大的文件對應的二進制數據。
- 對于業務的數據規模考慮不周到，比如使用集合類型的時候沒有考慮到數據量的快速增長。
- 未及時清理垃圾數據，比如哈希中冗余了大量的無用鍵值對。
bigkey 除了會消耗更多的內存空間和帶寬，還會對性能造成比較大的影響。
在 Redis 常見阻塞原因總結[1]這篇文章中我們提到：大 key 還會造成阻塞問題。具體來說，主要體現在下面三個方面：
- 客戶端超時阻塞：由于 Redis 執行命令是單線程處理，然后在操作大 key 時會比較耗時，那么就會阻塞 Redis，從客戶端這一視角看，就是很久很久都沒有響應。
- 網絡阻塞：每次獲取大 key 產生的網絡流量較大，如果一個 key 的大小是 1 MB，每秒訪問量為 1000，那么每秒會產生 1000MB 的流量，這對于普通千兆網卡的服務器來說是災難性的。
- 工作線程阻塞：如果使用 del 刪除大 key 時，會阻塞工作線程，這樣就沒辦法處理后續的命令。
大 key 造成的阻塞問題還會進一步影響到主從同步和集群擴容。
綜上，大 key 帶來的潛在問題是非常多的，我們應該盡量避免 Redis 中存在 bigkey。
如何發現 bigkey？
1、使用 Redis 自帶的 --bigkeys 參數來查找。
# 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從這個命令的運行結果，我們可以看出：這個命令會掃描(Scan) Redis 中的所有 key ，會對 Redis 的性能有一點影響。并且，這種方式只能找出每種數據結構 top 1 bigkey（占用內存最大的 String 數據類型，包含元素最多的復合數據類型）。然而，一個 key 的元素多并不代表占用內存也多，需要我們根據具體的業務情況來進一步判斷。
在線上執行該命令時，為了降低對 Redis 的影響，需要指定 -i 參數控制掃描的頻率。redis-cli -p 6379 --bigkeys -i 3 表示掃描過程中每次掃描后休息的時間間隔為 3 秒。
2、使用 Redis 自帶的 SCAN 命令
SCAN 命令可以按照一定的模式和數量返回匹配的 key。獲取了 key 之后，可以利用 STRLEN、HLEN、LLEN等命令返回其長度或成員數量。
數據結構命令復雜度結果（對應 key）StringSTRLENO(1)字符串值的長度HashHLENO(1)哈希表中字段的數量ListLLENO(1)列表元素數量SetSCARDO(1)集合元素數量Sorted SetZCARDO(1)有序集合的元素數量
對于集合類型還可以使用 MEMORY USAGE 命令（Redis 4.0+），這個命令會返回鍵值對占用的內存空間。
3、借助開源工具分析 RDB 文件。
通過分析 RDB 文件來找出 big key。這種方案的前提是你的 Redis 采用的是 RDB 持久化。
網上有現成的代碼/工具可以直接拿來使用：
- redis-rdb-tools[2]：Python 語言寫的用來分析 Redis 的 RDB 快照文件用的工具
- rdb_bigkeys[3] : Go 語言寫的用來分析 Redis 的 RDB 快照文件用的工具，性能更好。
4、借助公有云的 Redis 分析服務。
如果你用的是公有云的 Redis 服務的話，可以看看其是否提供了 key 分析功能（一般都提供了）。
這里以阿里云 Redis 為例說明，它支持 bigkey 實時分析、發現，文檔地址：https://www.alibabacloud.com/help/zh/apsaradb-for-redis/latest/use-the-real-time-key-statistics-feature 。
阿里云Key分析
如何處理 bigkey？
bigkey 的常見處理以及優化辦法如下（這些方法可以配合起來使用）：
- 分割 bigkey：將一個 bigkey 分割為多個小 key。例如，將一個含有上萬字段數量的 Hash 按照一定策略（比如二次哈希）拆分為多個 Hash。
- 手動清理：Redis 4.0+ 可以使用 UNLINK 命令來異步刪除一個或多個指定的 key。Redis 4.0 以下可以考慮使用 SCAN 命令結合 DEL 命令來分批次刪除。
- 采用合適的數據結構：例如，文件二進制數據不使用 String 保存、使用 HyperLogLog 統計頁面 UV、Bitmap 保存狀態信息（0/1）。
- 開啟 lazy-free（惰性刪除/延遲釋放） ：lazy-free 特性是 Redis 4.0 開始引入的，指的是讓 Redis 采用異步方式延遲釋放 key 使用的內存，將該操作交給單獨的子線程處理，避免阻塞主線程。
