Redis 內(nèi)存優(yōu)化與性能調(diào)優(yōu)編碼轉(zhuǎn)換、內(nèi)存碎片與慢查詢的定位鏈路1. 從一次線上告警說起假設(shè)你維護一個訂單系統(tǒng)某天凌晨收到告警Redis 實例內(nèi)存使用率 92%同時接口平均響應(yīng)時間從 8ms 漲到了 60ms。值班同事的第一反應(yīng)通常是下面幾種把maxmemory調(diào)大讓實例先“撐過去”重啟實例重置 used_memory懷疑是流量上漲直接擴機器。這些動作可能在短時間內(nèi)讓監(jiān)控恢復(fù)綠線但一兩周后同樣的問題會再次出現(xiàn)。原因在于它們都跳過了最關(guān)鍵的判斷內(nèi)存到底被誰占用了是真實業(yè)務(wù)數(shù)據(jù)增長還是編碼方式不合理、碎片率過高、過期 Key 沒被及時清理慢又是哪一種慢是單條命令本身耗時還是排隊、網(wǎng)絡(luò)、主從同步造成的本文不打算把 Redis 調(diào)優(yōu)講成一份參數(shù)清單而是先給出一條可以復(fù)述的定位鏈路。你可以把它理解成一次體檢先看整體內(nèi)存形狀再判斷數(shù)據(jù)結(jié)構(gòu)是否用了低效編碼然后檢查內(nèi)存碎片是否過高最后用慢查詢?nèi)罩炬i定具體命令。整條鏈路串起來才是一個可復(fù)用的工程方法。為了便于后續(xù)展開先記住一個最小模型客戶端命令 | v 命令執(zhí)行線程 -- 讀寫 Redis 對象 -- 編碼可能發(fā)生轉(zhuǎn)換 | | | v | 內(nèi)存分配 / 釋放 | | v v 慢查詢?nèi)罩?-- 耗時超閾值 內(nèi)存碎片率變化 | | v v 定位具體命令 觸發(fā)淘汰策略2. 先建立整體框架一次寫入會經(jīng)過哪些環(huán)節(jié)Redis 的內(nèi)存問題很少是單一原因?qū)е碌?。它更像一個鏈條一次寫入命令進入后先執(zhí)行命令邏輯然后決定用哪種內(nèi)部結(jié)構(gòu)保存數(shù)據(jù)隨著元素增多編碼可能從緊湊結(jié)構(gòu)轉(zhuǎn)換為通用結(jié)構(gòu)內(nèi)存占用隨之上升元素刪除或過期后釋放的內(nèi)存不一定能立刻被復(fù)用于是產(chǎn)生碎片當(dāng)內(nèi)存達到上限淘汰策略開始工作如果某條命令因為數(shù)據(jù)量過大而變慢它就會被 slowlog 記錄下來。把整體拆成四部分更容易理解對象與編碼層Redis 為了兼顧內(nèi)存和性能對同一種邏輯類型提供了多種底層編碼例如列表在小數(shù)據(jù)量時用緊湊列表變大后轉(zhuǎn)為快速鏈表。內(nèi)存分配與回收層內(nèi)存由分配器管理頻繁增刪會造成碎片碎片率過高會浪費物理內(nèi)存。淘汰與過期層達到maxmemory后觸發(fā)淘汰過期 Key 通過惰性刪除和定期刪除結(jié)合清理?？捎^測層INFO、MEMORY USAGE、SLOWLOG、LATENCY等命令幫助我們把現(xiàn)象對應(yīng)到原因。這四個部分并非獨立存在。編碼轉(zhuǎn)換會直接影響內(nèi)存占用和碎片產(chǎn)生碎片率又會影響淘汰觸發(fā)時機而淘汰和過期清理如果執(zhí)行不當(dāng)又可能造成延遲尖刺并進入慢查詢?nèi)罩尽＠斫馑鼈冎g的連接比單獨記住某個參數(shù)更重要。3. 編碼轉(zhuǎn)換為什么同樣 100 個元素內(nèi)存差好幾倍3.1 一句話模型可以先把它理解成Redis 對每種數(shù)據(jù)類型都準(zhǔn)備了兩套甚至多套“收納盒”小數(shù)據(jù)用緊湊盒省內(nèi)存大數(shù)據(jù)用性能盒操作更快。超過閾值時Redis 自動把數(shù)據(jù)從緊湊盒搬到性能盒這個過程叫編碼轉(zhuǎn)換。3.2 觸發(fā)條件與常見編碼以常見的列表和哈希為例數(shù)據(jù)類型小數(shù)據(jù)編碼大數(shù)據(jù)編碼常見轉(zhuǎn)換觸發(fā)條件Listlistpack早期為 ziplistquicklist元素個數(shù)或單個元素長度超過閾值Hashlistpack早期為 ziplisthashtable字段數(shù)或字段值長度超過閾值Setintsethashtable元素非整數(shù)或數(shù)量超閾值ZSetlistpack早期為 ziplistskiplist元素數(shù)或成員長度超閾值閾值由配置項控制例如hash-max-listpack-entries、hash-max-listpack-value、list-max-listpack-size、set-max-intset-entries、zset-max-listpack-entries。不同 Redis 版本默認值和名稱略有差異生產(chǎn)環(huán)境必須以當(dāng)前版本redis.conf為準(zhǔn)。3.3 一個可復(fù)現(xiàn)的實驗下面用redis-cli做一個最小實驗觀察哈希從緊湊編碼轉(zhuǎn)為通用編碼后內(nèi)存的變化。前置條件是本地或測試環(huán)境有一個可執(zhí)行redis-cli的 Redis 實例版本為 7.x。# 步驟一寫入少量字段查看編碼和內(nèi)存redis-cli DEL demo:hash redis-cli HSET demo:hash f1 v1 f2 v2 redis-cli OBJECT ENCODING demo:hash redis-cli MEMORY USAGE demo:hash# 預(yù)期輸出示例# listpack# (integer) 96# 步驟二寫入大量字段再次查看foriin$(seq1500);doredis-cli HSET demo:hashfield_$ivalue_$i/dev/nulldoneredis-cli OBJECT ENCODING demo:hash redis-cli MEMORY USAGE demo:hash# 預(yù)期輸出示例# hashtable# (integer) 32768關(guān)鍵步驟解釋OBJECT ENCODING用來查看當(dāng)前編碼MEMORY USAGE用來查看單個 Key 占用內(nèi)存。第一次輸出listpack說明數(shù)據(jù)量小、仍然使用緊湊結(jié)構(gòu)第二次輸出hashtable說明已經(jīng)發(fā)生轉(zhuǎn)換。內(nèi)存從幾十字節(jié)漲到幾萬字節(jié)不完全是數(shù)據(jù)本身變多還包括哈希表結(jié)構(gòu)、指針和預(yù)分配帶來的額外開銷。適用場景這個實驗適合在測試環(huán)境驗證業(yè)務(wù) Key 的編碼是否符合預(yù)期尤其適合字段數(shù)量接近閾值的場景。容易改錯的地方是直接用MEMORY USAGE比較不同版本可能得到不同結(jié)果因為采樣方式和版本實現(xiàn)會變化另外轉(zhuǎn)換是單向的一旦變成hashtable即使隨后刪掉大部分字段編碼通常也不會自動退回listpack。3.4 設(shè)計取舍緊湊編碼省內(nèi)存但每次修改都可能涉及整塊內(nèi)存搬移時間復(fù)雜度更接近 O(N)通用編碼操作快但內(nèi)存開銷大。Redis 用閾值來平衡這兩者。工程上真正要做的是判斷你的業(yè)務(wù)數(shù)據(jù)是否長期停留在“接近閾值但未超過”的位置。如果一個 Hash 有 400 個字段恰好沒觸發(fā) 500 的默認閾值但字段值較長內(nèi)存已經(jīng)不小這時可以考慮拆分成多個 Key或者顯式調(diào)整閾值并做壓測。4. 內(nèi)存碎片used_memory 和 RSS 為什么會差那么多4.1 碎片是怎么產(chǎn)生的內(nèi)存碎片可以理解成一間倉庫里堆滿了大小不一的箱子很多小空隙沒法再放進新的大箱子。Redis 也類似不斷創(chuàng)建和刪除不同大小的對象時分配器釋放的內(nèi)存塊可能無法被后續(xù)請求復(fù)用于是操作系統(tǒng)看到的進程 RSS 遠大于 Redis 自己統(tǒng)計的 used_memory。判斷碎片程度主要看兩個指標(biāo)used_memoryRedis 分配器統(tǒng)計的已用內(nèi)存used_memory_rss操作系統(tǒng)視角的常駐內(nèi)存碎片率近似為used_memory_rss / used_memory。通常碎片率在 1.0 到 1.5 之間可以接受持續(xù)高于 1.5 且業(yè)務(wù)有明顯增刪波動時就需要關(guān)注。4.2 一次診斷流程示例下面是一個完整的診斷流程輸入是一臺內(nèi)存持續(xù)高于預(yù)期的 Redis 實例步驟是讀取信息、計算碎片率、查看分配器狀態(tài)結(jié)果用于決定是否開啟主動碎片整理。# 步驟一讀取內(nèi)存相關(guān)指標(biāo)redis-cli INFO memory|grep-Eused_memory:|used_memory_rss:|mem_fragmentation_ratio|mem_allocator# 預(yù)期輸出示例# used_memory:2147483648# used_memory_rss:3758096384# mem_fragmentation_ratio:1.75# mem_allocator:jemalloc-5.2.1# 步驟二查看碎片整理是否可用及當(dāng)前狀態(tài)redis-cli CONFIG GET activedefrag redis-cli MEMORY STATS|grep-Efragmentation|allocator# 步驟三評估后開啟主動碎片整理生產(chǎn)需謹慎建議在低峰期驗證redis-cli CONFIG SET activedefragyesredis-cli CONFIG SET active-defrag-ignore-bytes 100mb redis-cli CONFIG SET active-defrag-threshold-lower10關(guān)鍵步驟解釋第一步算出碎片率約 1.75說明 RSS 比已用內(nèi)存高出很多第二步確認當(dāng)前沒有開啟主動碎片整理第三步調(diào)整參數(shù)讓 Redis 在碎片超過一定比例時后臺整理。active-defrag-ignore-bytes表示碎片浪費低于該值時忽略active-defrag-threshold-lower表示碎片率超過該百分比才開始整理?？捎^察結(jié)果整理期間used_memory_rss會逐步下降mem_fragmentation_ratio回落。邊界和常見錯誤主動碎片整理會消耗 CPU主線程和子線程都可能受影響不建議在高負載實例上直接大范圍開啟另外重啟實例也能消除碎片但會造成緩存雪崩風(fēng)險需要配合預(yù)熱方案。4.3 碎片與淘汰的關(guān)系這里最容易誤解的是碎片率高不等于淘汰會提前觸發(fā)。淘汰判斷基于maxmemory和used_memory而不是 RSS。也就是說碎片可能讓進程被操作系統(tǒng) OOM Kill卻不觸發(fā) Redis 自身的淘汰。生產(chǎn)上如果只盯著碎片率卻不看操作系統(tǒng)內(nèi)存會出現(xiàn)“Redis 自己覺得還有空間系統(tǒng)已經(jīng)把進程殺掉”的情況。因此內(nèi)存告警應(yīng)該同時覆蓋 used_memory、used_memory_rss 和操作系統(tǒng)剩余內(nèi)存。5. 內(nèi)存淘汰達到上限后誰先被犧牲當(dāng)used_memory超過maxmemoryRedis 會按照maxmemory-policy的策略淘汰 Key。常見策略如下策略淘汰范圍是否可能淘汰未過期 Key適用場景noeviction不淘汰寫入報錯不淘汰不允許丟數(shù)據(jù)的場景allkeys-lru所有 Key會純緩存允許按最近使用淘汰allkeys-lfu所有 Key會熱點差異明顯希望按頻率淘汰volatile-lru設(shè)置了過期時間的 Key不會混合存儲僅緩存部分可淘汰volatile-lfu設(shè)置了過期時間的 Key不會有過期時間的緩存熱點明顯allkeys-random所有 Key會對淘汰順序不敏感volatile-random設(shè)置了過期時間的 Key不會簡單緩存場景volatile-ttl設(shè)置了過期時間的 Key不會希望優(yōu)先淘汰快過期的 Key5.1 淘汰不是精確算法LRU 和 LFU 在 Redis 中都是近似實現(xiàn)。Redis 不會維護完整的訪問鏈表而是通過采樣若干個 Key從中選擇淘汰對象。采樣數(shù)量由maxmemory-samples控制默認值通常是 5調(diào)大更接近精確但更耗 CPU。5.2 一次淘汰行為的觀察下面在測試環(huán)境復(fù)現(xiàn)一次淘汰前置條件是把實例限制到很小的maxmemory并設(shè)置策略為allkeys-lru。# 步驟一設(shè)置小內(nèi)存和淘汰策略僅測試環(huán)境redis-cli CONFIG SET maxmemory 20mb redis-cli CONFIG SET maxmemory-policy allkeys-lru# 步驟二持續(xù)寫入直到觸發(fā)淘汰foriin$(seq120000);doredis-cli SETkey:$ivalue-$i/dev/nulldone# 步驟三查看淘汰統(tǒng)計和內(nèi)存redis-cli INFO stats|grepevicted_keys redis-cli INFO memory|grepused_memory:# 預(yù)期輸出示例# evicted_keys:5421# used_memory:20961480關(guān)鍵步驟解釋evicted_keys持續(xù)增長說明淘汰已經(jīng)發(fā)生used_memory穩(wěn)定在maxmemory附近。適用場景用于驗證策略是否生效、觀察淘汰速度。容易改錯的地方如果策略設(shè)為volatile-*但 Key 沒有設(shè)置過期時間那么淘汰集合為空寫入會直接報 OOM 錯誤而不是淘汰數(shù)據(jù)。5.3 淘汰與過期的關(guān)系過期 Key 的清理有兩種方式惰性刪除在訪問時判斷是否過期定期刪除由后臺周期性抽樣清理。淘汰則是在內(nèi)存達到上限時被動觸發(fā)。兩者都可能造成延遲但原因不同。如果大量 Key 設(shè)置了相同的過期時間會在同一時刻集中過期可能引起延遲尖刺更穩(wěn)妥的做法是在過期時間上加隨機抖動。6. 慢查詢把“變慢”拆成可定位的命令6.1 slowlog 記錄的是什么Redis 的慢查詢?nèi)罩居涗浀氖敲顖?zhí)行本身的耗時不包括網(wǎng)絡(luò)往返和排隊時間。相關(guān)配置有兩個slowlog-log-slower-than表示超過多少微秒記錄slowlog-max-len表示最多保留多少條。查看命令為SLOWLOG GET、SLOWLOG RESET、SLOWLOG LEN。命令作用注意事項SLOWLOG GET n查看最近 n 條慢查詢返回包含命令參數(shù)注意敏感信息SLOWLOG LEN查看當(dāng)前慢查詢條數(shù)長期增長說明持續(xù)有慢命令SLOWLOG RESET清空慢查詢?nèi)罩九耪锨跋扔涗浽偾蹇誏ATENCY RESET清空延遲事件用于配合延遲監(jiān)控LATENCY HISTORY查看延遲歷史可定位延遲尖刺類型6.2 一次完整的慢查詢定位下面的流程模擬從發(fā)現(xiàn)變慢到定位具體命令輸入是一個響應(yīng)時間上漲的實例步驟是先看慢查詢再分析命令涉及的數(shù)據(jù)規(guī)模。# 步驟一配置慢查詢閾值例如超過 10ms 記錄10000 微秒redis-cli CONFIG SET slowlog-log-slower-than10000redis-cli CONFIG SET slowlog-max-len256# 步驟二查看慢查詢redis-cli SLOWLOG GET5# 預(yù)期輸出示例節(jié)選# 1) 1) (integer) 14# 2) (integer) 1712345678# 3) (integer) 45231# 4) 1) HGETALL# 2) big:hash:order# 5) 127.0.0.1:52341# 6) # 步驟三確認該 Key 的規(guī)模和編碼redis-cli HLEN big:hash:order redis-cli OBJECT ENCODING big:hash:order redis-cli MEMORY USAGE big:hash:order# 預(yù)期輸出示例# (integer) 500000# hashtable# (integer) 48234496關(guān)鍵步驟解釋第一條慢查詢顯示HGETALL耗時約 45msKey 名為big:hash:order第三步確認它有 50 萬個字段、占用約 46MB屬于典型大 Key。HGETALL會一次性返回所有字段數(shù)據(jù)量大時不僅慢還會占用網(wǎng)絡(luò)帶寬和客戶端內(nèi)存。處理方向業(yè)務(wù)上改用HGET按需讀取、HSCAN分批遍歷或者把大 Hash 拆分成多個小 Key。適用場景所有出現(xiàn)響應(yīng)時間尖刺的實例。邊界SLOWLOG不記錄網(wǎng)絡(luò)延遲和執(zhí)行前的排隊時間如果慢查詢?nèi)罩緸榭盏涌谌匀宦枰挪檫B接池、網(wǎng)絡(luò)、主從同步或客戶端序列化。6.3 大 Key 的排查代碼下面給出一個用 Java 客戶端掃描大 Key 的完整示例。前置環(huán)境是 JDK 8 及以上、Maven 項目引入 Jedis 客戶端、本地可連接 Redis。目標(biāo)是按類型抽樣估算 Key 規(guī)模而不是在生產(chǎn)環(huán)境全量遍歷。importredis.clients.jedis.Jedis;importredis.clients.jedis.ScanParams;importredis.clients.jedis.ScanResult;importjava.util.List;publicclassBigKeyScanner{publicstaticvoidmain(String[]args){JedisjedisnewJedis(127.0.0.1,6379);try{StringcursorScanParams.SCAN_POINTER_START;ScanParamsparamsnewScanParams().count(100);longchecked0;longbigKeyCount0;do{ScanResultStringresultjedis.scan(cursor,params);ListStringkeysresult.getResult();for(Stringkey:keys){checked;Stringtypejedis.type(key);longsizeestimateSize(jedis,key,type);if(size10_000){bigKeyCount;System.out.println([BIG KEY] keykey, typetype, sizesize);}}cursorresult.getCursor();}while(!ScanParams.SCAN_POINTER_START.equals(cursor));System.out.println(checkedchecked, bigKeyCountbigKeyCount);}catch(Exceptione){System.err.println(scan failed: e.getMessage());}finally{jedis.close();}}privatestaticlongestimateSize(Jedisjedis,Stringkey,Stringtype){switch(type){casestring:returnjedis.strlen(key);casehash:returnjedis.hlen(key);caselist:returnjedis.llen(key);caseset:returnjedis.scard(key);casezset:returnjedis.zcard(key);default:return0;}}}關(guān)鍵步驟解釋使用SCAN而不是KEYS避免阻塞主線程每次只取 100 個 Key逐個按類型統(tǒng)計元素數(shù)量超過 10000 就打印。預(yù)期輸出會列出大 Key 及其類型和規(guī)模最后打印掃描總數(shù)和大 Key 數(shù)量。適用場景測試環(huán)境或低峰期對指定實例做抽樣檢查。容易改錯的地方SCAN只保證遍歷期間存在的元素最終被返回不保證不重復(fù)所以統(tǒng)計是近似值生產(chǎn)環(huán)境不要用KEYS *替代它。7. 性能調(diào)優(yōu)從參數(shù)到業(yè)務(wù)結(jié)構(gòu)7.1 調(diào)優(yōu)的優(yōu)先級Redis 性能調(diào)優(yōu)不是先改配置而是先確認瓶頸位置。可以按照下面的順序判斷命令層面是否存在 O(N) 大命令、大 Key、頻繁全量遍歷連接層面客戶端連接池是否過小或過大是否存在連接泄漏內(nèi)存層面編碼是否合理、碎片是否過高、淘汰是否頻繁持久化層面是否開啟了 AOF 頻繁刷盤或 RDB 頻繁快照部署層面主從、哨兵、Cluster 是否存在跨機房高延遲或頻繁故障轉(zhuǎn)移。7.2 管道與批量操作如果業(yè)務(wù)需要連續(xù)寫入大量小 Key逐條命令會產(chǎn)生大量網(wǎng)絡(luò)往返?？梢允褂霉艿琅堪l(fā)送但要控制每次批量的大小避免單次響應(yīng)過大。下面是一個完整示例前置環(huán)境與上一節(jié)相同。importredis.clients.jedis.Jedis;importredis.clients.jedis.Pipeline;publicclassPipelineDemo{publicstaticvoidmain(String[]args){JedisjedisnewJedis(127.0.0.1,6379);try{Pipelinepipelinejedis.pipelined();for(inti0;i1000;i){pipeline.set(batch:key:i,value-i);}pipeline.sync();System.out.println(pipeline done, samplejedis.get(batch:key:999));}catch(Exceptione){System.err.println(pipeline failed: e.getMessage());}finally{jedis.close();}}}關(guān)鍵步驟解釋pipelined()返回管道對象連續(xù)調(diào)用set只是把命令放入本地緩沖sync()才真正發(fā)送并讀取響應(yīng)。預(yù)期輸出會打印value-999。適用場景批量寫入、批量刪除等不需要逐條讀取結(jié)果的場景。邊界管道只節(jié)省網(wǎng)絡(luò)往返不減少服務(wù)端命令執(zhí)行成本單次管道過大可能導(dǎo)致客戶端內(nèi)存上漲或服務(wù)端輸出緩沖超限。7.3 用 Lua 減少往返的邊界有些場景需要在服務(wù)端原子執(zhí)行多條命令可以用 Lua 腳本。但腳本本身如果遍歷大集合同樣會阻塞主線程。下面是一個簡單示例目標(biāo)是原子地讀取并更新計數(shù)。importredis.clients.jedis.Jedis;publicclassLuaCounter{privatestaticfinalStringSCRIPTlocal current redis.call(GET, KEYS[1]) if current false then current 0 end current tonumber(current) tonumber(ARGV[1]) redis.call(SET, KEYS[1], current) return current;publicstaticvoidmain(String[]args){JedisjedisnewJedis(127.0.0.1,6379);try{Objectresultjedis.eval(SCRIPT,1,counter:order,5);System.out.println(counterresult);}catch(Exceptione){System.err.println(lua failed: e.getMessage());}finally{jedis.close();}}}關(guān)鍵步驟解釋腳本在服務(wù)端原子執(zhí)行避免客戶端讀取和寫回之間被其他命令插入。預(yù)期輸出為counter5重復(fù)執(zhí)行會遞增。適用場景計數(shù)、限流、簡單的原子讀改寫。邊界腳本執(zhí)行時間過長會阻塞其他命令lua-time-limit只控制腳本超時后的行為不會自動殺死腳本不要在腳本里做大范圍遍歷。8. 常見誤區(qū)誤區(qū)一used_memory 低就說明內(nèi)存沒問題。操作系統(tǒng)看的是 RSS碎片過高時可能被 OOM Kill。誤區(qū)二重啟能解決內(nèi)存問題。重啟只能清空碎片和過期數(shù)據(jù)如果編碼和 Key 結(jié)構(gòu)不合理問題會很快復(fù)發(fā)還可能造成緩存雪崩。誤區(qū)三設(shè)置 volatile-lru 就一定能淘汰。如果 Key 都沒有過期時間淘汰集合為空寫入會報錯。誤區(qū)四slowlog 沒記錄就說明沒有慢查詢。slowlog 只記錄命令執(zhí)行耗時不覆蓋網(wǎng)絡(luò)、排隊和客戶端處理。誤區(qū)五編碼轉(zhuǎn)換后刪除元素就能恢復(fù)內(nèi)存。大多數(shù)編碼轉(zhuǎn)換是單向的刪除元素不一定讓編碼退回緊湊結(jié)構(gòu)。誤區(qū)六KEYS 用于排查大 Key。KEYS會阻塞主線程生產(chǎn)環(huán)境應(yīng)使用SCAN。9. 生產(chǎn)實踐建議給所有緩存 Key 設(shè)置帶隨機抖動的過期時間避免集中過期。對 Hash、List、Set、ZSet 的業(yè)務(wù)規(guī)模設(shè)上限接近編碼閾值時提前拆分或壓測。監(jiān)控同時覆蓋 used_memory、used_memory_rss、evicted_keys、expired_keys 和 slowlog 長度。大 Key 和高頻 Key 定期抽檢寫入鏈路中避免一次性返回大集合。主動碎片整理只在評估 CPU 余量后開啟優(yōu)先在低峰期驗證。淘汰策略要與業(yè)務(wù)數(shù)據(jù)性質(zhì)匹配純緩存用 allkeys-lru 或 allkeys-lfu混合存儲用 volatile-lru 并確保有過期時間。10. 排障清單與面試復(fù)盤10.1 排障清單收到 Redis 內(nèi)存或延遲告警 | v 1. INFO memory看 used_memory、used_memory_rss、碎片率 | v 2. INFO stats看 evicted_keys、expired_keys 是否異常增長 | v 3. SLOWLOG GET確認是否有慢命令記錄參數(shù)和時間 | v 4. 對慢命令涉及的 Key 執(zhí)行 OBJECT ENCODING、MEMORY USAGE、HLEN/LLEN 等 | v 5. 判斷是編碼不合理、大 Key、碎片過高還是淘汰策略不匹配 | v 6. 制定改動拆分 Key、調(diào)整閾值、開啟整理、更換淘汰策略或優(yōu)化業(yè)務(wù)訪問 | v 7. 低峰期驗證并持續(xù)觀察10.2 面試與復(fù)盤問題為什么小 Hash 用 listpack 而大 Hash 用 hashtable轉(zhuǎn)換后為什么不能自動轉(zhuǎn)回used_memory_rss 遠大于 used_memory 時可能有哪些原因如何驗證allkeys-lru 和 volatile-lru 在 Key 都沒有過期時間時分別會發(fā)生什么slowlog 記錄不到某個慢請求可能是哪些環(huán)節(jié)造成的大 Key 的常見識別方式和拆分思路有哪些為什么管道不一定能提升服務(wù)端處理能力11. 總結(jié)回到開頭的告警場景正確的處理順序不是先調(diào)參數(shù)而是先建立定位鏈路用INFO memory看內(nèi)存形狀用OBJECT ENCODING和MEMORY USAGE判斷編碼和大 Key用碎片率判斷內(nèi)存是否被浪費用SLOWLOG找到具體慢命令最后再決定是拆分 Key、調(diào)整編碼閾值、開啟碎片整理還是更換淘汰策略。現(xiàn)象優(yōu)先排查方向典型動作內(nèi)存高但 used_memory 不高碎片率檢查 RSS評估主動碎片整理內(nèi)存高且 evicted_keys 增長淘汰策略與數(shù)據(jù)量調(diào)整策略或擴容檢查過期時間延遲尖刺且 slowlog 有記錄大 Key 或 O(N) 命令拆分 Key改用分批命令延遲尖刺但 slowlog 為空網(wǎng)絡(luò)、連接池、持久化檢查客戶端、AOF、RDB、主從延遲編碼從緊湊變?yōu)橥ㄓ脴I(yè)務(wù)數(shù)據(jù)規(guī)模控制元素數(shù)量必要時拆分把這張表當(dāng)作日常排障的入口比記住一堆參數(shù)更有用。12. 參考資料Redis 官方文檔Memory Optimizationhttps://redis.io/docs/latest/operate/oss_and_stack/management/optimization/memory-optimization/Redis 官方文檔Keyspace 與過期、淘汰策略說明https://redis.io/docs/latest/develop/reference/eviction/Redis 官方文檔SLOWLOG 命令https://redis.io/docs/latest/commands/slowlog/Redis 官方文檔MEMORY USAGE 命令https://redis.io/docs/latest/commands/memory-usage/Redis 官方文檔OBJECT ENCODING 命令https://redis.io/docs/latest/commands/object-encoding/Redis 官方文檔INFO 命令https://redis.io/docs/latest/commands/info/Jedis 項目文檔https://github.com/redis/jedis