前言：

????????首先，緩存由于其高并發和高性能的特性，已經在項目中被廣泛使用。在讀取緩存方面，大家沒啥疑問，都是按照下圖的流程來進行業務操作。

????????但是在更新緩存方面，對于更新完數據庫，是更新緩存呢，還是刪除緩存呢？又或者是先刪除緩存，再更新數據庫呢？其實大家存在很大的爭議。本文主要針對不同的更新進行總結，




文章結構由以下三個部分組成：

1、講解緩存更新策略

2、對每種策略進行缺點分析

3、針對缺點給出改進方案

---

????????先做一個說明，從理論上來說，給緩存設置過期時間，是保證最終一致性的解決方案。這種方案下，我們可以對存入緩存的數據設置過期時間，所有的寫操作以數據庫為準，對緩存操作只是盡最大努力即可。也就是說如果數據庫寫成功，緩存更新失敗，那么只要到達過期時間，則后面的讀請求自然會從數據庫中讀取新值然后回填緩存。因此，接下來討論的思路不依賴于給緩存設置過期時間這個方案。在這里，我們討論三種更新策略：

先更新數據庫，再更新緩存

先刪除緩存，再更新數據庫

先更新數據庫，再刪除緩存

應該沒人問我，為什么沒有先更新緩存，再更新數據庫這種策略。

一、先更新數據庫，再更新緩存：

這套方案，大家是普遍反對的。主要有以下兩個原因：

1、原因一：

從線程安全角度看，同時有請求A和請求B進行更新操作，那么會出現：

• （1）線程A更新了數據庫
• （2）線程B更新了數據庫
• （3）線程B更新了緩存
• （4）線程A更新了緩存

????????這就出現請求A更新緩存應該比請求B更新緩存早才對，但是因為網絡等原因，B卻比A更早更新了緩存。這就導致了臟數據，因此不考慮

2、原因二：

從業務場景角度看，存在以下兩個問題：

（1）如果是一個數據庫寫多讀少的業務場景求，采用這種方案就會導致，數據壓根還沒讀到，緩存就被頻繁的更新，浪費性能。

（2）如果你寫入數據庫的值，并不是直接寫入緩存的，而是要經過一系列復雜的計算再寫入緩存。那么，每次寫入數據庫后，都再次計算寫入緩存的值，無疑是浪費性能的。顯然，刪除緩存更為適合。

接下來討論的就是爭議最大的，先刪緩存，再更新數據庫。還是先更新數據庫，再刪緩存的問題

二、先刪緩存，再更新數據庫：

1、存在問題：

該方案會導致不一致的原因是：同時有一個請求A進行更新操作，另一個請求B進行查詢操作。那么會出現如下情形：

• （1）請求A進行寫操作前，先刪除緩存
• （2）請求B查詢發現緩存不存在
• （3）請求B去數據庫查詢得到舊值
• （4）請求B將舊值寫入緩存
• （5）請求A將新值寫入數據庫

上述情況就會導致不一致的情形出現。而且，如果不采用給緩存設置過期時間策略，該數據永遠都是臟數據。

2、解決方案：延時雙刪策略：

public?void?write(String?key,Object?data){

????????redis.delKey(key);

????????db.updateData(data);

????????Thread.sleep(1000);

????????redis.delKey(key);

????}

轉化為中文描述就是：?

• （1）先淘汰緩存
• （2）再寫數據庫
• （3）休眠1秒，再次淘汰緩存

這么做的目的是將休眠時間內產生的緩存臟數據再次刪除（這個休眠時間需要具體根據項目的業務邏輯耗時指定）

3、如果是 MySQL 的讀寫分離架構怎么辦？

????????在這種情況下，造成數據不一致的原因如下，還是兩個請求，一個請求A進行更新操作，另一個請求B進行查詢操作。

（1）請求A進行寫操作，刪除緩存
（2）請求A將數據寫入數據庫了，
（3）請求B查詢緩存發現，緩存沒有值
（4）請求B去從庫查詢，這時，還沒有完成主從同步，因此查詢到的是舊值
（5）請求B將舊值寫入緩存
（6）數據庫完成主從同步，從庫變為新值

上述情形，就是數據不一致的原因。還是使用雙刪延時策略。只是，睡眠時間修改為在主從同步的延時時間基礎上，加幾百ms

