溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹“Redis中的BigKey問題排查與解決方法是什么”，在日常操作中，相信很多人在Redis中的BigKey問題排查與解決方法是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Redis中的BigKey問題排查與解決方法是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！
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 存在時，返回有關信息。 當 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轉換成Hash，List或者Set等數據結構。
如果大key的大小主要是由于對象序列化后的體積過大，我們可以考慮使用壓縮算法來減小對象的大小。Redis自身支持多種壓縮算法，例如LZF、Snappy等。
如果你使用的是Redis 4.0+的版本，可以直接使用 unlink命令去異步刪除。4.0以下的版本 可以考慮使用 scan ,分批次刪除。
無論采用哪種方法，都需要注意以下幾點：
避免使用過大的value。如果需要存儲大量的數據，可以將其拆分成多個小的value。就像是吃飯一樣，一口一口的吃，不要貪多嚼不爛。
避免使用不必要的數據結構。例如，如果只需要存儲一個字符串，就不要使用Hash或者List等數據結構。
定期清理過期的key。如果Redis中存在大量的過期key，就會導致Redis的性能下降。就像是家里的垃圾，需要定期清理。
對象壓縮
到此，關于“Redis中的BigKey問題排查與解決方法是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
