日常生產場景中，為了避免大量請求同時打在數據庫上導致故障，數據庫+緩存的方式已經成了日常標配。對於讀取的部分，大家都很熟悉。但是對於寫的部分，到底是先寫庫還是先寫緩存，這點可能困擾着很多人。
先來看一下文章結構：
一、旁路緩存策略
提到這個有逼格的名詞你可能不是很熟悉，但是說到它的使用方式，你肯定用過。
這是一種最經典的緩存+數據庫讀寫的模式，英文是這樣 Cache Aside Pattern，可能你見過。
這種模式對應的使用方式有兩種情況，一讀一寫：
- 基本讀取方式；
- 先更新數據庫，后刪除緩存。
1、基本讀取方式
這部分相信大家已經輕車熟路：先讀緩存，緩存中沒有數據的話就去數據庫讀取，然后再存入緩存中，同時返回響應。
這沒什么可說的，平時都這么用。如果還不清楚，看圖：
那我們再看寫的部分。
2、先更新數據庫，后刪除緩存
你可能會問了，為什么不在更新完數據庫后，采取更新緩存的方案，而是將其刪除。原因有這么幾點：
（1）頻繁更新浪費資源
你想想，如果修改庫中的某個字段，一段時間內頻繁進行更新。那么你修改多少次，緩存也跟着更新多少次。但是這個緩存數據在這段時間內也就被偶爾使用了幾次。
那么你看，是不是就會導致資源浪費了。
（2）緩存數據計算復雜
還有一種情況，如果這個緩存的數據計算成本比較高。比如為了一個數據，要通過多張表來計算才能得到結果。那么每修改一次，為了更新緩存還要再查詢多張表來算一次，我的天。
（3）兩種情況都具備
這種情況最為致命，不但修改頻繁，同時緩存數據還要經過復雜計算。
生產環境里要是這么搞的話，那估計你就可以准備簡歷了。
既然更新緩存的方式不可行，那么我們換個思路，刪除掉呢？
還是按照上邊的步驟，先更新數據庫，只是我們把更新緩存的操作換成了刪除。
在這種情況下，讀請求過來的時候，發現 Redis 中沒有數據，就會去數據庫里讀取，然后寫入緩存中。
這也是一種懶加載方式，只有緩存被需要的時候才會去計算。這樣可以避免大量計算及頻繁更新。
但是，這樣會有什么隱患的問題？是不是看着沒什么毛病。你想想，如果數據更新成功，但是刪除緩存失敗怎么辦？
如圖中所示，剛開始時（初始），數據庫和緩存中的數據是一致的，但是在寫請求過來后，數據庫更新成功，而緩存刪除失敗。這就導致數據庫中的數據是最新的，但緩存中卻依然存着舊數據。
這時，如果讀請求過來，就會直接讀取緩存中的舊數據返回了。
二、雙寫一致方案
1、先刪除緩存，后更新數據庫
既然問題的原因是刪除緩存失敗了，那么我們先確保把緩存刪除成功了，再去更新數據庫。也就是說我們先刪除緩存，后更新數據庫。
可能你會問了，如果我數據庫更新失敗了呢？
我們不妨通過圖來看下這種情況：
緩存刪除成功后為空了，但是數據庫卻失敗了，還是原來的舊數據。
如果這時候有請求過來的話，一看緩存中沒有數據，於是就到數據庫讀取了舊數據更新到緩存中。
如果你的項目並發量很低的話，每天訪問量就那么點，那這么用沒毛病，很少情況下才會出現數據不一致的問題。
這種策略只能算作初級的解決方案，為什么這么說呢？
2、緩存延時雙刪策略
如果同時來了兩個請求，一個寫請求，一個讀請求。
寫請求先刪除Redis中的數據，然后去數據庫進行更新操作。
讀請求判斷Redis中有沒有數據，沒有數據時去請求數據庫，拿到數據后寫入緩存中。
但是寫請求此時並沒有更新成功，或者執行了一個事務還沒有成功。
這樣的話，讀請求拿到未修改的舊數據寫入緩存。過了一會兒，寫請求將數據庫更新成功了，那么此時緩存與庫中的數據就不一致了。
解決方案呢？延時雙刪策略：
寫請求過來先把 Redis緩存刪掉，等數據庫更新成功后，異步等待一段時間再次把緩存刪掉。
這種方案讀取速度快，但是會出現短時間的臟數據。
三、總結
- 旁路緩存策略: 讀的時候，先讀緩存，緩存沒有的話，再去讀數據庫，然后取出來放入緩存中，同時返回響應。更新的時候，先更新數據庫，再刪除緩存。
- 雙寫一致方案：先刪除緩存，后更新數據庫。解決了緩存刪除失敗導致庫與緩存不一致的問題，適用於並發量不高的業務場景。
- 緩存延時雙刪策略：這種方案解決了高並發情況下，同時有讀請求與寫請求時導致的不一致問題。讀取速度快，但是可能會出現短時間的臟數據。
每種方案各有利弊，對於不同的業務來說沒有通用的技術方案。在選擇技術方案時需要根據業務自身來定。沒有最好的，只有最合適的。