前言
使用緩存可以緩解大流量壓力，顯著提高程序的性能。我們在使用緩存系統時，尤其是大並發情況下，經常會遇到一些「疑難雜症」。本文總結了一些使用緩存時常見的問題及解決方案，以後在遇到這類問題時可以作為參考，在設計緩存系統的時候也應該考慮這些常見的情況。
為了表述方便，本文以資料庫查詢緩存為例，使用緩存可以減小對資料庫的壓力。
緩存穿透
我們在使用緩存時，往往先嘗試去緩存中取值，如果沒有，再去資料庫取值，如果資料庫也沒有值，則根據業務需求，返回空或者拋異常。
如果用戶一直訪問一個資料庫不存在的數據，比如id為-1的數據，就會導致每次請求都會先去緩存查一次，然後再去資料庫查一次，造成嚴重的性能問題。這種情況就叫緩存穿透。
解決方案
以下幾種解決方案：
- 對請求參數做校驗，比如用戶鑒權校驗，id做基礎校驗，id <= 0的直接攔截。
- 如果查詢到資料庫沒有值，也將對應的key存進緩存中，value為null。這樣下次查詢就直接從緩存返回了。但這裡的key的緩存時間應該比較短，比如30s。防止後面在資料庫插入了這條數據，而用戶獲取不到。
- 使用布隆過濾器，判斷一個key是否已經查過了，如果已經查過了，就不去資料庫查詢。
緩存擊穿
緩存擊穿指的是，一個key的訪問量非常大，比如某秒殺活動，有1w/s的並發量。這個key在某一時刻過期，那這些大量的請求就會一瞬間到資料庫，資料庫可能會直接崩潰。
解決方案
緩存擊穿的解決方案也有幾種，可以配合使用：
- 對於熱點數據，慎重考慮過期時間，確保熱點期間key不會過期，甚至有些可以設置永不過期。
- 使用互斥鎖（比如Java的多線程鎖機制），第一個線程訪問key的時候就鎖住，等查詢資料庫返回後，把值插入到緩存後再釋放鎖，這樣後面的請求就可以直接取緩存裡面的數據了。
緩存雪崩
緩存雪崩指的是，在某一時刻，多個key失效。這樣就會有大量的請求從緩存中獲取不到值，全部到資料庫。還有另一種情況，就是緩存伺服器宕機，也算做緩存雪崩。
解決方案
針對上述兩種情況，緩存雪崩有兩種解決方案：
- 對每個key的過期時間設置一個隨機值，而不是所有key都相同。
- 使用高可用的分布式緩存集群，確保緩存的高可用性，比如redis-cluster。
雙寫不一致
在使用資料庫緩存的時候，讀和寫的流程往往是這樣的：
- 讀取的時候，先讀取緩存，如果緩存中沒有，就直接從資料庫中讀取，然後取出數據後放入緩存
- 更新的時候，先刪除緩存，再更新資料庫
所謂雙寫不一致，就是在發生寫操作（更新）的時候或寫操作之後，可能會存在資料庫裡面的值和緩存中的值不同的情況。
為什麼更新的時候要先刪除緩存，再更新資料庫？因為如果先更新資料庫，然後在刪除緩存的時候失敗了，就會造成緩存裡面的值和資料庫的值不一致。
然而這樣並不能完全避免雙寫不一致問題。假設在大並發情景下，一個線程先刪除緩存，然後取更新資料庫，這個時候另一個線程去取緩存，發現沒有值，於是去讀資料庫，然後把資料庫舊的值設置進緩存。等第一個線程更新完資料庫後，資料庫裡面就是新的值，而緩存裡面是舊的值，所以就存在了數據不一致的問題。
一個比較簡單的解決辦法是把過期時間設置得比較低，這樣就只有在緩存沒過期之前存在數據不一致問題，在一些業務場景下也還能接受。
另一種解決方案是使用隊列輔助。先更新資料庫，再刪除緩存。如果刪除失敗，就放進隊列。然後另一個任務從隊列中取出消息，不斷去重試刪除相應的key。
還有一種解決方案是使用對一個數據使用一個隊列，使讀寫操作串行化。比如對id為n的數據建立一個隊列。對這條數據的寫操作，刪除緩存後，放進一個隊列；然後另一個線程過來了，發現沒有緩存，則把這個讀操作也放進這個隊列裡面。
不過這樣會增加程序的複雜性，串行化也會降低程序的吞吐量，可能得不償失。一般主流的解決方案還是先刪除緩存，再更新資料庫。可以滿足絕大部分需求。