人妖在线一区,国产日韩欧美一区二区综合在线,国产啪精品视频网站免费,欧美内射深插日本少妇

新聞動(dòng)態(tài)

淺談數(shù)據(jù)庫緩存最終一致性的四種方案

發(fā)布日期:2022-01-30 17:42 | 文章來源:源碼中國

背景

緩存是軟件開發(fā)中一個(gè)非常有用的概念,數(shù)據(jù)庫緩存更是在項(xiàng)目中必然會(huì)遇到的場景。而緩存一致性的保證,更是在面試中被反復(fù)問到,這里進(jìn)行一下總結(jié),針對不同的要求,選擇恰到好處的一致性方案。

緩存是什么

存儲的速度是有區(qū)別的。緩存就是把低速存儲的結(jié)果,臨時(shí)保存在高速存儲的技術(shù)。

如圖所示,金字塔更上面的存儲,可以作為下面存儲的緩存。

我們本次的討論,主要針對數(shù)據(jù)庫緩存場景,將以redis作為mysql的緩存為案例來進(jìn)行。

為什么需要緩存

存儲如mysql通常支持完整的ACID特性,因?yàn)榭煽啃裕志眯缘纫蛩?,性能普遍不高,高并發(fā)的查詢會(huì)給mysql帶來壓力,造成數(shù)據(jù)庫系統(tǒng)的不穩(wěn)定。同時(shí)也容易產(chǎn)生延遲。

根據(jù)局部性原理,80%請求會(huì)落到20%的熱點(diǎn)數(shù)據(jù)上,在讀多寫少場景,增加一層緩存非常有助提升系統(tǒng)吞吐量和健壯性。

存在問題

存儲的數(shù)據(jù)隨著時(shí)間可能會(huì)發(fā)生變化,而緩存中的數(shù)據(jù)就會(huì)不一致。具體能容忍的不一致時(shí)間,需要具體業(yè)務(wù)具體分析,但是通常的業(yè)務(wù),都需要做到最終一致。

redis作為mysql緩存

通常的開發(fā)模式中,都會(huì)使用mysql作為存儲,而redis作為緩存,加速和保護(hù)mysql。但是,當(dāng)mysql數(shù)據(jù)更新之后,redis怎么保持同步呢。

強(qiáng)一致性同步成本太高,如果追求強(qiáng)一致,那么沒必要用緩存了,直接用mysql即可。通常考慮的,都是最終一致性。

解決方案

方案一

通過key的過期時(shí)間,mysql更新時(shí),redis不更新。

這種方式實(shí)現(xiàn)簡單,但不一致的時(shí)間會(huì)很長。如果讀請求非常頻繁,且過期時(shí)間比較長,則會(huì)產(chǎn)生很多長期的臟數(shù)據(jù)。

優(yōu)點(diǎn):

開發(fā)成本低,易于實(shí)現(xiàn);

管理成本低,出問題的概率會(huì)比較小。

不足:

完全依賴過期時(shí)間,時(shí)間太短容易緩存頻繁失效,太長容易有長時(shí)間更新延遲(不一致)

方案二

在方案一的基礎(chǔ)上擴(kuò)展,通過key的過期時(shí)間兜底,并且,在更新mysql時(shí),同時(shí)更新redis。

優(yōu)點(diǎn):

相對方案一,更新延遲更小。

不足:

如果更新mysql成功,更新redis卻失敗,就退化到了方案一;

在高并發(fā)場景,業(yè)務(wù)server需要和mysql,redis同時(shí)進(jìn)行連接。這樣是損耗雙倍的連接資源,容易造成連接數(shù)過多的問題。

方案三

針對方案二的同步寫redis進(jìn)行優(yōu)化,增加消息隊(duì)列,將redis更新操作交給kafka,由消息隊(duì)列保證可靠性,再搭建一個(gè)消費(fèi)服務(wù),來異步更新redis。

優(yōu)點(diǎn):

