一、引入緩存后給業務帶來的問題

業務系統引入緩存之后，架構由原來的兩層架構變成了三層架構：

圖片

由此，帶來了三個問題需要解決，分別是緩存讀取、緩存更新和緩存淘汰。

1.緩存讀取

緩存讀取比較簡單，查詢數據時首先查詢緩存，如果緩存命中，則從緩存中讀取數據。如果緩存不命中，則查詢數據庫，并且更新緩存。

2.緩存更新

緩存更新時，在更新存儲和更新緩存的先后關系上，有以下幾種策略：

1）先更新數據庫再更新緩存

首先，這種方案會有線程安全的問題：

例如，同時有線程A和線程B對數據進行更新操作，可能會出現下面的執行順序。

①線程A更新了數據庫

②線程B更新了數據庫

③線程B更新了緩存

④線程A更新了緩存

此時就會出現數據庫中的數據與緩存的數據不一致的情況，這是因為線程A先更新了數據庫，可能因為網絡等異常情況，線程B更新完數據庫進而更新了緩存，當線程B更新完緩存后，線程A才更新緩存，這就導致了數據庫數據與緩存數據的不一致。

其次，這種方案也有其不適用的業務場景：

首先一個業務場景就是數據庫寫多讀少的場景，這種場景下采用先更新數據庫再更新緩存的策略，就會導致緩存并未被讀取就會被頻繁的更新，極大的浪費了服務器的性能。

再一個業務場景就是數據庫中的數據不是直接寫入緩存的，而是需要大量的復雜運算，將運算結果寫入緩存。如果這種場景下使用先更新數據庫再更新緩存的策略，也會造成服務器資源的浪費。

2）先刪除緩存，再更新數據庫

先刪除緩存再更新數據庫的方案也存在著線程安全的問題，例如，線程A更新緩存，同時，線程B讀取緩存的數據。可能會出現下面的執行順序：

①線程A刪除緩存

②線程B查詢緩存，發現緩存中沒有想要的數據

③線程B查詢數據庫中的舊數據

④線程B將查詢到的舊數據寫入緩存

⑤線程A將新數據寫入數據庫

此時，就出現了數據庫中的數據和緩存中的數據不一致的情況。如果刪除緩存失敗，也會出現數據庫數據和緩存數據不一致的現象。

3）先更新數據庫，再刪除緩存

首先，這種方式也有極小的概率發生數據庫數據和緩存數據不一致的情況，例如，線程A做查詢操作，線程B執行更新操作，其執行的順序如下所示：

①緩存剛好失效

②請求A查詢數據庫，獲取到數據庫中的舊值

③請求B將新值寫入數據庫

④請求B刪除緩存

⑤請求A將查到的舊值寫入緩存

如果上述順序一旦發生，就會造成數據庫中的數據和緩存中的數據不一致的情況發生。但是，先更新數據庫再刪除緩存的策略發生數據庫和緩存數據不一致的概率很低，原因就是：③的寫數據庫操作比步驟②的讀數據庫操作耗時更短，才有可能使得步驟④先于步驟⑤執行。

但是，往往數據庫的讀操作的速度遠快于寫操作，因此步驟③耗時比步驟②更短這一場景很難出現。因此，先更新數據庫，再刪除緩存是一種值得推薦的做法。

4）異常情況

上面的討論與對比都是在刪除緩存和更新數據庫這兩步操作都成功的情況下敘述的。當然系統正常運行時的操作基本上都是成功的，那么如果兩步操作有其中一步操作失敗了呢？以先更新數據庫再刪除緩存舉例：

• 更新數據庫失敗：這種情況很簡單，不會影響第二步操作，也不會影響數據一致性，直接拋異常出去就好了；
• 更新緩存失敗：這種情況需要繼續嘗試刪除緩存，直到緩存刪除成功，可以用一個消息隊列完成，如下圖所示：

圖片

①更新數據庫數據;

②刪除緩存數據失敗；

③將需要刪除的key發送至消息隊列；

④自己消費消息，獲得需要刪除的key；

⑤繼續重試刪除操作，直到成功。

3.緩存淘汰

主要有兩種策略，分別是主動淘汰和被動淘汰：

• 主動淘汰：給鍵值對設置TTL時間，到期自動淘汰（推薦），這種方式可以達到緩存熱數據的目的；
• 被動淘汰：內存達到最大限制時，通過LRU、LFU算法淘汰（不推薦），這種方式影響緩存性能，緩存質量不可控。

