[[346368]]

本文轉載自微信公眾號「IT界農民工」，作者萊烏。轉載本文請聯系IT界農民工公眾號。  

日常生產場景中，為了避免大量請求同時打在數據庫上導致故障，數據庫+緩存的方式已經成了日常標配。

對于讀取的部分，大家都很熟悉。但是對于寫的部分，到底是先寫庫還是先寫緩存，這點可能困擾著很多人。

各位看官請跟隨小萊往下看：

 

- 思維導圖 -

旁路緩存策略

提到這個有逼格的名詞你可能不是很熟悉，但是說到它的使用方式，你肯定用過。

這是一種最經典的緩存+數據庫讀寫的模式，英文是這樣 Cache Aside Pattern，可能你見過。

這種模式對應的使用方式有兩種情況，一讀一寫：

• 基本讀取方式;
• 先更新數據庫，后刪除緩存。

1、基本讀取方式

這部分相信大家已經輕車熟路：先讀緩存，緩存中沒有數據的話就去數據庫讀取，然后再存入緩存中，同時返回響應。

這沒什么可說的，平時都這么用。如果還不清楚，看下小萊為大家畫的圖：

 

那我們再看寫的部分。

2、先更新數據庫，后刪除緩存

你可能會問了，為什么不在更新完數據庫后，采取更新緩存的方案，而是將其刪除。原因有這么幾點：

• 頻繁更新浪費資源

你想想，如果修改庫中的某個字段，一段時間內頻繁進行更新。那么你修改多少次，緩存也跟著更新多少次。但是這個緩存數據在這段時間內也就被偶爾使用了幾次。

那么你看，是不是就會導致資源浪費了。

• 緩存數據計算復雜

還有一種情況，如果這個緩存的數據計算成本比較高。比如為了一個數據，要通過多張表來計算才能得到結果。那么每修改一次，為了更新緩存還要再查詢多張表來算一次，我的天。

• 兩種情況都具備

這種情況最為致命，不但修改頻繁，同時緩存數據還要經過復雜計算。

生產環境里要是這么搞的話，那估計你就可以準備簡歷了。

既然更新緩存的方式不可行，那么我們換個思路，刪除掉呢?

還是按照上邊的步驟，先更新數據庫，只是我們把更新緩存的操作換成了刪除。

在這種情況下，讀請求過來的時候，發現 Redis 中沒有數據，就會去數據庫里讀取，然后寫入緩存中。

這也是一種懶加載方式，只有緩存被需要的時候才會去計算。這樣可以避免大量計算及頻繁更新。

但是，這樣會有什么隱患的問題?是不是看著沒什么毛病。你想想，如果數據更新成功，但是刪除緩存失敗怎么辦?

 

如圖中所示，剛開始時(初始)，數據庫和緩存中的數據是一致的，但是在寫請求過來后，數據庫更新成功，而緩存刪除失敗。這就導致數據庫中的數據是最新的，但緩存中卻依然存著舊數據。

這時，如果讀請求過來，就會直接讀取緩存中的舊數據返回了。

雙寫一致方案

1、先刪除緩存，后更新數據庫

既然問題的原因是刪除緩存失敗了，那么我們先確保把緩存刪除成功了，再去更新數據庫。也就是說我們先刪除緩存，后更新數據庫。

可能你會問了，如果我數據庫更新失敗了呢?

我們不妨通過圖來看下這種情況：

 

緩存刪除成功后為空了，但是數據庫卻失敗了，還是原來的舊數據。

如果這時候有請求過來的話，一看緩存中沒有數據，于是就到數據庫讀取了舊數據更新到緩存中。

如果你的項目并發量很低的話，每天訪問量就那么點，那這么用沒毛病，很少情況下才會出現數據不一致的問題。

這種策略只能算作初級的解決方案，為什么這么說呢?

2、緩存延時雙刪策略

如果同時來了兩個請求，一個寫請求，一個讀請求。

寫請求先刪除Redis中的數據，然后去數據庫進行更新操作。

讀請求判斷Redis中有沒有數據，沒有數據時去請求數據庫，拿到數據后寫入緩存中。

但是寫請求此時并沒有更新成功，或者執行了一個事務還沒有成功。

這樣的話，讀請求拿到未修改的舊數據寫入緩存。過了一會兒，寫請求將數據庫更新成功了，那么此時緩存與庫中的數據就不一致了。

 

解決方案呢?延時雙刪策略：

 

寫請求過來先把 Redis緩存刪掉，等數據庫更新成功后，異步等待一段時間再次把緩存刪掉。

這種方案讀取速度快，但是會出現短時間的臟數據。

總結

旁路緩存策略

• 讀的時候，先讀緩存，緩存沒有的話，再去讀數據庫，然后取出來放入緩存中，同時返回響應。
• 更新的時候，先更新數據庫，再刪除緩存。

雙寫一致方案

• 先刪除緩存，后更新數據庫：

解決了緩存刪除失敗導致庫與緩存不一致的問題，適用于并發量不高的業務場景。

• 緩存延時雙刪策略：

這種方案解決了高并發情況下，同時有讀請求與寫請求時導致的不一致問題。讀取速度快，但是可能會出現短時間的臟數據。

 

每種方案各有利弊，對于不同的業務來說沒有通用的技術方案。在選擇技術方案時需要根據業務自身來定。沒有最好的，只有最合適的。