只要我們使用緩存，就必然會面對緩存和數據庫間的一致性問題。如果緩存中的數據和數據庫的數據不一致，那么業務應用從緩存中讀取的數據就不是最新的數據，對業務的影響可想而知。比如我們把商品的庫存數據存在緩存中，如果緩存中庫存數據不對，那么可能就會影響下單操作，這是業務上很難接受的。本篇文章我們來一起聊一聊緩存的一致性問題。
如何解決緩存不一致先刪緩存再更新數據庫
假設線程A刪除緩存后，還沒來得及更新數據庫，這時候線程B開始讀數據，線程B發現緩存缺失就只能去讀數據庫，等到線程B從數據庫中讀取完數據回塞緩存后，線程A才開始更新數據庫，此時，緩存中的數據是舊值，而數據庫中是最新值，兩者已經不一致了。
這種場景的解決方案是在線程A更新完數據庫的值后，可以讓它sleep一小段時間，再進行一次緩存刪除操作，之所以要加上sleep的一段時間，就是為了讓線程B能夠先從數據庫讀取出數據然后再把緩存miss的數據回塞到緩存，然后線程A再進行刪除。所以線程A的sleep時間就需要大于線程B讀取數據再寫入緩存的時間。這個時間是多少呢？這個是需要我們在業務中加入打點監控來統計的，根據這個統計值來估算該時間。這樣一來，其他線程讀取數據時，會發現緩存缺失，就會從數據庫中讀取最新的值。我們把這種模型叫做 "延時雙刪"。
先更新數據庫再刪除緩存
如果線程A更新了數據庫中的值，但還沒來得及刪除緩存中的值，線程B這時候開始讀取數據，此時，線程B查詢緩存時，命中了緩存數據庫一致性錯誤修復，就會直接使用緩存中的值，該值為舊值。不過在這種場景下，如果并發請求量不高的話，其實基本上不會有線程讀到舊值，而且線程A更新完數據庫后，刪除緩存是非常快的操作，所以，這種情況總體對業務影響較小。一般在生產環境中，也推薦大家采用該模式。
重試機制
可以把要刪除的緩存值或者要更新的數據庫的值放到消息隊列中，當應用沒能夠成功地刪除緩存或者是更新數據庫的值的時候，可以從消息隊列中消費這些值，這里消費消息隊列的服務叫job，然后再次進行刪除或者更新，起到一個兜底補償的作用，以此來保證最終的一致性。
如果能夠成功地刪除或更新，就需要把這些值從消息隊列中去除，以免重復操作，此時，我們也可以保證數據庫和緩存數據的一致了，否則的話，我們還需要再次進行重試，如果重試超過一定次數還是失敗，這時候一般都需要記錄錯誤日志或者發送告警通知。
并發讀寫
首先第一步線程A讀取緩存，這時候緩存沒有命中，由于使用的是cache aside這種模式，所以接下來第二步線程A會去讀數據庫，這個時候線程B更新數據庫，更新完數據庫后通過set cache更新了緩存，最后第五步線程A把從數據庫讀到的值通過set cache也更新了緩存，但是這時候線程A中的數據已經是臟數據了，由于第四步和第五步都是設置緩存數據庫一致性錯誤修復，導致寫入的值相互覆蓋，并且操作的順序具有不確定性，從而導致了緩存不一致情況的發生。
怎么解決這個問題呢？其實非常地簡單，我們只需要把第五步的set cache操作替換成add cache即可，add cache即setnx操作，只有緩存不存在的時候才會成功寫入，相當于加了優先級，即更新數據庫后的更新緩存優先級更高，而讀數據庫后回塞緩存的優先級較低，從而保證寫操作的最新數據不會被讀操作的回塞數據覆蓋。
結束語
本篇文章說明了在使用緩存時最常遇見的一個問題，也就是緩存和數據庫不一致的問題，針對這個問題我們列舉了一些可能導致不一致的場景以及對應場景的解決方案，特別地，對于job異步補償的場景我們可以使用set操作來強行覆蓋緩存，保證緩存的更新為最新的數據，而對于讀數據庫回塞緩存的操作我們一般使用add來更新緩存。
希望本篇文章對你有所幫助，謝謝。
每周一、周四更新
代碼倉庫:
項目地址
歡迎使用 go-zero 并 star 支持我們！
微信交流群