目錄

1. 前言
2. 先更新數(shù)據(jù)庫，再更新緩存
3. 先更新緩存，再更新數(shù)據(jù)庫
4. 先刪除緩存，再更新數(shù)據(jù)庫
5. 先更新數(shù)據(jù)庫，再刪除緩存
6. 刪除緩存失敗，導(dǎo)致不一致
7. 讀寫分離，導(dǎo)致不一致

前言

在項目中緩存是經(jīng)常用到的，為了減少和數(shù)據(jù)庫的交互，小伙伴們利用緩存的思路如下：

成都創(chuàng)新互聯(lián)公司是一家專業(yè)從事做網(wǎng)站、網(wǎng)站設(shè)計、網(wǎng)頁設(shè)計的品牌網(wǎng)絡(luò)公司。如今是成都地區(qū)具影響力的網(wǎng)站設(shè)計公司,作為專業(yè)的成都網(wǎng)站建設(shè)公司,成都創(chuàng)新互聯(lián)公司依托強(qiáng)大的技術(shù)實力、以及多年的網(wǎng)站運(yùn)營經(jīng)驗,為您提供專業(yè)的成都網(wǎng)站建設(shè)、營銷型網(wǎng)站建設(shè)及網(wǎng)站設(shè)計開發(fā)服務(wù)！

緩存設(shè)計思路

我們小伙伴們有沒有考慮到緩存更新的問題，小伙伴們肯定會說肯定用過啊，有數(shù)據(jù)更新時，把緩存清空掉就行了啊，下一次訪問的時候服務(wù)就會把新值設(shè)置到緩存中了。這樣不就行了嗎？對的，在一般項目中，這樣的使用就夠了。那老顧帶著大家看看在高并發(fā)場景下，會有什么問題？

我們舉例說明，就拿商品的庫存作為緩存。那現(xiàn)在我們要更新緩存中的庫存值，怎么進(jìn)行操作，我們看下面幾個場景：

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

存在的問題場景：請求A更新值為99，請求B更新值為98

上圖流程：

1. 請求A先發(fā)起，更新數(shù)據(jù)庫為99，但還沒有來得及更新緩存
2. 請求B發(fā)起，更新數(shù)據(jù)庫為98，又更新了緩存值為98
3. 請求A這時才更新緩存的值為99

這樣數(shù)據(jù)庫的值為98，但緩存的值為99，數(shù)值不一致。（不推薦）

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

這個流程跟上面很類似，出現(xiàn)的問題也很類似

1. 請求A先更新緩存為99，但還沒有來得及更新數(shù)據(jù)庫
2. 請求B更新緩存為98，又更新了數(shù)據(jù)庫為98
3. 請求A這時更新數(shù)據(jù)庫為99

這樣就緩存的值為98，數(shù)據(jù)庫為99導(dǎo)致不一致。（不推薦）

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

存在的問題場景：請求A更新值為99，請求B獲取值

上圖中請求流程：

1. 請求A更新值，先把緩存中的值刪除，但還沒有來得及更新數(shù)據(jù)庫
2. 此時請求B過來查詢此值，發(fā)現(xiàn)緩存中不存在，就到數(shù)據(jù)庫中查詢
3. 請求B在數(shù)據(jù)庫中獲取到值，在把值設(shè)置到緩存中。
4. 請求A這時才更新數(shù)據(jù)庫里面的值為99

這樣就導(dǎo)致了緩存和數(shù)據(jù)庫的不一致問題，緩存中的值一直是舊數(shù)據(jù)。（不推薦）

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

這個方案也是老外提出的《Cache-Aside pattern》更新緩存的策略。這種策略先保證了源頭的數(shù)據(jù)一定是正確的。這種策略是不是萬無一失呢，有一種非常特殊的場景

上圖流程：建立中緩存突然失效了

1. 請求A發(fā)起查詢請求，直接到數(shù)據(jù)庫查詢到100，但還沒有來得及去設(shè)置緩存
2. 請求B更新值，先更新數(shù)據(jù)庫，在刪除緩存
3. 請求A這時才設(shè)置緩存為100

這種情況發(fā)生的不一致，是因為緩存突然失效了。而且還要保證請求B更新操作 比 請求A的查詢操作還要快；才會導(dǎo)致不一致。這種情況概率會很少。一般要求不高的項目可以采用此方式（推薦）。

緩存刪除失敗，導(dǎo)致不一致

這種先更新數(shù)據(jù)庫，再刪除緩存的策略中，因為要刪除緩存，但如果緩存刪除失敗，就會導(dǎo)致數(shù)據(jù)庫與緩存不一致。這個問題怎么辦？我們正常想到的是利用我們MQ中間件去實現(xiàn)。

上圖的流程，如果刪除緩存失敗，發(fā)送消息投遞到消息中間件中，進(jìn)入消息隊列。也許有小伙伴就會問，如果消息投遞失敗怎么辦？我們可以利用消息中間件那邊的保證100%消息投遞的機(jī)制（這個以后再講）。這樣就保證了即使刪除消息失敗，我們也會重試。

不過這個方案有個問題，就是和我們應(yīng)用服務(wù)的業(yè)務(wù)代碼耦合的比較厲害。代碼業(yè)務(wù)不清晰。

那我們有沒有別的方案呢，對業(yè)務(wù)沒有侵入呢？

上圖中其實是利用了MySQL的底層機(jī)制，binlog日志進(jìn)行刪除緩存，這樣就不需要和業(yè)務(wù)關(guān)聯(lián)，刪除緩存服務(wù)是獨(dú)立的。我們可以利用阿里開源的canal去操作。

讀寫分離，導(dǎo)致不一致

這種先更新數(shù)據(jù)庫，再刪除緩存的策略是不是就沒有問題呢？我們來看一下另一個場景，數(shù)據(jù)庫的讀寫分離的場景。一般中大型項目都會用到數(shù)據(jù)庫的讀寫分離。寫請求在一個庫，讀請求在另一個庫。讀寫分離會有個問題，就是庫與庫之間會存在數(shù)據(jù)延遲，因為存在數(shù)據(jù)同步。

那我們再看一下上面的場景流程，就會有問題，因為請求B更新數(shù)據(jù) 在一個庫上面，請求A去讀取數(shù)據(jù)時是另一個庫。

1. 請求B更新值99，刪除緩存
2. 請求A查詢值100（讀庫數(shù)據(jù)還沒有同步），在更新到緩存中（值為100）

這樣就導(dǎo)致不一致，這個場景是經(jīng)常出現(xiàn)的，不是小概率事件。那我們?nèi)绾翁幚砟?？老顧下次再介紹。

總結(jié)：整個導(dǎo)致不一致的原因就是因為高并發(fā)情況下各個請求執(zhí)行的順序是無法確定的，不知道哪個請求先執(zhí)行，哪個后執(zhí)行導(dǎo)致。

標(biāo)題名稱：如何更新緩存嗎？如何保證緩存和數(shù)據(jù)庫雙寫一致性？
文章出自：http://chinadenli.net/article28/joiccp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)建站、ChatGPT、服務(wù)器托管、電子商務(wù)、企業(yè)建站、靜態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)