日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時(shí)間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷解決方案
如何保證緩存和數(shù)據(jù)庫的一致性？

很多小伙伴在面試的時(shí)候，應(yīng)該都遇到過類似的問題，如何確保緩存和數(shù)據(jù)庫的一致性?

10年積累的成都做網(wǎng)站、網(wǎng)站設(shè)計(jì)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程，更有東港免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

如果你對(duì)這個(gè)問題有過研究，應(yīng)該可以發(fā)現(xiàn)這個(gè)問題其實(shí)很好回答，如果第一次聽到或者第一次遇到這個(gè)問題，估計(jì)會(huì)有點(diǎn)懵，今天我們來聊聊這個(gè)話題。

1. 問題分析

首先我們來看看為什么會(huì)有這個(gè)問題!

我們?cè)谌粘ｉ_發(fā)中，為了提高數(shù)據(jù)響應(yīng)速度，可能會(huì)將一些熱點(diǎn)數(shù)據(jù)保存在緩存中，這樣就不用每次都去數(shù)據(jù)庫中查詢了，可以有效提高服務(wù)端的響應(yīng)速度，那么目前我們最常使用的緩存就是 Redis 了。

用 Redis 做緩存，并不是一說緩存就是 Redis，還是要結(jié)合業(yè)務(wù)的具體情況，我們可以根據(jù)不同業(yè)務(wù)對(duì)數(shù)據(jù)要求的實(shí)時(shí)性不同，將數(shù)據(jù)分為三級(jí)，以電商項(xiàng)目為例：

  • 第 1 級(jí)：訂單數(shù)據(jù)和支付流水?dāng)?shù)據(jù)：這兩塊數(shù)據(jù)對(duì)實(shí)時(shí)性和精確性要求很高，所以一般是不需要添加緩存的，直接操作數(shù)據(jù)庫即可。
  • 第 2 級(jí)：用戶相關(guān)數(shù)據(jù)：這些數(shù)據(jù)和用戶相關(guān)，具有讀多寫少的特征，所以我們使用 redis 進(jìn)行緩存。
  • 第 3 級(jí)：支付配置信息：這些數(shù)據(jù)和用戶無關(guān)，具有數(shù)據(jù)量小，頻繁讀，幾乎不修改的特征，所以我們使用本地內(nèi)存進(jìn)行緩存。

選中合適的數(shù)據(jù)存入 Redis 之后，接下來，每當(dāng)要讀取數(shù)據(jù)的時(shí)候，就先去 Redis 中看看有沒有，如果有就直接返回;如果沒有，則去數(shù)據(jù)庫中讀取，并且將從數(shù)據(jù)庫中讀取到的數(shù)據(jù)緩存到 Redis 中，大致上就是這樣一個(gè)流程，讀取數(shù)據(jù)的這個(gè)流程實(shí)際上是比較清晰也比較簡(jiǎn)單的，沒啥好說的。

然而，當(dāng)數(shù)據(jù)存入緩存之后，如果需要更新的話，往往會(huì)來帶另外的問題：

  • 當(dāng)有數(shù)據(jù)需要更新的時(shí)候，先更新緩存還是先更新數(shù)據(jù)庫?如何確保更新緩存和更新數(shù)據(jù)庫這兩個(gè)操作的原子性?
  • 更新緩存的時(shí)候該怎么更新?修改還是刪除?

怎么辦?正常來說，我們有四種方案：

  • 先更新緩存，再更新數(shù)據(jù)庫。
  • 先更新數(shù)據(jù)庫，再更新緩存。
  • 先淘汰緩存，再更新數(shù)據(jù)庫。
  • 先更新數(shù)據(jù)庫，再淘汰緩存。

到底使用哪種?

在回答這個(gè)問題之前，我們不妨先來看看三個(gè)經(jīng)典的緩存模式：

  • Cache-Aside
  • Read-Through/Write through
  • Write Behind

2. Cache-Aside

Cache-Aside，中文也叫旁路緩存模式，如果我們能夠在項(xiàng)目中采用 Cache-Aside，那么就能夠盡可能的解決緩存與數(shù)據(jù)庫數(shù)據(jù)不一致的問題，注意是盡可能的解決，并無法做到絕對(duì)解決。

