偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

數(shù)據(jù)更新策略:到底是先更新數(shù)據(jù)庫還是先更新緩存?

數(shù)據(jù)庫 其他數(shù)據(jù)庫
從本質(zhì)上講,無論是先寫數(shù)據(jù)庫還是先寫緩存,都是為了保證數(shù)據(jù)庫和緩存的數(shù)據(jù)一致,也就是我們常說的數(shù)據(jù)一致性。

很多小伙伴最近都在問我,在系統(tǒng)中引入緩存后,當(dāng)向數(shù)據(jù)庫中寫入數(shù)據(jù)時(shí),是先寫數(shù)據(jù)庫還是先寫緩存呢?先寫數(shù)據(jù)庫和先寫緩存有什么區(qū)別嗎?今天,我們就一起來聊聊這個(gè)話題。

又一個(gè)可直接應(yīng)用于生產(chǎn)環(huán)境的熔斷組件項(xiàng)目完結(jié)并上線,點(diǎn)擊鏈接:https://t.zsxq.com/HIE6n 快速學(xué)習(xí),并可直接應(yīng)用于你的生產(chǎn)環(huán)境項(xiàng)目。

從本質(zhì)上講,無論是先寫數(shù)據(jù)庫還是先寫緩存,都是為了保證數(shù)據(jù)庫和緩存的數(shù)據(jù)一致,也就是我們常說的數(shù)據(jù)一致性。

隨著互聯(lián)網(wǎng)的高速發(fā)展,當(dāng)今時(shí)代已然從IT時(shí)代進(jìn)入到DT時(shí)代?;ヂ?lián)網(wǎng)系統(tǒng)架構(gòu)也已經(jīng)由最初的單體架構(gòu)轉(zhuǎn)變?yōu)榉植际?、微服?wù)架構(gòu)模式。從數(shù)據(jù)體量上來看,各系統(tǒng)存儲(chǔ)的數(shù)據(jù)量越來越大,數(shù)據(jù)的查詢性能越來越低。此時(shí),就需要我們不斷的進(jìn)行優(yōu)化,一種常用的優(yōu)化手段就是引入緩存。而引入緩存后,我們?cè)谙驍?shù)據(jù)庫插入數(shù)據(jù)時(shí),到底是先更新數(shù)據(jù)庫還是先更新緩存呢?

緩存的一般使用

緩存,從本質(zhì)上講,是為了更好的協(xié)調(diào)兩個(gè)速度差異比較大的組件而引入的一種中間緩存層。例如,如果需要將數(shù)據(jù)讀入CPU進(jìn)行計(jì)算處理,由于CPU的運(yùn)算速度是非??斓?,而磁盤的IO處理相比于CPU來說,慢了很多數(shù)量級(jí),每次從磁盤讀取數(shù)據(jù),勢(shì)必會(huì)造成CPU長時(shí)間并且頻繁等待磁盤IO。此時(shí),我們就可以通過內(nèi)存來緩和CPU和磁盤之間的速度差異。

圖片圖片

從緩存的使用上來說,一般是按照如下的流程來使用緩存。

圖片圖片

我們也可以表示成如下的序列圖。

圖片圖片

在上面的使用示例中,我們只是簡單的將數(shù)據(jù)放入了緩存,最多為緩存設(shè)置一個(gè)過期時(shí)間,到期后,緩存自然就會(huì)被清除,后續(xù)的請(qǐng)求由于在緩存中獲取不到數(shù)據(jù),又會(huì)從數(shù)據(jù)庫中獲取數(shù)據(jù),將數(shù)據(jù)寫入緩存。

但是在后續(xù)更新數(shù)據(jù)的操作中,是更新完數(shù)據(jù)庫,接下來更新緩存還是刪除緩存?又或者是先刪除緩存,再更新數(shù)據(jù)庫?

緩存更新策略

從理論上來說,給緩存設(shè)置過期時(shí)間,其實(shí)是一種最終一致性的表現(xiàn)。這種方案下,可以對(duì)存入緩存的數(shù)據(jù)設(shè)置過期時(shí)間,所有的寫操作以數(shù)據(jù)庫為準(zhǔn),對(duì)緩存操作只是盡最大努力即可。也就是說如果數(shù)據(jù)庫寫成功,緩存更新失敗,那么只要到達(dá)過期時(shí)間,則后面的讀請(qǐng)求自然會(huì)從數(shù)據(jù)庫中讀取新值然后回填緩存。這也是一般情況下,使用的最多的一種方式。

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

