前言

快取（記憶體 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的介面：

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

一個模板：

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

改進後的程式碼：

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

好了，到這裡，關於快取擊穿就討論到這裡。

作者：張豐哲
連結：https://www.jianshu.com/p/93767dac6b56
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。