目錄
讀緩存時可能遇到的問題
老生常談的話題了，我這裏寫不是爲了別的，也沒有什麼獨特的見解（也許以後會有），我只是想總結下，整理下這部分的實踐點，知識點，便於以後遇到此類問題，有個方便查看的解決方案。所以該文章會詳細，全面的分析三讀緩存的問題，並在下篇文章會詳細分析寫緩存的問題。
一、緩存穿透：
1、問題出現場景
什麼情況下會出現緩存穿透呢？其實很多文章都會先說一下，嗯不例外我也會描述。哈哈哈！！！
緩存穿透是指查詢一個一定不存在的數據，因爲在緩存中也無該數據的信息，則系統會跳過緩存直接訪問數據庫，而對於高併發，高吞吐量的系統來說，無疑緩存失效了，同時對數據庫上了一個高負載的debuff，顯而易見的是數據庫的讀效率是比不過緩存的，那麼很有可能造成數據庫崩潰從而影響系統發生故障。當然，一般情況下，數據庫的架構一般會搭建HA數據庫，怕的就是惡意攻擊。
2、解決方案
①、布隆過濾器(Bloom Filter)
②、空值緩存
3、解決方案詳細實踐
①、BloomFilter
②、空值緩存：
一種比較簡單的解決辦法，在第一次查詢完不存在的數據後，將該key與對應的空值也放入緩存中，只不過設定爲較短的失效時間，例如幾分鐘，這樣則可以應對短時間的大量的該key攻擊，設置爲較短的失效時間是因爲該值可能業務無關，存在意義不大，且該次的查詢也未必是攻擊者發起，無過久存儲的必要，故可以早點失效。
二、緩存雪崩：
1、問題出現場景
在普通的緩存系統中一般例如redis、memcache等中，我們會給緩存設置一個失效時間，但是如果所有的緩存的失效時間相同，那麼在同一時間失效時，所有系統的請求都會發送到數據庫層，數據庫可能無法承受如此大的壓力導致系統崩潰。
2、解決方案
三、緩存擊穿：
1、問題出現場景
緩存擊穿實際上是緩存雪崩的一個特例，大家使用過微博的應該都知道，微博有一個熱門話題的功能，用戶對於熱門話題的搜索量往往在一些時刻會大大的高於其他話題，這種我們成爲系統的“熱點“，由於系統中對這些熱點的數據緩存也存在失效時間，在熱點的緩存到達失效時間時，此時可能依然會有大量的請求到達系統，沒有了緩存層的保護，這些請求同樣的會到達數據庫從而可能引起故障。擊穿與雪崩的區別即在於擊穿是對於特定的熱點數據來說，而雪崩是全部數據。