其實(shí),這種方案很多有經(jīng)驗(yàn)的小伙伴是很反對(duì)的,為啥,我們來分析下。

首先,這種方案會(huì)有線程安全的問題。

例如,同時(shí)有線程A和線程B對(duì)數(shù)據(jù)進(jìn)行更新操作,可能會(huì)出現(xiàn)下面的執(zhí)行順序。

(1) 線程A更新了數(shù)據(jù)庫

(2) 線程B更新了數(shù)據(jù)庫

(3) 線程B更新了緩存

(4) 線程A更新了緩存

此時(shí)就會(huì)出現(xiàn)數(shù)據(jù)庫中的數(shù)據(jù)與緩存的數(shù)據(jù)不一致的情況,這是因?yàn)榫€程A先更新了數(shù)據(jù)庫,可能因?yàn)榫W(wǎng)絡(luò)等異常情況,線程B更新完數(shù)據(jù)庫進(jìn)而更新了緩存,當(dāng)線程B更新完緩存后,線程A才更新緩存,這就導(dǎo)致了數(shù)據(jù)庫數(shù)據(jù)與緩存數(shù)據(jù)的不一致。

其次,這種方案也有其不適用的業(yè)務(wù)場(chǎng)景。

首先一個(gè)業(yè)務(wù)場(chǎng)景就是數(shù)據(jù)庫寫多讀少的場(chǎng)景,這種場(chǎng)景下采用先更新數(shù)據(jù)庫再更新緩存的策略,就會(huì)導(dǎo)致緩存并未被讀取就會(huì)被頻繁的更新,極大的浪費(fèi)了服務(wù)器的性能。

再一個(gè)業(yè)務(wù)場(chǎng)景就是數(shù)據(jù)庫中的數(shù)據(jù)不是直接寫入緩存的,而是需要大量的復(fù)雜運(yùn)算,將運(yùn)算結(jié)果寫入緩存。如果這種場(chǎng)景下使用先更新數(shù)據(jù)庫再更新緩存的策略,也會(huì)造成服務(wù)器資源的浪費(fèi)。

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

先刪除緩存再更新數(shù)據(jù)庫的方案也存在著線程安全的問題,例如,線程A更新緩存,同時(shí),線程B讀取緩存的數(shù)據(jù)??赡軙?huì)出現(xiàn)下面的執(zhí)行順序。

(1) 線程A刪除緩存

(2) 線程B查詢緩存,發(fā)現(xiàn)緩存中沒有想要的數(shù)據(jù)

(3) 線程B查詢數(shù)據(jù)庫中的舊數(shù)據(jù)

(4) 線程B將查詢到的舊數(shù)據(jù)寫入緩存

(5) 線程A將新數(shù)據(jù)寫入數(shù)據(jù)庫

此時(shí),就出現(xiàn)了數(shù)據(jù)庫中的數(shù)據(jù)和緩存中的數(shù)據(jù)不一致的情況。如果刪除緩存失敗,也會(huì)出現(xiàn)數(shù)據(jù)庫數(shù)據(jù)和緩存數(shù)據(jù)不一致的現(xiàn)象。

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

首先,這種方式也有極小的概率發(fā)生數(shù)據(jù)庫數(shù)據(jù)和緩存數(shù)據(jù)不一致的情況,例如,線程A做查詢操作,線程B執(zhí)行更新操作,其執(zhí)行的順序如下所示。

(1)緩存剛好失效

(2)請(qǐng)求A查詢數(shù)據(jù)庫,獲取到數(shù)據(jù)庫中的舊值

(3)請(qǐng)求B將新值寫入數(shù)據(jù)庫

(4)請(qǐng)求B刪除緩存

(5)請(qǐng)求A將查到的舊值寫入緩存

如果上述順序一旦發(fā)生,就會(huì)造成數(shù)據(jù)庫中的數(shù)據(jù)和緩存中的數(shù)據(jù)不一致的情況發(fā)生。

