Redis是一款效能強勁的記憶體資料庫，但在使用過程中，我們可能會遇到Big Key問題，這個問題就是Redis中某個key的value過大，所以Big Key問題本質是Big Value問題，導致Redis的效能下降或崩潰。
在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崩潰。
當出現Redis效能急遽下降的情況時，很可能是因為有大key所導致的。在排除大key問題時，可以考慮採取以下幾種方法：
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實例有足夠的資源來處理它，建議在從節點執行。
如果我們找到了Big Key，就需要進一步的分析。我們可以使用指令debug object key查看某個key的詳細信息，包括該key的value大小等。這時候你就可以「窺探」Redis的內部，看看到底是哪個key太大了。
當鍵存在時，Debug Object指令提供關於該鍵的信息，是一種偵錯指令。當 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序列化之後的位元組數
在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 是一個 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)
当发现存在大key问题时，我们需要及时采取措施来解决这个问题。下面列出几种可行的解决思路：
将Big Key拆分成多个小的key。这个方法比较简单，但是需要修改应用程序的代码。虽然有些费力，但将一个大蛋糕切成小蛋糕可以解决问题。
或者尝试将Big Key转换成Redis的数据结构。例如，可以使用哈希表、列表或集合等数据结构将“Big Key”进行转换。
若大key的大小源于对象序列化后的体积巨大，我们可思考运用压缩算法来缩小对象的尺寸。Redis自身支持多种压缩算法，例如LZF、Snappy等。
如果你所用的Redis版本是4.0或更高版本，你可以使用unlink命令进行异步删除。4.0以下的版本 可以考虑使用 scan ,分批次删除。
无论采用哪种方法，都需要注意以下几点：
避免使用过大的value。如果需要存储大量的数据，可以将其拆分成多个小的value。就像是吃饭一样，一口一口的吃，不要贪多嚼不烂。
避免使用不必要的数据结构。如果只需要保存一个字符串，应该避免使用像Hash或List这样的数据结构。
定期清理过期的key。当Redis中存在大量过期的key时，会导致Redis性能下降。就像是家里的垃圾，需要定期清理。
对象压缩
以上是Redis中的BigKey問題檢查與解決方法是什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！
