在處理大型數(shù)據(jù)時(shí)，Redis 作為我們的非關(guān)系型數(shù)據(jù)庫(kù)經(jīng)常出現(xiàn)在解決方案之中。然而，在使用 Redis 的過(guò)程中，有一些問(wèn)題可能會(huì)悄無(wú)聲息地影響我們的系統(tǒng)性能，其中最具代表性的就是 Big Key 問(wèn)題。

這個(gè)問(wèn)題往往被低估，Big Key會(huì)對(duì) Redis 的效率和整體性能產(chǎn)生重大影響。在本文中，我們將深入探索 Big Key 問(wèn)題的源頭，討論它如何影響系統(tǒng)性能，并提供相應(yīng)的解決策略。通過(guò)了解和解決 Big Key 問(wèn)題，我們可以更有效地利用 Redis，優(yōu)化我們的系統(tǒng)并提高性能。

一、Big Key問(wèn)題介紹

在Redis中，每個(gè)key都有一個(gè)對(duì)應(yīng)的value，如果某個(gè)key的value過(guò)大，就會(huì)導(dǎo)致Redis的性能下降或者崩潰。

因?yàn)镽edis需要將大key全部加載到內(nèi)存中，這會(huì)占用大量的內(nèi)存空間，會(huì)降低Redis的響應(yīng)速度，這個(gè)問(wèn)題被稱(chēng)為Big Key問(wèn)題。

不要小看這個(gè)問(wèn)題，它可是能讓你的Redis瞬間變成“烏龜”，由于Redis單線程的特性，操作Big Key的通常比較耗時(shí)，也就意味著B(niǎo)ig Key阻塞Redis的可能性很大，這樣會(huì)造成客戶(hù)端阻塞或者引起故障切換，有可能導(dǎo)致“慢查詢(xún)”或其他連鎖反應(yīng)。

一般而言，下面這兩種情況可以被稱(chēng)為Big Key：

• String 類(lèi)型的 key 對(duì)應(yīng)的value超過(guò) 10 MB。
• list、set、hash、zset等集合類(lèi)型，集合元素個(gè)數(shù)超過(guò) 5000個(gè)。

以上對(duì)Big Key的判斷標(biāo)準(zhǔn)并不唯一，只是一個(gè)大體的標(biāo)準(zhǔn)。在實(shí)際業(yè)務(wù)開(kāi)發(fā)中，對(duì)Big Key的判斷是需要根據(jù)具體的使用場(chǎng)景做不同的判斷。比如操作某個(gè) key 導(dǎo)致請(qǐng)求響應(yīng)時(shí)間變慢，那么這個(gè) key 就可以判定成 Big Key。

在Redis中，Big Key通常是由以下幾種原因?qū)е碌模?/p>

• 對(duì)象序列化后的大小過(guò)大。
• 存儲(chǔ)大量數(shù)據(jù)的容器，如set、list等。
• 大型數(shù)據(jù)結(jié)構(gòu)，如bitmap、hyperloglog等。

如果不及時(shí)處理這些大key，它們會(huì)逐漸消耗Redis服務(wù)器的內(nèi)存資源，最終導(dǎo)致Redis崩潰。

二、Big Key問(wèn)題排查

當(dāng)出現(xiàn)Redis性能急劇下降的情況時(shí)，很可能是由于存在大key導(dǎo)致的。在排除大key問(wèn)題時(shí)，可以考慮采取以下幾種方法：

1.BIGKEYS命令

Redis自帶的 BIGKEYS 命令可以查詢(xún)當(dāng)前Redis中所有key的信息，對(duì)整個(gè)數(shù)據(jù)庫(kù)中的鍵值對(duì)大小情況進(jìn)行統(tǒng)計(jì)分析。

比如說(shuō)，統(tǒng)計(jì)每種數(shù)據(jù)類(lèi)型的鍵值對(duì)個(gè)數(shù)以及平均大小。

此外，這個(gè)命令執(zhí)行后，會(huì)輸出每種數(shù)據(jù)類(lèi)型中最大的 big key 的信息，對(duì)于 String 類(lèi)型來(lái)說(shuō)，會(huì)輸出最大 big key 的字節(jié)長(zhǎng)度，對(duì)于集合類(lèi)型來(lái)說(shuō)，會(huì)輸出最大 big key 的元素個(gè)數(shù)。

BIGKEYS命令會(huì)掃描整個(gè)數(shù)據(jù)庫(kù)，這個(gè)命令本身會(huì)阻塞Redis，找出所有的大鍵，并將其以一個(gè)列表的形式返回給客戶(hù)端。

命令格式如下：

$ 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)

解讀下返回結(jié)果，從這個(gè)結(jié)果中可以看出：

