本篇文章帶大家簡單了解一下redis中的緩存穿透、緩存雪崩、緩存擊穿和緩存一致性，介紹一下緩存穿透和緩存雪崩的解決方案，希望對大家有所幫助！

緩存雪崩

緩存同一時間大面積失效，后面的請求都會落到數據庫上，造成數據庫短時間內無法承受大量請求而崩潰

例如在電商首頁，所有首頁的key失效時間都是12小時，中午12點刷新，如果零點有個秒殺活動大量用戶涌入，但是緩存當時所有key都失效，此時所有的請求會落到數據庫，數據庫扛不住，就直接就gg了，又或者redis宕機，也會讓大量請求落到mysql，造成掛機。【相關推薦：Redis視頻教程】

解決方案

• 所以像這種情況就應該把每個key的失效時間加個隨機值，避免同一時間大量的key失效，如果是redis集群部署，可以將熱點數據分布到各個不同的庫。

• 事前：盡量保證redis集群的高可用性，發現機器宕機盡快補上，選擇合適的內存淘汰策略

• 事中：本地ehcache緩存+hystrix限流加降級，避免mysql崩掉

• 事后：里有redis持久化機制保存的數據盡快恢復緩存。

緩存穿透

大量請求的key不存在于緩存中，例如某個黑客制造緩存中不存在的key發起大量請求，導致大量請求落到數據庫。

解決辦法

• 首先應該要做基本的入參校驗，將不合法的參數直接攔截，例如查詢數據庫id不能小于0，校驗郵箱格式等等

• 如果緩存和數據庫都查不到某個key的數據，就將key寫入到redis，value為NULL，并設置過期時間，避免下次請求落到數據庫上。

• 通過布隆過濾器，布隆過濾器可以非常方便的判定一個給定的數據是否存在與海量數據中.可以將所有可能存在的請求的值存到布隆過濾器，當請求過來先判斷用戶發來的請求是否存在于布隆過濾器，不存在就直接攔截。

緩存擊穿

緩存擊穿指的是一個Key非常熱點，在不停的扛著大并發，大并發集中對這一個點進行訪問，當這個key失效瞬間，持續的大并發就穿破緩存，直接請求到數據庫

緩存一致性

如果是要求強一致性，那就不能使用緩存，因為保證不了強一致性，只能保證最終一致性。

• 先刪除緩存，再更新數據庫

如果數據庫更新失敗，那么數據庫的還是舊數據，redis是空，數據不會不一致，讀到空會去數據庫進行查詢，然后更新到緩存。

• 加入隊列，進行串行化操作

先刪除緩存，再更新數據庫，在高并發場景下也會出現問題，例如刪除了緩存，這時還沒更新數據庫，另一個線程進來，發現redis是空，會去讀數據庫，然后更新到redis,而此時刪除了緩存的線程接著更新數據庫，就會造成數據庫和redis數據不一致，這時候可以將更新數據的操作放到隊列當中，串行化操作，不會出現，但一般不建議這樣做，因為會降低效率。

更多編程相關知識，請訪問：Redis視頻教程！！