Cache-Aside 又分為讀緩存和寫緩存兩種情況，我們分別來看。

2.1 讀緩存

先來看一張流程圖：

它的流程是這樣：

  • 讀取數(shù)據(jù)。
  • 檢查緩存中是否有需要的數(shù)據(jù)，如果命中緩存(Cache Hit)，則直接返回?cái)?shù)據(jù)。
  • 如果沒有命中緩存，即 Cache Miss，那么就先去訪問數(shù)據(jù)庫。
  • 將從數(shù)據(jù)庫中讀取到的數(shù)據(jù)設(shè)置到緩存中。
  • 返回?cái)?shù)據(jù)。

這是 Cache-Aside 的讀緩存流程。

其實(shí)對(duì)于讀緩存的流程而言，大家一般都沒什么異議，有異議的主要是寫流程，我們繼續(xù)來看。

2.2 寫緩存

先來看一張流程圖：

這個(gè)寫緩存的流程就比較簡(jiǎn)單，先更新數(shù)據(jù)庫中的數(shù)據(jù)，然后刪除舊的緩存即可。

流程雖然簡(jiǎn)單，但是卻引伸出來兩個(gè)問題：

  • 為什么是刪除舊緩存而不是更新舊緩存?
  • 為什么不先刪除舊的緩存，然后再更新數(shù)據(jù)庫?

我們來分別回答這兩個(gè)問題。

為什么是刪除舊緩存而不是更新舊緩存?

  • 更新緩存，說著容易做起來并不容易。很多時(shí)候我們更新緩存并不是簡(jiǎn)簡(jiǎn)單單更新一個(gè) Bean。很多時(shí)候，我們緩存的都是一些復(fù)雜操作或者計(jì)算(例如大量聯(lián)表操作、一些分組計(jì)算)的結(jié)果，如果不加緩存，不但無法滿足高并發(fā)量，同時(shí)也會(huì)給 MySQL 數(shù)據(jù)庫帶來巨大的負(fù)擔(dān)。那么對(duì)于這樣的緩存，更新起來實(shí)際上并不容易，此時(shí)選擇刪除緩存效果會(huì)更好一些。
  • 對(duì)于一些寫頻繁的應(yīng)用，如果按照更新緩存->更新數(shù)據(jù)庫的模式來，比較浪費(fèi)性能，因?yàn)槭紫葘懢彺婧苈闊?，其次每次都要寫緩存，但是可能寫了十次，只讀了一次，讀的時(shí)候讀到的緩存數(shù)據(jù)是第十次的，前面九次寫緩存都是無效的，對(duì)于這種情況不如采取先寫數(shù)據(jù)庫再刪除緩存的策略。
  • 在多線程環(huán)境下，這樣的更新策略還有可能會(huì)導(dǎo)致數(shù)據(jù)邏輯錯(cuò)誤，來看如下一張流程圖：

可以看到，有兩個(gè)并發(fā)的線程 A 和 B：

  • 首先 A 線程更新了數(shù)據(jù)庫。
  • 接下來 B 線程更新了數(shù)據(jù)庫。
  • 由于網(wǎng)絡(luò)等原因，B 線程先更新了緩存。
  • A 線程更新了緩存。

那么此時(shí)，緩存中保存的數(shù)據(jù)就是不正確的，而如果采用了刪除緩存的方式，就不會(huì)發(fā)生這種問題了。

為什么不先刪除舊的緩存，然后再更新數(shù)據(jù)庫?

這個(gè)也是考慮到并發(fā)請(qǐng)求，假設(shè)我們先刪除舊的緩存，然后再更新數(shù)據(jù)庫，那么就有可能出現(xiàn)如下這種情況：

這個(gè)操作是這樣的，有兩個(gè)線程，A 和 B，其中 A 寫數(shù)據(jù)，B 讀數(shù)據(jù)，具體流程如下：

  1. A 線程首先刪除緩存。
  2. B 線程讀取緩存，發(fā)現(xiàn)緩存中沒有數(shù)據(jù)。
  3. B 線程讀取數(shù)據(jù)庫。
  4. B 線程將從數(shù)據(jù)庫中讀取到的數(shù)據(jù)寫入緩存。
  5. A 線程更新數(shù)據(jù)庫。

