分佈式數據庫與緩存雙寫一致性方案解疑

在互聯網領域，緩存因爲其高併發和高性能的特性，已經在項目中被普遍使用。在讀取緩存方面，你們沒什麼疑問，都是按照下圖的流程來進行業務操做。

可是在更新緩存方面，對於更新完數據庫，是更新緩存呢，仍是刪除緩存；又或者是先刪除緩存，再更新數據庫，其實你們存在很大的爭議。目前筆者尚未見過一篇全面的文章，對這幾種方案進行解析。因而筆者戰戰兢兢，頂着被你們吐槽的風險，寫了這篇文章，若有不妥之處敬請在留言區指出，願與你們一塊兒探討。

本文將由如下三個部分組成：

1. 講解緩存更新策略

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

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

先作一個說明，從理論上來講，給緩存設置過時時間，是保證最終一致性的解決方案。這種方案下，咱們能夠對存入緩存的數據設置過時時間，全部的寫操做以數據庫爲準，對緩存操做只是盡最大努力便可。也就是說若是數據庫寫成功，緩存更新失敗，那麼只要到達過時時間，則後面的讀請求天然會從數據庫中讀取新值而後回填緩存。所以，接下來討論的思路不依賴於給緩存設置過時時間這個方案。

在這裏，咱們討論三種更新策略：

1. 先更新數據庫，再更新緩存；

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

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

應該沒有人會問我，爲何沒有先更新緩存，再更新數據庫這種策略吧？

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

這套方案，你們是廣泛反對的。爲何呢？有以下兩點緣由。

緣由一（線程安全角度）

同時有請求A和請求B進行更新操做，那麼會出現

1. 線程A更新了數據庫；

2. 線程B更新了數據庫；

3. 線程B更新了緩存；

4. 線程A更新了緩存。

這就出現請求A更新緩存應該比請求B更新緩存早纔對，可是由於網絡等緣由，B卻比A更早更新了緩存。這就致使了髒數據，所以不考慮。