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

當快取失效時，容易出現高併發的查詢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秒都沒有人訪問，那麼資料會過期

如果是熱門資料，一直有大流量訪問，那麼資料就是一直熱的，而且資料一直不會過期