Redis調優-BigKey如何處理？
Redis大Key核心問題
Redis庫中大數據量如何遍歷？
主機配置：
- redis: 6.2.14
- 主機內存：8G
圖片
執行步驟：
- 生成1000W條記錄腳本,插入redis數據庫
#!/bin/bash
# Redis服務器地址和端口
REDIS_HOST="localhost"
REDIS_PORT=6379
# 輸出文件名
OUTPUT_FILE="/tmp/redis-bigkey.txt"
# 要插入的數據條數
NUM_ENTRIES=1000000
# 清除輸出文件，如果它已存在
> "$OUTPUT_FILE"
# 生成數據并插入到Redis中，同時輸出到文件
for ((i=1; i<=$NUM_ENTRIES; i++)); do
# 生成一個隨機的key和value，這里簡化處理，僅使用數字作為key和value
KEY="key$i"
VALUE="$i"
# 將key和value輸出到文件中
echo "set $KEY $VALUE" >> "$OUTPUT_FILE"
# 如果需要的話，可以在這里添加檢查來確認SET操作是否成功
# 比如：redis-cli -h $REDIS_HOST -p $REDIS_PORT GET "$KEY" | grep -q "$VALUE"
# 如果上面的命令返回非零狀態，可以記錄錯誤或者退出腳本
done
echo "數據已插入Redis并輸出到$OUTPUT_FILE"- 讀取命令集，插入redis數據庫
cat /tmp/redis-bigkey.txt | /usr/local/redis/redis-6.2.14/src/redis-cli -h 192.168.XXX.XXX -p 6379 -a ****** --pipe這條命令是會將一個文本文件的內容通過管道（pipe）發送到Redis的命令行接口并執行。
重要參數說明：
cat /tmp/redis-bigkey.txt:
- cat 命令用于讀取 /tmp/redis-bigkey.txt 這個文件的內容。
-a ******:
- -a 參數用于指定連接Redis服務器所需的密碼。
- ****** 是連接Redis服務器時使用的密碼。
--pipe:
- --pipe 是一個特殊的選項，它告訴 redis-cli 通過管道從標準輸入讀取數據，并作為Redis命令發送到服務器。
注意：這里/tmp/redis-bigkey.txt 文件包含一系列的Redis命令，這些命令將被批量執行。例如，文件中可能包含 SET、GET、DEL 等命令，每行一個命令。使用 --pipe 選項時，需要確保Redis服務器配置允許批量操作。
- 執行后結果，redis數據庫中有1000W數據
127.0.0.1:6379> dbsize
(integer) 1000000嘗試用 keys * 遍歷，耗時8.55s
圖片
??由此可見，生產環境的數據量可能不止這些?？上氡闅v一次可能的耗時。那么，如何正確遍歷呢？ 使用SCAN命令。
SCAN cursor [MATCH pattern] [COUNT count] [TYPE type]??SCAN 命令是一個基于游標的迭代器，每次被調用之后， 都會向用戶返回一個新的游標， 用戶在下次迭代時需要使用這個新游標作為 SCAN 命令的游標參數， 以此來延續之前的迭代過程。
簡單演示
127.0.0.1:6379> scan 2 match * count 10
1) "720898"
2) 1) "key772152"
2) "key318823"
3) "key851172"
4) "key137276"
5) "key658069"
6) "key486655"
7) "key795861"
8) "key300972"
9) "key488665"
10) "key479460"
11) "key15673"什么是大Key，多大是大Key?
注意：Redis中的大key，實際上指的是key所關聯的value值特別大，或者是某種數據結構（如hash, set, zset, list）中存儲了過多的元素。
詳情可參照《阿里Redis開發規范》
圖片
一般來講，String類型控制在10KB以內，hash、list、set、zset元素個數不要超過5000。
為什么會產生BigKey？
大key的產生一般與業務方設計有關，對vaule的動態增長問題預估不足。造成大key問題的原因有：
- 數據結構設計不合理。在不適用的場景下使用Redis，易造成Key的value過大，如使用String類型的Key存放大體積二進制文件型數據；
- 業務規劃設計不足。沒有對Key中的成員進行合理的拆分將大key變成小key，從而造成個別Key中一直往value里面塞數據，沒有刪除機制，未定期清理無效數據，導致不斷增加。
- 上線前期預估不足。如頭條重大新聞，造成value值動態突增。如：百度熱搜
圖片
- 匯總統計類，隨著時間推移value逐漸增加
產生大Key會有什么問題？
- 內存不足（因為redis基于內存）
- 刪除超時
- 網絡阻塞
- 集群節點容量傾斜甚至宕機
因此需引起足夠重視。
如何判定redis變慢了？
- Redis 基準性能測試
- 測試基準
??了解Redis 在生產環境服務器上的基準性能，才能進一步評估，當其延遲達到什么程度時，才認為Redis確實變慢了。例如：按自身硬件配置，可能延遲是0.5ms 時就可以認為Redis 變慢了。
- 測試方法
執行以下命令，測試出這個實例60 秒內的最大響應延遲：
./redis-cli --intrinsic-latency 60
[root@bogon src]# ./redis-cli --intrinsic-latency 60
Max latency so far: 1 microseconds.
Max latency so far: 25 microseconds.
Max latency so far: 220 microseconds.
Max latency so far: 253 microseconds.
Max latency so far: 351 microseconds.
Max latency so far: 448 microseconds.
Max latency so far: 514 microseconds.
1706810010 total runs (avg latency: 0.0352 microseconds / 35.15 nanoseconds per run).
Worst run took 14622x longer than the average latency.從輸出結果可以看到，這60 秒內的最大響應延遲為514 微秒（0.514 毫秒）。
還可以使用以下命令，查看一段時間內Redis 的最小、最大、平均訪問延遲。如下：redis-cli 每隔1秒向 Redis 服務器發送一個 PING 命令，并測量其往返時間.
Redis-cli -h 127.0.0.1 -p 6379 --latency-history -i 1
[root@bogon src]# redis-cli -h 127.0.0.1 -p 6379 --latency-history -i 1
min: 0, max: 1, avg: 0.15 (82 samples) -- 1.01 seconds range
min: 0, max: 1, avg: 0.06 (80 samples) -- 1.00 seconds range
min: 0, max: 1, avg: 0.12 (82 samples) -- 1.00 seconds range
min: 0, max: 1, avg: 0.09 (81 samples) -- 1.01 seconds range
min: 0, max: 1, avg: 0.07 (82 samples) -- 1.00 seconds range
min: 0, max: 1, avg: 0.07 (82 samples) -- 1.01 seconds range根據《阿里開發手冊》如果你觀察到的Redis 運行時延遲是其基線性能的2倍及以上，就可以認定Redis變慢了。
- 使用Redis慢日志
Redis 提供了慢日志命令的統計功能，它記錄了有哪些命令在執行時耗時比較久。
例如，設置慢日志的閾值為5毫秒，并且保留最近10條慢日志記錄：
# 命令執行耗時超過 5 毫秒，記錄慢日志
CONFIG SET slowlog-log-slower-than 5000
# 只保留最近 10 條慢日志
CONFIG SET slowlog-max-len 10??如果你查詢慢日志發現，并不是復雜度過高的命令導致的，而都是SET/DEL這種簡單命令出現在慢日志中，那么你就要懷疑你的實例否寫入了bigkey。
如何發現BigKey？
使用命令redis-cli --bigkeys給出每種數據結構最大的bigkey，同時給出每種數據類型的鍵值個數和平均大小。
redis-cli --bigkeys
[root@bogon src]# 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 '"key162116"' with 6 bytes
[75.91%] Biggest string found so far '"key1000000"' with 7 bytes
[100.00%] Sampled 1000000 keys so far
-------- summary -------
Sampled 1000000 keys in the keyspace!
Total key length in bytes is 8888896 (avg len 8.89)
Biggest string found '"key1000000"' has 7 bytes
0 lists with 0 items (00.00% of keys, avg size 0.00)
0 hashs with 0 fields (00.00% of keys, avg size 0.00)
1000000 strings with 5888896 bytes (100.00% of keys, avg size 5.89)
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)注意：對線上實例進行bigkey掃描時，Redis 的OPS（Operation Per Second 每秒操作次數）會突增，掃描過程最好控制一下掃描的頻率，指定-i 參數，命令：redis-cli -h 127.0.0.1 -p 6379 --bigkeys -i 1.它表示掃描過程中每次掃描后休息的時間間隔，單位是秒。
但是，如果想要獲得一個 key 和它的值在 RAM 中所占用的字節數。需要使用以下命令：
redis 127.0.0.1:6379> MEMORY USAGE key [SAMPLES count]例如：
127.0.0.1:6379> MEMORY usage key1000000
(integer) 56當我們發現生產的大Key后，那么如何進行刪除？
如何處理大Key?
我們按照不同數據類型，給出以下命令：
- String類型: DEL/UNLINK
刪除Redis中String類型的大Key，你可以使用DEL命令：
DEL key [key ...]如果你使用的是Redis的集群模式，可以使用redis-cli的-c選項來啟用集群模式，并執行刪除命令。
redis-cli -c DEL key_name由于DEL命令會對Redis服務器造成阻塞，可以考慮使用UNLINK命令。Redis 4.0及以上版本中可用，它會異步地刪除Key，避免阻塞。
UNLINK key [key ...]注意: 即使使用UNLINK命令，刪除非常大的Key仍然可能會對Redis服務器造成一些影響，因為它仍然需要釋放內存。因此，在生產環境中執行此類操作時，請務必謹慎，并考慮在低峰時段進行，同時監控Redis的性能指標。
- Hash類型:HSCAN + HDEL
HSCAN key cursor [MATCH pattern] [COUNT count]
127.0.0.1:6379> HSET myhash field1 value1
(integer) 1
127.0.0.1:6379> HSET myhash field2 value2
(integer) 1
127.0.0.1:6379> HSET myhash field3 value3
(integer) 1
127.0.0.1:6379> HSCAN myhash 0 MATCH * COUNT 10
1) "0"
2) 1) "field1"
2) "value1"
3) "field2"
4) "value2"
5) "field3"
6) "value3"
127.0.0.1:6379> HDEL myhash field2
(integer) 1
127.0.0.1:6379> HGETALL myhash
1) "field1"
2) "value1"
3) "field3"
4) "value3"- List類型:LTRIM漸進式刪除
LTRIM key start stop
redis> RPUSH mylist "one"
(integer) 1
redis> RPUSH mylist "two"
(integer) 2
redis> RPUSH mylist "three"
(integer) 3
redis> LTRIM mylist 1 -1
"OK"
redis> LRANGE mylist 0 -1
1) "two"
2) "three"
redis>- Set類型:使用sscan每次獲取部分元素，再使用srem命令刪除每個元素
127.0.0.1:6379> SADD myset e1 e2 e3
(integer) 0
127.0.0.1:6379> SSCAN myset 1
1) "0"
2) 1) "e3"
127.0.0.1:6379> SMEMBERS myset
1) "e2"
2) "e1"
3) "e3"
127.0.0.1:6379> SREM myset e2
(integer) 1
127.0.0.1:6379> SMEMBERS myset
1) "e1"
2) "e3"
127.0.0.1:6379>- Zset類型： 使用zscan每次獲取部分元素，再使用ZREM命令刪除每個元素
127.0.0.1:6379> zadd score 98 xm 99 xb 100 xh
(integer) 3
127.0.0.1:6379> zscan score 0
1) "0"
2) 1) "xm"
2) "98"
3) "xb"
4) "99"
5) "xh"
6) "100"
127.0.0.1:6379> ZRANGE score 0 -1 WITHSCORES
1) "xm"
2) "98"
3) "xb"
4) "99"
5) "xh"
6) "100"
127.0.0.1:6379> ZREM score xm
(integer) 1
127.0.0.1:6379> ZRANGE score 0 -1 WITHSCORES
1) "xb"
2) "99"
3) "xh"
4) "100"
127.0.0.1:6379>生產BigKey如何調優？
??采用惰性刪除策略。具體在${redis_home}/redis.conf 文件配置修改
lazyfree-lazy-server-del yes
replica-lazy-flush yes
lazyfree-lazy-user-del yes總結
Redis中的大Key指的是占用內存特別大的Key，處理不當可能導致性能下降、內存消耗大等問題。
解決方案：
- 避免創建大Key：設計數據結構時，盡量分散數據，避免單一Key過大。
- 分批次處理：對于已存在的大Key，使用相關命令（如SCAN）分批次讀取和刪除。
- 設置過期時間：為大Key設置TTL，讓Redis自動清理。
- 監控與告警：使用監控工具及時發現大Key，并設置告警通知。
- 優化網絡：如果刪除大Key時網絡壓力大，考慮增加帶寬或優化網絡連接。
注意事項：
- 處理大Key時要謹慎，最好在低峰時段操作。
