參考：https://www.cnblogs.com/renxiuxing/p/14967390.html

快取雙寫不一致的問題描述的是資料庫和快取中的資料一樣的問題。

我們在呼叫介面去查詢的時候按照下面的流程去做處理的；

資料庫和快取的更新的問題

對於更新完資料庫，是更新快取呢，還是刪除快取？又或者是先刪除快取，再更新資料庫，其實大家存在很大的爭議。

從理論上來說，給快取設定過期時間，是保證最終一致性的解決方案。

對存入快取的資料設定過期時間，只要到達過期時間，讀請求自然會從資料庫中讀取新值然後回填快取，保證是資料的最終一致；所有的寫請求都以資料庫為準，對快取的操作只是盡最大努力處理到一致即可。

三種更新策略

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

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

該方案會導致不一致的原因是：請求A和請求B同時去更新；

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

• 原因一（請求A和B同時去更新）

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

　　（1）請求A更新了資料庫；

　　（2）請求B更新了資料庫；

　　（3）請求B更新了快取；

　　（4）請求A更新了快取；

　　按理說請求A更新快取應該比請求B更新快取早才對，但是因為網路等原因，B卻比A更早更新了快取，這樣就導致了髒資料。

• 原因二（業務場景角度）

　　有如下兩點：

　　（1）如果寫入資料庫的值，並不是直接寫入快取的，而是要經過一系列複雜的計算再寫入快取。那麼，每次的寫請求操作都是先寫入資料庫，經過計算後再寫入快取，無疑是浪費效能的。顯然，每次的寫請求寫入到資料庫中之後，刪除快取更為適合，這樣就不用去計算了，只有在查詢的時候只計算一次就好了。

　　（2）如果是一個寫資料庫場景比較多，而讀資料場景比較少的業務需求，採用這種方案就會導致，每次來的寫操作都要去更新快取，實際上好久才會讀一次資料，快取被頻繁的更新都做了無用功，浪費了效能。

　　所以，針對快取操作的方案還是採用 刪除快取 的方案較好；

　　接下來討論的就是爭議最大的，先刪快取，再更新資料庫。還是先更新資料庫，再刪快取的問題。

先刪快取，再更新資料庫

該方案會導致不一致的原因是：同時有一個請求A進行更新操作，請求B進行查詢操作。

那麼會出現如下情形:

（1）請求A進行先刪除快取；

（2）請求B查詢發現快取不存在，請求B去資料庫查詢得到舊值，並將舊值寫入快取；

（3）請求A將新值寫入資料庫；

上述情況就會導致不一致的情形出現。而且，如果不採用給快取設定過期時間策略，該資料永遠都是髒資料。

那麼，如何解決呢？

　　採用延時雙刪策略：

　　（1）先刪除快取；
　　（2）再更新資料庫；
　　（3）休眠1秒，再次刪除快取；

延時雙刪的策略還是不太好，因為休眠的這個時間不太好把控，而且影響介面的效能；若將休眠 一會，再去刪除快取的操作給非同步處理了，那麼可以解決效能的問題，但是若非同步處理的時候失敗了，還是會出現快取不一致的問題。

先更新資料庫，再刪快取

首先，先說一下。老外提出了一個快取更新套路，名為《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）更短，這一情形很難出現。