• Redis中樣本了506個(gè)鍵。
• 這506個(gè)鍵總共占用了3452字節(jié)，平均每個(gè)鍵占用6.82字節(jié)。
• 最大的字符串鍵是'c'，值有6字節(jié)。
• 最大的列表鍵是'b'，有100004個(gè)元素。
• 最大的哈希鍵是'd'，有3個(gè)字段。
• 有504個(gè)字符串鍵，總共1403字節(jié)，占所有鍵的99.60%，平均每個(gè)字符串鍵大小為2.78字節(jié)。
• 有1個(gè)列表鍵，包含100004個(gè)元素，占所有鍵的0.20%，平均每個(gè)列表鍵大小為100004個(gè)元素。
• 沒(méi)有集合(set)鍵。
• 有1個(gè)哈希鍵，包含3個(gè)字段，占所有鍵的0.20%，平均每個(gè)哈希鍵大小為3個(gè)字段。
• 沒(méi)有有序集合(zset)鍵。

這些信息可以幫助你理解Redis數(shù)據(jù)庫(kù)的使用狀態(tài)，以便進(jìn)行相應(yīng)的優(yōu)化或調(diào)整。

需要注意的是，由于BIGKEYS命令需要掃描整個(gè)數(shù)據(jù)庫(kù)，所以它可能會(huì)對(duì)Redis實(shí)例造成一定的負(fù)擔(dān)。在執(zhí)行這個(gè)命令之前，請(qǐng)確保你的Redis實(shí)例有足夠的資源來(lái)處理它，建議在從節(jié)點(diǎn)執(zhí)行。

2.Debug Object

如果我們找到了Big Key，就需要對(duì)其進(jìn)行進(jìn)一步的分析。我們可以使用命令debug object key查看某個(gè)key的詳細(xì)信息，包括該key的value大小等。這時(shí)候你就可以“窺探”Redis的內(nèi)部，看看到底是哪個(gè)key太大導(dǎo)致的問(wèn)題。

Debug Object 命令是一個(gè)調(diào)試命令，當(dāng) key 存在時(shí)，返回有關(guān)信息。當(dāng) key 不存在時(shí)，返回一個(gè)錯(cuò)誤。

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

第一次運(yùn)行命令時(shí)，返回了 key 對(duì)應(yīng)的具體信息。這些值的意思如下：

• Value at:0xb6838d20：key 所在的內(nèi)存地址。
• refcount:1：引用計(jì)數(shù)，表示該對(duì)象被引用的次數(shù)。
• encoding:raw：編碼類(lèi)型，這里是 raw ，表示這個(gè)字符串對(duì)象的編碼類(lèi)型。
• serializedlength:9：序列化后的長(zhǎng)度。
• lru:283790：LRU （Least Recently Used）信息，即最近最少使用算法的相關(guān)信息，在內(nèi)存淘汰策略中會(huì)用到。
• lru_seconds_idle:150：該 key 已空閑多久（單位為秒），也就是自從最后一次訪問(wèn)已經(jīng)過(guò)去多少秒。

第二次運(yùn)行命令時(shí)，返回了 (error) ERR no such key，說(shuō)明在 Redis 中沒(méi)有找到名為 'key' 的鍵。

3.memory usage

在Redis4.0之前，只能通過(guò)DEBUG OBJECT命令估算key的內(nèi)存使用(字段serializedlength)，但DEBUG OBJECT命令是存在誤差的。

4.0版本及以上，更推薦使用memory usag命令。

memory usage命令使用非常簡(jiǎn)單，格式為：memory usage key。

如果當(dāng)前key存在，則返回key的value實(shí)際使用內(nèi)存估算值，如果key不存在，則返回nil。

127.0.0.1:6379> set k1 value1
OK
127.0.0.1:6379> memory usage k1    //這里k1 value占用57字節(jié)內(nèi)存
(integer) 57
127.0.0.1:6379> memory usage aaa  // aaa鍵不存在，返回nil.
(nil)

對(duì)于除String類(lèi)型之外的類(lèi)型，memory usage命令采用抽樣的方式，默認(rèn)抽樣5個(gè)元素，所以計(jì)算是近似值，我們也可以手動(dòng)指定抽樣的個(gè)數(shù)。

示例說(shuō)明：生成一個(gè)100w個(gè)字段的hash鍵：hkey，每字段的value長(zhǎng)度是從1~1024字節(jié)的隨機(jī)值。

127.0.0.1:6379> hlen hkey    // hkey有100w個(gè)字段，每個(gè)字段的value長(zhǎng)度介于1~1024個(gè)字節(jié)
(integer) 1000000
127.0.0.1:6379> MEMORY usage hkey   //默認(rèn)SAMPLES為5，分析hkey鍵內(nèi)存占用521588753字節(jié)
(integer) 521588753
127.0.0.1:6379> MEMORY usage hkey SAMPLES  1000 //指定SAMPLES為1000，分析hkey鍵內(nèi)存占用617977753字節(jié)
(integer) 617977753
127.0.0.1:6379> MEMORY usage hkey SAMPLES  10000 //指定SAMPLES為10000，分析hkey鍵內(nèi)存占用624950853字節(jié)
(integer) 624950853

