您好,登錄后才能下訂單哦!
本篇內(nèi)容主要講解“Redis、MySQL緩存雙寫不一致如何解決”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學(xué)習(xí)“Redis、MySQL緩存雙寫不一致如何解決”吧!
redis、mysql雙寫緩存不一致:
給緩存數(shù)據(jù)設(shè)置過期時間
先做一個說明,從理論上來說,給緩存設(shè)置過期時間,是保證最終一致性的解決方案。這種方案下,我們可以對存入緩存的數(shù)據(jù)設(shè)置過期時間,所有的寫操作以數(shù)據(jù)庫為準(zhǔn),對緩存操作只是盡最大努力即可。也就是說如果數(shù)據(jù)庫寫成功,緩存更新失敗,那么只要到達過期時間,則后面的讀請求自然會從數(shù)據(jù)庫中讀取新值然后回填緩存。因此,接下來討論的思路不依賴于給緩存設(shè)置過期時間這個方案。
在這里,我們先討論三種更新策略:
先更新數(shù)據(jù)庫,再更新緩存
先刪除緩存,再更新數(shù)據(jù)庫
先更新數(shù)據(jù)庫,再刪除緩存
先更新數(shù)據(jù)庫,再更新緩存
這套方案,大家普遍反對。為什么呢?有如下兩點:
原因一(線程安全角度)
(1)線程A更新了數(shù)據(jù)庫
(2)線程B更新了數(shù)據(jù)庫
(3)線程B更新了緩存
(4)線程A更新了緩存
這就出現(xiàn)請求A更新緩存應(yīng)該比請求B更新緩存早才對,但是因為網(wǎng)絡(luò)等原因,B卻比A更早更新了緩存。這就導(dǎo)致了臟數(shù)據(jù),因此不考慮。
原因二(業(yè)務(wù)場景角度)
(1)如果你是一個寫數(shù)據(jù)庫場景比較多,而讀數(shù)據(jù)場景比較少的業(yè)務(wù)需求,采用這種方案就會導(dǎo)致,數(shù)據(jù)壓根還沒讀到,緩存就被頻繁的更新,浪費性能。
(2)如果你寫入數(shù)據(jù)庫的值,并不是直接寫入緩存的,而是要經(jīng)過一系列復(fù)雜的計算再寫入緩存。那么,每次寫入數(shù)據(jù)庫后,都再次計算寫入緩存的值,無疑是浪費性能的。顯然,刪除緩存更為適合。
先刪除緩存,再更新數(shù)據(jù)庫
該方案會導(dǎo)致不一致原因是。同時一個請求A進行更新操作,另一個請求B進行查詢操作。那么會出現(xiàn)如下情形:
(1)請求A進行寫操作,刪除緩存
(2)請求B查詢發(fā)現(xiàn)緩存不存在
(3)請求B去數(shù)據(jù)庫查詢得到舊值
(4)請求B將舊值寫入緩存
(5)請求A將新值寫入數(shù)據(jù)庫
上述情況就會導(dǎo)致不一致的情形出現(xiàn)。而且,如果不采用給緩存設(shè)置過期時間策略,該數(shù)據(jù)永遠都是臟數(shù)據(jù)。
那么,如何解決呢?采用延時雙刪策略
public class CacheServiceImpl implements ICacheService { @Resource private RedisOperator redisOperator; @Autowired private IShopService shopService; //1. 采用延時雙刪,解決數(shù)據(jù)庫和緩存的一致性 @Override public void updateHotCount(String id) { try { //刪除緩存 redisOperator.del("redis_key_" + id); //更新數(shù)據(jù)庫 shopService.updataHotShop(); Thread.sleep(1000);//休眠1秒 //延時刪除 redisOperator.del("redis_key_" + id); } catch (InterruptedException e) { e.printStackTrace(); } } @Override public Integer getHotCount(String id) { return null; }}
解釋:
先淘汰緩存
再寫數(shù)據(jù)庫
休眠1秒,再淘汰緩存(這么做,可以將1秒內(nèi)所造成的緩存臟數(shù)據(jù),再次刪除。)
針對上面的情形,讀者應(yīng)該自行評估自己的項目的讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時。然后寫數(shù)據(jù)的休眠時間則在讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時基礎(chǔ)上,加幾百ms即可。這么做的目的,就是確保讀請求結(jié)束,寫請求可以刪除讀請求造成的緩存臟數(shù)據(jù)。
如果數(shù)據(jù)庫采用了讀寫分離架構(gòu),這么辦?(主庫負(fù)責(zé)寫操作,從庫負(fù)責(zé)讀操作)
ok,在這種情況下,造成數(shù)據(jù)不一致的原因如下,還是兩個請求,一個請求A進行更新操作,另一個請求B進行查詢操作。
(1)請求A進行寫操作,刪除緩存,請求A把數(shù)據(jù)寫入主庫,還沒開始同步從庫
(2)(1s內(nèi))請求B查詢緩存,沒有發(fā)現(xiàn)緩存,請求B去從庫查詢,這時還沒有完成主從同步,查到是舊值,并且把舊值寫入緩存。
(3)主庫完成主從同步,從庫變?yōu)樾轮?/p>
上述流程,就是數(shù)據(jù)不一致問題,還使用雙刪延時策略。只是,睡眠時間修改為在主從同步的延時時間基礎(chǔ)之上,加幾百ms
采用這種同步淘汰策略,吞吐量降低怎么辦?
ok,那就將第二次刪除作為異步的。自己起一個線程,異步刪除。這樣,寫的請求就不用沉睡一段時間后了,再返回。這么做,加大吞吐量。
第二次刪除,如果刪除失敗怎么辦?
這是個非常好的問題,因為第二次刪除失敗,就會出現(xiàn)如下情形。還是有兩個請求,一個請求A進行更新操作,另一個請求B進行查詢操作,為了方便,假設(shè)是單庫:
(1)請求A進行寫操作,刪除緩存
(2)請求B查詢發(fā)現(xiàn)緩存不存在
(3)請求B去數(shù)據(jù)庫查詢得到舊值
(4)請求B將舊值寫入緩存
(5)請求A將新值寫入數(shù)據(jù)庫
(6)請求A試圖去刪除請求B寫入對緩存值,結(jié)果失敗了。
ok,這也就是說。如果第二次刪除緩存失敗,會再次出現(xiàn)緩存和數(shù)據(jù)庫不一致的問題。
如何解決呢?
具體解決方案,且看博主對第先更新數(shù)據(jù)庫,再刪緩存種更新策略的解析。
不管是延時雙刪還是Cache-Aside的先操作數(shù)據(jù)庫再刪除緩存,都可能會存在第二步的刪除緩存失敗,導(dǎo)致的數(shù)據(jù)不一致問題??梢允褂眠@個方案優(yōu)化:刪除失敗就多刪除幾次呀,保證刪除緩存成功就可以了呀~ 所以可以引入刪除緩存重試機制
(1)更新數(shù)據(jù)庫數(shù)據(jù);
(2)緩存因為種種問題刪除失敗
(3)將需要刪除的key發(fā)送至消息隊列
(4)自己消費消息,獲得需要刪除的key
(5)繼續(xù)重試刪除操作,直到成功
然而,該方案有一個缺點,對業(yè)務(wù)線代碼造成大量的侵入。于是有了方案二,在方案二中,啟動一個訂閱程序去訂閱數(shù)據(jù)庫的binlog,獲得需要操作的數(shù)據(jù)。在應(yīng)用程序中,另起一段程序,獲得這個訂閱程序傳來的信息,進行刪除緩存操作。
流程如下圖所示:
(1)更新數(shù)據(jù)庫數(shù)據(jù)
(2)數(shù)據(jù)庫會將操作信息寫入binlog日志當(dāng)中
(3)訂閱程序提取出所需要的數(shù)據(jù)以及key
(4)另起一段非業(yè)務(wù)代碼,獲得該信息
(5)嘗試刪除緩存操作,發(fā)現(xiàn)刪除失敗
(6)將這些信息發(fā)送至消息隊列
(7)重新從消息隊列中獲得該數(shù)據(jù),重試操作。
備注說明:上述的訂閱binlog程序在mysql中有現(xiàn)成的中間件**叫canal,**可以完成訂閱binlog日志的功能。至于oracle中,博主目前不知道有沒有現(xiàn)成中間件可以使用。另外,重試機制,博主是采用的是消息隊列的方式。如果對一致性要求不是很高,直接在程序中另起一個線程,每隔一段時間去重試即可,這些大家可以靈活自由發(fā)揮,只是提供一個思路。
到此,相信大家對“Redis、MySQL緩存雙寫不一致如何解決”有了更深的了解,不妨來實際操作一番吧!這里是億速云網(wǎng)站,更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢,關(guān)注我們,繼續(xù)學(xué)習(xí)!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。