主頁(yè) > 知識(shí)庫(kù) > 服務(wù)器端緩存失效的應(yīng)對(duì)方法經(jīng)驗(yàn)總結(jié)

服務(wù)器端緩存失效的應(yīng)對(duì)方法經(jīng)驗(yàn)總結(jié)

熱門標(biāo)簽:騰訊地圖標(biāo)注店面 農(nóng)村電銷機(jī)器人 福州防封電銷卡辦理低資費(fèi) 地圖標(biāo)注位置怎么快速上線 宜春手機(jī)外呼系統(tǒng) 柳州市電話電銷機(jī)器人團(tuán)隊(duì) 新科游樂(lè)園地圖標(biāo)注 廣州銷售外呼系統(tǒng)定制 天刀地圖標(biāo)注錯(cuò)誤

緩存失效情況舉例
看下這個(gè)段偽代碼:

復(fù)制代碼
代碼如下:

local value = get_from_cache(key)
if not value then
value = query_db(sql)
set_to_cache(value, timeout = 100)
end
return value

看上去沒(méi)有問(wèn)題,在單元測(cè)試情況下,也不會(huì)有異常。
但是,進(jìn)行壓力測(cè)試的時(shí)候,你會(huì)發(fā)現(xiàn),每隔100秒,數(shù)據(jù)庫(kù)的查詢就會(huì)出現(xiàn)一次峰值。如果你的cache失效時(shí)間設(shè)置的比較長(zhǎng),那么這個(gè)問(wèn)題被發(fā)現(xiàn)的機(jī)率就會(huì)降低。
為什么會(huì)出現(xiàn)峰值呢?想象一下,在cache失效的瞬間,如果并發(fā)請(qǐng)求有1000條同時(shí)到了 query_db(sql) 這個(gè)函數(shù)會(huì)怎樣?沒(méi)錯(cuò),會(huì)有1000個(gè)請(qǐng)求打向數(shù)據(jù)庫(kù)。這就是緩存失效瞬間引起的風(fēng)暴。它有一個(gè)英文名,叫 "dog-pile effect"。
怎么解決?自然的想法是發(fā)現(xiàn)緩存失效后,加一把鎖來(lái)控制數(shù)據(jù)庫(kù)的請(qǐng)求。具體的細(xì)節(jié),春哥在lua-resty-lock的文檔里面做了詳細(xì)的說(shuō)明,我就不重復(fù)了,請(qǐng)看這里。多說(shuō)一句,lua-resty-lock庫(kù)本身已經(jīng)替你完成了wait for lock的過(guò)程,看代碼的時(shí)候需要注意下這個(gè)細(xì)節(jié)。

傳統(tǒng)緩存失效應(yīng)對(duì)策略
為了提高業(yè)務(wù)訪問(wèn)速度,提升業(yè)務(wù)讀并發(fā),很多用戶都會(huì)在業(yè)務(wù)架構(gòu)中引入緩存層。業(yè)務(wù)所有讀請(qǐng)求全部路由到緩存層,通過(guò)緩存的內(nèi)存讀取機(jī)制大大提升業(yè)務(wù)讀取性能。緩存中的數(shù)據(jù)不能持久化 ,一旦緩存異常退出,那么內(nèi)存中的數(shù)據(jù)就會(huì)丟失,所以為了保證數(shù)據(jù)完整,業(yè)務(wù)的更新數(shù)據(jù)會(huì)落地到持久化存儲(chǔ)中,例如DB。目前云用戶的業(yè)務(wù)架構(gòu)一般如下圖:

