正文
博主本來覺得，《分布式之數據庫和緩存雙寫一致性方案解析》，一文已經十分清晰。然而這一兩天，有人在微信上私聊我，覺得應該要采用
先刪緩存，再更新數據庫，再刪緩存
這一方案作為緩存更新策略，而不是先更新數據庫，再刪緩存。並且搬出了兩篇大佬的文章，《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把舊值放入緩存
綜上所述，我們應該選擇方案二，而不是方案一。方案二存在的缺點，方案一全部存在，且方案一步驟上多了一步，增加了不穩定因素。
總結
該文章只是糾正了一下目前流傳的觀點的正確性，並沒有針對任何人。技術的世界，只論技術。