其實(shí)，這個場景幾乎每個程序員都會接觸到，但是還是有很多程序員對這種思路沒有好的辦法，下面我再整理下之前收集到的資料，重新發(fā)下。由于該文章轉(zhuǎn)載很多，找不到準(zhǔn)確出處。如有侵權(quán)，請聯(lián)系我。

當(dāng)緩存失效時，容易出現(xiàn)高并發(fā)的查詢DB，導(dǎo)致DB壓力驟然上升，這種現(xiàn)象我們稱之為緩存穿透。

這篇blog主要是探討如何在緩存將要失效時，及時地更新緩存，而不是如何在緩存失效之后，如何防止高并發(fā)的DB查詢

個人認(rèn)為，當(dāng)緩存將要失效時，及時地把新的數(shù)據(jù)刷到緩存里，這個是解決緩存失效瞬間高并發(fā)查DB的最好方法。 那么如何及時地知道緩存將要失效？

解決這個問題有幾種思路：

比如一個key是testKey，失效時間是30s

1.定期從DB里查詢數(shù)據(jù)，再刷到緩存里

缺點(diǎn)：有些業(yè)務(wù)的key可能是變化的，不確定的。而且不好界定哪些數(shù)據(jù)是應(yīng)該查詢出來放到緩存中的，難以區(qū)分冷熱數(shù)據(jù)

2.當(dāng)緩存取到為null時，加鎖去查詢DB，只允許一個線程去查詢DB

缺點(diǎn)：這種方式不太靠譜，不多討論。 而且如果是多個web服務(wù)器的話，還是有可能有并發(fā)的操作

3.在向緩存寫入value時，同時寫入當(dāng)前機(jī)器在時間作為過期時間

當(dāng)get得到數(shù)據(jù)時，如果當(dāng)前時間 – 過期時間 > 5s，則后臺啟動一個任務(wù)去查詢DB，更新緩存

當(dāng)然，這里的后臺任務(wù)必須保證同一個key，只有一個線程在執(zhí)行查詢DB的任務(wù)，不然這個還是高并發(fā)查詢DB

缺點(diǎn)：是要把過期時間和value合在一起序列化，取出數(shù)據(jù)后，還要反序列化。 很不方便

網(wǎng)上大部分文章提到的全都是前面兩種方式，有少數(shù)文章提到第3種方式。 下面提出一種基于兩個key的方法：

4.兩個key，一個key用來存放數(shù)據(jù)，另一個用來標(biāo)記失效時間

比如key是testKey，設(shè)置失效時間為30s，則另一個key為expire_testKey，失效時間為25s。用multiget，同時取出testKey和expire_testKey，如果expire_testKey的為null，則后臺啟動一個任務(wù)加鎖去查詢DB，更新緩存。集群式的部署的，如何實(shí)現(xiàn)只允許一個任務(wù)執(zhí)行，用到memcached的add命令,或redis的setnx命令。設(shè)置expire_testKey超時過間為3s，防止后臺任務(wù)失敗或者阻塞。

缺點(diǎn)：內(nèi)存翻倍，而且程序上要維護(hù)2個key。

5.兩個key,時間存到value里，結(jié)合add/setnx來保證原子性更新緩存

最近重新思考了下這個問題。 發(fā)現(xiàn)第4種兩個key的辦法比較耗memcached的內(nèi)存，因?yàn)閗ey數(shù)翻倍了。 結(jié)合第3種方式，重新設(shè)計(jì)了下，思路如下。

仍然使用2個key方案，但是expire_testKey相當(dāng)于鎖。只允許add/setnx成功的線程去更新數(shù)據(jù)。更新成功后把expire_testKey進(jìn)行刪除。由于這個expire_testKey存在時間較短，不會占用太多緩存內(nèi)存。

優(yōu)點(diǎn)：節(jié)省內(nèi)存，數(shù)據(jù)是自然冷熱適應(yīng)的，不用擔(dān)心集群帶來并發(fā)風(fēng)險

總結(jié)：

我個人是傾向于第5種方式的，因?yàn)楹芎唵危庇^。 比第4種方式要節(jié)省內(nèi)存，而且不用mget，在使用memcached集群時不用擔(dān)心出麻煩事

這種兩個key的方式，還有一個好處，就是數(shù)據(jù)是自然冷熱適應(yīng)的。 如果是冷數(shù)據(jù)，30秒都沒有人訪問，那么數(shù)據(jù)會過期

如果是熱門數(shù)據(jù)，一直有大流量訪問，那么數(shù)據(jù)就是一直熱的，而且數(shù)據(jù)一直不會過期