可以簡單的理解為: 系統剛剛部署完畢,所有快取資料還未準備完畢或者由於原有快取有效期集體到達
例如: 系統中所有快取都設定的一致的過期時間,在同一時刻出現大面積的快取過期,所以原本應該查詢快取的請求都去查詢資料庫了,造成資料庫壓力驟增,甚至宕機.
使用加鎖或者佇列的方式保證不會有大量執行緒對資料庫進行一次性讀寫,設定熱點資料永不過期,同時將快取的過期時間設定分散.
設定系統上線後就對需要快取的資料進行快取,而不是在第一次查詢後才把資料加入快取,這樣做到了事先對快取資料進行預熱.
1.寫乙個重新整理快取的介面,系統上線後手動請求重新整理快取
2.快取資料量不大時,可以設定專案啟動成功後載入快取資料
3.設定定時重新整理快取
快取穿透指使用者端查詢了乙個資料庫中不存在的資料,自然在快取中也不存在.這就導致了使用者進行了兩次無用查詢.
推薦的方式是使用bloom-filter(布隆過濾器),將所有可能存在的資料儲存到乙個足夠大的bitmap中,乙個一定不存在的資料會被這個bitmap過濾掉,從而避免了對底層資料庫系統的查詢壓力.
還有乙個簡單粗暴的方式,如果乙個查詢返回的資料為空(不管是資料不存在還是系統故障),仍然把這個空結果放入快取中,設定很短的過期時間(不超過5分鐘).通過這個直接設定預設值進快取的方式,這樣第二次查詢快取的時候就有值了,避免去訪問底層資料庫系統了.
redis快取常見問題及解決方案
快取雪崩 當快取伺服器重啟或者大量快取集中在某乙個時間段失效，這樣在失效的時候，會給後端系統帶來很大壓 力。導致系統崩潰。解決方案 在快取失效後，通過加鎖或者佇列來控制讀資料庫寫快取的執行緒數量。比如對某個key只允許乙個線 程查詢資料和寫快取，其他執行緒等待。做二級快取，a1為原始快取，a2為拷貝...
Redis快取常見問題
這是決定在使用快取時就該考慮的問題。快取的資料在資料來源發生變更時需要對快取進行更新，資料來源可能是 db，也可能是遠端服務。更新的方式可以是主動更新。資料來源是 db 時，可以在更新完 db 後就直接更新快取。當資料來源不是 db 而是其他遠端服務，可能無法及時主動感知資料變更，這種情況下一般會選...
Redis 快取常見問題 快取一致性的解決方案
先更新資料庫，再刪除快取 redis 快取常見問題 快取雪崩，快取擊穿，快取穿透，快取預熱 在之前的部落格中，我介紹了redis快取的一些常見問題，如 快取雪崩 快取擊穿 快取穿透等。這次就來介紹一下redis的快取一致性的問題。對於快取和資料庫的更新操作，主要分為以下兩種 首先可能會帶來疑惑的點是...