但是,先更新數(shù)據(jù)庫再刪除緩存的策略發(fā)生數(shù)據(jù)庫和緩存數(shù)據(jù)不一致的概率很低,原因就是:(3)的寫數(shù)據(jù)庫操作比步驟(2)的讀數(shù)據(jù)庫操作耗時(shí)更短,才有可能使得步驟(4)先于步驟(5)執(zhí)行。但是,往往數(shù)據(jù)庫的讀操作的速度遠(yuǎn)快于寫操作,因此步驟(3)耗時(shí)比步驟(2)更短,這一場(chǎng)景很難出現(xiàn)。

如果刪除緩存失敗,也會(huì)出現(xiàn)數(shù)據(jù)庫數(shù)據(jù)和緩存數(shù)據(jù)不一致的現(xiàn)象。

這樣說來,貌似三種方案都不安全呀,那我們?cè)撊绾巫瞿??最重要的就是需要引入重試機(jī)制。

推薦使用

在實(shí)際的生產(chǎn)環(huán)境中,推薦 使用先更新數(shù)據(jù)庫再刪除緩存 的操作。那么,我們?cè)撊绾谓鉀Q這種策略下的問題呢?

有兩種方案,一種是在程序邏輯中處理失敗重試的操作;另外,借助于阿里巴巴開源的Canal。

手動(dòng)失敗重試


圖片圖片

流程如下所示:

(1)更新數(shù)據(jù)庫數(shù)據(jù);

(2)刪除緩存數(shù)據(jù)失敗

(3)將需要?jiǎng)h除的key發(fā)送至消息隊(duì)列

(4)自己消費(fèi)消息,獲得需要?jiǎng)h除的key

(5)繼續(xù)重試刪除操作,直到成功

這種方案有一個(gè)缺點(diǎn),對(duì)業(yè)務(wù)線代碼造成大量的侵入。

同步數(shù)據(jù)庫數(shù)據(jù)

先來一張圖,這種圖從整體架構(gòu)上解決了數(shù)據(jù)庫數(shù)據(jù)和緩存數(shù)據(jù)不一致的情況。


圖片圖片

流程如下圖所示:

(1)更新數(shù)據(jù)庫數(shù)據(jù)

(2)數(shù)據(jù)庫將數(shù)據(jù)表數(shù)據(jù)的變更信息寫入binlog日志當(dāng)中

(3)訂閱程序獲取所需要的數(shù)據(jù)以及key

(4)程序邏輯中處理具體的業(yè)務(wù)邏輯,接收訂閱binlog、發(fā)起刪除緩存的請(qǐng)求。

(5)嘗試刪除緩存操作,發(fā)現(xiàn)刪除失敗

(6)將這些信息發(fā)送至消息隊(duì)列

(7)重新從消息隊(duì)列中獲得該數(shù)據(jù),重試操作

責(zé)任編輯:武曉燕 來源: 冰河技術(shù)
相關(guān)推薦

2021-03-19 07:40:22

緩存數(shù)據(jù)庫日志

2021-01-13 05:23:27

緩存數(shù)據(jù)庫高并發(fā)

2024-12-16 08:01:57

2018-07-13 15:56:39

緩存數(shù)據(jù)庫數(shù)據(jù)

2018-10-24 14:30:30

緩存服務(wù)更新

2023-12-27 13:44:00

數(shù)據(jù)庫系統(tǒng)分布式

2017-04-12 11:15:52

ReactsetState策略

2011-11-04 14:07:20

微軟Hotmail策略

2020-02-10 09:35:18

數(shù)據(jù)中心服務(wù)器技術(shù)

2018-10-19 11:07:02

主流緩存更新

2024-12-03 10:59:36

2021-01-29 10:51:48

高并發(fā)數(shù)據(jù)庫緩存

2019-12-24 09:12:10

運(yùn)維架構(gòu)技術(shù)

2021-10-15 21:16:00

手機(jī)內(nèi)存漏洞

2023-04-13 08:15:47

Redis緩存一致性

2011-05-26 15:53:59

數(shù)據(jù)庫更新維護(hù)

2009-03-19 10:08:09

C#數(shù)據(jù)庫查詢

2011-07-01 14:03:44

數(shù)據(jù)庫緩存

2022-04-01 16:55:22

數(shù)據(jù)庫緩存日志

2024-03-28 13:13:00

Htmx前端開發(fā)框架
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)