線上 Redis 頻繁崩潰？這套大 key 治理方案請收好
兄弟們，凌晨兩點，手機突然像地震一樣狂震，我迷迷糊糊摸到床頭一看，運維群里炸了鍋："Redis節點又掛了！內存使用率飆到99%，CPU直接打滿！" 頂著黑眼圈爬起來連服務器，剛登錄就看到熟悉的報錯：OOM killer 又把 Redis 進程干掉了。
那一刻我真想把寫代碼時隨手往 Redis 里塞大集合的同事拎過來——咱就是說，存數據能不能別跟往麻袋里裝磚頭似的，可勁兒造啊！
一、先搞明白：啥是 Redis 大 key？它憑啥能搞崩服務器？
很多新手可能還不清楚，所謂"大 key"其實分兩種情況：一種是單個 key 的值特別大（比如一個字符串類型的值超過1MB），另一種是集合類數據結構（像 hash、list、set、zset）里的元素數量超多（比如一個 zset 存了10萬+成員）。別小看這些大塊頭，它們就像藏在 Redis 里的定時炸彈，主要靠這三招搞破壞：
1. 內存分布不均勻，分片集群秒變"單腿跳"
現在稍微大點的項目都用 Redis 集群，假設你用的是分片集群（比如 Codis、Redis Cluster），一個大 key 會被固定分配到某個分片上。想象一下，其他分片內存使用率才50%，就這個分片像吹氣球一樣漲到90%，整個集群的負載均衡瞬間失效。更要命的是，當你要刪除這個大 key 時，分片節點會經歷一段漫長的"卡頓期"，因為刪除操作需要釋放大量連續內存，堪比在市中心拆除一棟摩天大樓，周圍的交通都得跟著堵。
2. 網絡IO成瓶頸，批量操作直接"卡脖子"
舉個真實的例子：之前有個兄弟在項目里用 list 存用戶的歷史操作記錄，一個 key 存了50萬條數據。某天運營要導出用戶數據，直接用 LRANGE key 0 -1 撈數據，結果 Redis 所在服務器的網卡流量直接飆到峰值，應用服務器這邊等了10秒都沒拿到響應。為啥？因為 Redis 是單線程模型，處理這種大集合操作時，會把所有元素序列化后通過網絡傳輸，就像用一根水管同時給100戶人家供水，水壓自然上不去。
3. 內存碎片瘋狂增長，好好的內存變成"碎紙片"
Redis 采用jemalloc分配內存，當大 key 被頻繁刪除和寫入時，會產生大量無法利用的小碎片。比如你先存了一個10MB的大字符串，然后刪除，再存一堆1KB的小字符串，jemalloc 沒辦法把這些小碎片合并成大的連續內存，導致實際內存使用率比 INFO memory 里看到的 used_memory 高很多。曾經見過一個線上節點，used_memory 顯示8GB，但物理內存已經用了12GB，就是被碎片坑的。
二、檢測大 key：別等崩潰了才后悔，提前掃描是王道
1. 最簡單的命令：redis-cli --bigkeys
這個命令是 Redis 自帶的大 key 掃描工具，原理是對每個數據庫的不同數據類型做抽樣檢查。比如檢查 string 類型時，會隨機選一些 key 用 STRLEN 查看長度；檢查集合類型時，用 HLEN、LLEN、SCARD、ZCOUNT 統計元素數量。注意要加 -i 0.1 參數，這表示每次掃描間隔0.1秒，避免阻塞主線程。不過它有個缺點：只能告訴你每個數據類型的最大 key 是誰，沒辦法掃描所有大 key，適合做初步排查。
# 掃描所有數據庫，每隔0.1秒掃描一次
redis-cli -h 127.0.0.1 -p 6379 --bigkeys -i 0.12. 更精準的方案：自己寫掃描工具（附Python代碼）
如果需要全量掃描，就得用 SCAN 命令代替 KEYS *，因為 KEYS 會阻塞主線程，在生產環境用就是"自殺行為"。下面這段 Python 代碼可以掃描指定前綴的大 key，支持設置字符串長度閾值和集合元素數量閾值：
import redis
def scan_big_keys(redis_client, prefix, str_threshold=1024*1024, collection_threshold=10000):
big_keys = []
cursor = '0'
while cursor != 0:
cursor, keys = redis_client.scan(cursor=cursor, match=prefix + '*')
for key in keys:
type_ = redis_client.type(key)
if type_ == 'string':
length = redis_client.strlen(key)
if length > str_threshold:
big_keys.append((key, 'string', length))
elif type_ in ['hash', 'list', 'set', 'zset']:
count = 0
if type_ == 'hash':
count = redis_client.hlen(key)
elif type_ == 'list':
count = redis_client.llen(key)
elif type_ == 'set':
count = redis_client.scard(key)
elif type_ == 'zset':
count = redis_client.zcard(key)
if count > collection_threshold:
big_keys.append((key, type_, count))
return big_keys
# 使用示例
redis_client = redis.Redis(host='localhost', port=6379, db=0)
big_keys = scan_big_keys(redis_client, 'user:')
for key, type_, size in big_keys:
print(f"大key: {key}, 類型: {type_}, 大小: {size}")3. 可視化工具輔助：讓大 key 一目了然
如果覺得命令行太麻煩，可以用 RedisInsight（官方可視化工具）或者開源的 RedisDesktopManager，這些工具都有大 key 掃描功能，能生成直觀的圖表。比如 RedisInsight 的"Memory Analysis"模塊，能按數據類型展示內存占用分布，點擊某個類型就能看到具體的大 key 列表，適合團隊協作時給非技術同學演示。
三、治理大 key：分場景出招，不同類型有不同解法
（一）字符串類型大 key：能壓縮就壓縮，能拆分就拆分
案例：用戶詳情存成大 JSON
某電商項目把用戶詳情（包括收貨地址、訂單歷史、會員信息）存成一個大 JSON，單個 key 大小超過2MB。解決方案分兩步：
- 數據壓縮：先用 gzip 壓縮 JSON 字符串，壓縮后大小能降到500KB左右。Redis 提供了 COMPRESS 和 DECOMPRESS 命令（需要開啟 redis-module-recompress 模塊），不過更推薦在應用層處理，比如 Java 里用 GZIPOutputStream 和 GZIPInputStream。
// 壓縮數據
ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
GZIPOutputStream gzipOutputStream = new GZIPOutputStream(byteArrayOutputStream);
gzipOutputStream.write(userJson.getBytes());
gzipOutputStream.close();
byte[] compressedData = byteArrayOutputStream.toByteArray();
redisTemplate.opsForValue().set("user:123", compressedData);
// 解壓縮數據
byte[] data = redisTemplate.opsForValue().get("user:123");
ByteArrayInputStream byteArrayInputStream = new ByteArrayInputStream(data);
GZIPInputStream gzipInputStream = new GZIPInputStream(byteArrayInputStream);
BufferedReader reader = new BufferedReader(new InputStreamReader(gzipInputStream));
StringBuilder decompressedJson = new StringBuilder();
String line;
while ((line = reader.readLine()) != null) {
decompressedJson.append(line);
}- 按需拆分：把常用字段（比如用戶名、頭像）和不常用字段（比如三年前的訂單）分開存儲。比如用 user:123:base 存基礎信息，user:123:order:2023 存2023年的訂單，查詢時用 MGET 批量獲取，雖然多了幾個 key，但每次獲取的數據量小了，網絡傳輸速度快了很多。
避坑指南：別用 APPEND 命令往大字符串里追加數據
曾經有個項目用 APPEND 記錄用戶操作日志，每天往一個 key 里追加幾MB數據，一個月后這個 key 變成了50MB。APPEND 操作在字符串底層實現是動態擴展數組，當數組需要擴容時，會申請一塊更大的內存，把舊數據復制過去，再追加新數據。50MB的字符串每次擴容都要復制大量數據，CPU使用率直接飆升，后來改成按天拆分key，問題立刻解決。
（二）集合類型大 key：分桶存儲，別把雞蛋放一個籃子里
案例：千萬級用戶的標簽集合
某社交APP用 set 存儲每個用戶的興趣標簽，個別活躍用戶的標簽數量超過20萬。直接遍歷這個 set 時，Redis 主線程被阻塞了好幾秒。解決方案是"分桶+哈希取模"：
- 確定桶的數量：根據最大元素數量決定，比如每個桶最多存1萬條數據，20萬條就分20個桶。
- 計算桶編號：用 CRC32 算法對用戶ID取模，保證同一個用戶的標簽分布在同一個桶里（如果需要保證順序，用 hash_mod 時要考慮一致性）。
- 修改數據結構：把 set user:123:tags 改成 set user:123:tags:0 到 set user:123:tags:19，每個桶最多1萬條數據。
// 計算桶編號
long userId = 123;
int bucketCount = 20;
int bucketId = (int) (userId % bucketCount);
String bucketKey = "user:" + userId + ":tags:" + bucketId;
// 添加標簽
redisTemplate.opsForSet().add(bucketKey, "tag1", "tag2");
// 遍歷所有桶
for (int i = 0; i < bucketCount; i++) {
String key = "user:" + userId + ":tags:" + i;
Set<String> tags = redisTemplate.opsForSet().members(key);
// 處理每個桶的數據
}進階操作：用分片集群的路由規則優化
如果用的是 Redis Cluster，大 key 會被分配到固定分片上，分桶后可以讓不同的桶分布在不同分片，比如每個桶的 key 加上分片標識（user:123:tags:0:shard1），不過這種方法需要和集群架構深度結合，建議在架構設計階段就考慮大 key 問題。
（三）業務層面優化：從源頭減少大 key 的產生
- 分頁處理：比如用戶的消息列表，別把所有歷史消息都存到一個 list 里，改成按頁存儲，用 list:user:123:page:1、list:user:123:page:2，每次只取當前頁的數據。
- 時效性控制：給大 key 設置合理的過期時間，比如臨時緩存的大集合，用完就自動刪除，別讓它一直占著內存。
- 數據歸檔：像電商的歷史訂單，超過半年的可以歸檔到數據庫或文件存儲，Redis 里只存最近三個月的常用數據。
四、實戰案例：從崩潰到穩定，我們是怎么搞定大 key 的
背景：某直播平臺的禮物排行榜
直播間的禮物排行榜用 zset 存儲，每個直播間一個 key，里面存了所有送禮用戶的分數，個別熱門直播間的 zset 成員超過50萬。每天晚上高峰期，存儲排行榜的 Redis 節點頻繁觸發 OOM，導致整個集群不可用。
治理過程：
- 第一步：定位罪魁禍首 用前面提到的 Python 掃描工具，發現 room:123:gifts 這個 zset 有67萬成員，ZRANGE 操作平均耗時200ms，遠超 Redis 單次操作1ms的正常水平。
- 第二步：分桶+冷熱分離
- 按送禮時間分桶：最近1小時的實時數據存在 room:123:gifts:hot，1-24小時的數據存在 room:123:gifts:warm，超過24小時的歸檔到數據庫。
- 每個桶限制成員數量：hot桶最多存1萬條（只保留最新的1萬條實時數據），warm桶按小時分桶（room:123:gifts:warm:2025041010 表示2025年4月10日10點的數據）。
- 第三步：優化查詢邏輯 原來的業務直接查整個 zset 取Top100，現在改成先查 hot 桶和最近24個 warm 桶，合并后再取Top100。雖然多了幾次 ZUNIONSTORE 操作，但每個 zset 的成員數量都控制在1萬以內，操作耗時降到了10ms以下。
- 第四步：監控與預警 用 Prometheus + Grafana 監控每個 zset 的成員數量，設置預警：當單個 zset 成員超過8000時觸發報警，同時監控內存碎片率（mem_fragmentation_ratio），當超過1.5時自動觸發大 key 掃描。
治理效果：
- 內存使用率從95%降到60%，OOM 再也沒出現過。
- CPU 負載從平均80%降到20%，因為處理小集合的速度快了很多。
- 業務查詢延遲從200ms降到15ms，用戶刷新禮物榜再也不卡頓了。
五、避坑指南：這些大 key 相關的坑，千萬別踩！
1. 別迷信"大 key 一定是壞事"
有些場景下，合理的大 key 反而更高效。比如存儲一個1MB的圖片二進制數據，雖然是大 key，但比拆分成多個小 key 更節省內存（每個 key 本身有元數據開銷，Redis 中每個 key 大約占1KB內存）。所以治理大 key 要結合業務場景，不能一刀切。
2. 批量操作時注意"管道"的使用
用 pipeline 批量處理小 key 沒問題，但處理大集合時別濫用管道。比如用管道執行100次 HGETALL 一個有10萬字段的 hash，會導致客戶端內存飆升，因為所有結果會一次性返回。正確的做法是分批次處理，每次處理1000個字段，或者用 HSCAN 漸進式掃描。
3. 集群遷移時的大 key 陷阱
當需要給 Redis 集群擴容時，大 key 的遷移會導致源節點和目標節點之間產生大量網絡流量。比如一個10MB的大 key 遷移，需要先在源節點序列化，通過網絡傳輸，再在目標節點反序列化，這個過程可能會阻塞兩個節點的主線程。建議在低峰期遷移，并且對大 key 單獨處理（比如先刪除，遷移后再重新生成）。
4. 監控要關注這幾個關鍵指標
- used_memory：超過物理內存80%就該警惕了。
- mem_fragmentation_ratio：大于1.5說明內存碎片太多，需要清理或重啟（僅單節點有效，集群節點重啟要謹慎）。
- blocked_clients：如果這個值經常大于0，說明有慢操作阻塞主線程，很可能是處理大 key 導致的。
六、總結：防患于未然，比事后救火更重要
回顧這次治理經歷，最大的感悟是：大 key 問題就像房間里的大象，剛開始覺得"存幾個大集合沒關系"，等到出問題時已經積重難返。
最好的辦法是在項目初期就建立規范：
- 開發階段：設計數據結構時預估元素數量，超過1萬的集合類數據強制分桶。
- 測試階段：用壓測工具模擬大 key 場景，比如用 redis-benchmark 測試 LRANGE 10萬條數據的耗時。
- 上線階段：部署自動掃描腳本，每天凌晨掃描大 key，發現異常及時報警。
- 迭代階段：每次上線新功能，檢查是否引入了潛在的大 key（比如新增的集合類存儲）。
希望這篇文章能讓你少走彎路，下次再遇到 Redis 崩潰，記得先查大 key——相信我，十有八九是它在搞事情。