4、采用延時雙刪除策略，吞吐量降低怎么辦？

????????可以另起一個線程異步執行第二次刪除操作，這樣寫的請求就不用沉睡一段時間后再返回了，從而加大吞吐量。但是如果第二次刪除的時候，刪除失敗怎么辦呢？如果第二次刪除失敗，就會出現如下情形。還是有兩個請求，一個請求A進行更新操作，另一個請求B進行查詢操作，為了方便，假設是單庫：

• （1）請求A進行寫操作，刪除緩存
• （2）請求B查詢發現緩存不存在
• （3）請求B去數據庫查詢得到舊值
• （4）請求B將舊值寫入緩存
• （5）請求A將新值寫入數據庫
• （6）請求A試圖去刪除請求B寫入對緩存值，結果失敗了

????????也就是說，如果第二次刪除緩存失敗，會再次出現緩存和數據庫不一致的問題。如何解決呢？具體解決方案，且看對第(3)種更新策略的解析。

三、先更新數據庫，再刪緩存：

????????首先，國外開發者提出了一個緩存更新策略名為《Cache-Aside pattern》，其中指出：

• 失效：應用程序先從cache取數據，沒有得到，則從數據庫中取數據，成功后，放到緩存中。
• 命中：應用程序從cache中取數據，取到后返回。
• 更新：先把數據存到數據庫中，成功后，再讓緩存失效。

????????另外，知名社交網站facebook也在論文《Scaling Memcache at Facebook》中提出，他們用的也是先更新數據庫，再刪緩存的策略。

? ? ? ? 但是這種策略并不是不存在并發問題，如果發生下述情況，還是會產生臟數據的。假設這會有兩個請求，一個請求A做查詢操作，一個請求B做更新操作，那么會有如下情形產生：

• （1）緩存剛好失效
• （2）請求A查詢數據庫，得一個舊值
• （3）請求B將新值寫入數據庫
• （4）請求B刪除緩存
• （5）請求A將查到的舊值寫入緩存

? ? ? ? 但是發生上述臟數據的情況有一個先天性條件，就是步驟（3）的寫數據庫操作比步驟（2）的讀數據庫操作耗時更短，才有可能使得步驟（4）先于步驟（5）。但是數據庫的讀操作的速度一般是遠快于寫操作的，因此步驟（3）耗時比步驟（2）更短，所以這一情形很難出現。

? ? ? ? 如果一定要解決怎么辦？首先，給緩存設有效時間是一種方案。其次，采用策略（2）里給出的異步延時刪除策略，保證讀請求完成以后，再進行刪除操作。

? ? ? ?最后，緩存更新策略二和緩存更新策略三都存在一個問題，如果刪緩存失敗了，還是會出現數據不一致的情況。針對這種情況，只要提供一個保障的重試機制即可，這里給出兩套方案：

方案一：

流程如下所示：

• （1）更新數據庫數據；
• （2）緩存因為種種問題刪除失敗
• （3）將需要刪除的key發送至消息隊列
• （4）自己消費消息，獲得需要刪除的key
• （5）繼續重試刪除操作，直到成功

????????然而，該方案有一個缺點，對業務線代碼造成大量的侵入。于是有了方案二，在方案二中，啟動一個訂閱程序去訂閱數據庫的binlog，獲得需要操作的數據。在應用程序中，另起一段程序，獲得這個訂閱程序傳來的信息，進行刪除緩存操作。

方案二：

流程如下圖所示：

• （1）更新數據庫數據
• （2）數據庫會將操作信息寫入binlog日志當中
• （3）訂閱程序提取出所需要的數據以及key
• （4）另起一段非業務代碼，獲得該信息
• （5）嘗試刪除緩存操作，發現刪除失敗
• （6）將這些信息發送至消息隊列
• （7）重新從消息隊列中獲得該數據，重試操作

備注說明：上述的訂閱binlog程序在mysql中有現成的中間件叫canal，可以完成訂閱binlog日志的功能。另外，重試機制，博主是采用的是消息隊列的方式。如果對一致性要求不是很高，直接在程序中另起一個線程，每隔一段時間去重試即可，這些大家可以靈活自由發揮，只是提供一個思路。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的Redis缓存与数据库双写一致性的全部內容，希望文章能夠幫你解決所遇到的問題。

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