二、緩存的三座大山

1.一致性

一致性主要解決以下幾個問題：

1）并行更新如何解決隔離性問題

• 串行更新：單個Key更新序列需要串行更新，保證時序
• 并行更新：不同的key可以放到不同的Slot中，在Slot維度可以進行并行更新，提升性能

2）原子性更新時如何解決部分更新的問題

• 系統聯動：緩存&存儲實時同步更新狀態，通過revision同步狀態
• 部分成功：緩存更新成功，存儲更新失敗，觸發HA，保障寫入成功（日志冪等）

3）如何解決讀一致的問題

• revision：每個Key都帶有一個revision，通過revision識別數據新舊
• 淘汰控制：Redis不淘汰存儲未更新的數據(Redis不淘汰revision < 4的數據)，保證Redis不緩存舊版本數據

2.緩存擊穿

緩存擊穿指的是訪問數據時直接繞過緩存，訪問數據庫。可能會有兩種原因造成這種現象：

圖片

一種是大量的空查詢，比如黑客攻擊；另外一種是緩存污染，比如大量的網絡爬蟲造成的。

1）為了解決空查詢帶來的緩存擊穿，主要有兩種方案：

第一種是在緩存層前面再加一層布隆過濾器，布隆過濾器是一種數據結構，比較巧妙的概率型數據結構（probabilistic data structure），特點是高效地插入和查詢，可以用來告訴你 “某樣東西一定不存在或者可能存在”。布隆過濾器是一個 bit 向量或者說 bit 數組，長這樣：

圖片

如果我們要映射一個值到布隆過濾器中，我們需要使用多個不同的哈希函數生成多個哈希值，并對每個生成的哈希值指向的 bit 位置 1，例如針對值 “baidu” 和三個不同的哈希函數分別生成了哈希值 1、4、7，則上圖轉變為：

圖片

我們現在再存一個值 “tencent”，如果哈希函數返回 3、4、8 的話，圖繼續變為：

圖片

值得注意的是，4 這個 bit 位由于兩個值的哈希函數都返回了這個 bit 位，因此它被覆蓋了。現在我們如果想查詢 “dianping” 這個值是否存在，哈希函數返回了 1、5、8三個值，結果我們發現 5 這個 bit 位上的值為 0，說明沒有任何一個值映射到這個 bit 位上，因此我們可以很確定地說 “dianping” 這個值不存在。

而當我們需要查詢 “baidu” 這個值是否存在的話，那么哈希函數必然會返回 1、4、7，然后我們檢查發現這三個 bit 位上的值均為 1，那么我們可以說 “baidu” 存在了么？答案是不可以，只能是 “baidu” 這個值可能存在。

這是為什么呢？答案很簡單，因為隨著增加的值越來越多，被置為 1 的 bit 位也會越來越多，這樣某個值 “taobao” 即使沒有被存儲過，但是萬一哈希函數返回的三個 bit 位都被其他值置位了 1 ，那么程序還是會判斷 “taobao” 這個值存在。

很顯然，過小的布隆過濾器很快所有的 bit 位均為 1，那么查詢任何值都會返回“可能存在”，起不到過濾的目的了。布隆過濾器的長度會直接影響誤報率，布隆過濾器越長其誤報率越小。另外，哈希函數的個數也需要權衡，個數越多則布隆過濾器 bit 位置位 1 的速度越快，且布隆過濾器的效率越低；但是如果太少的話，那我們的誤報率會變高。

第二種是把所有的key和熱數據value加入緩存，在緩存層攔截空數據查詢。

圖片

2）為了解決爬蟲帶來的緩存擊穿問題，可以設置緩存策略：

• 針對更新的操作，需要立即緩存
• 針對讀的操作，可以在設置是否立即緩沖還是延遲緩存，以及在規定的時間窗內命中的次數是否達到一定的次數才進行緩存

3.緩存雪崩

緩存雪崩指的是熱數據集中淘汰，大量請求瞬間透傳到存儲層，導致存儲層過載。

圖片

造成緩存雪崩的原因主要是TTL機制過于簡單造成的，解決方案主要有以下：

• 設置TTL時給過期時間加上一個隨機的時間值
• 每一次的訪問都會重新更新TTL，此外業務可以更精準地指定熱數據緩存時間