在網際網路領域，快取由於其高併發和高效能的特性，已經在專案中被廣泛使用。在讀取快取方面，大家沒什麼疑問，都是按照下圖的流程來進行業務操作。

但是在更新快取方面，對於更新完資料庫，是更新快取呢，還是刪除快取；又或者是先刪除快取，再更新資料庫，其實大家存在很大的爭議。目前筆者還沒有見過一篇全面的文章，對這幾種方案進行解析。於是筆者戰戰兢兢，頂著被大家吐槽的風險，寫了這篇文章，如有不妥之處敬請在留言區指出，願與大家一起探討。

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

1. 講解快取更新策略

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

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

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

在這裡，我們討論三種更新策略：

1. 先更新資料庫，再更新快取；

2. 先刪除快取，再更新資料庫；

3. 先更新資料庫，再刪除快取。

應該沒有人會問我，為什麼沒有先更新快取，再更新資料庫這種策略吧？

一、先更新資料庫，再更新快取

這套方案，大家是普遍反對的。為什麼呢？有如下兩點原因。

原因一（執行緒安全形度）

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

1. 執行緒A更新了資料庫；

2. 執行緒B更新了資料庫；

3. 執行緒B更新了快取；

4. 執行緒A更新了快取。

這就出現請求A更新快取應該比請求B更新快取早才對，但是因為網路等原因，B卻比A更早更新了快取。這就導致了髒資料，因此不考慮。

原文連結