業務層面緩存穿透的解決方案


 

網上有一些關於緩存穿透和緩存雪崩的解決方案,無非是:

      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


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM