網上有一些關於緩存穿透和緩存雪崩的解決方案,無非是:
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