作者|萊烏

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

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

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

- 思維導(dǎo)圖 -

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

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

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

• 基本讀取方式；

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

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

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

那我們再看寫的部分。

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

• 頻繁更新浪費(fèi)資源
  

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

那么你看，是不是就會導(dǎo)致資源浪費(fèi)了。

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

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

• 兩種情況都具備

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果同時(shí)來了兩個請求，一個寫請求，一個讀請求。

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

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

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

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

解決方案呢？延時(shí)雙刪策略：

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

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

旁路緩存策略

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

• 更新的時(shí)候，先更新數(shù)據(jù)庫，再刪除緩存。
  

雙寫一致方案

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

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

• 緩存延時(shí)雙刪策略：
  

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

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

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
長按訂閱更多精彩▼
如有收獲，點(diǎn)個在看，誠摯感謝