首先我們先了解下緩存是什么?

緩存就是把低速存儲(chǔ)的結(jié)果，臨時(shí)保存在高速存儲(chǔ)的技術(shù)。

為什么使用redis進(jìn)行緩存數(shù)據(jù)?

Redis嘛，就是一種運(yùn)行速度很快，并發(fā)很強(qiáng)的跑在內(nèi)存上的NoSql數(shù)據(jù)庫，支持鍵到五種數(shù)據(jù)類型的映射，(string、list、set、zset、hash),而memecache只能支持簡(jiǎn)單的數(shù)據(jù)類型。另外redis可以完成一部份數(shù)據(jù)的持久化，而memecache完全將數(shù)據(jù)保存在內(nèi)存中，不進(jìn)行持久化，如果服務(wù)器出問題，數(shù)據(jù)將全部丟失，另外一個(gè)原因是redis底層實(shí)現(xiàn)優(yōu)化比memecache好。另外采用了多路復(fù)用io阻塞機(jī)制，數(shù)據(jù)結(jié)構(gòu)簡(jiǎn)單，操作節(jié)省時(shí)間。

那常見的保證緩存與數(shù)據(jù)庫一致的方法有哪些呢?

想要保證緩存與數(shù)據(jù)庫的雙寫一致，一共有4種方式，即4種同步策略：

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

那么我們需要做的就是根據(jù)不同的場(chǎng)景來使用合理的方式來解決數(shù)據(jù)問題。

第一種：先刪除緩存，再更新數(shù)據(jù)庫

在出現(xiàn)失敗時(shí)可能出現(xiàn)的問題：

1：線程A刪除緩存成功，線程A更新數(shù)據(jù)庫失敗;

2 ：線程B從緩存中讀取數(shù)據(jù);由于緩存被刪，進(jìn)程B無法從緩存中得到數(shù)據(jù)，進(jìn)而從數(shù)據(jù)庫讀取數(shù)據(jù);此時(shí)數(shù)據(jù)庫中的數(shù)據(jù)更新失敗，線程B從數(shù)據(jù)庫成功獲取舊的數(shù)據(jù)，然后將數(shù)據(jù)更新到了緩存。

最終，緩存和數(shù)據(jù)庫的數(shù)據(jù)是一致的，但仍然是舊的數(shù)據(jù)。

第二種：先更新數(shù)據(jù)庫，再刪除緩存

假設(shè)這會(huì)有兩個(gè)請(qǐng)求，一個(gè)請(qǐng)求A做查詢操作，一個(gè)請(qǐng)求B做更新操作，那么會(huì)有如下情形產(chǎn)生

(1)緩存剛好失效

(2)請(qǐng)求A查詢數(shù)據(jù)庫，得一個(gè)舊值

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

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

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

如果發(fā)生上述情況，確實(shí)是會(huì)發(fā)生臟數(shù)據(jù)。

然而，發(fā)生這種情況的概率又有多少呢?

發(fā)生上述情況有一個(gè)先天性條件，就是步驟(3)的寫數(shù)據(jù)庫操作比步驟(2)的讀數(shù)據(jù)庫操作耗時(shí)更短，才有可能使得步驟(4)先于步驟(5)。

數(shù)據(jù)庫的讀操作的速度遠(yuǎn)快于寫操作的(不然做讀寫分離干嘛，做讀寫分離的意義就是因?yàn)樽x操作比較快，耗資源少)，因此步驟(3)耗時(shí)比步驟(2)更短，這一情形很難出現(xiàn)。

先更新數(shù)據(jù)庫，再刪緩存依然會(huì)有問題，不過，問題出現(xiàn)的可能性會(huì)因?yàn)樯厦嬲f的原因，變得比較低。

第三種：給所有的緩存一個(gè)失效期

第三種方案可以說是一個(gè)大殺器，任何不一致，都可以靠失效期解決，失效期越短，數(shù)據(jù)一致性越高。但是失效期越短，查數(shù)據(jù)庫就會(huì)越頻繁。因此失效期應(yīng)該根據(jù)業(yè)務(wù)來定。

1.并發(fā)不高的情況：

讀: 讀redis->沒有，讀mysql->把mysql數(shù)據(jù)寫回redis，有的話直接從redis中取;

寫: 寫mysql->成功，再寫redis;

2.并發(fā)高的情況：

讀: 讀redis->沒有，讀mysql->把mysql數(shù)據(jù)寫回redis，有的話直接從redis中取;

寫：異步話，先寫入redis的緩存，就直接返回;定期或特定動(dòng)作將數(shù)據(jù)保存到mysql，可以做到多次更新，一次保存;

第四種：加鎖，使線程順序執(zhí)行

如果一個(gè)服務(wù)部署到了多個(gè)機(jī)器，就變成了分布式鎖，或者是分布式隊(duì)列按順序去操作數(shù)據(jù)庫或者 Redis，帶來的副作用就是：數(shù)據(jù)庫本來是并發(fā)的，現(xiàn)在變成串行的了，加鎖或者排隊(duì)執(zhí)行的方案降低了系統(tǒng)性能，所以這個(gè)方案看起來不太可行。

第五種：采用雙刪

先刪除緩存，再更新數(shù)據(jù)庫，當(dāng)更新數(shù)據(jù)后休眠一段時(shí)間再刪除一次緩存。

方案推薦兩種：

1：項(xiàng)目整合quartz等定時(shí)任務(wù)框架，去實(shí)現(xiàn)延時(shí)3--5s再去執(zhí)行最后一步任務(wù) 。(推薦使用)

2：創(chuàng)建線程池，線程池中拿一個(gè)線程，線程體中延時(shí)3-5s再去執(zhí)行最后一步任務(wù)(不能忘了啟動(dòng)線程)

第六種：異步更新緩存(基于訂閱binlog的同步機(jī)制)

MySQL binlog增量訂閱消費(fèi)+消息隊(duì)列+增量數(shù)據(jù)更新到redis讀Redis

熱數(shù)據(jù)基本都在Redis寫MySQL:增刪改都是操作MySQL更新Redis數(shù)據(jù)：MySQ的數(shù)據(jù)操作binlog，來更新到Redis：

1)數(shù)據(jù)操作主要分為兩大塊：一個(gè)是全量(將全部數(shù)據(jù)一次寫入到redis)一個(gè)是增量(實(shí)時(shí)更新)。

這里說的是增量,指的是mysql的update、insert、delate變更數(shù)據(jù)。

2)讀取binlog后分析 ，利用消息隊(duì)列,推送更新各臺(tái)的redis緩存數(shù)據(jù)。

這樣一旦MySQL中產(chǎn)生了新的寫入、更新、刪除等操作，就可以把binlog相關(guān)的消息推送至Redis，Redis再根據(jù)binlog中的記錄，對(duì)Redis進(jìn)行更新。

其實(shí)這種機(jī)制，很類似MySQL的主從備份機(jī)制，因?yàn)镸ySQL的主備也是通過binlog來實(shí)現(xiàn)的數(shù)據(jù)一致性。

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

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

以上就是動(dòng)力節(jié)點(diǎn)小編介紹的"redis緩存怎么和數(shù)據(jù)庫同步到一致性呢"，希望對(duì)大家有幫助，如有疑問，請(qǐng)?jiān)诰€咨詢，有專業(yè)老師隨時(shí)為您務(wù)。