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

當緩存失效時，容易出現高并發的查詢DB，導致DB壓力驟然上升，這種現象我們稱之為緩存穿透。

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

個人認為，當緩存將要失效時，及時地把新的數據刷到緩存里，這個是解決緩存失效瞬間高并發查DB的最好方法。 那么如何及時地知道緩存將要失效？

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

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

1.定期從DB里查詢數據，再刷到緩存里

缺點：有些業務的key可能是變化的，不確定的。而且不好界定哪些數據是應該查詢出來放到緩存中的，難以區分冷熱數據

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

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

3.在向緩存寫入value時，同時寫入當前機器在時間作為過期時間

當get得到數據時，如果當前時間 – 過期時間 > 5s，則后臺啟動一個任務去查詢DB，更新緩存

當然，這里的后臺任務必須保證同一個key，只有一個線程在執行查詢DB的任務，不然這個還是高并發查詢DB

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

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

4.兩個key，一個key用來存放數據，另一個用來標記失效時間

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

缺點：內存翻倍，而且程序上要維護2個key。

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

最近重新思考了下這個問題。 發現第4種兩個key的辦法比較耗memcached的內存，因為key數翻倍了。 結合第3種方式，重新設計了下，思路如下。

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

優點：節省內存，數據是自然冷熱適應的，不用擔心集群帶來并發風險

總結：

我個人是傾向于第5種方式的，因為很簡單，直觀。 比第4種方式要節省內存，而且不用mget，在使用memcached集群時不用擔心出麻煩事

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

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