資訊專(zhuān)欄INFORMATION COLUMN
摘要：五先刪除緩存，再更新數(shù)據(jù)庫(kù)該方案會(huì)導(dǎo)致不一致的原因同時(shí)有一個(gè)請(qǐng)求進(jìn)行更新操作，另一個(gè)請(qǐng)求進(jìn)行查詢(xún)操作。
一.為什么寫(xiě)這邊文章
首先，緩存由于其高并發(fā)和高性能的特性，已經(jīng)在項(xiàng)目中被廣泛使用。在讀取緩存方面，大家沒(méi)啥疑問(wèn)，都是按照下午的流程來(lái)進(jìn)行業(yè)務(wù)操作：
但是，在更新緩存方面，對(duì)于更新完數(shù)據(jù)庫(kù)，是更新緩存呢，還是刪除緩存？又或者是先刪除緩存，再更新數(shù)據(jù)庫(kù)？其實(shí)這一塊是存在很大的爭(zhēng)議。
二、文章結(jié)構(gòu)
講解緩存更新策略；
對(duì)每種策略進(jìn)行缺點(diǎn)分析；
針對(duì)缺點(diǎn)給出改進(jìn)方案；
三、正文
先做一個(gè)說(shuō)明，從理論上來(lái)說(shuō)，給緩存設(shè)置過(guò)期時(shí)間，是保證最終一致性的解決方案。這種方案下，我們可以對(duì)緩存的數(shù)據(jù)設(shè)置過(guò)期時(shí)間，所有的寫(xiě)操作以數(shù)據(jù)庫(kù)為準(zhǔn)，對(duì)緩存操作只是盡最大努力即可。也就是說(shuō)如果數(shù)據(jù)庫(kù)寫(xiě)成功，緩存更新失敗，那么只要到達(dá)過(guò)期時(shí)間，則后面的讀請(qǐng)求自然會(huì)從數(shù)據(jù)庫(kù)中讀取新值，然后回填緩存。因此，接下來(lái)討論的思路不依賴(lài)于給緩存設(shè)置過(guò)期時(shí)間這個(gè)方案。在這里，我們討論三種更新策略：
先更新數(shù)據(jù)庫(kù)，再更新緩存
先刪除緩存，再更新數(shù)據(jù)庫(kù)
先更新數(shù)據(jù)庫(kù)，再刪除緩存
為什么沒(méi)有先更新緩存，再更新數(shù)據(jù)庫(kù)這種策略？答案不用說(shuō)了吧。
四、先更新數(shù)據(jù)庫(kù)，再更新緩存
這套方案，大家是普遍反對(duì)的，為什么呢？有如下兩點(diǎn)原因：
原因一：線(xiàn)程安裝角度
同時(shí)又請(qǐng)求A和請(qǐng)求B進(jìn)行更新操作，那么會(huì)出現(xiàn)：
線(xiàn)程A更新了數(shù)據(jù)庫(kù)
線(xiàn)程B更新了數(shù)據(jù)庫(kù)
線(xiàn)程B更新了緩存
線(xiàn)程A更新了緩存
這就出現(xiàn)請(qǐng)求A更新緩存應(yīng)該比請(qǐng)求B更新緩存早才對(duì)，但是因?yàn)榫W(wǎng)絡(luò)等原因，B比A更早更新了緩存。這就導(dǎo)致了臟數(shù)據(jù)，因此不考慮！
原因二、業(yè)務(wù)場(chǎng)景角度
有如下兩點(diǎn)：
1）如果你是一個(gè)寫(xiě)數(shù)據(jù)庫(kù)場(chǎng)景比較多，而讀數(shù)據(jù)場(chǎng)景比較少的業(yè)務(wù)需求，采用這種方案就會(huì)導(dǎo)致，數(shù)據(jù)壓根還沒(méi)讀到，緩存就被頻繁的更新，浪費(fèi)性能。
2）如果你寫(xiě)入數(shù)據(jù)庫(kù)的值，并不是直接寫(xiě)入緩存的，而是要經(jīng)過(guò)一系列負(fù)責(zé)的計(jì)算再寫(xiě)入緩存。那么，每次寫(xiě)入數(shù)據(jù)庫(kù)后，都要再次計(jì)算寫(xiě)入緩存的值，無(wú)疑是浪費(fèi)性能的。顯然，刪除緩存更為合適。
接下來(lái)討論的就是爭(zhēng)議最大的，先刪除緩存，再更新數(shù)據(jù)庫(kù)。還是先更新數(shù)據(jù)庫(kù)，再刪除緩存的問(wèn)題。
五、先刪除緩存，再更新數(shù)據(jù)庫(kù)
該方案會(huì)導(dǎo)致不一致的原因：同時(shí)有一個(gè)請(qǐng)求A進(jìn)行更新操作，另一個(gè)請(qǐng)求B進(jìn)行查詢(xún)操作。那么就會(huì)出現(xiàn)以下情形：
請(qǐng)求A進(jìn)行寫(xiě)操作，刪除緩存
請(qǐng)求B查詢(xún)發(fā)現(xiàn)緩存不存在
請(qǐng)求B去數(shù)據(jù)庫(kù)查詢(xún)得到舊值
請(qǐng)求B將舊值寫(xiě)入緩存
請(qǐng)求A將新值寫(xiě)入數(shù)據(jù)庫(kù)
上述情況就會(huì)導(dǎo)致不一致的請(qǐng)求出現(xiàn)。而且，如果不采用給緩存設(shè)置過(guò)期時(shí)間策略，該數(shù)據(jù)永遠(yuǎn)都是臟數(shù)據(jù)。
那么，該如何解決呢？采用延時(shí)雙刪除策略！偽代碼如下：
public void write(String key, Object data){
redis.delKey(key);
db.updateData(data);
Thread.sleep(1000);
redis.deleKey(key);
}
解釋一下：
先淘汰緩存
再寫(xiě)數(shù)據(jù)庫(kù)（這兩步和原來(lái)一樣）
休眠1秒，再次淘汰緩存
這么做，可以將1秒內(nèi)所造成的緩存臟數(shù)據(jù)，再次刪除！
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/69483.html
摘要：五先刪除緩存，再更新數(shù)據(jù)庫(kù)該方案會(huì)導(dǎo)致不一致的原因同時(shí)有一個(gè)請(qǐng)求進(jìn)行更新操作，另一個(gè)請(qǐng)求進(jìn)行查詢(xún)操作。 一.為什么寫(xiě)這邊文章 首先，緩存由于其高并發(fā)和高性能的特性，已經(jīng)在項(xiàng)目中被廣泛使用。在讀取緩存方面，大家沒(méi)啥疑問(wèn)，都是按照下午的流程來(lái)進(jìn)行業(yè)務(wù)操作： showImg(https://segmentfault.com/img/bVbaV5h?w=553&h=443);但是，在更新緩存方...
摘要：先更新數(shù)據(jù)庫(kù)，再更新緩存這套方案，大家是普遍反對(duì)的。采用這種同步淘汰策略，吞吐量降低怎么辦，那就將第二次刪除作為異步的。比如一個(gè)寫(xiě)數(shù)據(jù)請(qǐng)求，然后寫(xiě)入數(shù)據(jù)庫(kù)了，刪緩存失敗了，這會(huì)就出現(xiàn)不一致的情況了。 引言 為什么寫(xiě)這篇文章？ 首先，緩存由于其高并發(fā)和高性能的特性，已經(jīng)在項(xiàng)目中被廣泛使用。在讀取緩存方面，大家沒(méi)啥疑問(wèn)，都是按照下圖的流程來(lái)進(jìn)行業(yè)務(wù)操作。 showImg(https://s...
摘要：緩存穿透是指查詢(xún)一個(gè)一定不存在的數(shù)據(jù)。這就是緩存穿透請(qǐng)求的數(shù)據(jù)在緩存大量不命中，導(dǎo)致請(qǐng)求走數(shù)據(jù)庫(kù)。并發(fā)下解決數(shù)據(jù)庫(kù)與緩存不一致的思路將刪除緩存修改數(shù)據(jù)庫(kù)讀取緩存等的操作積壓到隊(duì)列里邊，實(shí)現(xiàn)串行化。 前言 只有光頭才能變強(qiáng)。 文本已收錄至我的GitHub倉(cāng)庫(kù)，歡迎Star：https://github.com/ZhongFuCheng3y/3y 回顧前面： 從零單排學(xué)Redis【青銅...
閱讀 1172·2021-11-15 18:14
閱讀 3645·2021-11-15 11:37
閱讀 768·2021-09-24 09:47
閱讀 2453·2021-09-04 16:48
閱讀 2189·2019-08-30 15:53
閱讀 2390·2019-08-30 15:53
閱讀 400·2019-08-30 11:20
閱讀 1244·2019-08-29 16:08
