在高并發(fā)場景下，先更新緩存還是先更新數(shù)據(jù)庫

本篇內(nèi)容主要講解“在高并發(fā)場景下，先更新緩存還是先更新數(shù)據(jù)庫”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“在高并發(fā)場景下，先更新緩存還是先更新數(shù)據(jù)庫”吧!

在大型系統(tǒng)中，為了減少數(shù)據(jù)庫壓力通常會引入緩存機制，一旦引入緩存又很容易造成緩存和數(shù)據(jù)庫數(shù)據(jù)不一致，導致用戶看到的是舊數(shù)據(jù)。

為了減少數(shù)據(jù)不一致的情況，更新緩存和數(shù)據(jù)庫的機制顯得尤為重要，接下來帶領(lǐng)大家踩踩坑。

Cache aside

Cache aside也就是旁路緩存，是比較常用的緩存策略。

(1)讀請求常見流程

Cache aside 讀請求

應用首先會判斷緩存是否有該數(shù)據(jù)，緩存命中直接返回數(shù)據(jù)，緩存未命中即緩存穿透到數(shù)據(jù)庫，從數(shù)據(jù)庫查詢數(shù)據(jù)然后回寫到緩存中，最后返回數(shù)據(jù)給客戶端。

(2)寫請求常見流程

Cache aside 寫請求

首先更新數(shù)據(jù)庫，然后從緩存中刪除該數(shù)據(jù)。

看了寫請求的圖之后，有些同學可能要問了：為什么要刪除緩存，直接更新不就行了?這里涉及到幾個坑，我們一步一步踩下去。

Cache aside踩坑

Cache aside策略如果用錯就會遇到深坑，下面我們來逐個踩。

踩坑一：先更新數(shù)據(jù)庫，再更新緩存

如果同時有兩個寫請求需要更新數(shù)據(jù)，每個寫請求都先更新數(shù)據(jù)庫再更新緩存，在并發(fā)場景可能會出現(xiàn)數(shù)據(jù)不一致的情況。

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

如上圖的執(zhí)行過程：

(1)寫請求1更新數(shù)據(jù)庫，將 age 字段更新為18;

(2)寫請求2更新數(shù)據(jù)庫，將 age 字段更新為20;

(3)寫請求2更新緩存，緩存 age 設(shè)置為20;

(4)寫請求1更新緩存，緩存 age 設(shè)置為18;

執(zhí)行完預期結(jié)果是數(shù)據(jù)庫 age 為20，緩存 age 為20，結(jié)果緩存 age為18，這就造成了緩存數(shù)據(jù)不是最新的，出現(xiàn)了臟數(shù)據(jù)。

踩坑二：先刪緩存，再更新數(shù)據(jù)庫

如果寫請求的處理流程是先刪緩存再更新數(shù)據(jù)庫，在一個讀請求和一個寫請求并發(fā)場景下可能會出現(xiàn)數(shù)據(jù)不一致情況。

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

如上圖的執(zhí)行過程：

(1)寫請求刪除緩存數(shù)據(jù);

(2)讀請求查詢緩存未擊中(Hit Miss)，緊接著查詢數(shù)據(jù)庫，將返回的數(shù)據(jù)回寫到緩存中;

(3)寫請求更新數(shù)據(jù)庫。

整個流程下來發(fā)現(xiàn)數(shù)據(jù)庫中age為20，緩存中age為18，緩存和數(shù)據(jù)庫數(shù)據(jù)不一致，緩存出現(xiàn)了臟數(shù)據(jù)。

踩坑三：先更新數(shù)據(jù)庫，再刪除緩存

在實際的系統(tǒng)中針對寫請求還是推薦先更新數(shù)據(jù)庫再刪除緩存，但是在理論上還是存在問題，以下面這個例子說明。

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

如上圖的執(zhí)行過程：

(1)讀請求先查詢緩存，緩存未擊中，查詢數(shù)據(jù)庫返回數(shù)據(jù);

(2)寫請求更新數(shù)據(jù)庫，刪除緩存;

(3)讀請求回寫緩存;

