對緩存擊穿的一點思考

前言

緩存（內(nèi)存 or Memcached or Redis.....）在互聯(lián)網(wǎng)項目中廣泛應(yīng)用，本篇博客將討論下緩存擊穿這一個話題，涵蓋緩存擊穿的現(xiàn)象、解決的思路、以及通過代碼抽象方式來處理緩存擊穿。

什么是緩存擊穿？

上面的代碼，是一個典型的寫法：當(dāng)查詢的時候，先從Redis集群中取，如果沒有，那么再從DB中查詢并設(shè)置到Redis集群中。

注意，在實際開發(fā)中，我們一般在緩存中，存儲的數(shù)據(jù)結(jié)構(gòu)是JSON。（JDK提供的序列化方式效率稍微比JSON序列化低一些；而且JDK序列化非常嚴(yán)格，字段的增減，就很可能導(dǎo)致反序列失敗，而JSON這方面兼容性較好）

假設(shè)從DB中查詢需要2S，那么顯然這段時間內(nèi)過來的請求，在上述的代碼下，會全部走DB查詢，相當(dāng)于緩存被直接穿透，這樣的現(xiàn)象就稱之為“緩存擊穿”！

避免緩存擊穿的思路分析

加synchronized？

如果synchronized加在方法上，使得查詢請求都得排隊，本來我們的本意是讓并發(fā)查詢走緩存。也就是現(xiàn)在synchronized的粒度太大了。

縮小synchronized的粒度？

上面代碼，在緩存有數(shù)據(jù)時，讓查詢緩存的請求不必排隊，減小了同步的粒度。但是，仍然沒有解決緩存擊穿的問題。

雖然，多個查詢DB的請求進(jìn)行排隊，但是即便一個DB查詢請求完成并設(shè)置到緩存中，其他查詢DB的請求依然會繼續(xù)查詢DB！

synchronized+雙重檢查機(jī)制

通過synchronized+雙重檢查機(jī)制：

在同步塊中，繼續(xù)判斷檢查，保證不存在，才去查DB。

代碼抽象

發(fā)現(xiàn)沒有，其實我們處理緩存的代碼，除了具體的查詢DB邏輯外，其他都是模板化的。下面我們就來抽象下！

一個查詢DB的接口：

既然查詢具體的DB是由業(yè)務(wù)來決定的，那么暴露這個接口讓業(yè)務(wù)去實現(xiàn)它。

一個模板：

Spring不是有很多Template類么？我們也可以通過這種思想對代碼進(jìn)行一個抽象，讓外界來決定具體的業(yè)務(wù)實現(xiàn)，而把模板步驟寫好。（有點類似AOP的概念）

改進(jìn)后的代碼：

從這里可以看出，我們并不關(guān)心緩存的數(shù)據(jù)從哪里加載，而是交給具體的使用方，而且使用方在使用時再也不必關(guān)注緩存擊穿的問題，因為我們都給抽象了。