網上有一些關於緩存穿透和緩存雪崩的解決方案，無非是：
1.如果查詢數據為null，則把null進行緩存
2.使用布隆過濾器
先來說說緩存穿透的概念：我們在項目中使用緩存通常都是APP先檢查緩存中是否存在，如果存在直接返回緩存內容，如果不存在就直接查詢數據庫然后再緩存查詢結果返回。這個時候如果我們查詢的某一個數據在緩存中一直不存在，就會造成每一次請求都查詢DB，這樣緩存就失去了意義，在流量大時，可能DB就掛掉了。
再來講講我們的業務場景：
1.通常我們是首頁，或是統計頁，用戶請求較多，首頁進入系統必定會加載，統計頁（針對一些准實時的統計結果）查詢的SQL或是結果比較復雜。
2.時效性一般，基本上小時級別
3.數據量較大，一般是億級或是千萬級別
4.業務邏輯比較復雜，可能需要進行各種表的關聯
5.如果請求過多，有可能數據庫奔潰，即使在進行分庫分表之后還是有可能占用一大部分的數據庫IO和CPU資源
6.統計的維度較多，每個用戶請求的維度可能是不一樣的。
針對上述情況我們一般的做法，就是加一層緩存，請求過來先去訪問緩存，可以使用memcached或是redis，如果緩存不存在或是緩存失效的情況下，再去load DB。大部分的情況下，這是非常好的，但是某一天如果你需要重啟緩存，或是緩存在某一時刻失效很大一部分，這就會導致我們之前所說的緩存穿透。
ok，來說下我們在緩存穿透的優化吧：先來看個架構圖，在來解釋
1.更具業務統計的維度或是場景，建立一張以JSON格式為模板的表
2.通過調度平台，定時的把任務統計完成並保存至模板表中和緩存集群中
3.不斷對2進行輪詢，保持數據的熱度
4.用戶請求過來，先訪問我們的緩存，一旦緩存失效或是重啟，直接從數據庫模板表中獲取最新的熱度數據並緩存，這樣我們就能有效的減輕數據庫的壓力。
5.這也是一種緩存預熱的方案
技術交流：534368042