存優(yōu)化與性能調(diào)優(yōu)：編碼轉(zhuǎn)換、內(nèi)存碎片與慢查詢的定位鏈路)
Redis 內(nèi)存優(yōu)化與性能調(diào)優(yōu)編碼轉(zhuǎn)換、內(nèi)存碎片與慢查詢的定位鏈路1. 從一次線上告警說起假設(shè)你維護(hù)一個(gè)訂單系統(tǒng)某天凌晨收到告警Redis 實(shí)例內(nèi)存使用率 92%同時(shí)接口平均響應(yīng)時(shí)間從 8ms 漲到了 60ms。值班同事的第一反應(yīng)通常是下面幾種把maxmemory調(diào)大讓實(shí)例先“撐過去”重啟實(shí)例重置 used_memory懷疑是流量上漲直接擴(kuò)機(jī)器。這些動(dòng)作可能在短時(shí)間內(nèi)讓監(jiān)控恢復(fù)綠線但一兩周后同樣的問題會(huì)再次出現(xiàn)。原因在于它們都跳過了最關(guān)鍵的判斷內(nèi)存到底被誰占用了是真實(shí)業(yè)務(wù)數(shù)據(jù)增長還是編碼方式不合理、碎片率過高、過期 Key 沒被及時(shí)清理慢又是哪一種慢是單條命令本身耗時(shí)還是排隊(duì)、網(wǎng)絡(luò)、主從同步造成的本文不打算把 Redis 調(diào)優(yōu)講成一份參數(shù)清單而是先給出一條可以復(fù)述的定位鏈路。你可以把它理解成一次體檢先看整體內(nèi)存形狀再判斷數(shù)據(jù)結(jié)構(gòu)是否用了低效編碼然后檢查內(nèi)存碎片是否過高最后用慢查詢?nèi)罩炬i定具體命令。整條鏈路串起來才是一個(gè)可復(fù)用的工程方法。為了便于后續(xù)展開先記住一個(gè)最小模型客戶端命令 | v 命令執(zhí)行線程 -- 讀寫 Redis 對(duì)象 -- 編碼可能發(fā)生轉(zhuǎn)換 | | | v | 內(nèi)存分配 / 釋放 | | v v 慢查詢?nèi)罩?-- 耗時(shí)超閾值 內(nèi)存碎片率變化 | | v v 定位具體命令 觸發(fā)淘汰策略2. 先建立整體框架一次寫入會(huì)經(jīng)過哪些環(huán)節(jié)Redis 的內(nèi)存問題很少是單一原因?qū)е碌?。它更像一個(gè)鏈條一次寫入命令進(jìn)入后先執(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)存達(dá)到上限淘汰策略開始工作如果某條命令因?yàn)閿?shù)據(jù)量過大而變慢它就會(huì)被 slowlog 記錄下來。把整體拆成四部分更容易理解對(duì)象與編碼層Redis 為了兼顧內(nèi)存和性能對(duì)同一種邏輯類型提供了多種底層編碼例如列表在小數(shù)據(jù)量時(shí)用緊湊列表變大后轉(zhuǎn)為快速鏈表。內(nèi)存分配與回收層內(nèi)存由分配器管理頻繁增刪會(huì)造成碎片碎片率過高會(huì)浪費(fèi)物理內(nèi)存。淘汰與過期層達(dá)到maxmemory后觸發(fā)淘汰過期 Key 通過惰性刪除和定期刪除結(jié)合清理?？捎^測(cè)層INFO、MEMORY USAGE、SLOWLOG、LATENCY等命令幫助我們把現(xiàn)象對(duì)應(yīng)到原因。這四個(gè)部分并非獨(dú)立存在。編碼轉(zhuǎn)換會(huì)直接影響內(nèi)存占用和碎片產(chǎn)生碎片率又會(huì)影響淘汰觸發(fā)時(shí)機(jī)而淘汰和過期清理如果執(zhí)行不當(dāng)又可能造成延遲尖刺并進(jìn)入慢查詢?nèi)罩?。理解它們之間的連接比單獨(dú)記住某個(gè)參數(shù)更重要。3. 編碼轉(zhuǎn)換為什么同樣 100 個(gè)元素內(nèi)存差好幾倍3.1 一句話模型可以先把它理解成Redis 對(duì)每種數(shù)據(jù)類型都準(zhǔn)備了兩套甚至多套“收納盒”小數(shù)據(jù)用緊湊盒省內(nèi)存大數(shù)據(jù)用性能盒操作更快。超過閾值時(shí)Redis 自動(dòng)把數(shù)據(jù)從緊湊盒搬到性能盒這個(gè)過程叫編碼轉(zhuǎn)換。3.2 觸發(fā)條件與常見編碼以常見的列表和哈希為例數(shù)據(jù)類型小數(shù)據(jù)編碼大數(shù)據(jù)編碼常見轉(zhuǎn)換觸發(fā)條件Listlistpack早期為 ziplistquicklist元素個(gè)數(shù)或單個(gè)元素長度超過閾值Hashlistpack早期為 ziplisthashtable字段數(shù)或字段值長度超過閾值Setintsethashtable元素非整數(shù)或數(shù)量超閾值ZSetlistpack早期為 ziplistskiplist元素?cái)?shù)或成員長度超閾值閾值由配置項(xiàng)控制例如hash-max-listpack-entries、hash-max-listpack-value、list-max-listpack-size、set-max-intset-entries、zset-max-listpack-entries。不同 Redis 版本默認(rèn)值和名稱略有差異生產(chǎn)環(huán)境必須以當(dāng)前版本redis.conf為準(zhǔn)。3.3 一個(gè)可復(fù)現(xiàn)的實(shí)驗(yàn)下面用redis-cli做一個(gè)最小實(shí)驗(yàn)觀察哈希從緊湊編碼轉(zhuǎn)為通用編碼后內(nèi)存的變化。前置條件是本地或測(cè)試環(huán)境有一個(gè)可執(zhí)行redis-cli的 Redis 實(shí)例版本為 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用來查看單個(gè) 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ù)分配帶來的額外開銷。適用場(chǎng)景這個(gè)實(shí)驗(yàn)適合在測(cè)試環(huán)境驗(yàn)證業(yè)務(wù) Key 的編碼是否符合預(yù)期尤其適合字段數(shù)量接近閾值的場(chǎng)景。容易改錯(cuò)的地方是直接用MEMORY USAGE比較不同版本可能得到不同結(jié)果因?yàn)椴蓸臃绞胶桶姹緦?shí)現(xiàn)會(huì)變化另外轉(zhuǎn)換是單向的一旦變成hashtable即使隨后刪掉大部分字段編碼通常也不會(huì)自動(dòng)退回listpack。3.4 設(shè)計(jì)取舍緊湊編碼省內(nèi)存但每次修改都可能涉及整塊內(nèi)存搬移時(shí)間復(fù)雜度更接近 O(N)通用編碼操作快但內(nèi)存開銷大。Redis 用閾值來平衡這兩者。工程上真正要做的是判斷你的業(yè)務(wù)數(shù)據(jù)是否長期停留在“接近閾值但未超過”的位置。如果一個(gè) Hash 有 400 個(gè)字段恰好沒觸發(fā) 500 的默認(rèn)閾值但字段值較長內(nèi)存已經(jīng)不小這時(shí)可以考慮拆分成多個(gè) Key或者顯式調(diào)整閾值并做壓測(cè)。4. 內(nèi)存碎片used_memory 和 RSS 為什么會(huì)差那么多4.1 碎片是怎么產(chǎn)生的內(nèi)存碎片可以理解成一間倉庫里堆滿了大小不一的箱子很多小空隙沒法再放進(jìn)新的大箱子。Redis 也類似不斷創(chuàng)建和刪除不同大小的對(duì)象時(shí)分配器釋放的內(nèi)存塊可能無法被后續(xù)請(qǐng)求復(fù)用于是操作系統(tǒng)看到的進(jìn)程 RSS 遠(yuǎn)大于 Redis 自己統(tǒng)計(jì)的 used_memory。判斷碎片程度主要看兩個(gè)指標(biāo)used_memoryRedis 分配器統(tǒng)計(jì)的已用內(nèi)存used_memory_rss操作系統(tǒng)視角的常駐內(nèi)存碎片率近似為used_memory_rss / used_memory。通常碎片率在 1.0 到 1.5 之間可以接受持續(xù)高于 1.5 且業(yè)務(wù)有明顯增刪波動(dòng)時(shí)就需要關(guān)注。4.2 一次診斷流程示例下面是一個(gè)完整的診斷流程輸入是一臺(tái)內(nèi)存持續(xù)高于預(yù)期的 Redis 實(shí)例步驟是讀取信息、計(jì)算碎片率、查看分配器狀態(tài)結(jié)果用于決定是否開啟主動(dòng)碎片整理。# 步驟一讀取內(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# 步驟三評(píng)估后開啟主動(dòng)碎片整理生產(chǎn)需謹(jǐn)慎建議在低峰期驗(yà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)存高出很多第二步確認(rèn)當(dāng)前沒有開啟主動(dòng)碎片整理第三步調(diào)整參數(shù)讓 Redis 在碎片超過一定比例時(shí)后臺(tái)整理。active-defrag-ignore-bytes表示碎片浪費(fèi)低于該值時(shí)忽略active-defrag-threshold-lower表示碎片率超過該百分比才開始整理?？捎^察結(jié)果整理期間used_memory_rss會(huì)逐步下降mem_fragmentation_ratio回落。邊界和常見錯(cuò)誤主動(dòng)碎片整理會(huì)消耗 CPU主線程和子線程都可能受影響不建議在高負(fù)載實(shí)例上直接大范圍開啟另外重啟實(shí)例也能消除碎片但會(huì)造成緩存雪崩風(fēng)險(xiǎn)需要配合預(yù)熱方案。4.3 碎片與淘汰的關(guān)系這里最容易誤解的是碎片率高不等于淘汰會(huì)提前觸發(fā)。淘汰判斷基于maxmemory和used_memory而不是 RSS。也就是說碎片可能讓進(jìn)程被操作系統(tǒng) OOM Kill卻不觸發(fā) Redis 自身的淘汰。生產(chǎn)上如果只盯著碎片率卻不看操作系統(tǒng)內(nèi)存會(huì)出現(xiàn)“Redis 自己覺得還有空間系統(tǒng)已經(jīng)把進(jìn)程殺掉”的情況。因此內(nèi)存告警應(yīng)該同時(shí)覆蓋 used_memory、used_memory_rss 和操作系統(tǒng)剩余內(nèi)存。5. 內(nèi)存淘汰達(dá)到上限后誰先被犧牲當(dāng)used_memory超過maxmemoryRedis 會(huì)按照maxmemory-policy的策略淘汰 Key。常見策略如下策略淘汰范圍是否可能淘汰未過期 Key適用場(chǎng)景noeviction不淘汰寫入報(bào)錯(cuò)不淘汰不允許丟數(shù)據(jù)的場(chǎng)景allkeys-lru所有 Key會(huì)純緩存允許按最近使用淘汰allkeys-lfu所有 Key會(huì)熱點(diǎn)差異明顯希望按頻率淘汰volatile-lru設(shè)置了過期時(shí)間的 Key不會(huì)混合存儲(chǔ)僅緩存部分可淘汰volatile-lfu設(shè)置了過期時(shí)間的 Key不會(huì)有過期時(shí)間的緩存熱點(diǎn)明顯allkeys-random所有 Key會(huì)對(duì)淘汰順序不敏感volatile-random設(shè)置了過期時(shí)間的 Key不會(huì)簡單緩存場(chǎng)景volatile-ttl設(shè)置了過期時(shí)間的 Key不會(huì)希望優(yōu)先淘汰快過期的 Key5.1 淘汰不是精確算法LRU 和 LFU 在 Redis 中都是近似實(shí)現(xiàn)。Redis 不會(huì)維護(hù)完整的訪問鏈表而是通過采樣若干個(gè) Key從中選擇淘汰對(duì)象。采樣數(shù)量由maxmemory-samples控制默認(rèn)值通常是 5調(diào)大更接近精確但更耗 CPU。5.2 一次淘汰行為的觀察下面在測(cè)試環(huán)境復(fù)現(xiàn)一次淘汰前置條件是把實(shí)例限制到很小的maxmemory并設(shè)置策略為allkeys-lru。# 步驟一設(shè)置小內(nèi)存和淘汰策略僅測(cè)試環(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)計(jì)和內(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附近。適用場(chǎng)景用于驗(yàn)證策略是否生效、觀察淘汰速度。容易改錯(cuò)的地方如果策略設(shè)為volatile-*但 Key 沒有設(shè)置過期時(shí)間那么淘汰集合為空寫入會(huì)直接報(bào) OOM 錯(cuò)誤而不是淘汰數(shù)據(jù)。5.3 淘汰與過期的關(guān)系過期 Key 的清理有兩種方式惰性刪除在訪問時(shí)判斷是否過期定期刪除由后臺(tái)周期性抽樣清理。淘汰則是在內(nèi)存達(dá)到上限時(shí)被動(dòng)觸發(fā)。兩者都可能造成延遲但原因不同。如果大量 Key 設(shè)置了相同的過期時(shí)間會(huì)在同一時(shí)刻集中過期可能引起延遲尖刺更穩(wěn)妥的做法是在過期時(shí)間上加隨機(jī)抖動(dòng)。6. 慢查詢把“變慢”拆成可定位的命令6.1 slowlog 記錄的是什么Redis 的慢查詢?nèi)罩居涗浀氖敲顖?zhí)行本身的耗時(shí)不包括網(wǎng)絡(luò)往返和排隊(duì)時(shí)間。相關(guān)配置有兩個(gè)slowlog-log-slower-than表示超過多少微秒記錄slowlog-max-len表示最多保留多少條。查看命令為SLOWLOG GET、SLOWLOG RESET、SLOWLOG LEN。命令作用注意事項(xiàng)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)變慢到定位具體命令輸入是一個(gè)響應(yīng)時(shí)間上漲的實(shí)例步驟是先看慢查詢?cè)俜治雒钌婕暗臄?shù)據(jù)規(guī)模。# 步驟一配置慢查詢閾值例如超過 10ms 記錄10000 微秒redis-cli CONFIG SET slowlog-log-slower-than10000redis-cli CONFIG SET slowlog-max-len256# 步驟二查看慢查詢r(jià)edis-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) # 步驟三確認(rèn)該 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耗時(shí)約 45msKey 名為big:hash:order第三步確認(rèn)它有 50 萬個(gè)字段、占用約 46MB屬于典型大 Key。HGETALL會(huì)一次性返回所有字段數(shù)據(jù)量大時(shí)不僅慢還會(huì)占用網(wǎng)絡(luò)帶寬和客戶端內(nèi)存。處理方向業(yè)務(wù)上改用HGET按需讀取、HSCAN分批遍歷或者把大 Hash 拆分成多個(gè)小 Key。適用場(chǎng)景所有出現(xiàn)響應(yīng)時(shí)間尖刺的實(shí)例。邊界SLOWLOG不記錄網(wǎng)絡(luò)延遲和執(zhí)行前的排隊(duì)時(shí)間如果慢查詢?nèi)罩緸榭盏涌谌匀宦枰挪檫B接池、網(wǎng)絡(luò)、主從同步或客戶端序列化。6.3 大 Key 的排查代碼下面給出一個(gè)用 Java 客戶端掃描大 Key 的完整示例。前置環(huán)境是 JDK 8 及以上、Maven 項(xiàng)目引入 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 個(gè) Key逐個(gè)按類型統(tǒng)計(jì)元素?cái)?shù)量超過 10000 就打印。預(yù)期輸出會(huì)列出大 Key 及其類型和規(guī)模最后打印掃描總數(shù)和大 Key 數(shù)量。適用場(chǎng)景測(cè)試環(huán)境或低峰期對(duì)指定實(shí)例做抽樣檢查。容易改錯(cuò)的地方SCAN只保證遍歷期間存在的元素最終被返回不保證不重復(fù)所以統(tǒng)計(jì)是近似值生產(chǎn)環(huán)境不要用KEYS *替代它。7. 性能調(diào)優(yōu)從參數(shù)到業(yè)務(wù)結(jié)構(gòu)7.1 調(diào)優(yōu)的優(yōu)先級(jí)Redis 性能調(diào)優(yōu)不是先改配置而是先確認(rèn)瓶頸位置?？梢园凑障旅娴捻樞蚺袛嗝顚用媸欠翊嬖?O(N) 大命令、大 Key、頻繁全量遍歷連接層面客戶端連接池是否過小或過大是否存在連接泄漏內(nèi)存層面編碼是否合理、碎片是否過高、淘汰是否頻繁持久化層面是否開啟了 AOF 頻繁刷盤或 RDB 頻繁快照部署層面主從、哨兵、Cluster 是否存在跨機(jī)房高延遲或頻繁故障轉(zhuǎn)移。7.2 管道與批量操作如果業(yè)務(wù)需要連續(xù)寫入大量小 Key逐條命令會(huì)產(chǎn)生大量網(wǎng)絡(luò)往返?？梢允褂霉艿琅堪l(fā)送但要控制每次批量的大小避免單次響應(yīng)過大。下面是一個(gè)完整示例前置環(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()返回管道對(duì)象連續(xù)調(diào)用set只是把命令放入本地緩沖sync()才真正發(fā)送并讀取響應(yīng)。預(yù)期輸出會(huì)打印value-999。適用場(chǎng)景批量寫入、批量刪除等不需要逐條讀取結(jié)果的場(chǎng)景。邊界管道只節(jié)省網(wǎng)絡(luò)往返不減少服務(wù)端命令執(zhí)行成本單次管道過大可能導(dǎo)致客戶端內(nèi)存上漲或服務(wù)端輸出緩沖超限。7.3 用 Lua 減少往返的邊界有些場(chǎng)景需要在服務(wù)端原子執(zhí)行多條命令可以用 Lua 腳本。但腳本本身如果遍歷大集合同樣會(huì)阻塞主線程。下面是一個(gè)簡單示例目標(biāo)是原子地讀取并更新計(jì)數(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í)行會(huì)遞增。適用場(chǎng)景計(jì)數(shù)、限流、簡單的原子讀改寫。邊界腳本執(zhí)行時(shí)間過長會(huì)阻塞其他命令lua-time-limit只控制腳本超時(shí)后的行為不會(huì)自動(dòng)殺死腳本不要在腳本里做大范圍遍歷。8. 常見誤區(qū)誤區(qū)一used_memory 低就說明內(nèi)存沒問題。操作系統(tǒng)看的是 RSS碎片過高時(shí)可能被 OOM Kill。誤區(qū)二重啟能解決內(nèi)存問題。重啟只能清空碎片和過期數(shù)據(jù)如果編碼和 Key 結(jié)構(gòu)不合理問題會(huì)很快復(fù)發(fā)還可能造成緩存雪崩。誤區(qū)三設(shè)置 volatile-lru 就一定能淘汰。如果 Key 都沒有過期時(shí)間淘汰集合為空寫入會(huì)報(bào)錯(cuò)。誤區(qū)四slowlog 沒記錄就說明沒有慢查詢。slowlog 只記錄命令執(zhí)行耗時(shí)不覆蓋網(wǎng)絡(luò)、排隊(duì)和客戶端處理。誤區(qū)五編碼轉(zhuǎn)換后刪除元素就能恢復(fù)內(nèi)存。大多數(shù)編碼轉(zhuǎn)換是單向的刪除元素不一定讓編碼退回緊湊結(jié)構(gòu)。誤區(qū)六KEYS 用于排查大 Key。KEYS會(huì)阻塞主線程生產(chǎn)環(huán)境應(yīng)使用SCAN。9. 生產(chǎn)實(shí)踐建議給所有緩存 Key 設(shè)置帶隨機(jī)抖動(dòng)的過期時(shí)間避免集中過期。對(duì) Hash、List、Set、ZSet 的業(yè)務(wù)規(guī)模設(shè)上限接近編碼閾值時(shí)提前拆分或壓測(cè)。監(jiān)控同時(shí)覆蓋 used_memory、used_memory_rss、evicted_keys、expired_keys 和 slowlog 長度。大 Key 和高頻 Key 定期抽檢寫入鏈路中避免一次性返回大集合。主動(dòng)碎片整理只在評(píng)估 CPU 余量后開啟優(yōu)先在低峰期驗(yàn)證。淘汰策略要與業(yè)務(wù)數(shù)據(jù)性質(zhì)匹配純緩存用 allkeys-lru 或 allkeys-lfu混合存儲(chǔ)用 volatile-lru 并確保有過期時(shí)間。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確認(rèn)是否有慢命令記錄參數(shù)和時(shí)間 | v 4. 對(duì)慢命令涉及的 Key 執(zhí)行 OBJECT ENCODING、MEMORY USAGE、HLEN/LLEN 等 | v 5. 判斷是編碼不合理、大 Key、碎片過高還是淘汰策略不匹配 | v 6. 制定改動(dòng)拆分 Key、調(diào)整閾值、開啟整理、更換淘汰策略或優(yōu)化業(yè)務(wù)訪問 | v 7. 低峰期驗(yàn)證并持續(xù)觀察10.2 面試與復(fù)盤問題為什么小 Hash 用 listpack 而大 Hash 用 hashtable轉(zhuǎn)換后為什么不能自動(dòng)轉(zhuǎn)回used_memory_rss 遠(yuǎn)大于 used_memory 時(shí)可能有哪些原因如何驗(yàn)證allkeys-lru 和 volatile-lru 在 Key 都沒有過期時(shí)間時(shí)分別會(huì)發(fā)生什么slowlog 記錄不到某個(gè)慢請(qǐng)求可能是哪些環(huán)節(jié)造成的大 Key 的常見識(shí)別方式和拆分思路有哪些為什么管道不一定能提升服務(wù)端處理能力11. 總結(jié)回到開頭的告警場(chǎng)景正確的處理順序不是先調(diào)參數(shù)而是先建立定位鏈路用INFO memory看內(nèi)存形狀用OBJECT ENCODING和MEMORY USAGE判斷編碼和大 Key用碎片率判斷內(nèi)存是否被浪費(fèi)用SLOWLOG找到具體慢命令最后再?zèng)Q定是拆分 Key、調(diào)整編碼閾值、開啟碎片整理還是更換淘汰策略?，F(xiàn)象優(yōu)先排查方向典型動(dòng)作內(nèi)存高但 used_memory 不高碎片率檢查 RSS評(píng)估主動(dòng)碎片整理內(nèi)存高且 evicted_keys 增長淘汰策略與數(shù)據(jù)量調(diào)整策略或擴(kuò)容檢查過期時(shí)間延遲尖刺且 slowlog 有記錄大 Key 或 O(N) 命令拆分 Key改用分批命令延遲尖刺但 slowlog 為空網(wǎng)絡(luò)、連接池、持久化檢查客戶端、AOF、RDB、主從延遲編碼從緊湊變?yōu)橥ㄓ脴I(yè)務(wù)數(shù)據(jù)規(guī)?？刂圃?cái)?shù)量必要時(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 項(xiàng)目文檔https://github.com/redis/jedis Redis 內(nèi)存優(yōu)化與性能調(diào)優(yōu)：編碼轉(zhuǎn)換、內(nèi)存碎片與慢查詢的定位鏈路
Redis 內(nèi)存優(yōu)化與性能調(diào)優(yōu)編碼轉(zhuǎn)換、內(nèi)存碎片與慢查詢的定位鏈路1. 從一次線上告警說起假設(shè)你維護(hù)一個(gè)訂單系統(tǒng)某天凌晨收到告警Redis 實(shí)例內(nèi)存使用率 92%同時(shí)接口平均響應(yīng)時(shí)間從 8ms 漲到了 60ms。值班同事的第一反應(yīng)通常是下面幾種把maxmemory調(diào)大讓實(shí)例先“撐過去”重啟實(shí)例重置 used_memory懷疑是流量上漲直接擴(kuò)機(jī)器。這些動(dòng)作可能在短時(shí)間內(nèi)讓監(jiān)控恢復(fù)綠線但一兩周后同樣的問題會(huì)再次出現(xiàn)。原因在于它們都跳過了最關(guān)鍵的判斷內(nèi)存到底被誰占用了是真實(shí)業(yè)務(wù)數(shù)據(jù)增長還是編碼方式不合理、碎片率過高、過期 Key 沒被及時(shí)清理慢又是哪一種慢是單條命令本身耗時(shí)還是排隊(duì)、網(wǎng)絡(luò)、主從同步造成的本文不打算把 Redis 調(diào)優(yōu)講成一份參數(shù)清單而是先給出一條可以復(fù)述的定位鏈路。你可以把它理解成一次體檢先看整體內(nèi)存形狀再判斷數(shù)據(jù)結(jié)構(gòu)是否用了低效編碼然后檢查內(nèi)存碎片是否過高最后用慢查詢?nèi)罩炬i定具體命令。整條鏈路串起來才是一個(gè)可復(fù)用的工程方法。為了便于后續(xù)展開先記住一個(gè)最小模型客戶端命令 | v 命令執(zhí)行線程 -- 讀寫 Redis 對(duì)象 -- 編碼可能發(fā)生轉(zhuǎn)換 | | | v | 內(nèi)存分配 / 釋放 | | v v 慢查詢?nèi)罩?-- 耗時(shí)超閾值 內(nèi)存碎片率變化 | | v v 定位具體命令 觸發(fā)淘汰策略2. 先建立整體框架一次寫入會(huì)經(jīng)過哪些環(huán)節(jié)Redis 的內(nèi)存問題很少是單一原因?qū)е碌?。它更像一個(gè)鏈條一次寫入命令進(jìn)入后先執(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)存達(dá)到上限淘汰策略開始工作如果某條命令因?yàn)閿?shù)據(jù)量過大而變慢它就會(huì)被 slowlog 記錄下來。把整體拆成四部分更容易理解對(duì)象與編碼層Redis 為了兼顧內(nèi)存和性能對(duì)同一種邏輯類型提供了多種底層編碼例如列表在小數(shù)據(jù)量時(shí)用緊湊列表變大后轉(zhuǎn)為快速鏈表。內(nèi)存分配與回收層內(nèi)存由分配器管理頻繁增刪會(huì)造成碎片碎片率過高會(huì)浪費(fèi)物理內(nèi)存。淘汰與過期層達(dá)到maxmemory后觸發(fā)淘汰過期 Key 通過惰性刪除和定期刪除結(jié)合清理?？捎^測(cè)層INFO、MEMORY USAGE、SLOWLOG、LATENCY等命令幫助我們把現(xiàn)象對(duì)應(yīng)到原因。這四個(gè)部分并非獨(dú)立存在。編碼轉(zhuǎn)換會(huì)直接影響內(nèi)存占用和碎片產(chǎn)生碎片率又會(huì)影響淘汰觸發(fā)時(shí)機(jī)而淘汰和過期清理如果執(zhí)行不當(dāng)又可能造成延遲尖刺并進(jìn)入慢查詢?nèi)罩?。理解它們之間的連接比單獨(dú)記住某個(gè)參數(shù)更重要。3. 編碼轉(zhuǎn)換為什么同樣 100 個(gè)元素內(nèi)存差好幾倍3.1 一句話模型可以先把它理解成Redis 對(duì)每種數(shù)據(jù)類型都準(zhǔn)備了兩套甚至多套“收納盒”小數(shù)據(jù)用緊湊盒省內(nèi)存大數(shù)據(jù)用性能盒操作更快。超過閾值時(shí)Redis 自動(dòng)把數(shù)據(jù)從緊湊盒搬到性能盒這個(gè)過程叫編碼轉(zhuǎn)換。3.2 觸發(fā)條件與常見編碼以常見的列表和哈希為例數(shù)據(jù)類型小數(shù)據(jù)編碼大數(shù)據(jù)編碼常見轉(zhuǎn)換觸發(fā)條件Listlistpack早期為 ziplistquicklist元素個(gè)數(shù)或單個(gè)元素長度超過閾值Hashlistpack早期為 ziplisthashtable字段數(shù)或字段值長度超過閾值Setintsethashtable元素非整數(shù)或數(shù)量超閾值ZSetlistpack早期為 ziplistskiplist元素?cái)?shù)或成員長度超閾值閾值由配置項(xiàng)控制例如hash-max-listpack-entries、hash-max-listpack-value、list-max-listpack-size、set-max-intset-entries、zset-max-listpack-entries。不同 Redis 版本默認(rèn)值和名稱略有差異生產(chǎn)環(huán)境必須以當(dāng)前版本redis.conf為準(zhǔn)。3.3 一個(gè)可復(fù)現(xiàn)的實(shí)驗(yàn)下面用redis-cli做一個(gè)最小實(shí)驗(yàn)觀察哈希從緊湊編碼轉(zhuǎn)為通用編碼后內(nèi)存的變化。前置條件是本地或測(cè)試環(huán)境有一個(gè)可執(zhí)行redis-cli的 Redis 實(shí)例版本為 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用來查看單個(gè) 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ù)分配帶來的額外開銷。適用場(chǎng)景這個(gè)實(shí)驗(yàn)適合在測(cè)試環(huán)境驗(yàn)證業(yè)務(wù) Key 的編碼是否符合預(yù)期尤其適合字段數(shù)量接近閾值的場(chǎng)景。容易改錯(cuò)的地方是直接用MEMORY USAGE比較不同版本可能得到不同結(jié)果因?yàn)椴蓸臃绞胶桶姹緦?shí)現(xiàn)會(huì)變化另外轉(zhuǎn)換是單向的一旦變成hashtable即使隨后刪掉大部分字段編碼通常也不會(huì)自動(dòng)退回listpack。3.4 設(shè)計(jì)取舍緊湊編碼省內(nèi)存但每次修改都可能涉及整塊內(nèi)存搬移時(shí)間復(fù)雜度更接近 O(N)通用編碼操作快但內(nèi)存開銷大。Redis 用閾值來平衡這兩者。工程上真正要做的是判斷你的業(yè)務(wù)數(shù)據(jù)是否長期停留在“接近閾值但未超過”的位置。如果一個(gè) Hash 有 400 個(gè)字段恰好沒觸發(fā) 500 的默認(rèn)閾值但字段值較長內(nèi)存已經(jīng)不小這時(shí)可以考慮拆分成多個(gè) Key或者顯式調(diào)整閾值并做壓測(cè)。4. 內(nèi)存碎片used_memory 和 RSS 為什么會(huì)差那么多4.1 碎片是怎么產(chǎn)生的內(nèi)存碎片可以理解成一間倉庫里堆滿了大小不一的箱子很多小空隙沒法再放進(jìn)新的大箱子。Redis 也類似不斷創(chuàng)建和刪除不同大小的對(duì)象時(shí)分配器釋放的內(nèi)存塊可能無法被后續(xù)請(qǐng)求復(fù)用于是操作系統(tǒng)看到的進(jìn)程 RSS 遠(yuǎn)大于 Redis 自己統(tǒng)計(jì)的 used_memory。判斷碎片程度主要看兩個(gè)指標(biāo)used_memoryRedis 分配器統(tǒng)計(jì)的已用內(nèi)存used_memory_rss操作系統(tǒng)視角的常駐內(nèi)存碎片率近似為used_memory_rss / used_memory。通常碎片率在 1.0 到 1.5 之間可以接受持續(xù)高于 1.5 且業(yè)務(wù)有明顯增刪波動(dòng)時(shí)就需要關(guān)注。4.2 一次診斷流程示例下面是一個(gè)完整的診斷流程輸入是一臺(tái)內(nèi)存持續(xù)高于預(yù)期的 Redis 實(shí)例步驟是讀取信息、計(jì)算碎片率、查看分配器狀態(tài)結(jié)果用于決定是否開啟主動(dòng)碎片整理。# 步驟一讀取內(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# 步驟三評(píng)估后開啟主動(dòng)碎片整理生產(chǎn)需謹(jǐn)慎建議在低峰期驗(yà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)存高出很多第二步確認(rèn)當(dāng)前沒有開啟主動(dòng)碎片整理第三步調(diào)整參數(shù)讓 Redis 在碎片超過一定比例時(shí)后臺(tái)整理。active-defrag-ignore-bytes表示碎片浪費(fèi)低于該值時(shí)忽略active-defrag-threshold-lower表示碎片率超過該百分比才開始整理?？捎^察結(jié)果整理期間used_memory_rss會(huì)逐步下降mem_fragmentation_ratio回落。邊界和常見錯(cuò)誤主動(dòng)碎片整理會(huì)消耗 CPU主線程和子線程都可能受影響不建議在高負(fù)載實(shí)例上直接大范圍開啟另外重啟實(shí)例也能消除碎片但會(huì)造成緩存雪崩風(fēng)險(xiǎn)需要配合預(yù)熱方案。4.3 碎片與淘汰的關(guān)系這里最容易誤解的是碎片率高不等于淘汰會(huì)提前觸發(fā)。淘汰判斷基于maxmemory和used_memory而不是 RSS。也就是說碎片可能讓進(jìn)程被操作系統(tǒng) OOM Kill卻不觸發(fā) Redis 自身的淘汰。生產(chǎn)上如果只盯著碎片率卻不看操作系統(tǒng)內(nèi)存會(huì)出現(xiàn)“Redis 自己覺得還有空間系統(tǒng)已經(jīng)把進(jìn)程殺掉”的情況。因此內(nèi)存告警應(yīng)該同時(shí)覆蓋 used_memory、used_memory_rss 和操作系統(tǒng)剩余內(nèi)存。5. 內(nèi)存淘汰達(dá)到上限后誰先被犧牲當(dāng)used_memory超過maxmemoryRedis 會(huì)按照maxmemory-policy的策略淘汰 Key。常見策略如下策略淘汰范圍是否可能淘汰未過期 Key適用場(chǎng)景noeviction不淘汰寫入報(bào)錯(cuò)不淘汰不允許丟數(shù)據(jù)的場(chǎng)景allkeys-lru所有 Key會(huì)純緩存允許按最近使用淘汰allkeys-lfu所有 Key會(huì)熱點(diǎn)差異明顯希望按頻率淘汰volatile-lru設(shè)置了過期時(shí)間的 Key不會(huì)混合存儲(chǔ)僅緩存部分可淘汰volatile-lfu設(shè)置了過期時(shí)間的 Key不會(huì)有過期時(shí)間的緩存熱點(diǎn)明顯allkeys-random所有 Key會(huì)對(duì)淘汰順序不敏感volatile-random設(shè)置了過期時(shí)間的 Key不會(huì)簡單緩存場(chǎng)景volatile-ttl設(shè)置了過期時(shí)間的 Key不會(huì)希望優(yōu)先淘汰快過期的 Key5.1 淘汰不是精確算法LRU 和 LFU 在 Redis 中都是近似實(shí)現(xiàn)。Redis 不會(huì)維護(hù)完整的訪問鏈表而是通過采樣若干個(gè) Key從中選擇淘汰對(duì)象。采樣數(shù)量由maxmemory-samples控制默認(rèn)值通常是 5調(diào)大更接近精確但更耗 CPU。5.2 一次淘汰行為的觀察下面在測(cè)試環(huán)境復(fù)現(xiàn)一次淘汰前置條件是把實(shí)例限制到很小的maxmemory并設(shè)置策略為allkeys-lru。# 步驟一設(shè)置小內(nèi)存和淘汰策略僅測(cè)試環(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)計(jì)和內(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附近。適用場(chǎng)景用于驗(yàn)證策略是否生效、觀察淘汰速度。容易改錯(cuò)的地方如果策略設(shè)為volatile-*但 Key 沒有設(shè)置過期時(shí)間那么淘汰集合為空寫入會(huì)直接報(bào) OOM 錯(cuò)誤而不是淘汰數(shù)據(jù)。5.3 淘汰與過期的關(guān)系過期 Key 的清理有兩種方式惰性刪除在訪問時(shí)判斷是否過期定期刪除由后臺(tái)周期性抽樣清理。淘汰則是在內(nèi)存達(dá)到上限時(shí)被動(dòng)觸發(fā)。兩者都可能造成延遲但原因不同。如果大量 Key 設(shè)置了相同的過期時(shí)間會(huì)在同一時(shí)刻集中過期可能引起延遲尖刺更穩(wěn)妥的做法是在過期時(shí)間上加隨機(jī)抖動(dòng)。6. 慢查詢把“變慢”拆成可定位的命令6.1 slowlog 記錄的是什么Redis 的慢查詢?nèi)罩居涗浀氖敲顖?zhí)行本身的耗時(shí)不包括網(wǎng)絡(luò)往返和排隊(duì)時(shí)間。相關(guān)配置有兩個(gè)slowlog-log-slower-than表示超過多少微秒記錄slowlog-max-len表示最多保留多少條。查看命令為SLOWLOG GET、SLOWLOG RESET、SLOWLOG LEN。命令作用注意事項(xiàng)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)變慢到定位具體命令輸入是一個(gè)響應(yīng)時(shí)間上漲的實(shí)例步驟是先看慢查詢?cè)俜治雒钌婕暗臄?shù)據(jù)規(guī)模。# 步驟一配置慢查詢閾值例如超過 10ms 記錄10000 微秒redis-cli CONFIG SET slowlog-log-slower-than10000redis-cli CONFIG SET slowlog-max-len256# 步驟二查看慢查詢r(jià)edis-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) # 步驟三確認(rèn)該 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耗時(shí)約 45msKey 名為big:hash:order第三步確認(rèn)它有 50 萬個(gè)字段、占用約 46MB屬于典型大 Key。HGETALL會(huì)一次性返回所有字段數(shù)據(jù)量大時(shí)不僅慢還會(huì)占用網(wǎng)絡(luò)帶寬和客戶端內(nèi)存。處理方向業(yè)務(wù)上改用HGET按需讀取、HSCAN分批遍歷或者把大 Hash 拆分成多個(gè)小 Key。適用場(chǎng)景所有出現(xiàn)響應(yīng)時(shí)間尖刺的實(shí)例。邊界SLOWLOG不記錄網(wǎng)絡(luò)延遲和執(zhí)行前的排隊(duì)時(shí)間如果慢查詢?nèi)罩緸榭盏涌谌匀宦枰挪檫B接池、網(wǎng)絡(luò)、主從同步或客戶端序列化。6.3 大 Key 的排查代碼下面給出一個(gè)用 Java 客戶端掃描大 Key 的完整示例。前置環(huán)境是 JDK 8 及以上、Maven 項(xiàng)目引入 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 個(gè) Key逐個(gè)按類型統(tǒng)計(jì)元素?cái)?shù)量超過 10000 就打印。預(yù)期輸出會(huì)列出大 Key 及其類型和規(guī)模最后打印掃描總數(shù)和大 Key 數(shù)量。適用場(chǎng)景測(cè)試環(huán)境或低峰期對(duì)指定實(shí)例做抽樣檢查。容易改錯(cuò)的地方SCAN只保證遍歷期間存在的元素最終被返回不保證不重復(fù)所以統(tǒng)計(jì)是近似值生產(chǎn)環(huán)境不要用KEYS *替代它。7. 性能調(diào)優(yōu)從參數(shù)到業(yè)務(wù)結(jié)構(gòu)7.1 調(diào)優(yōu)的優(yōu)先級(jí)Redis 性能調(diào)優(yōu)不是先改配置而是先確認(rèn)瓶頸位置?？梢园凑障旅娴捻樞蚺袛嗝顚用媸欠翊嬖?O(N) 大命令、大 Key、頻繁全量遍歷連接層面客戶端連接池是否過小或過大是否存在連接泄漏內(nèi)存層面編碼是否合理、碎片是否過高、淘汰是否頻繁持久化層面是否開啟了 AOF 頻繁刷盤或 RDB 頻繁快照部署層面主從、哨兵、Cluster 是否存在跨機(jī)房高延遲或頻繁故障轉(zhuǎn)移。7.2 管道與批量操作如果業(yè)務(wù)需要連續(xù)寫入大量小 Key逐條命令會(huì)產(chǎn)生大量網(wǎng)絡(luò)往返?？梢允褂霉艿琅堪l(fā)送但要控制每次批量的大小避免單次響應(yīng)過大。下面是一個(gè)完整示例前置環(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()返回管道對(duì)象連續(xù)調(diào)用set只是把命令放入本地緩沖sync()才真正發(fā)送并讀取響應(yīng)。預(yù)期輸出會(huì)打印value-999。適用場(chǎng)景批量寫入、批量刪除等不需要逐條讀取結(jié)果的場(chǎng)景。邊界管道只節(jié)省網(wǎng)絡(luò)往返不減少服務(wù)端命令執(zhí)行成本單次管道過大可能導(dǎo)致客戶端內(nèi)存上漲或服務(wù)端輸出緩沖超限。7.3 用 Lua 減少往返的邊界有些場(chǎng)景需要在服務(wù)端原子執(zhí)行多條命令可以用 Lua 腳本。但腳本本身如果遍歷大集合同樣會(huì)阻塞主線程。下面是一個(gè)簡單示例目標(biāo)是原子地讀取并更新計(jì)數(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í)行會(huì)遞增。適用場(chǎng)景計(jì)數(shù)、限流、簡單的原子讀改寫。邊界腳本執(zhí)行時(shí)間過長會(huì)阻塞其他命令lua-time-limit只控制腳本超時(shí)后的行為不會(huì)自動(dòng)殺死腳本不要在腳本里做大范圍遍歷。8. 常見誤區(qū)誤區(qū)一used_memory 低就說明內(nèi)存沒問題。操作系統(tǒng)看的是 RSS碎片過高時(shí)可能被 OOM Kill。誤區(qū)二重啟能解決內(nèi)存問題。重啟只能清空碎片和過期數(shù)據(jù)如果編碼和 Key 結(jié)構(gòu)不合理問題會(huì)很快復(fù)發(fā)還可能造成緩存雪崩。誤區(qū)三設(shè)置 volatile-lru 就一定能淘汰。如果 Key 都沒有過期時(shí)間淘汰集合為空寫入會(huì)報(bào)錯(cuò)。誤區(qū)四slowlog 沒記錄就說明沒有慢查詢。slowlog 只記錄命令執(zhí)行耗時(shí)不覆蓋網(wǎng)絡(luò)、排隊(duì)和客戶端處理。誤區(qū)五編碼轉(zhuǎn)換后刪除元素就能恢復(fù)內(nèi)存。大多數(shù)編碼轉(zhuǎn)換是單向的刪除元素不一定讓編碼退回緊湊結(jié)構(gòu)。誤區(qū)六KEYS 用于排查大 Key。KEYS會(huì)阻塞主線程生產(chǎn)環(huán)境應(yīng)使用SCAN。9. 生產(chǎn)實(shí)踐建議給所有緩存 Key 設(shè)置帶隨機(jī)抖動(dòng)的過期時(shí)間避免集中過期。對(duì) Hash、List、Set、ZSet 的業(yè)務(wù)規(guī)模設(shè)上限接近編碼閾值時(shí)提前拆分或壓測(cè)。監(jiān)控同時(shí)覆蓋 used_memory、used_memory_rss、evicted_keys、expired_keys 和 slowlog 長度。大 Key 和高頻 Key 定期抽檢寫入鏈路中避免一次性返回大集合。主動(dòng)碎片整理只在評(píng)估 CPU 余量后開啟優(yōu)先在低峰期驗(yàn)證。淘汰策略要與業(yè)務(wù)數(shù)據(jù)性質(zhì)匹配純緩存用 allkeys-lru 或 allkeys-lfu混合存儲(chǔ)用 volatile-lru 并確保有過期時(shí)間。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確認(rèn)是否有慢命令記錄參數(shù)和時(shí)間 | v 4. 對(duì)慢命令涉及的 Key 執(zhí)行 OBJECT ENCODING、MEMORY USAGE、HLEN/LLEN 等 | v 5. 判斷是編碼不合理、大 Key、碎片過高還是淘汰策略不匹配 | v 6. 制定改動(dòng)拆分 Key、調(diào)整閾值、開啟整理、更換淘汰策略或優(yōu)化業(yè)務(wù)訪問 | v 7. 低峰期驗(yàn)證并持續(xù)觀察10.2 面試與復(fù)盤問題為什么小 Hash 用 listpack 而大 Hash 用 hashtable轉(zhuǎn)換后為什么不能自動(dòng)轉(zhuǎn)回used_memory_rss 遠(yuǎn)大于 used_memory 時(shí)可能有哪些原因如何驗(yàn)證allkeys-lru 和 volatile-lru 在 Key 都沒有過期時(shí)間時(shí)分別會(huì)發(fā)生什么slowlog 記錄不到某個(gè)慢請(qǐng)求可能是哪些環(huán)節(jié)造成的大 Key 的常見識(shí)別方式和拆分思路有哪些為什么管道不一定能提升服務(wù)端處理能力11. 總結(jié)回到開頭的告警場(chǎng)景正確的處理順序不是先調(diào)參數(shù)而是先建立定位鏈路用INFO memory看內(nèi)存形狀用OBJECT ENCODING和MEMORY USAGE判斷編碼和大 Key用碎片率判斷內(nèi)存是否被浪費(fèi)用SLOWLOG找到具體慢命令最后再?zèng)Q定是拆分 Key、調(diào)整編碼閾值、開啟碎片整理還是更換淘汰策略?，F(xiàn)象優(yōu)先排查方向典型動(dòng)作內(nèi)存高但 used_memory 不高碎片率檢查 RSS評(píng)估主動(dòng)碎片整理內(nèi)存高且 evicted_keys 增長淘汰策略與數(shù)據(jù)量調(diào)整策略或擴(kuò)容檢查過期時(shí)間延遲尖刺且 slowlog 有記錄大 Key 或 O(N) 命令拆分 Key改用分批命令延遲尖刺但 slowlog 為空網(wǎng)絡(luò)、連接池、持久化檢查客戶端、AOF、RDB、主從延遲編碼從緊湊變?yōu)橥ㄓ脴I(yè)務(wù)數(shù)據(jù)規(guī)?？刂圃?cái)?shù)量必要時(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 項(xiàng)目文檔https://github.com/redis/jedis