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

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


旁路緩存策略

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

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

這種模式對應的使用方式有兩種情況，一讀一寫：
基本讀取方式；
先更新數據庫，后刪除緩存。

1、基本讀取方式

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

那我們再看寫的部分。

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

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

頻繁更新浪費資源

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

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

緩存數據計算復雜

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

兩種情況都具備

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

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

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

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

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

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

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

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

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

雙寫一致方案

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

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

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

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

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

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

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

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

2、緩存延時雙刪策略

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

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

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

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

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

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

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

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

———————————————————————————————————————

總結

旁路緩存策略

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

雙寫一致方案

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

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

緩存延時雙刪策略：

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

總結

以上是生活随笔為你收集整理的缓存与库先删哪个（转自网络，侵删）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。