緩存系列：緩存一致性問題的解決思路
大家好，我是李哥。
上次我們討論了在分布式系統(tǒng)下的緩存架構體系，從瀏覽器緩存到客戶端緩存，再到CDN緩存，再到反向代理緩存，再到本地緩存，再到分布式緩存。整個鏈路中有非常多的緩存。
在整個緩存鏈路，存在各種各樣的問題，常見的問題有緩存穿透、緩存擊穿、緩存雪崩、緩存數(shù)據(jù)一致性問題等。不常見的問題有緩存傾斜、緩存阻塞、緩存慢查詢、緩存主從一致性問題、緩存高可用、緩存故障發(fā)現(xiàn)與故障恢復、集群擴容收縮、大Key熱Key等等。
今天我們來聊聊緩存一致性問題，對于這個問題，不管在工作中還是面試中，都是一個非常常見的問題。
今天我們的主題是： 緩存一致性問題
老規(guī)矩，上大綱：
1、緩存一致性問題是什么
我們知道，緩存的工作原理是先從緩存中獲取數(shù)據(jù)，如果有數(shù)據(jù)則直接返回給用戶，如果沒有數(shù)據(jù)則從慢速設備上讀取實際數(shù)據(jù)并且將數(shù)據(jù)放入緩存。就像這樣：
但是，這樣的架構是存在問題的， 因為數(shù)據(jù)庫與緩存是不同的組件，操作必須有先后順序，無法像數(shù)據(jù)庫的事務一樣滿足ACID的特性，所以就會出現(xiàn)數(shù)據(jù)在緩存中與在數(shù)據(jù)庫中不一致的問題 。
緩存一致性問題的表現(xiàn)：同一份數(shù)據(jù)，緩存中的數(shù)據(jù)與數(shù)據(jù)庫中的數(shù)據(jù)不一致，那么上升到業(yè)務層面就有著千奇百怪的現(xiàn)象了，比如每次讀都是讀的老數(shù)據(jù)，或者每次讀是一份過時的數(shù)據(jù)等。
2、解決方案
對于寫入操作：
- 只寫DB，不寫Cache，依賴下次查詢
- 先寫DB，（同步/異步）再寫Cache
- 先寫Cache，再寫DB
對于更新操作：
- 先更新DB，再刪除Cache
- 先刪除Cache，再更新DB
- 先刪除Cache，再更新DB，再刪除Cache
2.1、只寫DB，不寫Cache，依賴下次查詢
這種是我們常見的設計方案，這種方案只寫數(shù)據(jù)庫不寫緩存，依賴下一次請求從數(shù)據(jù)庫取出數(shù)據(jù)再放入緩存。細心的讀者已經(jīng)發(fā)現(xiàn)了，這種設計有可能引發(fā)新的問題：緩存擊穿（復習緩存擊穿：DB有數(shù)據(jù)，Cache無數(shù)據(jù)，瞬間流量將DB擊穿）。
這種可能性是存在的，但是可能性比較小，因為緩存擊穿的前提條件是大量請求透過緩存打入數(shù)據(jù)庫層，但是因為我們討論本次小標題的前提條件是新寫入，一般不會有很大的瞬間流量進來。就算有，那也不屬于本文緩存一致性問題的討論范圍了。
2.2、先寫數(shù)據(jù)庫，再寫緩存
這種也是我們常見的設計方案，先寫數(shù)據(jù)庫，再寫緩存，上面的圖也有體現(xiàn)這一點。
所以在這種場景下，線程1再去讀數(shù)據(jù)的時候，讀數(shù)據(jù)則優(yōu)先走緩存，緩存此時值為1，所以讀到的值是1，此時線程1懵逼了啊......我剛才不是更新成2了嗎？
大家還記得之前的一篇文章《 緩存系列：緩存擊穿的解決思路 》，在面臨緩存穿透的時候，我們其中一個解決方案是：查詢數(shù)據(jù)庫如果沒有數(shù)據(jù)，則約定一個空數(shù)據(jù)格式放入緩存中，當再次查詢的時候，先查詢緩存，發(fā)現(xiàn)是一個空數(shù)據(jù)格式，則直接返回空，避免數(shù)據(jù)庫被瞬間流量擊垮。在這個方案下，還有第二個步驟，當數(shù)據(jù)保存后，需要主動將數(shù)據(jù)放入緩存，以便下次能夠查詢。
所以如果你的系統(tǒng)中如果有做緩存穿透的防護，有可能你寫完數(shù)據(jù)庫后還需要記得寫緩存。
2.3、先寫緩存，再寫數(shù)據(jù)庫
顧名思義，就是一個寫操作，先寫緩存，成功后，再寫數(shù)據(jù)庫。
那么，如果寫數(shù)據(jù)庫失敗呢？
如果寫失敗了，在下次讀的時候那么就會讀取到臟數(shù)據(jù)的情況。
如果寫數(shù)據(jù)庫失敗，有兩種方案
- 刪除緩存
- 異步任務繼續(xù)寫數(shù)據(jù)庫
這兩個方案都有問題！
下面我們挨個分析。
刪除緩存。如果刪除緩存失敗呢？再用異步任務重試刪除？那你是否有考慮重試的時候這種短暫不一致的情況？還是說接受這種數(shù)據(jù)不一致的情況？系統(tǒng)復雜度被你提高了多少？
異步任務繼續(xù)寫數(shù)據(jù)庫。異步任務如果寫失敗呢？重試？重試也一直失敗呢？重試任務落庫+定時任務兜底？可以，那么，短暫的數(shù)據(jù)不一致是否接受？系統(tǒng)復雜度被你提高了多少？
所以，這種先寫緩存再寫數(shù)據(jù)庫的方案一般不會正式使用，一旦出問題，很難保證數(shù)據(jù)的最終一致性。
接下來我們討論一下更新數(shù)據(jù)的情況。
2.4、先更新數(shù)據(jù)庫，再刪除緩存
這種情況下，你可能想說這是你們現(xiàn)在正在使用的技術方案，但是我想說是這個方案是存在問題的，別慌反駁，大家看看這張圖：
首先，這種技術方案，確實是我們在日常開發(fā)中是最常見的，但是作為開發(fā)的我們，也應該明白它存在什么問題，以及能夠有哪些應對措施，下面談談我個人對這個解決方案的一些改進。
- 延遲刪除緩存。
- 先刪除緩存，再更新數(shù)據(jù)庫。
- 延遲雙刪策略。
- 定時任務增量/全量更新緩存數(shù)據(jù)。
- 監(jiān)聽數(shù)據(jù)庫binlog增量數(shù)據(jù)更新緩存。
方案一：延遲刪除緩存。這種改進方案的優(yōu)點是能有效的防止數(shù)據(jù)不一致，但不能夠完全防止。為什么說不能夠完全防止呢？因為查詢數(shù)據(jù)的那個線程有可能也延遲了一定時間才去更新緩存。這個改進方案的缺點是無法嚴格的控制時間，這個時間需要開發(fā)人員根據(jù)經(jīng)驗給出，第二個缺點是延遲行為有可能讓系統(tǒng)引入一些新的依賴，你可能想說是否可以用jdk自帶的延遲隊列呢？可以，但是如果延遲期間，服務重啟了，怎么處理？第三個缺點是可能導致系統(tǒng)的復雜度提高、維護成本提高、可讀性降低。
方案二：先刪除緩存，再更新數(shù)據(jù)庫。這個方案我們下面單獨細說，這里咱不介紹。
方案三：延遲雙刪策略。這個方案我們下面單獨細說，這里咱不介紹。
方案四：定時任務增量/全量更新緩存數(shù)據(jù)。這種解題方式是最直接最暴力的，它的優(yōu)點是能夠保證數(shù)據(jù)的最終一致性。它的缺點有：可能需要引入分布式調(diào)度任務（如果不引入則又存在多實例同時更新的情況，純屬浪費資源，或者加分布式鎖）、如果是增量同步的話則需要有一種方式方法區(qū)分出什么數(shù)據(jù)才是增量數(shù)據(jù)，這種方式可能有業(yè)務侵入和性能影響、如果是全量同步的話數(shù)據(jù)量太多又太耗時，嚴重的話可能導致任務阻塞以及加重數(shù)據(jù)不一致的問題。經(jīng)過分析，優(yōu)點很明顯，一般情況下，異步主動的對緩存數(shù)據(jù)更新是一種不可采取的方式。但是也會有一些業(yè)務場景，數(shù)據(jù)變更不太頻繁，但是訪問非常頻繁，并且更新數(shù)據(jù)更新時間已經(jīng)同步更新緩存了，再使用這種異步將DB數(shù)據(jù)載入緩存作為兜底的策略是可行的。
方案五：監(jiān)聽數(shù)據(jù)庫binlog增量數(shù)據(jù)更新緩存。
這種方式讓開發(fā)不再關注緩存層，專注于業(yè)務開發(fā)，只關注于數(shù)據(jù)庫，而不用關心緩存。
可以看到這種方案對研發(fā)人員來說比較輕量，不用關心緩存層面，而且這個方案雖然比較重，但是卻容易形成統(tǒng)一的解決方案。
2.5、先刪除緩存，再更新數(shù)據(jù)庫
這種方式也比較容易理解，先刪除緩存數(shù)據(jù)，再更新DB的數(shù)據(jù)，如果刪除緩存失敗了，直接返回失??；如果更新DB失敗了，影響的也只是刪除緩存而已，下次查詢的時候重新種一次即可。
那如果，會不會因為刪除了緩存的數(shù)據(jù)，從而導致DB被擊穿呢？這種可能性是存在的，但是可能性比較小。
再說了，這種方案真的可以解決問題嗎？如果在刪除緩存后，馬上有新線程查詢緩存，新線程發(fā)現(xiàn)緩存不存在（剛被刪），新線程查詢數(shù)據(jù)庫后將數(shù)據(jù)放于緩存，老線程刪除數(shù)據(jù)庫成功。此時數(shù)據(jù)庫無數(shù)據(jù)，緩存有數(shù)據(jù)。
2.6、先刪除緩存，再更新數(shù)據(jù)庫，再刪除緩存
基于2.5，在這個基礎上可以做出一些改進，那就是延遲雙刪。
延遲雙刪的流程：刪除緩存->刪除DB->延遲一段時間再刪除緩存。
延遲雙刪能解決大部分的問題，但是在極端情況下，還是會出現(xiàn)問題，造成數(shù)據(jù)不一致。
這里存在一個問題，延遲一段時間，是延遲多久？1s？3s？這是一個經(jīng)驗值，一般情況是1s~2s。具體取值根據(jù)監(jiān)控實際情況而定。那既然是估計值，那么就一定存在誤差，所以必然極端情況下的數(shù)據(jù)不一致問題。
解決這個問題的方法之前也說了，監(jiān)聽數(shù)據(jù)庫binlog增量數(shù)據(jù)更新緩存，或者還可以使用異步消息等。
3、總結
在實際的工作中，或者在面試中，如果有人問你各種沒有場景化的純粹的技術問題，比如說有人看了上面的種種方案還是會提出疑問，你的這些方案仍然存在數(shù)據(jù)不一致的問題啊，那怎么解決呢？
技術是為了業(yè)務服務的，所以，在所有不同的業(yè)務場景下，對于技術的選擇，和方案的設計都是不同的。我們需要反問他，具體的業(yè)務場景是什么？我們需要根據(jù)具體的業(yè)務場景來選擇最合適的技術方案。
我們要明確的是：一個技術方案不可能cover住所有的場景，脫離業(yè)務的技術都是刷流氓。