要想獲取key較精確的內(nèi)存值，就指定更大抽樣個(gè)數(shù)。但是抽樣個(gè)數(shù)越大，占用cpu時(shí)間分片就越大。

4.redis-rdb-tools

redis-rdb-tools 是一個(gè) python 的解析 rdb 文件的工具，在分析內(nèi)存的時(shí)候，我們主要用它生成內(nèi)存快照。可以把 rdb 快照文件生成 CSV 或 JSON 文件，也可以導(dǎo)入到 MySQL 生成報(bào)表來(lái)分析。

使用 PYPI 安裝：

pip install rdbtools

生成內(nèi)存快照：

rdb -c memory dump.rdb > memory.csv

在生成的 CSV 文件中主要有以下幾列：

• database key在Redis的db
• type key類(lèi)型
• key key值
• size_in_bytes key的內(nèi)存大小
• encoding value的存儲(chǔ)編碼形式
• num_elements key中的value的個(gè)數(shù)
• len_largest_element key中的value的長(zhǎng)度

可以在MySQL中新建表然后導(dǎo)入進(jìn)行分析，然后可以直接通過(guò)SQL語(yǔ)句進(jìn)行查詢(xún)分析。

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

例如，查詢(xún)內(nèi)存占用最高的3個(gè) 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問(wèn)題解決思路

當(dāng)發(fā)現(xiàn)存在Big Key問(wèn)題時(shí)，我們需要及時(shí)采取措施來(lái)解決這個(gè)問(wèn)題。下面列出幾種可行的解決思路：

1.分割大key

將Big Key拆分成多個(gè)小key。這個(gè)方法比較簡(jiǎn)單，但是需要修改應(yīng)用程序的代碼。就像是把一個(gè)大蛋糕切成小蛋糕一樣，有點(diǎn)費(fèi)力，但是可以解決問(wèn)題。

或者嘗試將Big Key轉(zhuǎn)換成Redis的其他數(shù)據(jù)結(jié)構(gòu)。例如，將Big Key轉(zhuǎn)換成Hash，List或者Set等數(shù)據(jù)結(jié)構(gòu)。

2.對(duì)象壓縮

如果大key的產(chǎn)生原因主要是由于對(duì)象序列化后的體積過(guò)大，我們可以考慮使用壓縮算法來(lái)減小對(duì)象的大小。需要在客戶(hù)端使用一些壓縮算法對(duì)數(shù)據(jù)進(jìn)行壓縮和解壓縮操作，例如LZF、Snappy等。

3.直接刪除

如果你使用的是Redis 4.0+的版本，可以直接使用 unlink命令去異步刪除大key。4.0以下的版本 可以考慮使用 scan命令，分批次刪除。

無(wú)論采用哪種方法，日常使用中都需要注意以下幾點(diǎn)：

• 避免使用過(guò)大的value。如果需要存儲(chǔ)大量的數(shù)據(jù)，可以將其拆分成多個(gè)小的value。就像是吃飯一樣，一口一口的吃，不要貪多嚼不爛。
• 避免使用不必要的數(shù)據(jù)結(jié)構(gòu)。例如，如果只需要存儲(chǔ)一個(gè)字符串，就不要使用Hash或者List等數(shù)據(jù)結(jié)構(gòu)。
• 定期清理過(guò)期的key。如果Redis中存在大量的過(guò)期key，就會(huì)導(dǎo)致Redis的性能下降。就像是家里的垃圾，需要定期清理。
• 對(duì)象壓縮。

最后，結(jié)束本文時(shí)，我們要明確的是，Redis Big Key問(wèn)題是所有使用Redis作為數(shù)據(jù)存儲(chǔ)方案的開(kāi)發(fā)者都需要密切關(guān)注的重要話題。大Key可能會(huì)對(duì)Redis的性能產(chǎn)生嚴(yán)重影響，或者導(dǎo)致意外的內(nèi)存問(wèn)題。

因此，開(kāi)發(fā)者應(yīng)該充分利用現(xiàn)有的工具和策略來(lái)檢測(cè)和避免Big Key。在使用Redis時(shí)，需要注意避免使用過(guò)大的value和不必要的數(shù)據(jù)結(jié)構(gòu)，以及定期清理過(guò)期的key。

另外，我們還應(yīng)持續(xù)探索更高效、更可靠的解決方案，來(lái)優(yōu)化我們的Redis實(shí)例，使其更穩(wěn)定地為我們的應(yīng)用提供服務(wù)。最后，不斷學(xué)習(xí)和實(shí)踐才是提高我們對(duì)Redis使用的理解，并準(zhǔn)確處理Redis Big Key問(wèn)題的最佳方式。