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