在上圖中,大家可以看到,用戶的更新數(shù)據(jù)直接持久化到DB, 業(yè)務(wù)讀請(qǐng)求直接請(qǐng)求緩存數(shù)據(jù),所以業(yè)務(wù)需要解決緩存失效問(wèn)題,即解決因?yàn)閿?shù)據(jù)變更導(dǎo)致緩存中的數(shù)據(jù)失效的問(wèn)題。 目前業(yè)務(wù)解決緩存失效問(wèn)題的解決方法一般是業(yè)務(wù)實(shí)現(xiàn)DB、緩存雙寫。通過(guò)業(yè)務(wù)雙寫解決緩存失效,存在如下的問(wèn)題:
代碼侵入性比較強(qiáng),需要雙寫兩份存儲(chǔ),任何對(duì)DB的數(shù)據(jù)變更,都需要同時(shí)更新緩存,代碼層面后期可維護(hù)程度不高
用戶請(qǐng)求線程里同步調(diào)用緩存,對(duì)緩存存在強(qiáng)以來(lái),遇到緩存超時(shí)等異常時(shí),沒(méi)有辦法做到有效的重試,遇到異常給用戶返回系統(tǒng)錯(cuò)誤、操作失敗等信息,嚴(yán)重影響用戶體驗(yàn)
用戶請(qǐng)求線程里同步完成DB、緩存雙寫,變更請(qǐng)求鏈路長(zhǎng),訪問(wèn)延遲大,影響用戶體驗(yàn)
RDS數(shù)據(jù)訂閱消費(fèi),輕松解決緩存失效
在阿里巴巴內(nèi)部同樣也遇到了緩存失效的問(wèn)題,隨著業(yè)務(wù)架構(gòu)得不斷調(diào)整優(yōu)化,我們已經(jīng)沉淀出一套高可靠、極優(yōu)雅得緩存失效架構(gòu)。即通過(guò)數(shù)據(jù)傳輸提供的數(shù)據(jù)訂閱功能,異步獲取DB(例如公共云上的RDS)的增量數(shù)據(jù),根據(jù)增量數(shù)據(jù)進(jìn)行緩存失效。具體的架構(gòu)類似下圖:

在這個(gè)架構(gòu)里面,緩存更新流程如下:
1.業(yè)務(wù)完成DB更新后即返回請(qǐng)求
2.數(shù)據(jù)訂閱通過(guò)日志解析方式實(shí)時(shí)解析并訂閱DB的增量更新數(shù)據(jù),當(dāng)發(fā)現(xiàn)DB有數(shù)據(jù)更新時(shí),將增量數(shù)據(jù)推送給下游消費(fèi)者
3.下游消費(fèi)業(yè)務(wù)一旦接收到增量更新數(shù)據(jù),即調(diào)用消費(fèi)線程進(jìn)行緩存更新
至此完成整個(gè)緩存更新過(guò)程。
從上面的緩存失效流程,可以看出這種緩存失效機(jī)制:
1.更新路徑短,延遲低: 緩存失效為異步流程,業(yè)務(wù)更新DB完成后直接返回,不需要關(guān)心緩存失效流程,整個(gè)更新路徑短,更新延遲低
2.應(yīng)用簡(jiǎn)單可靠:應(yīng)用無(wú)需實(shí)現(xiàn)復(fù)雜雙寫邏輯,只需啟動(dòng)異步線程監(jiān)聽(tīng)增量數(shù)據(jù),更新緩存數(shù)據(jù)即可
3.應(yīng)用更新無(wú)性能消耗:因?yàn)閿?shù)據(jù)訂閱是通過(guò)解析DB的增量日志來(lái)獲取增量數(shù)據(jù),獲取數(shù)據(jù)的過(guò)程對(duì)業(yè)務(wù)、DB性能無(wú)損

小結(jié)
數(shù)據(jù)訂閱功能為阿里云數(shù)據(jù)傳輸提供的一種數(shù)據(jù)分發(fā)方式。通過(guò)數(shù)據(jù)訂閱實(shí)現(xiàn)的緩存失效策略,讓業(yè)務(wù)更新更快捷,讓業(yè)務(wù)邏輯更簡(jiǎn)單、更可靠。
數(shù)據(jù)訂閱只是數(shù)據(jù)傳輸提供的一種傳輸方式,除數(shù)據(jù)訂閱之外,數(shù)據(jù)傳輸還提供了數(shù)據(jù)實(shí)時(shí)同步,不停服遷移等多種傳輸能力,如需了解數(shù)據(jù)傳輸更多詳情,請(qǐng)猛擊數(shù)據(jù)傳輸。

標(biāo)簽:揭陽(yáng) 貴州 宣城 和田 呼和浩特 南昌 雅安 陽(yáng)江

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《服務(wù)器端緩存失效的應(yīng)對(duì)方法經(jīng)驗(yàn)總結(jié)》,本文關(guān)鍵詞  服務(wù)器,端,緩存,失效,的,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問(wèn)題,煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無(wú)關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《服務(wù)器端緩存失效的應(yīng)對(duì)方法經(jīng)驗(yàn)總結(jié)》相關(guān)的同類信息!
  • 本頁(yè)收集關(guān)于服務(wù)器端緩存失效的應(yīng)對(duì)方法經(jīng)驗(yàn)總結(jié)的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章