作者：孤獨煙出處： http：//rjzheng.cnblogs.com/

正文

博主本來覺得，《分散式之資料庫和快取雙寫一致性方案解析》，一文已經十分清晰。然而這一兩天，有人在微信上私聊我，覺得應該要採用

先刪快取，再更新資料庫，再刪快取

這一方案作為快取更新策略，而不是先更新資料庫，再刪快取。並且搬出了兩篇大佬的文章，《Cache Aside Pattern》，《快取與資料庫不一致，咋辦？》，希望博主能加以說明。因為問的人太多了，所以才有了這篇文章的誕生。

正文

在開始這篇文章之前，我們先自己思考一下以下兩個更新策略

方案一

(1)刪快取 (2)更資料庫 (3)刪快取

方案二

(1)更資料庫 (2)刪快取

大家看下面的文章前，自己先思考一下，方案一的步驟(1)有沒有存在的必要？ 先上一個結論:方案二存在的缺點，方案一全部存在，且方案一比方案二多一個步驟，所以應該選方案二。

下面，針對《Cache Aside Pattern》，《快取與資料庫不一致，咋辦？》這兩篇文章提出的論點，提出小小的質疑。這兩篇文章認為方案二不行的原因，主要有以下兩點(1)方案二在步驟(2)，出現刪快取失敗的情況下，會出現資料不一致的情形，如下圖所示(2)方案二存在下面的主從同步，導致cache不一致問題，如下圖所示 大致流程就是，執行緒A寫，執行緒B讀，會有以下流程出現 (1)快取剛好失效 (2)執行緒A寫入master資料庫，slave還沒同步 (3)執行緒B發現快取失效，去slave讀到舊值 (4)執行緒A刪除快取 (5)執行緒B把舊值放入快取

然而大家發現了麼，這兩篇文章提出的反對意見，在該文作者自己所提出的方案一里頭也是存在的？(1)針對刪快取失敗問題 方案一的步驟(3)也會可能出現刪除快取失敗問題，可是作者沒有加以詳細說明。(2)針對資料不一致問題 執行緒A寫，執行緒B讀，會有以下流程出現 (1)執行緒A刪除快取 (2)執行緒A寫入master資料庫，slave還沒同步 (3)執行緒B發現快取失效，去slave讀到舊值 (4)執行緒A刪除快取 (5)執行緒B把舊值放入快取

綜上所述，我們應該選擇方案二，而不是方案一。方案二存在的缺點，方案一全部存在，且方案一步驟上多了一步，增加了不穩定因素。

總結

該文章只是糾正了一下目前流傳的觀點的正確性，並沒有針對任何人。技術的世界，只論技術。