Redis中的BigKey問題：排查與解決思路-有解無憂

本文已收錄至Github，推薦閱讀 ?? Java隨想錄

微信公眾號：Java隨想錄

摘要
Big Key問題介紹
Big Key問題排查
- 使用BIGKEYS命令
  - Debug Object
  - memory usage
- redis-rdb-tools
Big Key問題解決思路
- 分割大key
- 物件壓縮
- 直接洗掉
總結

摘要

Redis是一款性能強勁的記憶體資料庫，但是在使用程序中，我們可能會遇到Big Key問題，這個問題就是Redis中某個key的value過大，所以Big Key問題本質是Big Value問題，導致Redis的性能下降或者崩潰，本文將向大家介紹如何排查和解決這個問題，

Big Key問題介紹

在Redis中，每個key都有一個對應的value，如果某個key的value過大，就會導致Redis的性能下降或者崩潰，比玄學更玄學，因為Redis需要將大key全部加載到記憶體中，這會占用大量的記憶體空間，會降低Redis的回應速度，這個問題被稱為Big Key問題，不要小看這個問題，它可是能讓你的Redis瞬間變成“烏龜”，由于Redis單執行緒的特性，操作Big Key的通常比較耗時，也就意味著阻塞Redis可能性越大，這樣會造成客戶端阻塞或者引起故障切換，有可能導致“慢查詢”，

一般而言，下面這兩種情況被稱為大 key：

String 型別的 key 對應的value超過 10 MB，
list、set、hash、zset等集合型別，集合元素個數超過 5000個，

以上對 Big Key 的判斷標準并不是唯一，只是一個大體的標準，在實際業務開發中，對 Big Key的判斷是需要根據具體的使用場景做不同的判斷，比如操作某個 key 導致請求回應時間變慢，那么這個 key 就可以判定成 Big Key，

在Redis中，大key通常是由以下幾種原因導致的：

物件序列化后的大小過大
存盤大量資料的容器，如set、list等
大型資料結構，如bitmap、hyperloglog等

如果不及時處理這些大key，它們會逐漸消耗Redis服務器的記憶體資源，最終導致Redis崩潰，

Big Key問題排查

當出現Redis性能急劇下降的情況時，很可能是由于存在大key導致的，在排除大key問題時，可以考慮采取以下幾種方法：

使用BIGKEYS命令

Redis自帶的 BIGKEYS 命令可以查詢當前Redis中所有key的資訊，對整個資料庫中的鍵值對大小情況進行統計分析，比如說，統計每種資料型別的鍵值對個數以及平均大小，此外，這個命令執行后，會輸出每種資料型別中最大的 bigkey 的資訊，對于 String 型別來說，會輸出最大 bigkey 的位元組長度，對于集合型別來說，會輸出最大 bigkey 的元素個數

BIGKEYS命令會掃描整個資料庫，這個命令本身會阻塞Redis，找出所有的大鍵，并將其以一個串列的形式回傳給客戶端，

命令格式如下：

$ 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命令需要掃描整個資料庫，所以它可能會對Redis實體造成一定的負擔，在執行這個命令之前，請確保您的Redis實體有足夠的資源來處理它，建議在從節點執行，

Debug Object

如果我們找到了Big Key，就需要對其進行進一步的分析，我們可以使用命令debug object key查看某個key的詳細資訊，包括該key的value大小等，這時候你就可以“窺探”Redis的內部，看看到底是哪個key太大了，

Debug Object 命令是一個除錯命令，當 key 存在時，回傳有關資訊，當 key 不存在時，回傳一個錯誤，

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對應的value序列化之后的位元組數

memory usage

在Redis4.0之前，只能通過DEBUG OBJECT命令估算key的記憶體使用(欄位serializedlength)，但DEBUG OBJECT命令是有誤差的，

4.0版本及以上，我們可以使用memory usag命令，

memory usage命令使用非常簡單，直接按memory usage key名字；如果當前key存在，則回傳key的value實際使用記憶體估算值；如果key不存在，則回傳nil，

