[[346368]]

本文轉(zhuǎn)載自微信公眾號「IT界農(nóng)民工」，作者萊烏。轉(zhuǎn)載本文請聯(lián)系IT界農(nóng)民工公眾號。  

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

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

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

- 思維導圖 -

旁路緩存策略

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

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

這種模式對應(yīng)的使用方式有兩種情況，一讀一寫：

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

1、基本讀取方式

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

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

那我們再看寫的部分。

2、先更新數(shù)據(jù)庫，后刪除緩存

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

• 頻繁更新浪費資源

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

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

• 緩存數(shù)據(jù)計算復雜

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

• 兩種情況都具備

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

生產(chǎn)環(huán)境里要是這么搞的話，那估計你就可以準備簡歷了。

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

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

在這種情況下，讀請求過來的時候，發(fā)現(xiàn) Redis 中沒有數(shù)據(jù)，就會去數(shù)據(jù)庫里讀取，然后寫入緩存中。

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

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

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

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

雙寫一致方案

1、先刪除緩存，后更新數(shù)據(jù)庫

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

可能你會問了，如果我數(shù)據(jù)庫更新失敗了呢?

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

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

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

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

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

2、緩存延時雙刪策略

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

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

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

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

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

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

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

這種方案讀取速度快，但是會出現(xiàn)短時間的臟數(shù)據(jù)。

總結(jié)

旁路緩存策略

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

雙寫一致方案

• 先刪除緩存，后更新數(shù)據(jù)庫：

解決了緩存刪除失敗導致庫與緩存不一致的問題，適用于并發(fā)量不高的業(yè)務(wù)場景。

• 緩存延時雙刪策略：

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

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