對緩存擊穿的一點思考

前言

緩存（內存 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的概念）

改進後的代碼：

從這裏能夠看出，咱們並不關心緩存的數據從哪裏加載，而是交給具體的使用方，並且使用方在使用時不再必關注緩存擊穿的問題，由於咱們都給抽象了。