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

標籤：

 

網上有一些關於緩衝穿透和緩衝雪崩的解決方案，無非是：

      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

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