前言

前兩天我們聊到 Redis 記憶體爆炸的問題，並且發現了一個警訊：快取命中率偏低。
照理說，Page Cache 打開之後，大部分的頁面都應該要直接吃快取，命中率理應很高。
但我們實際看到的卻不是這樣。

那麼問題來了 —— 到底是哪些快取沒有被用到？

我們開始檢查 Cache 內容

為了搞清楚狀況，我們決定直接去 Redis 裡看看快取的內容。
一開始只是抱著好奇心，隨便抽幾個來對照，結果發現：

👉 很多 cache 的內容其實長得一模一樣。

也就是說，Redis 裡存了好幾份相同的頁面 HTML。
這就很奇怪了，因為快取的目的就是「存一次 → 多次使用」，不應該同一個東西被重複塞滿記憶體。

廣告期間的發現

更誇張的是，這件事情在我們打廣告的時候特別明顯。
因為廣告流量進來的使用者，常常會帶著各種追蹤參數（像是 utm_source=fb、utm_source=google 這類）。
我們觀察到：

• Redis 的快取 key 數量在短時間內暴增。
• 裡面大部分的內容，其實就是同一個商品頁或同一個 Landing Page。
• 唯一的差別就是 URL 上的 query 參數。

這讓我們更確定：同一個頁面被快取成了好多份。

為什麼這會導致命中率低？

回頭來看命中率偏低的問題，現在就合理了：

• 使用者帶著不同參數進來，Redis 會覺得這是「不同的頁面」。
• 結果同一個商品頁，可能被快取成十幾份。
• 當流量平均分散到這些重複快取，命中率自然被稀釋掉。

換句話說：
我們原本以為 Redis 裡的快取是一份份「精挑細選」的寶物，結果實際上卻是滿滿的「重複檔案」。
佔了記憶體，卻沒有帶來真正的效益。

總結

今天我們更進一步觀察了 Redis 的快取內容，得到了一個重要發現：

• 命中率低 → 很多快取沒有派上用場。
• 檢查內容後 → 發現 Redis 裡存了大量重複的頁面。
• 在廣告期間 → 這個現象更嚴重，因為同一頁面被各種 query 參數分裂成多份快取。

預告明天

那麼問題來了：為什麼同一個頁面會被重複快取呢？
是我們的設定錯誤？還是 Magento 本身的快取邏輯？
明天，我們就來揭開這個黑箱。