1 Mysql查完數(shù)據(jù)，再同步寫入到Redis中

缺點(diǎn)1：會(huì)對(duì)接口造成延遲，因?yàn)橥綄懭雛edis本身就有延遲，并且還要做重試，如果redis寫入失敗，還需要重試，那就更費(fèi)時(shí)間了。

缺點(diǎn)2：不解耦，如果redis崩了，那直接卡線程了

缺點(diǎn)3：如果人為該數(shù)據(jù)庫，那就沒法同步了， 除非再人為刪除對(duì)應(yīng)的Redis，但刪除Redis這個(gè)過程也有個(gè)時(shí)間差

2 Mysql查完數(shù)據(jù)，通過發(fā)送MQ，在消費(fèi)者線程去同步Redis

缺點(diǎn)1：多了層MQ，也就是會(huì)有很大的概率導(dǎo)致同步延遲問題.

缺點(diǎn)2：要對(duì)MQ的可用性做預(yù)防

缺點(diǎn)3：如果人為該數(shù)據(jù)庫，那就沒法同步了

優(yōu)點(diǎn)1：可以大幅減少接口的延遲返回的問題

優(yōu)點(diǎn)2：MQ本身有重試機(jī)制，無需人工去寫重試代碼

優(yōu)點(diǎn)3：解耦，把查詢Mysql和同步Redis完全分離，互不干擾

3 訂閱Mysql的Binlog文件(可借助Canal來進(jìn)行)

CanalServer會(huì)偽裝成MysqlServer從庫，去訂閱MysqlServer主庫的Binlog文件

Canal啟動(dòng)的時(shí)候會(huì)配置對(duì)應(yīng)的消息MQ(RabbitMQ, RocketMQ, Kafka), 監(jiān)聽到Binlog文件有變化是，會(huì)把變化的sql語句轉(zhuǎn)換成json格式，并作為消息內(nèi)容發(fā)送到MQ中

項(xiàng)目中只要監(jiān)聽對(duì)應(yīng)MQ，就能拿到Binlog改動(dòng)的內(nèi)容，Json數(shù)據(jù)中有明確的操作類型(CURD), 以及對(duì)應(yīng)的數(shù)據(jù)。把對(duì)應(yīng)數(shù)據(jù)同步到redis即可

缺點(diǎn)1：canal訂閱Binlog的整個(gè)操作過程是單線程的，所以面臨超高并發(fā)的情況下，性能可能不太出色。當(dāng)然可以部署多個(gè)Canal 與 多個(gè)消費(fèi)者，但是要注意消息重復(fù)消費(fèi)問題，做好冪等性校驗(yàn)

優(yōu)點(diǎn)1：即使人為改數(shù)據(jù)庫，也會(huì)監(jiān)聽到，并且也會(huì)同步

優(yōu)點(diǎn)2：異步同步，不會(huì)對(duì)接口返回有格外延遲

4 延遲雙刪

在執(zhí)行修改sql之前，先將redis的數(shù)據(jù)刪除

執(zhí)行更新sql

延遲一段時(shí)間

再次刪除redis的數(shù)據(jù)

// 延遲雙刪偽代碼
deleteRedisCache(key);   // 刪除redis緩存
updateMysqlSql(obj);        // 更新mysql
Thread.sleep(100);           // 延遲一段時(shí)間
deleteRedisCache(key);   // 再次刪除該key的緩存

缺點(diǎn)：這個(gè)延遲時(shí)間不好把控，到底延遲多久，這個(gè)很難去評(píng)估

擴(kuò)展： 如果不使用延遲雙刪，僅僅是delete緩存，然后改mysql數(shù)據(jù)。只有這兩步會(huì)出現(xiàn)什么問題呢？

5. 單個(gè)請(qǐng)求，單線程沒問題，高并發(fā)多線程下會(huì)出問題

6. 如果Thread1線程要更新數(shù)據(jù)，此時(shí)Thread1線程把redis清理了

7. 此時(shí)Thread2線程來了，但Thread1還沒有更新mysql完畢

8. Thread2查詢r(jià)edis肯定是null，此時(shí)Thread2就要查mysql了，然后再把查到的數(shù)據(jù)寫到緩存

9. 由于Thread1還沒來得及修改mysql數(shù)據(jù)，所以此時(shí)Thread2查出來的數(shù)據(jù)是【舊數(shù)據(jù)】，Thread2把舊數(shù)據(jù)又寫入Redis 了

10. 此時(shí)Thread3線程來了，查詢Redis發(fā)現(xiàn)有數(shù)據(jù)，則直接拿緩存數(shù)據(jù)了，此時(shí)【Thread3查出來的是舊數(shù)據(jù)】，直接帶著舊數(shù)據(jù)返回了，這就是問題所在

11. 而延遲雙刪的第二次刪除作用就是防止Thread2把舊數(shù)據(jù)又寫入了，有了延遲雙刪，Thread3查詢Redis的時(shí)候還是null，就會(huì)從mysql 去拿最新數(shù)據(jù)了

12. 所以正常的這個(gè)延遲時(shí)間，應(yīng)該是Thread2查緩存到拿mysql數(shù)據(jù)，到再保存到redis這整個(gè)時(shí)間，作為Thread1的延遲時(shí)間，但是這個(gè)Thread2這個(gè)過程的時(shí)間會(huì)受到很多因素影響，因此很難斷定究竟會(huì)是多久

5 延遲雙寫

// 延遲雙寫偽代碼
updateMysqlSql(obj);        // 更新mysql
addRedis(key);   // 再次刪除該key的緩存

上述代碼缺陷;

• 高并發(fā)下，兩條線程同時(shí)執(zhí)行上面代碼，并對(duì)mysql 修改，且修改內(nèi)容不通，可能會(huì)導(dǎo)致Redis與Mysql數(shù)據(jù)不一致
• T1線程執(zhí)行完updateMysqlSql，釋放了行鎖，此時(shí)T2線程再執(zhí)行updateMysqlSql 與 addRedis， 最后T1執(zhí)行addRedis，這種情況會(huì)導(dǎo)致數(shù)據(jù)庫改成了T2線程的數(shù)據(jù)，但Redis卻是T1線程的數(shù)據(jù)

優(yōu)化

// 完美延遲雙寫偽代碼
開啟事務(wù)
updateMysqlSql(obj);        // 更新mysql
addRedis(key);   // 再次刪除該key的緩存
提交事務(wù)

上述代碼改正：

把兩句代碼放到一個(gè)事務(wù)里面，只有T1執(zhí)行完Mysql 與 Redis的時(shí)候，T2才能開始執(zhí)行，就可以保證數(shù)據(jù)一致性。推薦使用分布式鎖

雙寫缺點(diǎn)：Mysql 與 Redis是單線程的。性能方面不行，因此不推薦使用

6 總結(jié)

推薦使用Canal的方式，進(jìn)行異步同步。其次是MQ方式

到此這篇關(guān)于淺談MySQL數(shù)據(jù)同步到 Redis 緩存的幾種方法的文章就介紹到這了,更多相關(guān)MySQL數(shù)據(jù)同步到Redis緩存內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論