設計一個緩存系統，不得不要考慮的問題就是：緩存穿透、緩存擊穿與失效時的雪崩效應。
這裏不涉及一級緩存還是二級緩存，主要是講述使用緩存的時候可能會遇到的一些問題以及一些解決辦法
我們使用緩存的時候流程一般是這樣：
當我們查詢一條數據時，先去查詢緩存，如果緩存有就直接返回，如果沒有就去查詢數據庫，然後返回並緩存。
這種情況下就可能會出現一些現象。
緩存穿透
正常情況下，我們去查詢數據都是存在。
那麼請求查詢一條壓根兒數據庫中根本就不存在的數據，也就是緩存和數據庫都查詢不到這條數據，但是請求每次都會打到數據庫上面去。 這種查詢不存在數據的現象我們稱爲緩存穿透。在流量大時，DB壓力很大，要是有人利用不存在的key頻繁攻擊我們的應用，這就是漏洞。
解決方案
緩存空值
之所以會發生穿透，就是因爲緩存中沒有存儲這些空數據的key。從而導致每次查詢都到數據庫去了。那麼我們就可以爲這些key對應的值設置爲null 丟到緩存裏面去。後面再出現查詢這個key 的請求的時候，直接返回null 。這樣就不用在到數據庫中去走一圈了，但是別忘了設置過期時間
BloomFilter布隆過濾器
BloomFilter 類似於一個hbase set 用來判斷某個元素（key）是否存在於某個集合中。這種方式在大數據場景應用比較多，比如 Hbase 中使用它去判斷數據是否在磁盤上。還有在爬蟲場景判斷url是否已經被爬取過。這種方案可以加在上面方案中，在緩存之前在加一層 BloomFilter，在查詢的時候先去 BloomFilter 去查詢 key 是否存在，如果不存在就直接返回，存在再走查緩存 -> 查 DB。
如何選擇
針對於一些惡意攻擊，攻擊帶過來的大量key 是不存在的，那麼我們採用第一種方案就會緩存大量不存在key的數據。此時我們採用第一種方案就不合適了，我們完全可以先對使用第二種方案進行過濾掉這些key。
針對這種key異常多、請求重複率比較低的數據，我們就沒有必要進行緩存，使用第二種方案直接過濾掉。
對於空數據的key有限的，重複率比較高的，我們則可以採用第一種方式進行緩存。
緩存擊穿
緩存擊穿是我們可能遇到布隆過濾器緩存方案可能遇到的問題。
在平常高併發的系統中，大量的請求同時查詢一個 key 時，此時這個key正好失效了，就會導致大量的請求都打到數據庫上面去。這種現象我們稱爲緩存擊穿。
解決方案
上面的現象是多個線程同時去查詢數據庫的這條數據，那麼我們可以在第一個查詢數據的請求上使用一個 互斥鎖來鎖住它。其他的線程走到這一步拿不到鎖就等着(自旋)，等第一個線程查詢到了數據，然後做緩存。後面的線程進來發現已經有緩存了，就直接走緩存。
緩存雪崩
緩存雪崩的情況是說，當某一時刻發生大規模的緩存失效的情況，比如你的緩存服務宕機了，會有大量的請求進來直接打到DB上面。結果就是DB 稱不住，掛掉。
解決方案
方案轉自喬二爺
針對緩存服務器宕機的情況分三步
- 事前-使用集羣緩存，保證緩存服務的高可用
這種方案就是在發生雪崩前對緩存集羣實現高可用，如果是使用 Redis，可以使用 主從+哨兵 ，Redis Cluster 來避免 Redis 全盤崩潰的情況。 - 事中-ehcache本地緩存 + Hystrix限流&降級,避免MySQL被打死
使用 ehcache 本地緩存的目的也是考慮在 Redis Cluster 完全不可用的時候，ehcache 本地緩存還能夠支撐一陣。可以不用。
使用 Hystrix進行限流 & 降級 ，比如一秒來了5000個請求，我們可以設置假設只能有一秒 2000個請求能通過這個組件，那麼其他剩餘的 3000 請求就會走限流邏輯。然後去調用我們自己開發的降級組件（降級），比如設置的一些默認值呀之類的。以此來保護最後的 MySQL 不會被大量的請求給打死。 - 事後開啓Redis持久化機制，儘快恢復緩存集羣(AOF、RDB)
解決熱點數據集中失效問題-也屬於雪崩
我們設置緩存時採用了相同的過期時間，導致緩存在某一時刻同時失效，請求全部轉發到DB，DB瞬時壓力過重雪崩。
解決方案
爲了避免這些熱點的數據集中失效，那麼我們在設置緩存過期時間的時候，我們讓他們失效的時間錯開。比如在一個基礎的時間上加上或者減去一個範圍內的隨機值
結合上面的擊穿的情況，在第一個請求去查詢數據庫的時候對他加一個互斥鎖，其餘的查詢請求都會被阻塞住，直到鎖被釋放，從而保護數據庫。但是也是由於它會阻塞其他的線程，此時系統吞吐量會下降。需要結合實際的業務去考慮是否要這麼做
到鎖被釋放，從而保護數據庫。但是也是由於它會阻塞其他的線程，此時系統吞吐量會下降。需要結合實際的業務去考慮是否要這麼做**