首先，我們先來看看有哪幾種一致性的情況呢？

一、一致性

1、強(qiáng)一致性

如果你的項(xiàng)目對緩存的要求是強(qiáng)一致性的，那么請不要使用緩存。這種一致性級別是最符合用戶直覺的，它要求系統(tǒng)寫入什么，讀出來的也會是什么，用戶體驗(yàn)好，但實(shí)現(xiàn)起來往往對系統(tǒng)的性能影響大。

2、弱一致性

這種一致性級別約束了系統(tǒng)在寫入成功后，不承諾立即可以讀到寫入的值，也不承諾多久之后數(shù)據(jù)能夠達(dá)到一致，但會盡可能地保證到某個(gè)時(shí)間級別（比如秒級別）后，數(shù)據(jù)能夠達(dá)到一致狀態(tài)。

3、最終一致性

最終一致性是弱一致性的一個(gè)特例，系統(tǒng)會保證在一定時(shí)間內(nèi)，能夠達(dá)到一個(gè)數(shù)據(jù)一致的狀態(tài)。這里之所以將最終一致性單獨(dú)提出來，是因?yàn)樗侨跻恢滦灾蟹浅Ｍ瞥绲囊环N一致性模型，也是業(yè)界在大型分布式系統(tǒng)的數(shù)據(jù)一致性上比較推崇的模型。一般情況下，高可用只確保最終一致性，不確保強(qiáng)一致性。

強(qiáng)一致性，讀請求和寫請求會串行化，串到一個(gè)內(nèi)存隊(duì)列里去，這樣會大大增加系統(tǒng)的處理效率，吞吐量也會大大降低。

二、redis緩存和mysql數(shù)據(jù)庫數(shù)據(jù)一致性解決

這張圖，大多數(shù)人的很多業(yè)務(wù)操作都是根據(jù)這個(gè)圖來做緩存的。但是一旦設(shè)計(jì)到雙寫或者
數(shù)據(jù)庫和緩存更新等操作，就很容易出現(xiàn)數(shù)據(jù)一致性的問題。無論是先寫數(shù)據(jù)庫，在刪除緩存，還是先刪除緩存，在寫入數(shù)據(jù)庫，都會出現(xiàn)數(shù)據(jù)一致性的問題。列舉兩個(gè)小例子。

1、 先刪除了redis緩存，但是因?yàn)槠渌裁丛蜻€沒來得及寫入數(shù)據(jù)庫，另外一個(gè)線程就來讀取，發(fā)現(xiàn)緩存為空，則去數(shù)據(jù)庫讀取到之前的數(shù)據(jù)并寫入緩存，此時(shí)緩存中為臟數(shù)據(jù)。

2、 如果先寫入了數(shù)據(jù)庫，但是在緩存被刪除前，寫入數(shù)據(jù)庫的線程因?yàn)槠渌虮恢袛嗔?，沒有刪除掉緩存，就也會出現(xiàn)數(shù)據(jù)不一致的情況。

總的來說，寫和讀在多數(shù)情況下都是并發(fā)的，不能絕對保證先后順序，就會很容易出現(xiàn)緩存和數(shù)據(jù)庫數(shù)據(jù)不一致的情況，還怎么解決呢？

1、方案一：采用延時(shí)雙刪策略

基本思路： 在寫庫前后都進(jìn)行刪除緩存操作，并且設(shè)置合理的超時(shí)時(shí)間
基本步驟： 先刪除緩存–再寫數(shù)據(jù)庫—休眠一段時(shí)間—再次刪除緩存
注：休眠的時(shí)間是根據(jù)自己的項(xiàng)目的讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時(shí)來確定的。這樣做主要是為了保證在寫請求之前確保讀請求結(jié)束，寫請求可以刪除讀請求造成的緩存臟數(shù)據(jù)。

該方案的弊端： 集合雙刪策略+緩存超時(shí)策略設(shè)置，這樣最差的結(jié)果就是在超時(shí)時(shí)間內(nèi)數(shù)據(jù)存在不一致，又增加了寫請求的耗時(shí)。

2、方案二：一步更新緩存（基于訂閱Binlog的同步機(jī)制）

基本思路： mysql Binlog增強(qiáng)訂閱消費(fèi)+消息隊(duì)列+增量數(shù)據(jù)更新到redis—讀redis：熱數(shù)據(jù)基本上都在redis—寫mysql：增刪改都是操作mysql—更新redis數(shù)據(jù)：mysql的數(shù)據(jù)操作Binlog，來更新redis

我們再來看看詳細(xì)的過程

1、Redis更新

1）、數(shù)據(jù)操作主要分為兩大塊：
一個(gè)是全量，將全部數(shù)據(jù)寫去redis；另一個(gè)就是增量（update、insert、delete），實(shí)時(shí)更新。

2）、讀取binlog后分析 ，利用消息隊(duì)列,推送更新各臺的redis緩存數(shù)據(jù)。
這樣一旦MySQL中產(chǎn)生了新的寫入、更新、刪除等操作，就可以把binlog相關(guān)的消息推送至Redis，Redis再根據(jù)binlog中的記錄，對Redis進(jìn)行更新。
其實(shí)這種機(jī)制，很類似MySQL的主從備份機(jī)制，因?yàn)镸ySQL的主備也是通過binlog來實(shí)現(xiàn)的數(shù)據(jù)一致性。

這里可以結(jié)合使用canal(阿里的一款開源框架)，通過該框架可以對MySQL的binlog進(jìn)行訂閱，而canal正是模仿了mysql的slave數(shù)據(jù)庫的備份請求，使得Redis的數(shù)據(jù)更新達(dá)到了相同的效果。

當(dāng)然，這里的消息推送工具你也可以采用別的第三方：kafka、rabbitMQ等來實(shí)現(xiàn)推送更新Redis。

歡迎小伙伴們留言討論！

以上就是面試官常問：如何保證Redis緩存和數(shù)據(jù)庫的數(shù)據(jù)一致性的詳細(xì)內(nèi)容，更多關(guān)于Redis緩存和數(shù)據(jù)庫數(shù)據(jù)一致的資料請關(guān)注本站其它相關(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處理。