????????緩存可以提升性能，減輕數(shù)據(jù)庫壓力，在獲取這部分好處的同時，它卻帶來了一些新的問題，緩存和數(shù)據(jù)庫之間的數(shù)據(jù)一致性問題。

想必大家在工作中只要用了咱們緩存勢必就會遇到過此類問題

首先我們來看看一致性：

• 強一致性：任何一次讀都能讀到某個數(shù)據(jù)的最近一次寫的數(shù)據(jù)。
• 弱一致性：數(shù)據(jù)更新后，如果能容忍后續(xù)的訪問只能訪問到部分或者全部訪問不到，則是弱一致性。

1.讀取數(shù)據(jù)

1. 當(dāng)應(yīng)用程序需要從數(shù)據(jù)庫讀取數(shù)據(jù)時，先檢查緩存數(shù)據(jù)是否命中。
2. 如果緩存未命中，則查詢數(shù)據(jù)庫獲取數(shù)據(jù)，同時將數(shù)據(jù)寫到緩存中，以便后續(xù)讀取相同數(shù)據(jù)會命中緩存，最后再把數(shù)據(jù)返回給調(diào)用者。
3. 如果緩存命中，直接返回。

????????單獨的只讀取數(shù)據(jù)場景是不會出現(xiàn)不一致。 只有讀和寫一起才會出現(xiàn) ， 那我們再來說下寫數(shù)據(jù)的場景

問題：如果數(shù)據(jù)庫中的某條數(shù)據(jù)放入緩存后，又馬上被更新了，那我們應(yīng)該如何更新緩存

2.寫數(shù)據(jù)

當(dāng)我們對數(shù)據(jù)進行修改的時候，到底是先刪緩存，還是先寫數(shù)據(jù)庫？

• 先更新緩存再更新數(shù)據(jù)庫
• 先刪除緩存再更新數(shù)據(jù)庫
• 先更新數(shù)據(jù)庫再更新緩存
• 先更新數(shù)據(jù)庫再刪除緩存

無非就是緩存用更新或用刪除？推薦直接刪除

????????為什么不更新？而直接刪， 因為緩存的更新成本更高（因為你寫入數(shù)據(jù)庫的值，很多情況并不是直接寫入緩存的，而是要經(jīng)過一系列復(fù)雜的計算再寫入緩存。那么，每次寫入數(shù)據(jù)庫后，都再次計算寫入緩存的值，無疑是浪費性能的。顯然，刪除緩存更為適合。）刪除緩存操作簡單，副作用只是增加了一次 chache miss，建議大家使用該策略。

先操作數(shù)據(jù)庫還是先操作緩存？

2.先操作緩存

2.1先更新緩存，再更新數(shù)據(jù)庫

缺點：如果先更新緩存成功，在更新數(shù)據(jù)庫的時候失敗，這時候會導(dǎo)致數(shù)據(jù)不一致；緩存的作用是不是臨時將我們數(shù)據(jù)保存在內(nèi)存，便于提高查詢速度；但是如果某條數(shù)據(jù)在數(shù)據(jù)庫中都不存在，緩存這種數(shù)據(jù)沒有一點意義

2.2.先刪除緩存，再更新數(shù)據(jù)庫

缺點：高并發(fā)場景下，如果多個線程同時執(zhí)行更新數(shù)據(jù)庫再寫緩存操作可能會出現(xiàn)數(shù)據(jù)庫是新值，而緩存中是舊值

2.3.先刪緩存再刪數(shù)據(jù)庫?

????????先刪緩存再刪數(shù)據(jù)庫：在多線程環(huán)境下，當(dāng)一個線程把緩存刪掉之后，另一個線程讀緩存，讀不到緩存就會直接讀庫，讀到數(shù)據(jù)后就會更新緩存，先前的線程呢，才更新數(shù)據(jù)庫，會造成緩存臟讀的情況，很容易產(chǎn)生緩存臟讀。

而且，如果不采用給緩存設(shè)置過期時間策略，該數(shù)據(jù)永遠(yuǎn)都是臟數(shù)據(jù)。

3.先操作數(shù)據(jù)庫

3.1.先更新數(shù)據(jù)庫，再更新緩存

優(yōu)點：可以解決先更新緩存，再更新數(shù)據(jù)庫帶來的假數(shù)據(jù)問題

缺點：高并發(fā)場景下，如果多個線程同時執(zhí)行更新數(shù)據(jù)庫再寫緩存操作可能會出現(xiàn)數(shù)據(jù)庫是新值，而緩存中是舊值

3.2.先更新數(shù)據(jù)庫，再刪除緩存

????????在高可用的系統(tǒng)系統(tǒng)里面，我們追求數(shù)據(jù)最終一致性的話，我們可以考慮先更新數(shù)據(jù)庫，再去刪除緩存

