前言

昨天我們一起實戰看了 Magento 的 Full Page Cache（FPC）到底是怎麼存進 Redis 的。
那個過程有點像「打開黑箱」，原本我們只看到一個索引，差點以為什麼都沒有，結果仔細一看，真的有頁面快取藏在裡面。

不過光是「看得到快取」還不夠。
因為前面我們就提到一個更大的問題 —— Redis 記憶體常常爆炸，導致整個 FPC 失效。
所以我們開始思考：是不是 Redis 裡塞了很多沒什麼用的快取，才會讓記憶體一直撐不住？

帶著這個疑問，我們就去檢查 Redis 的一些狀態指標，特別是「快取命中率」。

Redis 的幾個必要指標

在伺服器裡，我們可以透過以下指令看到 Redis 狀態：

redis-cli info

會出現一大堆參數，但其實只要注意幾個重點，就能快速判斷 Redis 的健康狀態。

1. maxmemory / maxmemory_policy

• maxmemory：Redis 的最大可用記憶體。

• maxmemory_policy：超過記憶體後，要用什麼方式淘汰資料。
  常見策略有：

  • noeviction → 不允許再寫入（通常會導致錯誤）
  • allkeys-lru → 從所有 key 裡挑最少用的刪掉
  • volatile-lru → 只刪掉有設定過期時間的 key

👉 這個數值直接決定 Redis 撐不撐得住，如果 maxmemory 設太小，快取很快就被擠掉。

2. used_memory / used_memory_human

• 這就是 Redis 目前實際用掉的記憶體量。
• used_memory_human 會用比較好懂的單位（MB/GB）顯示。

👉 通常要定期觀察這個數值，如果快逼近 maxmemory，就要小心了。

3. keyspace_hits / keyspace_misses

• keyspace_hits → 有成功從快取讀到資料的次數。
• keyspace_misses → 沒有讀到快取，只能去資料庫或後端撈的次數。

👉 這兩個數字最關鍵，因為它們能告訴我們「快取到底有沒有發揮作用」。

4. 命中率（hit ratio）

這個要自己算：

hits / (hits + misses)

例如：

• hits = 800
• misses = 200
• 命中率 = 800 / (800+200) = 80%

👉 一般來說，命中率要高才合理，如果低於 50%，就代表快取常常沒派上用場，Redis 白白佔了很多空間。

我們觀察到的狀況：命中率偏低！

之所以我們會特別去看 快取命中率，就是因為 Redis 記憶體老是爆炸。
我們懷疑：是不是 Redis 裡面存了太多「沒什麼用的快取」，才會把記憶體撐爆？

結果實際去看 Redis 的狀態，果然發現一件有點奇怪的事情：
快取命中率偏低。

這代表什麼？
就代表 Redis 裡雖然存了很多頁面快取，但有不少其實沒有被用到。

用個比喻來講，就好像我們準備了一個大冰箱，把各種菜都塞進去，結果真正有吃到的菜比例不高，很多最後都壞掉被丟掉。
這樣就不太合理了，因為快取的目的就是要幫忙減輕後端壓力，如果命中率偏低，那些快取反而是在浪費記憶體。

💡 小提醒
這種「大量快取卻沒被有效使用」的狀況，很可能就是導致 Redis 記憶體爆炸的原因之一。
換句話說，問題可能不只是「Redis 太小」，而是「快取本身沒有效率地派上用場」。

總結

今天我們先小小科普了 Redis 幾個重要的參數：

• maxmemory / policy 決定 Redis 的天花板。
• used_memory 看現在用了多少。
• hits / misses 則能看快取到底有沒有派上用場。

最後我們也發現了一個警訊：快取命中率偏低，而這也許就是跟 Redis 記憶體老是爆炸有關聯。

那到底是什麼機制，讓 Redis 塞了一堆沒什麼用的快取？
這個，我們就留到明天再深入探討啦！