127.0.0.1:6379> set k1 value1
OK
127.0.0.1:6379> memory usage k1    //這里k1 value占用57位元組記憶體
(integer) 57
127.0.0.1:6379> memory usage aaa  // aaa鍵不存在，回傳nil.
(nil)

對于除String型別之外的型別，memory usage命令采用抽樣的方式，默認抽樣5個元素，所以計算是近似值，我們也可以指定抽樣的個數，

示例說明：生成一個100w個欄位的hash鍵：hkey，每欄位的value長度是從1~1024位元組的隨機值，

127.0.0.1:6379> hlen hkey    // hkey有100w個欄位，每個欄位的value長度介于1~1024個位元組
(integer) 1000000
127.0.0.1:6379> MEMORY usage hkey   //默認SAMPLES為5，分析hkey鍵記憶體占用521588753位元組
(integer) 521588753
127.0.0.1:6379> MEMORY usage hkey SAMPLES  1000 //指定SAMPLES為1000，分析hkey鍵記憶體占用617977753位元組
(integer) 617977753
127.0.0.1:6379> MEMORY usage hkey SAMPLES  10000 //指定SAMPLES為10000，分析hkey鍵記憶體占用624950853位元組
(integer) 624950853

要想獲取key較精確的記憶體值，就指定更大抽樣個數，但是抽樣個數越大，占用cpu時間分片就越大，

redis-rdb-tools

redis-rdb-tools 是一個 python 的決議 rdb 檔案的工具，在分析記憶體的時候，我們主要用它生成記憶體快照，可以把 rdb 快照檔案生成 CSV 或 JSON 檔案，也可以匯入到 MySQL 生成報表來分析，

使用 PYPI 安裝

pip install rdbtools

生成記憶體快照

rdb -c memory dump.rdb > memory.csv

在生成的 CSV 檔案中有以下幾列：

database key在Redis的db
type key型別
key key值
size_in_bytes key的記憶體大小
encoding value的存盤編碼形式
num_elements key中的value的個數
len_largest_element key中的value的長度

可以在MySQL中新建表然后匯入進行分析，然后可以直接通過SQL陳述句進行查詢分析，

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`)
 );

例子：查詢記憶體占用最高的3個 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問題解決思路

當發現存在大key問題時，我們需要及時采取措施來解決這個問題，下面列出幾種可行的解決思路：

分割大key

將Big Key拆分成多個小的key，這個方法比較簡單，但是需要修改應用程式的代碼，就像是把一個大蛋糕切成小蛋糕一樣，有點費力，但是可以解決問題，

或者嘗試將Big Key轉換成Redis的資料結構，例如，將Big Key轉換成Hash，List或者Set等資料結構，

物件壓縮

如果大key的大小主要是由于物件序列化后的體積過大，我們可以考慮使用壓縮演算法來減小物件的大小，Redis自身支持多種壓縮演算法，例如LZF、Snappy等，

直接洗掉

如果你使用的是Redis 4.0+的版本，可以直接使用 unlink命令去異步洗掉，4.0以下的版本可以考慮使用 scan ,分批次洗掉，

無論采用哪種方法，都需要注意以下幾點：

避免使用過大的value，如果需要存盤大量的資料，可以將其拆分成多個小的value，就像是吃飯一樣，一口一口的吃，不要貪多嚼不爛，
避免使用不必要的資料結構，例如，如果只需要存盤一個字串，就不要使用Hash或者List等資料結構，
定期清理過期的key，如果Redis中存在大量的過期key，就會導致Redis的性能下降，就像是家里的垃圾，需要定期清理，
物件壓縮

總結

Big Key問題是Redis中常見的問題之一，但是通過合理的排查和解決思路，我們可以有效地避免這個問題，在使用Redis時，需要注意避免使用過大的value和不必要的資料結構，以及定期清理過期的key，

本篇文章就到這里，感謝閱讀，如果本篇博客有任何錯誤和建議，歡迎給我留言指正，文章持續更新，可以關注公眾號第一時間閱讀，

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/547998.html

標籤：Java

上一篇：PLG SaaS 產品 Figma 商業模式拆解

下一篇：Java生產者消費者