🌀 快取踐踏 (Cache Stampede)

Image

當某個熱門資料的快取過期時，瞬間湧入大量請求，導致所有請求同時打到原始資料來源（如資料庫或第三方 API），形成類似「踩踏」的效應。
這些請求原本應E2該從快取中直接取得結果，卻因快取剛好失效，全部穿透防線、直接進攻後端資源，造成伺服器短暫過載。

📦 實際案例：
假設你有一個商品頁，每次顯示都包含了價格、樣式、庫存狀態等資訊。這些資料通常是快取的理想對象。但當電商促銷活動一開始，流量暴增，而快取又在這個時候剛好過期，所有用戶的請求就會「同時」觸發重新生成快取，導致伺服器一時間被壓垮。

🔒 解法：
為了防止這種現象，系統會採用「資源鎖定（Lock）」機制，讓第一個進入的請求負責重建快取，其餘的請求等待結果完成後再讀取，這樣就能避免所有請求同時打進後端。

這也是一個絕佳的壓力測試案例！可以刻意設計快取在高流量時過期，觀察系統是否有妥善應對。



🌀 雷鳴群聚 (Thundering Herd)

Image

在短時間內大量請求同時湧入，對快取系統或後端資源造成瞬間衝擊。不同於「快取踐踏」是因為某個快取過期才導致的，雷鳴群聚是主動湧現的洪流，常見於以下場景：

🎟️ 典型案例：

搶票網站開賣：演唱會門票一開放，數十萬人同時刷新頁面搶票。

限時秒殺活動：某商品在 12:00 準時開搶，所有人都設好鬧鐘準時點擊。

大型直播網站：重大賽事開打瞬間，用戶齊聚進入主頁。

這類情境就像雷聲齊鳴、群獸奔騰，若系統快取策略與資源配置不足，很容易導致系統雪崩。

🧯 解法建議：

  • 提前預熱（Warm-up）：可在活動前預先產生快取內容。
  • 分批引流：透過 CDN 或 queue 分流請求，避免同時進站。
  • 使用更具彈性的分布式快取（如 Redis + Lock 機制）。