遊戲 Lag 白皮書 › L12 資料庫
Cache stampede Cache stampede / thundering herd
原因 ID db-cache-stampede · 主要負責 遊戲開發團隊（伺服器開發） · 協同 基礎設施團隊（DB 基礎設施）
在含圖解與實驗的完整版中開啟卡片 →
熱門資料的快取同時過期時，數千個請求會一口氣湧向 DB。
為什麼 存放在 Redis 等快取中的熱門資料同時過期 → 於是 要重新產生同一筆資料的請求一口氣湧向 DB → 畫面上 DB 過載，多項功能接連變慢甚至停住
症狀 輸入延遲 , 定格 , 連不上／無限讀取 因素 停滯, 延遲
誰會遇到 整個伺服器
何時 固定週期, 人潮湧入時
負責單位 主要負責 遊戲開發團隊（伺服器開發） · 協同 基礎設施團隊（DB 基礎設施）
遊戲開發團隊要做的事 把過期時間隨機分散；只讓一個請求更新，其餘請求繼續使用舊值。
基礎設施團隊要做的事 為 Redis 建置複本與自動容錯移轉，避免重新啟動或故障時整個快取被清空；確認 DB 有足夠餘裕，即使快取全空也撐得住。
圖表上 查看位置 把 Redis INFO 的 keyspace_hits、keyspace_misses（命中率）、expired_keys、是否重新啟動（uptime_in_seconds）與 DB 每秒查詢數疊在一起看，並統計那個瞬間 DB 上同一個查詢同時有幾個在執行（MySQL SHOW PROCESSLIST、PostgreSQL pg_stat_activity） 符合的跡象 快取未命中瞬間暴衝時，DB 查詢數也一起往上衝，同時執行的查詢大多是讀取同一筆資料的同一個查詢。與熱門 key 的過期週期或 Redis 重新啟動時間重疊 不符合的跡象 快取未命中與平常相同、只有 DB 查詢增加時，是登入暴增（db-login-storm）或批次作業（db-batch） 確認方式 用基礎設施工具確認（不需要遊戲程式碼）
深入了解 Redis 重新啟動或因故障導致快取整個清空時，也會發生同樣的事。越是仰賴快取而把 DB 規格壓小的架構，風險越高。
出處 Scaling Memcache at Facebook (NSDI '13) USENIX 常用的 key 失效時大量讀取湧向 DB 的 thundering herd，以 lease（只讓一個用戶端更新）與回傳舊值來防止；快取為空的叢集另外預熱 Optimal Probabilistic Cache Stampede Prevention VLDB Endowment 熱門項目過期時多個請求同時重新產生的 cache stampede，以在過期前依機率提早更新來防止 High availability with Redis Sentinel Redis 主伺服器故障時把複本升格的自動容錯移轉 INFO Redis keyspace_hits、keyspace_misses（key 查詢成功、失敗次數）、expired_keys（過期的 key 數）、uptime_in_seconds（啟動後經過的時間） SHOW PROCESSLIST Statement MySQL 每個 session 正在執行的陳述式（Info）與停留在目前狀態的時間（Time，秒） The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL pg_stat_activity：每個 session 目前執行中的查詢（query） 相關原因
同一層：L12 資料庫
同一症狀（輸入延遲）在其他層的原因
查看含圖解與實驗的完整版卡片