你以為Redis只是個簡單的緩存？不，它吃內存的速度堪比我深夜點外賣的速度。今天我們就通過一個真實的“線上事故”，聊聊Redis的物理資源消耗、內存滿了會發生什麼、以及我們該怎麼優雅地做內存優化。

引言

那天，我正愜意地泡着咖啡，準備開個早會。結果Slack上一個紅色警告信息像驚雷一樣炸響：

“Redis節點內存使用率100%，應用開始大量超時！”

“啊？Redis又吃滿了？”我心頭一緊。

這不是第一次了。作為團隊裏那個“凡是有緩存就找他”的人，我深知這意味着什麼——線上緩存雪崩，數據庫壓力暴漲，系統延遲飛天。

我一邊衝進監控面板，一邊心想：這次一定要徹底搞明白——Redis到底主要消耗什麼物理資源？為什麼老是吃內存？又該怎麼優雅地控制它？

Redis最“愛吃”的資源是什麼？

Redis的核心本質就是一個內存數據庫（in-memory database），從名字就能看出來——它最愛的就是內存（Memory）。

但別以為只有內存，它也會消耗：

我看着Grafana上的資源監控圖，果然，內存條那根紅線幾乎貼在頂上，CPU卻還算平穩。

我笑着搖搖頭：“果然是個吃內存的傢伙。”

那Redis內存滿了，會發生什麼？

我在事故分析會上舉了個形象的比喻：

“Redis的內存就像一杯水，水太多會溢出來；而溢出的方式，取決於你裝的是什麼杯子。”

Redis的“杯子”就是——內存淘汰策略（Eviction Policy）。當Redis內存被吃光時，它會根據策略來決定“誰該被趕出去”。

常見策略如下：

在那次事故中，發現他們的Redis配置居然還是默認的noeviction。

也就是説——內存滿了，Redis直接拒絕所有寫入！結果：

• 業務線程在等待寫緩存；
• 緩存寫不進；
• 數據庫被反覆請求，負載飆升；
• 系統延遲一路飛天。

我嘆了口氣：“怪不得那天數據庫CPU飆到90%，原來是Redis堵車了。”

Redis內存為什麼會越來越“胖”？

我打開info memory一看，好傢伙，used_memory已經突破了預警線。我總結了幾類Redis吃內存的常見“黑洞”：

1. Key太多太碎

• Redis存的每一個key都有元數據（比如類型、過期時間、引用計數等），這些開銷在百萬級數據時非常明顯。
• 解決思路：合併小key、使用hash結構、壓縮存儲。

2. value太大

• 有人把幾百KB的JSON對象直接塞進Redis……
• 結果：內存用得飛快，網絡傳輸還變慢。
• 解決思路：只緩存必要字段，或使用壓縮（如Snappy、LZ4）。

3. 過期策略設置不當

• 沒設置TTL的緩存永遠不刪，最終內存被“殭屍數據”佔滿。
• 解決思路：緩存一定要設置合理TTL。

4. 複製（Replication）

• 主從同步時，主節點會生成RDB快照，臨時會額外佔用一倍內存。
• 解決思路：合理設置複製延遲、使用AOF+RDB混合持久化。

5. 內存碎片化

• Redis底層使用jemalloc內存分配器，不同大小的對象混在一起容易造成內存浪費。
• 解決思路：定期重啓節點或使用MEMORY PURGE。

那Redis內存滿了，我們該怎麼救？

事故處理會上，我總結了三步走策略：

第一步：立刻止血

• 臨時提高maxmemory（如果機器內存足夠）；
• 或臨時切換淘汰策略為allkeys-lru；
• 同時用redis-cli --bigkeys分析大key；
• 再用MEMORY USAGE查看高佔用鍵，進行手動清理。

我笑説：“那天我像在拔插管救人，刪的都是幾十MB的大key，手都抖。”

第二步：系統優化

這才是關鍵：

第三步：內存“減肥”術

後來，我的團隊甚至給Redis做了一套“減肥計劃”：

• 壓縮數據結構：開啓hash-max-ziplist-entries和list-max-ziplist-size等配置，讓小對象以緊湊編碼存儲。
• 刪除無用key：用scan命令定期掃描過期key，做延遲清理。
• 冷數據下沉：把長期不用的歷史數據，遷移到MySQL或Elasticsearch。
• 熱點key隔離：高頻訪問的數據放在獨立實例，防止拖慢整體性能。

事後覆盤：那次Redis事故，學到了什麼？

幾天後，我在團隊分享會上説了一句話，讓大家印象深刻：

“Redis最危險的地方在於——它用得越順手，你越容易忘了它有上限。”

這話一點不假。很多團隊把Redis當“無底洞”，不停往裏塞數據，卻忘了它是基於內存的系統。

內存是有限的。數據有生命週期。緩存是用來加速訪問的，不是用來堆積歷史的。

最後的思考：Redis內存優化的“哲學”

我後來在技術博客上寫道：

Redis優化，不只是調參數，更是一種“數據治理”的思維。

我總結出一條金句：

“Redis的優化，本質上是對數據的取捨。”

緩存的設計哲學應該是：

把最有價值、最常訪問的數據留在內存裏；把冷門、冗餘、歷史數據交給磁盤。

內存是Redis的生命，也是它的陷阱。理解它、控制它，才能真正駕馭Redis這匹“野馬”。

Redis優化建議

1. 為每個key設置TTL；
2. 優先使用allkeys-lfu策略；
3. 定期用bigkeys和info memory巡檢；
4. 開啓壓縮結構（ziplist、intset）；
5. 建立監控+告警；
6. 永遠記得——Redis不是數據庫，是緩存。

面試結語

當面試官問你：

“Redis主要消耗什麼物理資源？內存滿了會怎樣？如何優化？”

你只要笑着答：

“Redis最核心的是內存資源；當內存耗盡時，它會根據淘汰策略清除數據；優化的關鍵在結構、策略、壓縮與監控。”

然後輕輕補上一句：

“Redis的優化，不是讓它裝更多，而是讓它裝得更聰明。”

面試官一定會心一笑。而你，也從那個“Redis崩潰現場”中，真正畢業了。

END

我是小米，一個喜歡分享技術的31歲程序員。如果你喜歡我的文章，歡迎關注我的微信公眾號“軟件求生”，獲取更多技術乾貨！