前言

前幾天我們聊過 Redis 記憶體爆炸，也提到命中率偏低，代表裡面有很多快取是「存了卻沒被用到」。
那問題來了 —— 為什麼會有這麼多重複的 cache？
今天我們就直接打開 Magento 的程式碼，來看看它到底是怎麼生成 Redis key 的。

程式碼追蹤：Identifier.php

在 Magento 的 \Magento\Framework\App\PageCache\Identifier 裡，有一個 getValue() 方法負責產生快取用的 identifier。

public function getValue()
{
    $data = [
        $this->request->isSecure(),                // 是否 HTTPS
        $this->request->getUriString(),            // 完整網址 (含 query string)
        $this->request->get(Http::COOKIE_VARY_STRING)
            ?: $this->context->getVaryString(),    // 其他參數 (通常是 null)
    ];

    return sha1($this->serializer->serialize($data));
}

生成流程

1. 組合 $data

   • isSecure() → 判斷是否 https
   • getUriString() → 取完整網址
   • getVaryString() → 帶入 cookie vary 或額外參數

2. 序列化
   serialize($data) → 把 array 轉成字串

3. 轉雜湊
   sha1() → 計算哈希，得到固定長度的字串

4. 結果
   這個字串就是 identifier 值，會被用在 Redis 當作快取 key 的一部分。

問題在哪？

光是看這段程式碼，我們就能發現一些關鍵：

• http / https 不同 → 兩份快取
• 網址不同（即使 query string 不影響內容） → 兩份快取
• cookie vary string 不同 → 又一份快取

結果就是：
「同一個實際內容的頁面，卻可能生成出多個不同的快取 key」，導致 Redis 裡充滿重複又浪費的快取。

結語

所以答案很明顯了：
Redis 快取裡的重複資料，並不是 Redis 本身的問題，而是 Magento 在生成 identifier 時過於敏感，把 URL、協議、cookie 全部都考慮進去，才會讓快取數量爆炸。

明天我們就來討論：
👉 既然知道原因了，那要怎麼優化？能不能「合併這些重複快取」？