? ? ? ? 也算是常用的方案，這里介紹一下，這個叫 Cache Aside Pattern。如果先更新數(shù)據(jù)庫，再刪除緩存，那么就會出現(xiàn)更新數(shù)據(jù)庫之前有瞬間數(shù)據(jù)不是很及時。

????????同時，如果在更新之前，緩存剛好失效了，讀客戶端有可能讀到舊值，然后在寫客戶端刪除結(jié)束后再次設(shè)置了舊值，非常巧合的情況。

????????有 2 個前提條件：緩存在寫之前的時候失效，同時，在寫客戶度刪除操作結(jié)束后，放置舊數(shù)據(jù) — 也就是讀比寫慢。設(shè)置有的寫操作還會鎖表。

這個很難出現(xiàn)，但是如果出現(xiàn)了怎么辦？使用雙刪！！！

3.3先刪數(shù)據(jù)庫再刪緩存?

先刪數(shù)據(jù)庫再刪緩存，在多線程情況下，當(dāng)一個線程刪除數(shù)據(jù)庫，另一個線程讀取緩存數(shù)據(jù)，讀到的是緩存的數(shù)據(jù)，當(dāng)先前一個線程刪完數(shù)據(jù)庫后就會更新緩存，這是緩存就正常了，產(chǎn)生了一次臟讀。?

5.解決

5.1.強一致性？

在強一致性系統(tǒng)中，通過2PC、Paxos或分布式鎖保持一致性可能會成為影響系統(tǒng)吞吐量、響應(yīng)時間和可伸縮性的昂貴開銷， 因此通常采用一種相當(dāng)寬松的一致性方法，稱為最終一致性。

5.2.最終一致性：延時雙刪

關(guān)鍵：間隔一段時間再刪除是為了保證并發(fā)讀請求寫入的舊值最終能夠被第二次刪除刪除掉

缺點：延時雙刪可能對我們性能要求方面不能有太高的要求

注意：我們需要自行評估項目的讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時（即線程二從數(shù)據(jù)庫讀取數(shù)據(jù) 寫入緩存完成）， 防止線程二覆蓋掉新數(shù)據(jù)

如果第二次刪除緩存失敗怎么辦?

4.為了防止刪除緩存失敗，可以進行重試機制

• 同步重試，如果并發(fā)量高的時候可能會影響接口性能
• 異步重試：
  • 創(chuàng)建單獨的一個線程，進行重試；但是在高并發(fā)的場景下，可能會因為創(chuàng)建線程太多，導(dǎo)致OOM
  • 交給線程池處理；但是如果服務(wù)重啟，會導(dǎo)致數(shù)據(jù)丟失
  • 重試數(shù)據(jù)寫入表，通過定時任務(wù)重試（可以保證數(shù)據(jù)不丟失，但是對于實時性要求較高的該場景不太適用）
  • 利用MQ消息中間件進行重試，在消費者中處理

• 訂閱mysql的binlong，在訂閱者中，如果發(fā)現(xiàn)更新數(shù)據(jù)請求，則刪除響應(yīng)的緩存，比如使用canal中間件；為了保證刪除緩存成功，可以增加MQ

6.總結(jié)?

緩存策略的最佳實踐是 **Cache Aside Pattern。**分別分為讀緩存最佳實踐和寫緩存最佳實踐。

讀緩存最佳實踐：先讀緩存，命中則返回；未命中則查詢數(shù)據(jù)庫，再寫到數(shù)據(jù)庫。

寫緩存最佳實踐：

• 先寫數(shù)據(jù)庫，再操作緩存；
• 直接刪除緩存，而不是修改，因為緩存的更新成本很高，刪除緩存操作簡單，副作用只是增加了一次 chache miss，建議大家使用該策略。

在以上最佳實踐下，為了盡可能保證緩存與數(shù)據(jù)庫的一致性，我們可以采用延遲雙刪。

防止刪除失敗，我們采用異步重試機制保證能正確刪除，異步機制我們可以發(fā)送刪除消息到 mq 消息中間件，或者利用 canal 訂閱 MySQL binlog 日志監(jiān)聽寫請求刪除對應(yīng)緩存。

那么，如果我非要保證絕對一致性怎么辦，先給出結(jié)論：

沒有辦法做到絕對的一致性，這是由 CAP 理論決定的，緩存系統(tǒng)適用的場景就是非強一致性的場景，所以它屬于 CAP 中的 AP。

所以，我們得委曲求全，可以去做到 BASE 理論中說的最終一致性。

其實一旦在方案中使用了緩存，那往往也就意味著我們放棄了數(shù)據(jù)的強一致性，但這也意味著我們的系統(tǒng)在性能上能夠得到一些提升。