作者：張豐哲 來(lái)源：www.jianshu.com/p/93767dac6b56
前言
緩存（內(nèi)存 or Memcached or redis.....）在互聯(lián)網(wǎng)項(xiàng)目中廣泛應(yīng)用，本篇博客將討論下緩存擊穿這一個(gè)話題，涵蓋緩存擊穿的現(xiàn)象、解決的思路、以及通過(guò)代碼抽象方式來(lái)處理緩存擊穿。
什么是緩存擊穿？
上面的代碼，是一個(gè)典型的寫(xiě)法：當(dāng)查詢的時(shí)候，先從Redis集群中取，如果沒(méi)有，那么再?gòu)腄B中查詢并設(shè)置到Redis集群中。
注意，在實(shí)際開(kāi)發(fā)中，我們一般在緩存中，存儲(chǔ)的數(shù)據(jù)結(jié)構(gòu)是JSON。（JDK提供的序列化方式效率稍微比JSON序列化低一些；而且JDK序列化非常嚴(yán)格，字段的增減，就很可能導(dǎo)致反序列失敗，而JSON這方面兼容性較好）
假設(shè)從DB中查詢需要2S，那么顯然這段時(shí)間內(nèi)過(guò)來(lái)的請(qǐng)求，在上述的代碼下，會(huì)全部走DB查詢，相當(dāng)于緩存被直接穿透，這樣的現(xiàn)象就稱之為“緩存擊穿”！
避免緩存擊穿的思路分析
加synchronized？
如果synchronized加在方法上，使得查詢請(qǐng)求都得排隊(duì)，本來(lái)我們的本意是讓并發(fā)查詢走緩存。也就是現(xiàn)在synchronized的粒度太大了。
縮小synchronized的粒度？
上面代碼，在緩存有數(shù)據(jù)時(shí)，讓查詢緩存的請(qǐng)求不必排隊(duì)，減小了同步的粒度。但是，仍然沒(méi)有解決緩存擊穿的問(wèn)題。
雖然，多個(gè)查詢DB的請(qǐng)求進(jìn)行排隊(duì)，但是即便一個(gè)DB查詢請(qǐng)求完成并設(shè)置到緩存中，其他查詢DB的請(qǐng)求依然會(huì)繼續(xù)查詢DB！
synchronized+雙重檢查機(jī)制
通過(guò)synchronized+雙重檢查機(jī)制：
在同步塊中，繼續(xù)判斷檢查，保證不存在，才去查DB。
代碼抽象
發(fā)現(xiàn)沒(méi)有，其實(shí)我們處理緩存的代碼，除了具體的查詢DB邏輯外，其他都是模板化的。下面我們就來(lái)抽象下！
一個(gè)查詢DB的接口：
既然查詢具體的DB是由業(yè)務(wù)來(lái)決定的，那么暴露這個(gè)接口讓業(yè)務(wù)去實(shí)現(xiàn)它。
一個(gè)模板：
Spring不是有很多Template類么？我們也可以通過(guò)這種思想對(duì)代碼進(jìn)行一個(gè)抽象，讓外界來(lái)決定具體的業(yè)務(wù)實(shí)現(xiàn)，而把模板步驟寫(xiě)好。（有點(diǎn)類似AOP的概念）
改進(jìn)后的代碼：
從這里可以看出，我們并不關(guān)心緩存的數(shù)據(jù)從哪里加載，而是交給具體的使用方，而且使用方在使用時(shí)再也不必關(guān)注緩存擊穿的問(wèn)題，因?yàn)槲覀兌冀o抽象了。
好了，到這里，關(guān)于緩存擊穿就討論到這里。
