凌晨兩點被電話叫起來原因是一條 Redis 慢查詢告警某條 HGETALL 命令耗時 800ms把接口 P99 從 120ms 頂?shù)搅?900ms。登上機器一看那個 Hash 里塞了 260 萬個 field整個 value 接近 300MB。這類事故在有一定體量的業(yè)務里幾乎避不開所以我常拿“Redis 大key的判定標準與多key拆分方案”這個話題去面候選人——不是考背誦而是看這個人有沒有真的在生產(chǎn)上救過火。這篇文章就把我在實際項目里踩過的、驗證過的、以及面試時聽到的好答案爛答案一次性攤開講清楚。大key這件事說穿了不復雜單個 key 承載的數(shù)據(jù)量或訪問量超出了 Redis 單線程模型能從容處理的范圍。但它牽扯出的東西很多——內(nèi)存分布、網(wǎng)絡帶寬、持久化、主從復制、集群槽位傾斜每一個都能獨立把服務打掛。多key拆分是治理手段里最主流的一種但它不是萬能藥拆錯了反而把簡單問題搞復雜。下面這些內(nèi)容適合三類人寫業(yè)務代碼時習慣hset一把梭的初中級開發(fā)、正在準備面試想搞明白原理的求職者以及線上已經(jīng)出現(xiàn)慢查詢需要緊急止血的運維同學。我會從判定標準講到拆分設計再落到四類數(shù)據(jù)結構的可直接抄的代碼最后把遷移和踩坑都過一遍。1. 大key的判定標準與被放大的三重危害1.1 多大算大三條不同口徑的判定線很多人面試時被問“多大算大key”條件反射答“超過 10KB”。這個答案太單薄因為 String 和 Hash 的“大”根本不是一回事。我一般按三個口徑分口徑類型經(jīng)驗閾值典型觸發(fā)的問題字節(jié)體積Stringvalue 10KB高頻訪問場景收緊到 1KB網(wǎng)絡往返耗時、帶寬占用元素數(shù)量Hash / List / Set / ZSet元素數(shù) 5000或總體積 1MBHGETALL、SMEMBERS、LRANGE 全量讀阻塞訪問熱度任意類型單 key QPS 5000單節(jié)點集群槽位熱點、單核 CPU 打滿這三條線要分開看。一條 100KB 的 String 如果每秒讀十萬次它比一個 5MB 但一天只讀一次的 Hash 危險得多反過來一個 200 萬元素的 Set 哪怕 QPS 只有 10一次SMEMBERS也能讓整個實例卡住半秒以上因為那 200 萬個元素的序列化和網(wǎng)絡發(fā)送全在 Redis 的單線程里做。字節(jié)線也不是拍腦袋定的。Redis 處理命令時value 需要走“讀取-序列化-寫入 socket 緩沖區(qū)”這條鏈10KB 大概對應一次 0.1ms 量級的處理而 1MB 就是 10ms 量級。業(yè)務側通常要求 Redis 單次操作控制在 1ms 以內(nèi)所以 10KB 是個比較務實的界。元素數(shù)量線的 5000 也是類似邏輯——5000 個短 field 拼起來差不多 100KB 到 300KB再大就該警惕。需要強調(diào)一點判定閾值必須跟業(yè)務場景綁定不能跨團隊照抄。緩存型業(yè)務比如商品詳情容忍度可以高一些因為讀放大有 CDN 和本地緩存頂著而計數(shù)型、會話型的場景1KB 都算大。我在某個內(nèi)容平臺項目里定的規(guī)則就是“String 8KB 或集合類 2000 元素一律進周巡檢名單”跑了一年多誤報率很低。1.2 危害拆解一次大key阻塞的完整鏈路光說“會阻塞”太籠統(tǒng)我把它拆成五條鏈路每一條都能對上真實現(xiàn)象。第一條是命令執(zhí)行阻塞。Redis 6.0 之后雖然引入了 IO 多線程處理網(wǎng)絡讀寫但命令執(zhí)行始終是單線程的。一個HGETALL返回 2MB 數(shù)據(jù)這 2MB 的遍歷、內(nèi)存拷貝、resp 協(xié)議編碼全在那一個線程里完成期間所有其他客戶端的命令都在排隊。2MB 大概 10~20ms如果這個 key 被高頻調(diào)用就變成持續(xù)性的排隊雪崩。第二條是網(wǎng)絡帶寬擠占。假設一個 200 萬元素的 Hash 被HGETALL每秒調(diào)用 50 次那就是 300MB × 50 15GB/s 的出流量。這個數(shù)字已經(jīng)超出絕大多數(shù)實例的網(wǎng)卡上限結果是所有正常的請求都跟著超時。帶寬打滿的表面現(xiàn)象往往是“偶發(fā)超時”“連接池被打穿”跟大key好像沒關系排查時特別容易走偏。第三條是刪除阻塞這條最容易被忽略。你用DEL刪一個 200 萬元素的 HashRedis 需要先釋放這 200 萬個對象的引用、回收內(nèi)存整個過程同步執(zhí)行實測能卡住兩三秒。正確做法是UNLINK它把內(nèi)存回收丟到后臺線程異步做主線程只做一次 key 摘除。Redis 4.0 才有 UNLINK老版本只能用SCAN 分批HDEL慢慢刪。第四條是持久化放大。RDB 落盤時大key會導致fork之后的寫時復制COW內(nèi)存膨脹因為父進程在 fork 期間只要有寫入被改動的內(nèi)存頁就要復制一份。一個 300MB 的 Hash 如果整體被改寫可能直接多出幾百 MB 的額外內(nèi)存極端情況下觸發(fā) OOM。AOF 也是同理大key的一次寫入會產(chǎn)生一條巨大的 AOF 記錄重寫和回放都會被拖慢。第五條是集群槽位傾斜。在集群模式下一個大key整體落在某一個槽上而槽又落到某一個節(jié)點上。結果是那個節(jié)點的內(nèi)存和 CPU 使用率遠高于其他節(jié)點擴容也沒用——因為熱點還是那一個槽。這種現(xiàn)象在監(jiān)控圖上非常典型所有節(jié)點的內(nèi)存都在 40%就一個節(jié)點 85%。1.3 面試時真正被考察的思維鏈我面人的時候問“你怎么處理大key”最想聽到的是一條完整的鏈怎么發(fā)現(xiàn)、怎么判定、怎么止血、怎么根治、怎么做長期防護。只答“拆成多個小key”的候選人我會追問“拆多少片、怎么算的、拆完原子性怎么辦”多半就答不上來了。比較理想的回答層次是這樣的先說發(fā)現(xiàn)手段--bigkeys掃描、MEMORY USAGE、慢日志、RDB 離線分析再說危害阻塞、帶寬、持久化、傾斜然后給治理方案拆分、壓縮、換存儲最后補一句預防寫入攔截、閾值告警、編碼規(guī)范。這條鏈能完整走下來的人基本上手上是真管過 Redis 的。2. 拆分方案的整體設計先定維度再定粒度2.1 三條拆分主線及其適用邊界拆分不是只有“按哈希取?！币粭l路。我把它歸成三條主線選哪條取決于數(shù)據(jù)結構和讀寫模式。第一條是業(yè)務維度拆分。這是最自然的方式比如按用戶 ID 拆、按租戶拆、按業(yè)務線拆。典型例子是用戶會話session:{uid}本身就是按用戶分開的天然不構成大key。真正需要業(yè)務拆分的場景是“一個大對象里塞了多個業(yè)務域的數(shù)據(jù)”比如商品詳情里既有基礎屬性又有營銷信息又有庫存快照正確做法是把它們拆成獨立 key各自設不同的過期時間。第二條是哈希分桶拆分。適合單個業(yè)務對象的內(nèi)部結構無法再細分的情況比如一個用戶的畫像標簽有 5000 個字段。做法是對 field 名或元素本身做哈希取模落到 N 個桶里每個桶是一個獨立的 key。這種方式拆分均勻度高代價是失去整體的原子性和一次性讀取能力。第三條是 value 內(nèi)部切片。主要針對超大 String比如一個 8MB 的 JSON 文檔或一張 Base64 編碼的圖片。做法是按固定字節(jié)數(shù)切成若干片每片一個 key讀取時重新拼裝。還有一條補充思路值得單獨提冷熱分離。一個 5000 字段的對象實際高頻訪問的可能只有 20 個字段剩下的都是長尾。那就把熱字段拎出來單獨存一個小 Hash冷字段留在原地或者挪到冷存儲。這個方案對讀性能提升最明顯改造量也最小但前提是你得先摸清楚訪問分布——MONITOR采樣或者客戶端埋點都能拿到。2.2 桶數(shù)量的計算兩個約束取最大值“拆幾個桶”是最容易被敷衍過去的環(huán)節(jié)。我見過有人隨手拆 10 個結果單桶還是 20 萬 field等于沒拆。正確的算法是同時滿足兩個約束約束一單桶元素數(shù) ≤ 上限比如 1000約束二單桶字節(jié)數(shù) ≤ 上限比如 1MB桶數(shù) N max(ceil(總元素數(shù) / 元素上限), ceil(總體積 / 字節(jié)上限))然后向上取到 2 的冪舉個具體例子。某項目有個用戶標簽 Hash200 萬個 field平均每個 field 加 value 約 100 字節(jié)總體積約 200MB。代入公式按元素數(shù)2,000,000 / 1000 2000 個桶按字節(jié)數(shù)200MB / 1MB 200 個桶取最大值 2000向上取 2 的冪得到 2048拆完平均每桶約 977 個 field、97KB 左右完全在安全范圍內(nèi)。選 2 的冪是為了把取模換成位與運算hash 2047比hash % 2048快一截雖然 Redis 側其實不差這點但客戶端側調(diào)用量大的時候還是有點意義。注意桶數(shù)量一旦上線就盡量別再改。因為桶號是靠取模算出來的桶數(shù)從 2048 改成 1024所有歷史數(shù)據(jù)的桶號全變等于要做一次全量遷移。所以初期寧可多拆一點留出增長空間。2.3 拆分前必須先回答的四個問題我每次做拆分方案評審都會強制要求把這四個問題寫進文檔里答不上來就不許動手。問題一讀模式是單字段讀還是整體讀如果業(yè)務 90% 是整體讀比如渲染整個詳情頁那拆成多個 key 之后需要 N 次往返或者一次 pipeline端到端延遲不一定下降這時候冷熱分離比硬拆更合適。如果主要是單字段讀拆分收益極大因為讀一個字段只需要訪問一個桶。問題二需不需要跨桶原子性如果需要就必須在 key 里加 hash tag比如profile:{12345}:0保證同一個對象的多個桶落在同一個槽上這樣才能用 Lua 或者 MULTI 包起來。但加了 hash tag 就意味著所有桶壓在同一個節(jié)點上失去了分散壓力的意義。這是個明確的權衡點必須顯式?jīng)Q策。問題三有沒有順序性要求List 拆片時尤其要注意。如果按時間窗口切片feed:{uid}:202506這種LPUSH的順序天然保持新數(shù)據(jù)進新片沒問題。但如果按成員哈希切片LRANGE出來的順序就完全亂了。所以 List 一般不按哈希拆只按時間或按序號區(qū)間拆。問題四有沒有全量遍歷需求如果業(yè)務存在“遍歷所有元素”的操作比如統(tǒng)計、導出、對賬拆分之后就要遍歷 N 個桶SCAN的復雜度上升。這時候要么維護一個索引 key 記錄所有桶號要么接受遍歷成本上升。3. 四類數(shù)據(jù)結構的可直接落地的拆分實踐3.1 String 超大 value切片存儲與拼裝讀取某項目的商品詳情緩存是一個 8MB 的 JSON。直接GET的耗時接近 100ms而且每次大促前預熱時會持續(xù)壓滿帶寬。改造方案是按 64KB 切片。切片大小的選擇有講究。太小會導致 key 數(shù)量爆炸、pipeline 命令數(shù)過多太大則單片仍然偏重。64KB 到 256KB 是比較舒服的區(qū)間8MB 切成 64KB 是 128 片。public class ChunkedStringStore { private static final int CHUNK_SIZE 64 * 1024; private static final String PREFIX prod:detail:; private final StringRedisTemplate redis; public ChunkedStringStore(StringRedisTemplate redis) { this.redis redis; } public void put(String id, byte[] payload, Duration ttl) { int total (payload.length CHUNK_SIZE - 1) / CHUNK_SIZE; MapString, String batch new HashMap(total 1); for (int i 0; i total; i) { int from i * CHUNK_SIZE; int to Math.min(from CHUNK_SIZE, payload.length); byte[] slice Arrays.copyOfRange(payload, from, to); batch.put(chunkKey(id, i), Base64.getEncoder().encodeToString(slice)); } batch.put(metaKey(id), String.valueOf(total)); redis.executePipelined((RedisCallbackObject) conn - { batch.forEach((k, v) - { byte[] kb k.getBytes(StandardCharsets.UTF_8); byte[] vb v.getBytes(StandardCharsets.UTF_8); conn.stringCommands().setEx(kb, ttl.getSeconds(), vb); }); return null; }); } public byte[] get(String id) { String totalStr redis.opsForValue().get(metaKey(id)); if (totalStr null) { return null; } int total Integer.parseInt(totalStr); ListString keys new ArrayList(total); for (int i 0; i total; i) { keys.add(chunkKey(id, i)); } ListString slices redis.opsForValue().multiGet(keys); ByteArrayOutputStream out new ByteArrayOutputStream(total * CHUNK_SIZE); for (String s : slices) { if (s null) { return null; } out.writeBytes(Base64.getDecoder().decode(s)); } return out.toByteArray(); } private String chunkKey(String id, int idx) { return PREFIX id :seg: idx; } private String metaKey(String id) { return PREFIX id :meta; } }幾個實操細節(jié)必須說明。第一切片是按字節(jié)切的絕對不能在中途把每一片單獨按 UTF-8 解碼——一個中文字符占 3 個字節(jié)很可能被切成兩半解碼就出亂碼。正確的做法是全程保持byte[]全部拼完再統(tǒng)一 decode。上面這段代碼用 Base64 編碼后存 String是為了兼容StringRedisTemplate如果直接用RedisTemplateString, byte[]可以省掉編解碼開銷。第二片數(shù)要單獨存一個 meta key否則讀的時候根本不知道有多少片。meta key 的 TTL 要跟數(shù)據(jù)片一致但不能反過來——如果 meta 先過期了殘留的數(shù)據(jù)片就變成孤兒 key只能靠定期掃描清理。第三讀的時候用multiGet一次發(fā)出所有片請求StringRedisTemplate底層會走 pipeline128 次往返壓縮成 1 次。如果不走集群模式這是最省事的方案。3.2 Hash 巨型對象二次哈希分桶用戶畫像、購物車、配置表這類數(shù)據(jù)基本都用 Hash 存。當 field 數(shù)量漲到幾十萬HGETALL就成了定時炸彈。分桶方案如下public class ShardedHash { private static final int BUCKETS 2048; private static final int MASK BUCKETS - 1; private static final String PREFIX profile:; private final StringRedisTemplate redis; public ShardedHash(StringRedisTemplate redis) { this.redis redis; } private int bucketOf(String field) { int h field.hashCode(); h ^ (h 16); return h MASK; } private String bucketKey(String uid, int bucket) { return PREFIX uid : bucket; } public void put(String uid, String field, String value) { redis.opsForHash().put(bucketKey(uid, bucketOf(field)), field, value); } public String get(String uid, String field) { Object v redis.opsForHash().get(bucketKey(uid, bucketOf(field)), field); return v null ? null : v.toString(); } public MapString, String getAll(String uid) { ListString keys new ArrayList(BUCKETS); for (int i 0; i BUCKETS; i) { keys.add(bucketKey(uid, i)); } ListObject results redis.executePipelined((RedisCallbackObject) conn - { for (String k : keys) { conn.hashCommands().hGetAll(k.getBytes(StandardCharsets.UTF_8)); } return null; }); MapString, String merged new HashMap(); for (Object r : results) { if (r instanceof Map) { ((Map?, ?) r).forEach((k, v) - merged.put(String.valueOf(k), String.valueOf(v))); } } return merged; } }這里最關鍵的實現(xiàn)點是哈希函數(shù)的選擇。String.hashCode()對短字符串分布還行但對形如tag_0001、tag_0002這種有規(guī)律的 field 名低位容易聚集。所以我在上面做了h ^ (h 16)的高低位混淆跟 HashMap 里那套擾動函數(shù)是一個思路。如果 field 名規(guī)律性特別強建議直接上 CRC32 或者 MurmurHash分布更均勻。第二個點是空桶的處理。2048 個桶里如果這個用戶只有 30 個字段那 2018 個桶都是不存在的空 key。HGETALL一個不存在的 key 返回空 Map代價很小但 2048 次 pipeline 調(diào)用仍然是實打?qū)嵉拈_銷。所以實際項目里我一般會做一個自適應桶數(shù)不是固定的 2048而是根據(jù)對象的實際字段數(shù)量動態(tài)算。字段少于 1000 的直接單 key 存超過才分桶桶數(shù)按 2.2 節(jié)的公式算出來存到 meta 里。第三個點是HGETALL的替代。很多業(yè)務其實只需要讀部分字段那就用HMGET但HMGET要求所有 field 在同一個 key 里。分桶之后只能按桶分組每個桶發(fā)一次HMGET然后 pipeline 打包。寫起來啰嗦但比全量讀便宜得多。3.3 List / ZSet / Set按時間片和成員哈希切片這三類結構各有各的拆法不能混用一套模板。List 最合適按時間切片。消息流、操作日志、評論列表這類數(shù)據(jù)天然有時間維度key 設計成feed:{uid}:{yyyyMM}每個月一個 ListLPUSH新數(shù)據(jù)進當前月讀的時候按需拼最近幾個月。這樣單 key 的元素數(shù)天然被時間窗口限制住了而且歷史數(shù)據(jù)可以按需設置更長的 TTL 甚至歸檔。要注意的是跨片的范圍查詢想讀最近 100 條可能需要讀 2 到 3 個片然后合并好在LRANGE支持負數(shù)索引實現(xiàn)起來不復雜。ZSet 按周期切分最自然。排行榜類需求日榜rank:{yyyyMMdd}、周榜rank:{yyyyWW}、月榜rank:{yyyyMM}各存各的互不干擾。缺點是跨周期的聚合排序需要應用層歸并。如果業(yè)務確實需要“全站總榜”那就得用定時任務把周期榜的結果匯總到一個總榜里而不是讓客戶端去實時歸并。Set 只能按成員哈希拆。標簽集合、好友關系這類數(shù)據(jù)沒有天然的時間序只能對成員本身做哈希。tags:{id}:{bucket}判斷是否包含某成員時先算出桶號再SISMEMBER。這里有個必須接受的代價SINTER、SUNION、SDIFF這些集合運算徹底沒法用了因為參與運算的兩個集合分片規(guī)則不同。如果業(yè)務強依賴集合運算那就老老實實別拆改用別的方案比如用 BitMap 或者換到支持集合運算的存儲。3.4 實在拆不動的場景壓縮、換存儲與協(xié)議優(yōu)化不是所有大key都能拆。有三種情況我建議放棄拆分換思路。第一種是強事務場景。比如庫存扣減、賬戶余額它們的正確性依賴單 key 的原子操作。拆了之后跨 key 的原子性只能靠 Lua 或者分布式鎖復雜度暴漲出問題的概率遠高于收益。這類 key 本來就該小——余額只有一個數(shù)字怎么會大如果大了說明設計有問題該拆的是業(yè)務模型不是存儲結構。第二種是超大二進制對象。視頻、圖片、安裝包這類東西根本不該進 Redis。正確的做法是存到對象存儲Redis 里只放一個指針URL 或 ID。我見過有人把 PDF 文件 Base64 之后塞進 Redis一個 key 十幾 MB這種屬于用錯了工具。第三種是必須整體讀的復雜聚合。如果一個 5MB 的 JSON 每次都要整體反序列化成對象那切片和拼裝只是把一次大傳輸變成多次小傳輸總字節(jié)數(shù)沒變CPU 側的序列化開銷反而更高。這時候更該做的是壓縮——開啟 value 壓縮比如用 Snappy、LZ4 在應用層壓一遍再存通常能壓到原來的 20% 到 30%比拆分省事得多?；蛘呖紤]把這份數(shù)據(jù)從緩存層挪到搜索層、文檔層。4. 遷移落地雙寫、灰度與一致性校驗三板斧4.1 雙寫期的讀寫路由設計拆分方案想得再漂亮上線才是真正的考驗。歷史數(shù)據(jù)不能停機遷移所以必須要有一段雙寫期。路由邏輯我用一個統(tǒng)一的組件收口public class SplitRouter { private final StringRedisTemplate redis; private final SplitSwitch splitSwitch; public void write(String uid, String field, String value) { if (splitSwitch.isDualWrite(uid)) { redis.opsForHash().put(legacyKey(uid), field, value); } if (splitSwitch.isSplitRead(uid)) { shardedHash.put(uid, field, value); } } public String read(String uid, String field) { if (splitSwitch.isSplitRead(uid)) { String v shardedHash.get(uid, field); if (v ! null) { return v; } return legacyRead(uid, field); } return legacyRead(uid, field); } }設計要點有三個。第一寫路徑以新結構為準舊結構只做兼容即新結構寫成功、舊結構寫失敗可以容忍反過來不行。第二讀路徑先讀新結構miss 才回源舊結構這樣遷移過程中不會出現(xiàn)讀到空數(shù)據(jù)的情況。第三舊 key 的 TTL 不能直接刪掉要持續(xù)續(xù)期否則雙寫期間一部分用戶的數(shù)據(jù)會因為舊 key 過期而重新走回源邏輯讀放大嚴重。雙寫期的長度取決于數(shù)據(jù)規(guī)模和訪問頻率。一般我建議至少覆蓋一個完整的訪問周期比如一周確保所有活躍用戶的數(shù)據(jù)都被自然遷移過一遍。對于長期不活躍的用戶可以在雙寫結束時跑一次全量遷移腳本兜底。4.2 灰度切流與回滾預案灰度必須按用戶 ID 取模來切不能按流量隨機切。原因是同一個用戶的數(shù)據(jù)必須始終走同一套邏輯否則會出現(xiàn)“這次讀新結構、下次讀舊結構”的抖動數(shù)據(jù)對不上?；叶裙?jié)奏我一般這么排5% 跑一天觀察錯誤率和延遲沒問題放到 20% 跑一天然后 50%、100%。每一檔都要盯三個指標新結構的HGET延遲分布、舊結構的讀命中率應該逐步下降、以及雙寫的失敗計數(shù)?；貪L預案必須在上線前就準備好而不是出事再想。具體就是配置中心里放一個開關把isSplitRead全部置為 false讀流量瞬間全部回落到舊結構。這時候新結構還留著不影響數(shù)據(jù)等排查清楚再重新灰度。這個開關必須做到秒級生效不能依賴重啟。注意回滾開關只管讀不管寫。雙寫邏輯一旦開啟就不建議關掉因為關掉之后新結構就停止更新再想恢復又得重新補數(shù)據(jù)。所以開關要設計成“讀寫分離的兩個開關”而不是一個總開關。4.3 一致性校驗的腳本實現(xiàn)思路雙寫期間最怕的是“以為寫進去了其實沒有”。所以要跑對賬。校驗的核心思路是遍歷舊結構的所有用戶把新結構的多個桶拼起來跟舊結構做摘要比對。public class ConsistencyChecker { public void check(String uid) { MapString, String legacy redis.opsForHash().entries(profile: uid); MapString, String split shardedHash.getAll(uid); if (!legacy.keySet().equals(split.keySet())) { log.warn(field set mismatch, uid{}, legacy{}, split{}, uid, legacy.size(), split.size()); return; } for (Map.EntryString, String e : legacy.entrySet()) { String other split.get(e.getKey()); if (!Objects.equals(e.getValue(), other)) { log.warn(value mismatch, uid{}, field{}, uid, e.getKey()); } } } }對賬腳本要注意兩點。第一不能一次跑全量要用SCAN分批每批 500 個 key跑完 sleep 一下避免把實例壓垮。第二比對結果的輸出要做聚合不能每條差異都打一行日志——線上跑的時候差異可能是幾十萬條日志直接把磁盤寫滿。做法是每個 uid 只記錄差異數(shù)量和前三條樣例。發(fā)現(xiàn)差異之后的修復策略我傾向于“以新結構為準重寫舊結構”——因為新結構是未來的權威數(shù)據(jù)源。但如果差異集中在某個時間段那說明雙寫邏輯有 bug這時候應該先修代碼再修復數(shù)據(jù)。5. 大key的發(fā)現(xiàn)手段與長期防護體系5.1 五種發(fā)現(xiàn)手段的適用場景對比治理的前提是能發(fā)現(xiàn)。我把常用的發(fā)現(xiàn)手段列一下各有各的適用范圍。手段命令/方式優(yōu)點局限內(nèi)置掃描redis-cli --bigkeys開箱即用按類型給出最大 key基于 SCAN 采樣可能漏掉只報最大不報全部內(nèi)存查詢MEMORY USAGE key SAMPLES 0精確到單 key 字節(jié)數(shù)需要先知道 key 名全量掃代價高慢日志SLOWLOG GET直接反映線上真實耗時只能抓到慢的命令抓不到“快但頻繁”的大key離線分析解析 RDB 文件全量精確不影響線上需要額外機器有延遲客戶端埋點統(tǒng)計命令參數(shù)長度能抓寫入側提前攔截需要改代碼接入實際生產(chǎn)里我是組合用的。日常巡檢跑--bigkeys一周一次出個 Top 50 名單慢日志實時采集超過 50ms 的命令全部上報RDB 離線分析每月一次做精確摸底。三者交叉驗證基本不會漏。MEMORY USAGE那個命令要多說一句它默認會采樣估算加SAMPLES 0才是全量精確計算但代價是可能阻塞。所以線上千萬別對著幾百萬元素的 key 執(zhí)行我吃過這個虧——一次MEMORY USAGE卡了 1.2 秒直接觸發(fā)了主從切換。5.2 寫入側的硬攔截與閾值告警發(fā)現(xiàn)是被動的防護要主動。我在編碼層加了兩道閘。第一道是序列化層的體積檢查。所有寫 Redis 的操作都走一個統(tǒng)一的RedisWriter組件寫入前檢查 value 的字節(jié)數(shù)超過配置的閾值就直接拋異常并打點讓問題在測試環(huán)境就暴露而不是等到線上。閾值按業(yè)務配置緩存類給 16KB會話類給 4KB。public void setEx(String key, String value, long seconds) { int bytes value.getBytes(StandardCharsets.UTF_8).length; if (bytes maxValueBytes) { metrics.counter(redis.write.reject).increment(); throw new IllegalStateException( value too large: bytes bytes, key key); } redis.opsForValue().set(key, value, seconds, TimeUnit.SECONDS); }第二道是元素數(shù)量的軟告警。集合類寫入時無法預知最終大小所以改成寫后檢查每寫入 1000 次采樣一次HLEN超過 5000 就發(fā)告警超過 50000 就自動觸發(fā)遷移任務。這個邏輯聽起來粗糙但實測非常有效——大部分大key都是慢慢長起來的早期發(fā)現(xiàn)處理成本極低。還有一條容易被忽略的給所有集合類 key 強制設置 TTL。我見過太多“臨時數(shù)據(jù)”因為忘了設過期時間跑了兩年變成幾百萬條。在封裝層里把 TTL 做成必填參數(shù)比任何事后治理都管用。6. 高頻追問與踩坑實錄6.1 拆分之后的批量操作陷阱最容易踩的坑是MGET和集群的CROSSSLOT報錯。把一個大 String 拆成 128 片之后如果直接redisTemplate.opsForValue().multiGet(keys)在集群模式下會直接拋異常因為這 128 個 key 分布在不同的槽上。解決方案有兩條。方案 A 是給所有分片 key 加 hash tag比如prod:{12345}:seg:0這樣同一個商品的 128 片全部落在同一個槽上MGET可以正常執(zhí)行也支持 Lua 原子操作。代價是這個商品的所有分片壓在同一個節(jié)點如果這個商品是爆款節(jié)點就成了熱點。方案 B 是不加 tag改用 pipeline 逐個 GET。這樣分片自然分散到不同節(jié)點壓力均勻但拿不到原子性而且 pipeline 的往返次數(shù)雖然被壓縮成 1 次命令處理仍然是 N 次。我的選擇標準是這樣的單次讀取的分片數(shù)小于 50走方案 A 加 tag因為延遲更低分片數(shù)超過 50 或者是熱點數(shù)據(jù)走方案 B 分散壓力。這個取舍沒有標準答案必須結合具體數(shù)據(jù)量判斷。6.2 原子性、Lua 與事務的邊界拆分之后原本一條HSET能搞定的事可能要寫 2 個 key。如果業(yè)務要求要么全成功要么全失敗就得用 Lua 或者MULTI/EXEC。但這兩個機制在集群模式下都要求所有 key 在同一個槽所以又回到了 hash tag 的老問題。有個更隱蔽的坑Lua 腳本里的 key 數(shù)量是有上限的雖然官方?jīng)]明確說死但腳本執(zhí)行期間會阻塞整個實例腳本里操作幾十個 key 會讓阻塞時間線性增長。所以我的經(jīng)驗是Lua 只用于 2 到 5 個 key 的小規(guī)模原子操作超過這個數(shù)就該重新設計數(shù)據(jù)模型而不是硬用 Lua 兜。還有一個反直覺的結論大部分所謂的“原子性需求”其實是偽需求。用戶畫像的多個字段之間本來就沒有強一致要求晚幾百毫秒更新完全可接受。真正需要原子的只有計數(shù)、庫存這類場景而這類數(shù)據(jù)本來就不該大。所以在設計拆分方案時先質(zhì)疑一下“是否真的需要原子”往往能省掉一半復雜度。6.3 拆分過度反而更慢的真實案例這個坑我必須單獨講因為它是我自己踩的。早期做用戶標簽拆分時我把一個只有 200 個字段的 Hash 也套用了分桶方案拆成了 8 個桶。結果上線后發(fā)現(xiàn)接口 P99 反而漲了 15ms——原因很簡單原本一次HGETALL能拿到的數(shù)據(jù)現(xiàn)在要發(fā) 8 次 pipeline 請求雖然網(wǎng)絡往返被合并了但 Redis 側的命令解析、槽位路由、結果聚合全都翻了 8 倍。后來復盤定了一條鐵律只有當 key 真的超過閾值才拆且拆分收益必須大于拆分成本。200 個字段的 Hash 完全沒必要拆5000 個字段以上才進拆分流程。這個閾值后來寫進了團隊的編碼規(guī)范避免新人無腦照搬。6.4 常見問題速查表現(xiàn)象可能原因排查手段處置動作接口偶發(fā)超時無明顯規(guī)律大key 的HGETALL阻塞主線程查慢日志看是否有大 value 命令拆分或改為HMGET按需讀集群單節(jié)點內(nèi)存異常高大key 導致槽位傾斜--bigkeys掃一遍對比各節(jié)點內(nèi)存拆分打散或加 hash tag 后定向遷移刪除 key 時服務卡頓DEL同步釋放大量內(nèi)存觀察刪除時段的主線程阻塞指標改用UNLINK老版本用分批HDEL主從延遲突然增大大key 寫入產(chǎn)生巨大復制包查主從offset差值拆分寫入、降低單次寫入體積雙寫后數(shù)據(jù)對不上路由邏輯或桶號計算不一致跑一致性校驗腳本抽樣比對修代碼后以新結構為準重刷舊數(shù)據(jù)分片后讀延遲反而升高拆分過度往返次數(shù)增加統(tǒng)計單次請求的分片數(shù)量合并小桶或撤銷不必要的拆分RDB 落盤時內(nèi)存暴漲fork 期間大key 的 COW 復制觀察fork前后的內(nèi)存曲線拆分、開啟壓縮、調(diào)整save策略最后再分享一個我在實際項目中的體會大key治理這件事技術方案只占三成剩下七成靠的是規(guī)范約束和早期發(fā)現(xiàn)。我見過太多團隊把拆分方案寫得非常漂亮但因為沒有寫入側的硬攔截半年之后新的大key 又長出來了等于白干。所以真正有效的做法是把閾值檢查、TTL 強制、巡檢告警這三件事固化到基礎組件里讓業(yè)務方想寫大key 都寫不進去這比事后救火省心一百倍。