一套操作下來，我們發(fā)現(xiàn)數(shù)據(jù)庫和緩存中的數(shù)據(jù)不一致了!所以，在 Cache-Aside 中是先更新數(shù)據(jù)庫，再刪除緩存。

2.3 延遲雙刪

其實(shí)無論是先更新數(shù)據(jù)庫再刪除緩存，還是先刪除緩存再更新數(shù)據(jù)庫，在并發(fā)環(huán)境下都有可能存在問題：

假設(shè)有 A、B 兩個(gè)并發(fā)請(qǐng)求：

  • 先更新數(shù)據(jù)庫再刪除緩存：當(dāng)請(qǐng)求 A 更新數(shù)據(jù)庫之后，還未來得及進(jìn)行緩存清除，此時(shí)請(qǐng)求 B 查詢到并使用了 Cache 中的舊數(shù)據(jù)。
  • 先刪除緩存再更新數(shù)據(jù)庫：當(dāng)請(qǐng)求 A 執(zhí)行清除緩存后，還未進(jìn)行數(shù)據(jù)庫更新，此時(shí)請(qǐng)求 B 進(jìn)行查詢，查到了舊數(shù)據(jù)并寫入了 Cache。

當(dāng)然我們前面已經(jīng)分析過了，盡量先操作數(shù)據(jù)庫再操作緩存，但是即使這樣也還是有可能存在問題，解決問題的辦法就是延遲雙刪。

延遲雙刪是這樣：先執(zhí)行緩存清除操作，再執(zhí)行數(shù)據(jù)庫更新操作，延遲 N 秒之后再執(zhí)行一次緩存清除操作，這樣就不用擔(dān)心緩存中的數(shù)據(jù)和數(shù)據(jù)庫中的數(shù)據(jù)不一致了。

那么這個(gè)延遲 N 秒，N 是多大比較合適呢?一般來說，N 要大于一次寫操作的時(shí)間，如果延遲時(shí)間小于寫入緩存的時(shí)間，會(huì)導(dǎo)致請(qǐng)求 A 已經(jīng)延遲清除了緩存，但是此時(shí)請(qǐng)求 B 緩存還未寫入，具體是多少，就要結(jié)合自己的業(yè)務(wù)來統(tǒng)計(jì)這個(gè)數(shù)值了。

2.4 如何確保原子性

但是更新數(shù)據(jù)庫和刪除緩存畢竟不是一個(gè)原子操作，要是數(shù)據(jù)庫更新完畢后，刪除緩存失敗了咋辦?

對(duì)于這種情況，一種常見的解決方案就是使用消息中間件來實(shí)現(xiàn)刪除的重試。大家知道，MQ 一般都自帶消費(fèi)失敗重試的機(jī)制，當(dāng)我們要?jiǎng)h除緩存的時(shí)候，就往 MQ 中扔一條消息，緩存服務(wù)讀取該消息并嘗試刪除緩存，刪除失敗了就會(huì)自動(dòng)重試。如果小伙伴們還不懂 RabbitMQ 的使用，可以在公眾號(hào)江南一點(diǎn)雨后臺(tái)回復(fù) rabbitmq，有免費(fèi)的視頻+文檔。

3. Read-Through/Write-Through

這種緩存操作模式，松哥印象最深的是在 Oracle Coherence 中有應(yīng)用，不知道小伙伴們有沒有用過 Oracle Coherence，這是一個(gè)內(nèi)存數(shù)據(jù)網(wǎng)格，通過這個(gè)，應(yīng)用開發(fā)人員和管理人員可快速訪問鍵值數(shù)據(jù)，Coherence 可提供集群式低延遲數(shù)據(jù)存儲(chǔ)、多語言網(wǎng)格計(jì)算和異步事件流處理，從而為客戶企業(yè)應(yīng)用賦予超高水平的可擴(kuò)展性和性能。

Oracle Coherence 我們就不討論了，我們就來說說 Read-Through。

3.1 Read-Through

這里為了省事，我就不自己畫圖了，網(wǎng)上找了一張圖片，如下：

