前言

在過去幾天，我們一路從 問題發現（Redis 記憶體爆炸、命中率偏低）、原因分析（同樣內容卻被不同 URL Cache 重複存入）、到 解法落地（寫了一個 Plugin 攔截 Identifier，把 URL 正規化）。
今天，我們終於可以跟大家分享 實際上線後的成果 —— 這不只是理論上的優化，而是真正在 2025/03/03 上線，並且在 Google Cloud Monitoring 裡持續追蹤觀察的結果。

上線時間

📅 2025/03/03 已正式上線
從這天開始，所有進來的頁面快取識別符（FPC Identifier）都經過我們的過濾邏輯，確保 同內容 → 同 Key。

觀察結果

記憶體用量/記憶體上限

👉 結果：使用量下降，符合預期
過去因為同一個頁面多了不同參數（例如排序、追蹤碼），會產生不同 Redis Key，導致快取越存越多，最終記憶體被撐爆。
現在，這種重複情況消失了，Redis 用量明顯下降，也代表快取「更乾淨」。

已撤銷的金鑰/過期的金鑰

👉 結果：撤銷減少，符合預期
因為記憶體沒有再被過度吃滿，Redis 不再頻繁丟棄舊 Key，大部分快取都能被完整保留。
這代表使用者命中快取的機率更穩定。

已接收的連線/已拒絕的連線

👉 結果：不變
這部分其實在預期之內，因為流量本身沒有減少。
快取優化是「同樣流量 → 更有效利用 Redis」，所以連線數量自然不會有差別。

命中率

👉 結果：維持甚至提高
命中率沒有降低，這非常重要。
我們做的事情是「減少重複快取」，所以命中率應該 維持或往上升。
目前的數據也印證了這個推測。

呼叫數量

👉 結果：下降！
因為現在同一個頁面都命中同一個快取，不會再額外去抓其他 Block 或 Model 的 Redis，導致整體呼叫次數下降了。
這直接減少了後端壓力。

結語

這次的實驗證明了：

• 小小一個 Identifier Plugin，就能帶來 記憶體用量下降、快取保留率提升、呼叫數減少 的顯著成果。
• 命中率維持甚至更好，讓我們確認這條路是正確的。

太棒了！ 🎉
我們真的解決了公司一直以來的效能瓶頸。
從此以後，Redis 不再被一堆沒意義的 query 污染，整個系統跑得更快、更穩定。