到底是先更新數據庫還是先更新緩存？
很多小伙伴最近都在問我，在系統中引入緩存后，當向數據庫中寫入數據時，是先寫數據庫還是先寫緩存呢?先寫數據庫和先寫緩存有什么區別嗎?今天，我們就一起來聊聊這個話題。
從本質上講，無論是先寫數據庫還是先寫緩存，都是為了保證數據庫和緩存的數據一致，也就是我們常說的數據一致性。
隨著互聯網的高速發展，當今時代已然從IT時代進入到DT時代。互聯網系統架構也已經由最初的單體架構轉變為分布式、微服務架構模式。從數據體量上來看，各系統存儲的數據量越來越大，數據的查詢性能越來越低。此時，就需要我們不斷的進行優化，一種常用的優化手段就是引入緩存。而引入緩存后，我們在向數據庫插入數據時，到底是先更新數據庫還是先更新緩存呢?
緩存的一般使用
緩存，從本質上講，是為了更好的協調兩個速度差異比較大的組件而引入的一種中間緩存層。例如，如果需要將數據讀入CPU進行計算處理，由于CPU的運算速度是非常快的，而磁盤的IO處理相比于CPU來說，慢了很多數量級，每次從磁盤讀取數據，勢必會造成CPU長時間并且頻繁等待磁盤IO。此時，我們就可以通過內存來緩和CPU和磁盤之間的速度差異。
從緩存的使用上來說，一般是按照如下的流程來使用緩存。
我們也可以表示成如下的序列圖。
在上面的使用示例中，我們只是簡單的將數據放入了緩存，最多為緩存設置一個過期時間，到期后，緩存自然就會被清除，后續的請求由于在緩存中獲取不到數據，又會從數據庫中獲取數據，將數據寫入緩存。
但是在后續更新數據的操作中，是更新完數據庫，接下來更新緩存還是刪除緩存?又或者是先刪除緩存，再更新數據庫?
緩存更新策略
從理論上來說，給緩存設置過期時間，其實是一種最終一致性的表現。這種方案下，可以對存入緩存的數據設置過期時間，所有的寫操作以數據庫為準，對緩存操作只是盡最大努力即可。也就是說如果數據庫寫成功，緩存更新失敗，那么只要到達過期時間，則后面的讀請求自然會從數據庫中讀取新值然后回填緩存。這也是一般情況下，使用的最多的一種方式。
先更新數據庫再更新緩存
其實，這種方案很多有經驗的小伙伴是很反對的，為啥，我們來分析下。
首先，這種方案會有線程安全的問題。
例如，同時有線程A和線程B對數據進行更新操作，可能會出現下面的執行順序。
(1) 線程A更新了數據庫
(2) 線程B更新了數據庫
(3) 線程B更新了緩存
(4) 線程A更新了緩存
此時就會出現數據庫中的數據與緩存的數據不一致的情況，這是因為線程A先更新了數據庫，可能因為網絡等異常情況，線程B更新完數據庫進而更新了緩存，當線程B更新完緩存后，線程A才更新緩存，這就導致了數據庫數據與緩存數據的不一致。
其次，這種方案也有其不適用的業務場景。
首先一個業務場景就是數據庫寫多讀少的場景，這種場景下采用先更新數據庫再更新緩存的策略，就會導致緩存并未被讀取就會被頻繁的更新，極大的浪費了服務器的性能。
再一個業務場景就是數據庫中的數據不是直接寫入緩存的，而是需要大量的復雜運算，將運算結果寫入緩存。如果這種場景下使用先更新數據庫再更新緩存的策略，也會造成服務器資源的浪費。
先刪除緩存再更新數據庫
先刪除緩存再更新數據庫的方案也存在著線程安全的問題，例如，線程A更新緩存，同時，線程B讀取緩存的數據。可能會出現下面的執行順序。
(1) 線程A刪除緩存
(2) 線程B查詢緩存，發現緩存中沒有想要的數據
(3) 線程B查詢數據庫中的舊數據
(4) 線程B將查詢到的舊數據寫入緩存
(5) 線程A將新數據寫入數據庫
此時，就出現了數據庫中的數據和緩存中的數據不一致的情況。如果刪除緩存失敗，也會出現數據庫數據和緩存數據不一致的現象。
先更新數據庫再刪除緩存
首先，這種方式也有極小的概率發生數據庫數據和緩存數據不一致的情況，例如，線程A做查詢操作，線程B執行更新操作，其執行的順序如下所示。
(1)緩存剛好失效
(2)請求A查詢數據庫，獲取到數據庫中的舊值
(3)請求B將新值寫入數據庫
(4)請求B刪除緩存
(5)請求A將查到的舊值寫入緩存
如果上述順序一旦發生，就會造成數據庫中的數據和緩存中的數據不一致的情況發生。
但是，先更新數據庫再刪除緩存的策略發生數據庫和緩存數據不一致的概率很低，原因就是：(3)的寫數據庫操作比步驟(2)的讀數據庫操作耗時更短，才有可能使得步驟(4)先于步驟(5)執行。但是，往往數據庫的讀操作的速度遠快于寫操作，因此步驟(3)耗時比步驟(2)更短，這一場景很難出現。
如果刪除緩存失敗，也會出現數據庫數據和緩存數據不一致的現象。
這樣說來，貌似三種方案都不安全呀，那我們該如何做呢?最重要的就是需要引入重試機制。
推薦使用
在實際的生產環境中，推薦 使用先更新數據庫再刪除緩存 的操作。那么，我們該如何解決這種策略下的問題呢?
有兩種方案，一種是在程序邏輯中處理失敗重試的操作;另外，借助于阿里巴巴開源的Canal。
手動失敗重試
流程如下所示
(1)更新數據庫數據;
(2)刪除緩存數據失敗
(3)將需要刪除的key發送至消息隊列
(4)自己消費消息，獲得需要刪除的key
(5)繼續重試刪除操作，直到成功
這種方案有一個缺點，對業務線代碼造成大量的侵入。
同步數據庫數據
先來一張圖，這種圖從整體架構上解決了數據庫數據和緩存數據不一致的情況。
流程如下圖所示：
(1)更新數據庫數據
(2)數據庫將數據表數據的變更信息寫入binlog日志當中
(3)訂閱程序獲取所需要的數據以及key
(4)程序邏輯中處理具體的業務邏輯，接收訂閱binlog、發起刪除緩存的請求。
(5)嘗試刪除緩存操作，發現刪除失敗
(6)將這些信息發送至消息隊列
(7)重新從消息隊列中獲得該數據，重試操作。
本文轉載自微信公眾號「冰河技術」，可以通過以下二維碼關注。轉載本文請聯系冰河技術公眾號。
