快取雪崩

快取雪崩指的是，大量的應用無法在 Redis 快取中處理，然後大量請求傳送到了資料庫，導致資料庫的壓力激增，甚至可能導致資料庫崩潰，從而導致整個系統崩潰，引發雪崩一樣的連鎖效應。

而引起快取雪崩的原因，一般如下：
1、快取中大量 key 同時過期
2、Redis 例項掛掉了，無法處理請求

對於原因 1，在實際應用中應當避免大量 key 同時過期的場景。如果確實有這種業務場景，可以微調這批 key 過期的時間，使其能有一定的相差間隔。

對於原因 2，之前提到的Redis 主從叢集其實可以比較好地實現主 Redis 例項掛掉後，能有其他從庫快速切換為主庫，繼續提供服務。

當然，以上都是預防的措施，如果已經發生了 快取雪崩，為了防止資料庫被大量的請求搞崩潰，可以採用 服務熔斷

服務熔斷就是暫停對業務提供 Redis 服務，直到 Redis 恢復正常，再向外提供服務。 當然，這種情況下，業務也會整個停擺了。 另外一種比較溫和的辦法就是請求限流。請求限流顧名思義，就是限制請求的流量，隨機丟棄一部分的請求，以保證不會同時有太多請求壓入資料庫

快取擊穿

快取穿透指的是，資料既不在 Redis 中，也不在資料庫中。每次請求 Redis 發現沒有對應的 key之後，再去請求資料庫，發現數據庫也沒有。 那麼這時， Redis 就相當於一個擺設，沒有具體的作用了。如果有人惡意攻擊系統，故意使用空值或者其他不存在的值進行頻繁請求，那麼也會對資料庫造成比較大的壓力。

為了避免快取穿透，我們可以：
1、快取空值或預設值

2、採用布隆過濾器，提前判斷是否有此資料。
布隆過濾器實際上就是把 key 通過三次不同的雜湊，計算出三個雜湊值，然後在雜湊表中把對應雜湊值位置置為1。當有新的請求過來時，先判斷這個 key 經過N次雜湊後，對應的雜湊值位置是否為1，只要有一個不為1，就說明此 key 之前沒有快取過。
實際上，布隆過濾器也是有缺陷的，它不能完全保證請求過來的 key ，通過布隆過濾器的校驗，就一定有這個資料。 但是，只要沒有通過布隆過濾器的校驗，那麼這個 key 就一定不存在。 其實這樣就已經可以過濾掉大部分不存在的 key 請求了。
正如以上提到的布隆過濾器缺陷，如果布隆過濾器的雜湊槽過短，很有可能導致大部分的位置都為 1 ，那麼此時，布隆過濾器就失去了它的意義。 所以，當我們發現布隆過濾器大部分位置都為1了，應該要擴寬雜湊槽。

3、在實際業務中，我們對於請求的引數應該要先進行校驗，請求的引數應該要在規定範圍內。實際上，在工程應用中，主要也是依賴於引數的校驗，過濾掉很多無效請求。

資料不一致性

當使用 Redis 作為資料庫快取時，可能會存在資料不一致的問題。
當需要修改一份資料時，需要同時修改資料庫和快取，那麼這裡就要區分：先修改資料庫還是修改快取；對於快取，是直接修改資料還是刪除資料？