1、快取雪崩： redis 集群徹底崩潰後，大量請求直接打到 mysql 上面，導致 mysql 也崩潰繼而導致源服務乃至整個**崩潰
解決方案：
事前：發生快取雪崩之前怎麼防止 redis 掛掉
事中：redis 集群已掛
事後：redis 集群重啟時
2、快取穿透：大量請求在穿過快取直接訪問 redis 且每次執行結果都為空，導致各層快取機制失效，當請求到達一定大時就會把 mysql 打死
解決方案：把查詢結果為空的資料也放在 redis 集群 + 快取服務 + nginx 裡面
3、快取失效：大量快取設定了同一過期時間失效，導致大量請求突然穿過快取直接訪問後端服務，大量的網路請求導致網路負載加重或者服務掛掉
解決方案：在 nginx 端給快取設定一定範圍內的隨機過期時間避免大量快取資料在同一時間過期
快取失效，穿透，雪崩
快取可以狹義的理解為是擋在db之前的一層資料塊，效能比db高很多倍。服務系統查資料，首先會查快取，如果快取資料不存在，就進一步查 db，最後查到資料後回種到快取並返回。快取裡的資料儲存基本上都是以 key 為索引進行儲存和獲取的。原因 寫快取時一般都會帶上乙個過期時間，讓快取資料在這個固定的過期時間...
快取失效 穿透和雪崩的處理總結
問題描述 快取第乙個經典問題是快取失效。服務系統查資料 首先會查詢快取，如果快取資料不存在，就進一步查db，最後查到資料後回種到快取並返回。快取的效能比db高50 100倍以上，所以希望資料在查詢的時候盡可能命中快取，這樣系統符合最小，效能最佳。快取裡的資料儲存基本上都是以key為索引進行儲存和獲取...
快取穿透和雪崩
一般的快取系統，都是按照key去快取查詢，如果不存在對應的value，就應該去後端系統查詢 比如db 如果key對應的value是一定不存在的，並且對該key併發請求量很大，就會對後端系統造成很大的壓力。這就叫做快取穿透。1 對查詢結果為空的情況也進行快取，快取時間設定短一點，或者該key對應的資料...