消息隊(duì)列可以用一個(gè)句柄,很多消息隊(duì)列客戶端還支持本地緩存發(fā)送,有效解決了方案二連接數(shù)過多的問題;

使用消息隊(duì)列,實(shí)現(xiàn)了邏輯上的解耦;

消息隊(duì)列本身具有可靠性,通過手動(dòng)提交等手段,可以至少一次消費(fèi)到redis。

不足:

依舊解決不了時(shí)序性問題,如果多臺業(yè)務(wù)服務(wù)器分別處理針對同一行數(shù)據(jù)的兩條請求,舉個(gè)栗子,a = 1;a = 5; 如果mysql中是第一條先執(zhí)行,而進(jìn)入kafka的順序是第二條先執(zhí)行,那么數(shù)據(jù)就會(huì)產(chǎn)生不一致。

引入了消息隊(duì)列,同時(shí)要增加服務(wù)消費(fèi)消息,成本較高,還有重復(fù)消費(fèi)的風(fēng)險(xiǎn)。

方案四

通過訂閱binlog來更新redis,把我們搭建的消費(fèi)服務(wù),作為mysql的一個(gè)slave,訂閱binlog,解析出更新內(nèi)容,再更新到redis。

優(yōu)點(diǎn):

在mysql壓力不大情況下,延遲較低;

和業(yè)務(wù)完全解耦;

解決了時(shí)序性問題。

缺點(diǎn):

要單獨(dú)搭建一個(gè)同步服務(wù),并且引入binlog同步機(jī)制,成本較大。

總結(jié)

方案選型

首先確認(rèn)產(chǎn)品上對延遲性的要求,如果要求極高,且數(shù)據(jù)有可能變化,別用緩存。

通常來說,方案1就夠了,筆者咨詢過4,5個(gè)團(tuán)隊(duì),基本都是用方案1,因?yàn)槟苡镁彺娣桨福ǔJ亲x多寫少場景,同時(shí)業(yè)務(wù)上對延遲具有一定的包容性。方案1沒有開發(fā)成本,其實(shí)比較實(shí)用。

如果想增加更新時(shí)的即時(shí)性,就選擇方案2,不過沒必要做重試保證之類的。

方案3,方案4針對于對延時(shí)要求比較高業(yè)務(wù),一個(gè)是推模式,一個(gè)是拉模式,而方案4具備更強(qiáng)的可靠性,既然都愿意花功夫做處理消息的邏輯,不如一步到位,用方案4。

結(jié)論

一般情況,方案1夠用。若延時(shí)要求高,直接選擇方案4。如果是面試場景,從簡單講到復(fù)雜,面試官會(huì)一步一步追問,咱們就一點(diǎn)點(diǎn)推導(dǎo),賓主盡歡。

到此這篇關(guān)于淺談數(shù)據(jù)庫緩存最終一致性的四種方案的文章就介紹到這了,更多相關(guān)數(shù)據(jù)庫緩存一致性內(nèi)容請搜索本站以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持本站!

香港快速服務(wù)器

版權(quán)聲明:本站文章來源標(biāo)注為YINGSOO的內(nèi)容版權(quán)均為本站所有,歡迎引用、轉(zhuǎn)載,請保持原文完整并注明來源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站,禁止在非www.sddonglingsh.com所屬的服務(wù)器上建立鏡像,否則將依法追究法律責(zé)任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來,僅供學(xué)習(xí)參考,不代表本站立場,如有內(nèi)容涉嫌侵權(quán),請聯(lián)系alex-e#qq.com處理。

實(shí)時(shí)開通

自選配置、實(shí)時(shí)開通

免備案

全球線路精選!

全天候客戶服務(wù)

7x24全年不間斷在線

專屬顧問服務(wù)

1對1客戶咨詢顧問

在線
客服

在線客服:7*24小時(shí)在線

客服
熱線

400-630-3752
7*24小時(shí)客服服務(wù)熱線

關(guān)注
微信

關(guān)注官方微信
頂部