快取由於其高併發和高效能的特性，在專案中被廣泛使用。讀快取流程如下圖：

雙寫一致性有以下三個要求：

1. 快取不能讀到髒資料
2. 快取可能會讀到過期資料，但要在可容忍時間內實現最終一致
3. 這個可容忍時間儘可能的小

要想同時滿足上面三條，可以採用讀請求和寫請求序列化，串到一個記憶體佇列裡去，這樣就可以保證一定不會出現不一致的情況。但是，序列化之後，就會導致系統的吞吐量會大幅度的降低，要用比正常情況下多幾倍的機器去支撐線上請求。

所以，在這裡，我們討論三種常見方法：

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

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

這種方法是大家普遍反對的，原因集中在下面兩點：

原因1：執行緒安全形度。
同時有請求A和請求B進行更新操作，那麼會出現:

1. 執行緒A更新了資料庫
   
2. 執行緒B更新了資料庫
   
3. 執行緒B更新了快取
   

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

   "先更新快取，再更新資料庫"這種方案同理，也是造成髒資料，所以不被考慮

原因2：業務場景角度。
有如下兩點：

1. 如果你是一個寫資料庫場景比較多，而讀資料場景比較少的業務需求，採用這種方案就會導致資料壓根還沒讀到，快取就被頻繁的更新，浪費效能。
2. 如果你寫入資料庫的值，並不是直接寫入快取的，而是要經過一系列複雜的計算再寫入快取。那麼，每次寫入資料庫後，都再次計算寫入快取的值，無疑是浪費效能的。顯然，刪除快取更為適合。

如果一定要更新快取，可以考慮給快取資料增加版本號

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

該方案同樣會導致不一致。同時有請求A和請求B進行更新操作，那麼會出現:

1. 請求A進行寫操作，刪除快取
2. 請求B查詢發現快取不存在
3. 請求B去資料庫查詢得到舊值
4. 請求B將舊值寫入快取
5. 請求A將新值寫入資料庫上述情況就會導致不一致的情形出現。而且，如果不採用給快取設定過期時間策略，該資料永遠都是髒資料。

解決方法：

1. 先刪除快取
2. 再寫資料庫(這兩步和原來一樣)
3. 休眠一定時間（例如1秒或200ms），再次刪除快取。這麼做，可以將快取髒資料再次刪除。

然而這種解決方案由於要休眠執行緒還是很影響吞吐量的

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

這種方案是很多工程採用的方案，我們來看下是否一定安全。
假設有兩個請求，一個請求A做查詢操作，一個請求B做更新操作，那麼會有如下情形產生

1. 快取剛好失效
2. 請求A查詢資料庫，得一箇舊值
3. 請求B將新值寫入資料庫
4. 請求B刪除快取
5. 請求A將查到的舊值寫入快取

這樣，髒資料就產生了，然而上面的情況是假設在資料庫寫請求比讀請求還要快。實際上，工程中資料庫的讀操作的速度遠快於寫操作的。
要麼通過2PC或是Paxos協議保證一致性，要麼就是想盡辦法降低併發時髒資料的概率，大概是因為2PC太慢，而Paxos又太複雜，綜合考慮，Facebook選擇了這個第三種方案。

如果刪除快取失敗了怎麼辦？

啟動一個訂閱程式去訂閱資料庫的binlog，獲得需要操作的資料。在應用程式中，另起一段程式，獲得這個訂閱程式傳來的資訊，進行刪除快取操作。

阿里開源的中介軟體canal可以完成訂閱binlog日誌的功能。

總結

本文是對目前網際網路中已有的一致性方案進行了一個總結，希望大家有所收穫。

最後，限於筆者經驗水平有限，歡迎讀者就文中的觀點提出寶貴的建議和意見。如果想獲得更多的學習資源或者想和更多的技術愛好者一起交流，可以關注我的公眾號『全菜工程師小輝』後臺回覆關鍵詞領取學習資料、進入前後端技術交流群和程式設計師副業群。同時也可以加入程式設計師副業群Q群：735764906 一起交流。

相關推薦