快取可以狹義的理解為是擋在db之前的一層資料塊，效能比db高很多倍。服務系統查資料，首先會查快取，如果快取資料不存在，就進一步查 db，最後查到資料後回種到快取並返回。快取裡的資料儲存基本上都是以 key 為索引進行儲存和獲取的。
原因
寫快取時一般都會帶上乙個過期時間，讓快取資料在這個固定的過期時間後被淘汰。一般情況下寫入時間肯定是不同的，所以過期也是不同的。但是如果快取資料是通過定時任務等操作來載入的，那麼過期時間就會相同，這批資料如果到時間後，一起過期了，那麼大量快取就不存在了，此時就視為快取失效
解決方案
讓過期時間不相同，在設定過期時間時，使用：過期時間=固定時間+隨機時間，比如expiretiime=6h+30min ,就是讓一批快取在6小時後，在30分鐘內慢慢的過期，以保證不會一次性大量失效。
原因
當請求需要查詢資料的時候，快取中查詢的key不存在，然後去db中查詢資料，結果也不存在，這樣就不會有資料塞回快取中，那麼下一次相同的操作又會重複查db。一兩次這樣的錯誤操作db可以承受，但如果短時間內大量這種情況發生，就會對db產生很大的壓力，影響正常db操作。比如有某些指令碼機械人無限重複查詢。
解決方案
方案一：查詢這些不存在的資料時，第一次查 db，雖然沒查到結果返回 null，仍然記錄這個 key 到快取，只是這個 key 對應的 value 是乙個自定義的預設值。另外可以將正常key與異常key分開存放，同時異常key的過期時間設定的短一點，查詢時先查正常快取，再看異常快取，最後在db，如果db為空塞回異常快取，不為空塞回正常快取
方案二：當資料量不是很大的時候，可以構建乙個快取過濾器，記錄全量資料的key，這樣訪問資料時，可以直接通過判斷這個 key 是否存在，如果不存在直接返回即可，根本無需查快取和 db。快取過濾器可以用bloomfilter
原因
快取不支援 rehash 導致的系統雪崩不可用:
較多快取節點不可用時，大量 cache 訪問會失敗,壓力直接進入db。
快取支援 rehash 導致的快取雪崩不可用:
一致性 hash 分布+rehash 策略在一般情況下可以很好得執行，但在較大的流量洪峰到臨之時，如果大流量 key 比較集中，正好在某 1～2 個快取節點，快取節點就會崩潰下線，然後 key 請求又被 rehash 到其他快取節點，導致其他節點也崩潰，就想癌症擴散了一樣，最終整個快取系統崩潰。
解決方案
方案一：增加多個快取副本，快取異常或請求 miss 後，再讀取其他快取副本，而且多個快取副本盡量部署在不同機架，從而確保在任何情況下，快取系統都會正常對外提供服務。
方案二：通過各種自動故障轉移策略，自動關閉異常介面、停止邊緣服務、停止部分非核心功能措施，確保在極端場景下，核心功能的正常執行。
快取雪崩 穿透和失效問題
1 快取雪崩 redis 集群徹底崩潰後，大量請求直接打到 mysql 上面，導致 mysql 也崩潰繼而導致源服務乃至整個 崩潰 解決方案 事前 發生快取雪崩之前怎麼防止 redis 掛掉 事中 redis 集群已掛 事後 redis 集群重啟時 2 快取穿透 大量請求在穿過快取直接訪問 redi...
快取穿透 快取擊穿 快取雪崩 熱點資料失效
在我們專案中，多少是會使用快取知識的，因為對於很多資料沒必要每次都到資料庫中進行查詢，如果每次都到資料庫中進行查詢，當出現併發情況時，可能會導致資料庫的宕機。比如一些經常查詢但是又不經常修改的資料，我們可以直接將資料存入快取中，以減少資料庫的壓力。當然在實現快取的時候，我們也會遇見很多問題，於是彙總...
快取穿透 快取雪崩
一 快取穿透 描述 快取穿透是指快取和資料庫中都沒有的資料，而使用者不斷發起請求，如發起為id為 1 的資料或id為特別大不存在的資料。這時的使用者很可能是攻擊者，攻擊會導致資料庫壓力過大。解決方案 1 介面層增加校驗，如使用者鑑權校驗，id做基礎校驗，id 0的直接攔截 2 從快取取不到的資料，在...