圖片來源：pexels
Progressive Caching Strategy：在大基數、慢建立的狀況下優雅快取更新資料
快取是什麼？
快取是絕大多數中大型網站都會用到的一種效能優化機制，核心目的只有一個：避免重複的資料處理或查詢，提升系統反應速度與穩定性。只要系統開始出現「流量集中」或「重複查詢」的情況，例如熱門頁面或熱門商品列表，快取就會成為你不可避免要考慮的手段。
快取的建立方式大致可以分成兩類：
- 預先建構：當資料量已知、邏輯穩定時，可以事先批次產出所有需要的快取。例如熱門商品排行榜、每日新聞首頁這類 group by 或 aggregation 場景。這種方式讓使用者幾乎永遠命中快取，但這會佔用較多儲存空間，建立與維護大量快取也可能對系統造成額外壓力。
- 動態建立：當使用者請求某筆資料時，若快取不存在，系統才會即時建構資料並儲存供下次使用。這種方式彈性高又節省儲存空間，但若建立成本高或資料來源不穩定，容易導致使用者等待過久甚至 timeout，更可能因為命中失敗而造成快取雪崩、擊穿 (cache avalanche、hotspot invalid) 等問題。
可以看出，預建適合基數小、建立速度慢的情境；動態建立則偏好基數大、建立速度快的場景。但當你同時遇上「資料基數大」與「建立速度慢」的場景時，常見快取策略便難以為繼。
什麼時候經典快取策略會失效？
當你同時遇上以下兩種條件時，常見的快取策略往往全面失效：
- 資料基數極大：預建所需資源龐大、耗時費力，甚至可能難以順利執行。
- 建立成本極高：資料需跨服務聚合、依賴第三方 API 或模型推論，導致單次建構耗時且不穩定。
以大型電商平台為例，假設每個商品頁都有一個推薦區塊，其內容來自多個外部來源與即時推論，平均建構時間超過 3 秒。在商品數量達數萬至數十萬級的情況下，全面預建幾乎無法完成——排程時間過長、儲存壓力劇增；而若改為動態建立，使用者則需面對漫長等待，並進一步放大 timeout、雪崩、擊穿等問題。
但這樣的場景真的無解嗎？在我們討論解法之前，有一個關鍵問題值得先釐清：
| 這些資料真的「每一筆」都同樣熱門嗎？ |
我們以典型推薦系統資料集 MovieLens Latest Datasets (small version) 為例 (共 600 位使用者、9,000 部電影、100,000 筆評分)，統計每部電影被評分的次數，並依照熱度排序如下：
圖中紅線標示的區段為：前 2,224 部 (約 25%) 最熱門的電影，就佔據了整體 80% 的互動量。這種高度不對稱的流量分佈，是打破快取兩難的破口。
當你意識到，大多數資料其實是冷門、幾乎不會被請求時，就可以放下「每一筆都要預建」或「每次都要立即建構」的執念，轉而思考一種更務實的策略 —— 逐步建立、分階段更新的 Progressive Caching。
| 補充說明：若資料規模極大，且幾乎每筆都是高頻熱點，這已超出快取策略的能力範疇，屬於大規模系統設計問題。建議從模型優化、分散式架構設計，與第三方 API 協議重新協商等方向思考整體架構。 |
解法總覽：三階段 Progressive Caching 策略
當我們認清：不是所有資料都需要即時、也不是所有請求都有相同頻率，就能跳脫「單一快取策略」的框架，設計出一套更彈性、分層的快取更新方案。我們將這套 Progressive Caching 策略劃分為三個階段，從「熱資料快取」開始，延伸到「冷資料更新」，最後再進一步規劃「預判預取」。
圖片由 napkin.ai 產生
在接下來的章節中，我們將分別介紹這三個階段的具體作法與設計細節。
第一階段：熱資料快取
熱資料快取的核心精神，是根據歷史行為資料，預測那少數承擔絕大多數流量的熱門資料，並定時預先建構快取內容，確保使用者幾乎永遠命中。
但「熱門」該怎麼定義？本質上這是一種預測問題，你必須根據過去的觀察，去判斷哪些資料在未來會再度被需要。不同的系統規模與精細程度，可以採取不同的實作方式：
- 簡單規則：以「過去一小時點擊數」、「本週購買數」等統計值為基礎，排出 Top N 項目。
- 加權指標：將瀏覽、點擊、互動、轉換等指標加權計算，調整不同行為的影響力。
- 機器學習模型：根據歷史資料訓練 CTR / 熱度預測模型，自動預測未來的熱門資料，甚至個人化建構使用者特定快取。
- 混合機制：將人工規則與模型預測結合，例如定期重新選出候選清單，再透過模型排序。
選擇哪種方式取決於你對準確率、更新頻率、與系統負載的需求。
這個階段屬於快取策略中最高報酬的部分，近八成的使用者需求都能被妥善處理。下一章，我們將進入比較棘手的，那些剩餘的冷資料。
第二階段：冷資料更新
針對那些剩餘的冷資料，我們無法也不該為他們逐一預建快取，但可以採取懶更新 (lazy update) 的策略，在使用者請求發生時觸發快取建構，但將資料建構的工作推往背景執行，不阻斷當前請求流程、不犧牲使用者體驗。
實際作法上，當某筆資料快取未命中時，系統會：
- 嘗試提供已有的 fallback（例如不需快取的欄位、殘留快取、骨架畫面或舊資料等）。
- 同時將該請求排入非同步佇列，交由背景 worker 處理資料抓取與快取建構。
- 資料建構完成後，除了寫入快取外，也可通知前端資料已就緒，使取得 fallback 的使用者看到更新提示或自動刷新內容。
- 隨後的使用者請求，即可命中更新後的快取。
為了讓這套機制穩定運作，建議搭配以下措施：
- 推播通知：當快取建構完成時，主動通知前端（如 WebSocket、Server-Sent Events、Polling）。
- 非同步佇列 (queue)：建構任務與主請求流程解耦，也方便後續控制更新流量與管理失敗重試。
- 去重與資源鎖 (deduplication / lock)：避免短時間內重複建構同一筆資料。
- rate limiting：控制處理任務速度，避免過載資料來源或外部 API。
- 重試與錯誤記錄：針對建構失敗的項目做重試、記錄錯誤等策略。
整體核心概念是，資料可以慢一點建構出來，但不能把使用者卡住。除了透過後端的非同步處理與逐步建構，前端畫面也能在 UX 設計上盡可能感受不到被卡住、不讓尚未更新的資料太過搶眼。
下一章，我們將更進一步，嘗試在使用者還沒請求前就先開始建構冷資料快取。
第三階段：預判預取
在快取策略的最後一層，我們嘗試預測使用者「下一步」可能會點擊的資料，讓資料在還沒被請求時就已準備妥當。將「冷資料更新」的觸發條件，從實際請求移動到「潛在即將發生的行為」。
1. 簡單預測：基於熱門區塊或結構化引導
適合流量大、頁面結構明確的平台。舉例來說：
- 當使用者開啟首頁，即排程載入「你可能感興趣的商品」或「下一個頁籤」的快取建構。
- 根據 CTR 模型預測推薦區塊點擊率較高的商品，提前建構其商品頁面快取。
- 頁面邏輯已知的流程（如「類別頁 → 商品頁」），可透過路徑分析模擬下一步點擊機率，依此預載商品清單。
這些方法本質上屬於「單點預測」問題，僅需判斷某個資源是否值得預先快取。
2. 進階預測：基於使用者瀏覽序列的行為預測
若能記錄使用者的近期瀏覽路徑（如滑過哪些商品、點過哪些類別），就能採用類似推薦系統與 NLP 常見的序列模型，預測出接下來最有可能被點擊的資料。例如：
- 將「商品 A → 商品 B → 商品 C」視為一段 session 行為序列。
- 使用 Seq2Seq 模型、Transformer、或 RNN 類型架構訓練行為路徑預測。
- 根據預測序列產生前 N 名可能請求資料，提前丟入 queue 建構快取。
這類方法的訓練與部署較複雜，但能更細緻捕捉使用者興趣轉移與點擊路徑。
整體來看，這一階段不只是資料快取，也屬於機器學習、推薦系統的範疇，讓整個服務擁有預判、猜測的能力。
結論
第三階段的預測快取雖然具備高度技術含量與應用潛力，但也意味著更多投入。團隊需建立完善的資料收集流程、行為建模與推論邏輯，才能有效運作這樣的機制。因此，若系統規模尚小、資源有限，其實僅實作前兩階段（熱資料快取與冷資料更新）就足以解決多數效能與體驗瓶頸。
但若有意更進一步導入使用者行為預測邏輯，這些技術將同步擴展系統的反應與佈局能力。當你能預判使用者的下一步，許多新的應用場景也會自然浮現：
- 主動推播可能感興趣的內容，提升用戶參與度。
- 預先載入推薦素材或廣告，提升系統整體反應效率。
- 更精準地安排畫面內容與佈局順序，強化使用者體驗。
這樣的能力不一定要直接發展為推薦系統，而是代表系統逐漸具備預測能力，也為日後的搜尋優化、個人化推薦或用戶分析打下基礎。
參考資料：
[1] napkin AI (用於繪圖)