乍一看，很多人感覺這和 Cache-Aside 一樣呀，沒啥區(qū)別!是的，單看流程是不太容易看到區(qū)別。

Read-Through 是一種類似于 Cache-Aside 的緩存方法，區(qū)別在于，在 Cache-Aside 中，由應(yīng)用程序決定去讀取緩存還是讀取數(shù)據(jù)庫，這樣就會(huì)導(dǎo)致應(yīng)用程序中出現(xiàn)了很多業(yè)務(wù)無關(guān)的代碼;而在 Read-Through 中，相當(dāng)于多出來了一個(gè)中間層 Cache Middleware，由它去讀取緩存或者數(shù)據(jù)庫，應(yīng)用層的代碼得到了簡(jiǎn)化，松哥之前寫過 Spring Cache 的用法，大家回憶下 Spring Cache 中的 @Cacheable 注解，感覺像不像 Read-Through?

我畫一個(gè)簡(jiǎn)單的流程圖大家來看下：

可以看到，和 Cache-Aside 相比，其實(shí)就相當(dāng)于是多了一個(gè) Cache Middleware，這樣我們?cè)趹?yīng)用程序中就只需要正常的讀寫數(shù)據(jù)就行了，并不用管底層的具體邏輯，相當(dāng)于把緩存相關(guān)的代碼從應(yīng)用程序中剝離出來了，應(yīng)用程序只需要專注于業(yè)務(wù)就行了。

3.2 Write-Through

Write-Through 其實(shí)也是差不多，所有的操作都交給 Cache Middleware 來完成，應(yīng)用程序中就是一句簡(jiǎn)單的更新就行了，我們來看看流程：

在 Write-Through 策略中，所有的寫操作都經(jīng)過 Cache Middleware，每次寫入時(shí)，Cache Middleware 會(huì)將數(shù)據(jù)存儲(chǔ)在 DB 和 Cache 中，這兩個(gè)操作發(fā)生在一個(gè)事務(wù)中，因此，只有兩個(gè)都寫入成功，一切才會(huì)成功。

這種寫數(shù)據(jù)的優(yōu)勢(shì)在于，應(yīng)用程序只與 Cache Middleware 對(duì)話，所以它的代碼更加干凈和簡(jiǎn)單。

4. Write Behind

Write-Behind 緩存策略類似于 Write-Through 緩存，應(yīng)用程序僅與 Cache Middleware 通信，Cache Middleware 會(huì)預(yù)留一個(gè)與應(yīng)用程序通信的接口。

Write-Behind 與 Write-Through 最大的區(qū)別在于，前者是數(shù)據(jù)首先寫入緩存，一段時(shí)間后(或通過其他觸發(fā)器)再將數(shù)據(jù)寫入 Database，并且這里涉及到的寫入是一個(gè)異步操作。這種方式下，Cache 和 DB 數(shù)據(jù)的一致性不強(qiáng)，對(duì)一致性要求高的系統(tǒng)要謹(jǐn)慎使用，如果有人在數(shù)據(jù)尚未寫入數(shù)據(jù)源的情況下直接從數(shù)據(jù)源獲取數(shù)據(jù)，則可能導(dǎo)致獲取過期數(shù)據(jù)，不過對(duì)于頻繁寫入的場(chǎng)景，這個(gè)其實(shí)非常適用。

將數(shù)據(jù)寫入 DB 可以通過多種方式完成：

  • 一種是收集所有寫入操作，然后在某個(gè)時(shí)間點(diǎn)(例如，當(dāng) DB 負(fù)載較低時(shí))對(duì)數(shù)據(jù)源進(jìn)行批量寫入。
  • 另一種方法是將寫入合并成更小的批次，例如每次收集五個(gè)寫入操作，然后對(duì)數(shù)據(jù)源進(jìn)行批量寫入。

這個(gè)流程圖就不想畫了，在網(wǎng)上找了一張，小伙伴們參考下：

參考資料：

https://www.jianshu.com/p/a8eb1412471f

https://catsincode.com/caching-strategy/


本文題目：如何保證緩存和數(shù)據(jù)庫的一致性？
網(wǎng)頁地址：http://www.5511xx.com/article/dpicdpo.html