目錄

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

前言

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

創(chuàng)新互聯(lián)公司一直秉承“誠信做人，踏實(shí)做事”的原則，不欺瞞客戶，是我們最起碼的底線！ 以服務(wù)為基礎(chǔ)，以質(zhì)量求生存，以技術(shù)求發(fā)展，成交一個(gè)客戶多一個(gè)朋友！為您提供做網(wǎng)站、成都網(wǎng)站制作、成都網(wǎng)頁設(shè)計(jì)、微信平臺(tái)小程序開發(fā)、成都網(wǎng)站開發(fā)、成都網(wǎng)站制作、成都軟件開發(fā)、成都app軟件開發(fā)公司是成都本地專業(yè)的網(wǎng)站建設(shè)和網(wǎng)站設(shè)計(jì)公司，等你一起來見證！

緩存設(shè)計(jì)思路

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

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

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

存在的問題場(chǎng)景：請(qǐng)求A更新值為99，請(qǐng)求B更新值為98

上圖流程：

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

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

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

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

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

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

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

存在的問題場(chǎng)景：請(qǐng)求A更新值為99，請(qǐng)求B獲取值

上圖中請(qǐng)求流程：

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

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

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

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

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

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

這種情況發(fā)生的不一致，是因?yàn)榫彺嫱蝗皇Я?。而且還要保證請(qǐng)求B更新操作 比 請(qǐng)求A的查詢操作還要快；才會(huì)導(dǎo)致不一致。這種情況概率會(huì)很少。一般要求不高的項(xiàng)目可以采用此方式（推薦）。

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

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

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

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

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

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

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

這種先更新數(shù)據(jù)庫，再刪除緩存的策略是不是就沒有問題呢？我們來看一下另一個(gè)場(chǎng)景，數(shù)據(jù)庫的讀寫分離的場(chǎng)景。一般中大型項(xiàng)目都會(huì)用到數(shù)據(jù)庫的讀寫分離。寫請(qǐng)求在一個(gè)庫，讀請(qǐng)求在另一個(gè)庫。讀寫分離會(huì)有個(gè)問題，就是庫與庫之間會(huì)存在數(shù)據(jù)延遲，因?yàn)榇嬖跀?shù)據(jù)同步。

那我們?cè)倏匆幌律厦娴膱?chǎng)景流程，就會(huì)有問題，因?yàn)檎?qǐng)求B更新數(shù)據(jù) 在一個(gè)庫上面，請(qǐng)求A去讀取數(shù)據(jù)時(shí)是另一個(gè)庫。

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

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

總結(jié)：整個(gè)導(dǎo)致不一致的原因就是因?yàn)楦卟l(fā)情況下各個(gè)請(qǐng)求執(zhí)行的順序是無法確定的，不知道哪個(gè)請(qǐng)求先執(zhí)行，哪個(gè)后執(zhí)行導(dǎo)致。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。

網(wǎng)站欄目：如何更新緩存嗎？如何保證緩存和數(shù)據(jù)庫雙寫一致性？-創(chuàng)新互聯(lián)
瀏覽路徑：http://weahome.cn/article/djcsso.html