快取中沒有命中資料，直接到資料庫中查詢
解決：對這些不存在的資料快取乙個空資料
對這類請求進行過濾（）布隆過濾器
指的是由於資料沒有被載入到快取中，或者快取資料在同一時間大面積失效（過期），又或者快取伺服器宕機，導致大量的請求都到達資料庫。
解決：為了防止快取在同一時間大面積過期導致的快取雪崩，可以通過觀察使用者行為，合理設定快取過期時間來實現；
為了防止快取伺服器宕機出現的快取雪崩，可以使用分布式快取，分布式快取中每乙個節點只快取部分的資料，當某個節點宕機時可以保證其它節點的快取仍然可用。
也可以進行快取預熱，避免在系統剛啟動不久由於還未將大量資料進行快取而導致快取雪崩。
快取一致性要求資料更新的同時快取資料也能夠實時更新。
解決方案：
在資料更新的同時立即去更新快取
在讀快取之前先判斷快取是否是最新的，如果不是最新的先進行更新
要保證快取一致性需要付出很大的代價，快取資料最好是那些對一致性要求不高的資料，允許快取資料存在一些髒資料。
Redis快取雪崩 快取穿透 快取一致性問題
一 快取雪崩 1 快取失效時間相同導致大量快取同時失效 2 快取系統故障 事後 快取資料持久化，在故障後快速恢復快取系統 二 快取穿透 1 訪問不存在資料從而繞過快取，直接讀取資料庫 三 快取一致性 1 常規流程是 讀操作 命中快取則返回，無快取則讀資料庫並寫快取 寫操作 先刪除快取，再更新資料庫。...
快取一致性問題討論
在資料庫與快取之間的一致性問題?最好的是 先寫資料庫,再刪除快取.原因 寫資料庫之後證明寫成功了,順便把快取刪除了.寫成功之後拿到的資料就是最新的.寫資料庫失敗了,快取沒刪除,還是原來的資料,無傷大雅,寫失敗了,刪除快取成功了?這種事情不會發生的,即使發生了,也沒有問題,查庫,還是原來的資料.問題來...
redis快取一致性問題
1 不一致產生的原因？我們在是使用redis過程中，通常會這樣做，先讀取快取，如果快取不存在，則讀取資料庫。不管是先寫庫，再刪除快取 還是先刪除快取，再寫庫，都有可能出現資料不一致的情況。因為寫和讀是併發的，沒法保證順序，如果刪除了快取，還沒有來得及寫庫，另乙個執行緒就來讀取，發現快取為空，則去資料...