整個流程操作下來發(fā)現(xiàn)數(shù)據(jù)庫age為20，緩存age為18，即數(shù)據(jù)庫與緩存不一致，導致應用程序從緩存中讀到的數(shù)據(jù)都為舊數(shù)據(jù)。

但我們仔細想一下，上述問題發(fā)生的概率其實非常低，因為通常數(shù)據(jù)庫更新操作比內(nèi)存操作耗時多出幾個數(shù)量級，上圖中最后一步回寫緩存(set age  18)速度非?？欤ǔ诟聰?shù)據(jù)庫之前完成。

如果這種極端場景出現(xiàn)了怎么辦?我們得想一個兜底的辦法：緩存數(shù)據(jù)設(shè)置過期時間。通常在系統(tǒng)中是可以允許少量的數(shù)據(jù)短時間不一致的場景出現(xiàn)。

Read through

在 Cache Aside 更新模式中，應用代碼需要維護兩個數(shù)據(jù)源頭：一個是緩存，一個是數(shù)據(jù)庫。而在 Read-Through  策略下，應用程序無需管理緩存和數(shù)據(jù)庫，只需要將數(shù)據(jù)庫的同步委托給緩存提供程序 Cache Provider 即可。所有數(shù)據(jù)交互都是通過抽象緩存層完成的。

Read-Through流程

如上圖，應用程序只需要與Cache Provider交互，不用關(guān)心是從緩存取還是數(shù)據(jù)庫。

在進行大量讀取時，Read-Through  可以減少數(shù)據(jù)源上的負載，也對緩存服務的故障具備一定的彈性。如果緩存服務掛了，則緩存提供程序仍然可以通過直接轉(zhuǎn)到數(shù)據(jù)源來進行操作。

Read-Through 適用于多次請求相同數(shù)據(jù)的場景，這與 Cache-Aside 策略非常相似，但是二者還是存在一些差別，這里再次強調(diào)一下：

• 在 Cache-Aside 中，應用程序負責從數(shù)據(jù)源中獲取數(shù)據(jù)并更新到緩存。

• 在 Read-Through 中，此邏輯通常是由獨立的緩存提供程序(Cache Provider)支持。

Write through

Write-Through 策略下，當發(fā)生數(shù)據(jù)更新(Write)時，緩存提供程序 Cache Provider 負責更新底層數(shù)據(jù)源和緩存。

緩存與數(shù)據(jù)源保持一致，并且寫入時始終通過抽象緩存層到達數(shù)據(jù)源。

Cache Provider類似一個代理的作用。

Write-Through流程

Write behind

Write behind在一些地方也被成為Write back， 簡單理解就是：應用程序更新數(shù)據(jù)時只更新緩存， Cache  Provider每隔一段時間將數(shù)據(jù)刷新到數(shù)據(jù)庫中。說白了就是延遲寫入。

Write behind流程

如上圖，應用程序更新兩個數(shù)據(jù)，Cache Provider 會立即寫入緩存中，但是隔一段時間才會批量寫入數(shù)據(jù)庫中。

這種方式有優(yōu)點也有缺點：

• 優(yōu)點是數(shù)據(jù)寫入速度非?？欤m用于頻繁寫的場景。

• 缺點是緩存和數(shù)據(jù)庫不是強一致性，對一致性要求高的系統(tǒng)慎用。

總結(jié)

學了這么多，相信大家對緩存更新的策略都已經(jīng)有了清晰的認識。最后稍稍總結(jié)一下。

緩存更新的策略主要分為三種：

• Cache aside

• Read/Write through

• Write behind

Cache aside 通常會先更新數(shù)據(jù)庫，然后再刪除緩存，為了兜底通常還會將數(shù)據(jù)設(shè)置緩存時間。

Read/Write through 一般是由一個 Cache Provider 對外提供讀寫操作，應用程序不用感知操作的是緩存還是數(shù)據(jù)庫。

Write behind簡單理解就是延遲寫入，Cache Provider 每隔一段時間會批量輸入數(shù)據(jù)庫，優(yōu)點是應用程序?qū)懭胨俣确浅？臁?/p>

到此，相信大家對“在高并發(fā)場景下，先更新緩存還是先更新數(shù)據(jù)庫”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學習！