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