擺事實講道理,什麼是快取擊穿?

JAVA架構發表於2019-01-08

前言

快取(記憶體 or Memcached or Redis.....)在網際網路專案中廣泛應用,本篇部落格將討論下快取擊穿這一個話題,涵蓋快取擊穿的現象、解決的思路、以及通過程式碼抽象方式來處理快取擊穿。


什麼是快取擊穿?

擺事實講道理,什麼是快取擊穿?
快取擊穿

上面的程式碼,是一個典型的寫法:當查詢的時候,先從Redis叢集中取,如果沒有,那麼再從DB中查詢並設定到Redis叢集中。

注意,在實際開發中,我們一般在快取中,儲存的資料結構是JSON。(JDK提供的序列化方式效率稍微比JSON序列化低一些;而且JDK序列化非常嚴格,欄位的增減,就很可能導致反序列失敗,而JSON這方面相容性較好)

假設從DB中查詢需要2S,那麼顯然這段時間內過來的請求,在上述的程式碼下,會全部走DB查詢,相當於快取被直接穿透,這樣的現象就稱之為“快取擊穿”!


避免快取擊穿的思路分析

加synchronized?

擺事實講道理,什麼是快取擊穿?
同步方式

如果synchronized加在方法上,使得查詢請求都得排隊,本來我們的本意是讓併發查詢走快取。也就是現在synchronized的粒度太大了。

縮小synchronized的粒度?

擺事實講道理,什麼是快取擊穿?
縮小粒度

上面程式碼,在快取有資料時,讓查詢快取的請求不必排隊,減小了同步的粒度。但是,仍然沒有解決快取擊穿的問題。

雖然,多個查詢DB的請求進行排隊,但是即便一個DB查詢請求完成並設定到快取中,其他查詢DB的請求依然會繼續查詢DB!

synchronized+雙重檢查機制

擺事實講道理,什麼是快取擊穿?
雙重檢查

通過synchronized+雙重檢查機制:

在同步塊中,繼續判斷檢查,保證不存在,才去查DB。


程式碼抽象

發現沒有,其實我們處理快取的程式碼,除了具體的查詢DB邏輯外,其他都是模板化的。下面我們就來抽象下!

一個查詢DB的介面:

擺事實講道理,什麼是快取擊穿?
CacheLoader

既然查詢具體的DB是由業務來決定的,那麼暴露這個介面讓業務去實現它。

一個模板:

擺事實講道理,什麼是快取擊穿?
Template

Spring不是有很多Template類麼?我們也可以通過這種思想對程式碼進行一個抽象,讓外界來決定具體的業務實現,而把模板步驟寫好。(有點類似AOP的概念)

改進後的程式碼:

擺事實講道理,什麼是快取擊穿?
改進後的呼叫程式碼

從這裡可以看出,我們並不關心快取的資料從哪裡載入,而是交給具體的使用方,而且使用方在使用時再也不必關注快取擊穿的問題,因為我們都給抽象了。



相關文章