Redis和DB数据一致性解决方案
生活随笔
收集整理的這篇文章主要介紹了
Redis和DB数据一致性解决方案
小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.
問題出現(xiàn)原因
- 并發(fā)時(shí)候無法保證讀寫的先后順序,如果刪掉了緩存還沒來得及寫庫,另外一個(gè)縣城就多來讀取,發(fā)現(xiàn)緩存為空就去讀取數(shù)據(jù)庫并且寫入緩存,這時(shí)候緩存中就是臟數(shù)據(jù)
- 如果先寫庫,在刪除緩存前,寫庫的線程宕機(jī),沒有刪除掉緩存,則也會(huì)出現(xiàn)不一致的情況
- 如果redis集群,在注冊(cè)模式中,寫主庫,讀從庫,也會(huì)出現(xiàn)redis復(fù)制存在的一些延遲操作,也可能導(dǎo)致數(shù)據(jù)不一致
解決方案
雙刪除+超時(shí)
- 寫庫前后都加上redis.del(key)操作,并且舍得合了的超時(shí)時(shí)間,這樣最差的情況就是在超時(shí)時(shí)間之內(nèi)存在不太一致,當(dāng)然這種情況極其少見,可能的原因就是服務(wù)器宕機(jī),此種情況可以滿足絕大多數(shù)需求
- 這種策略要考慮redis的和數(shù)據(jù)庫注冊(cè)同步的耗時(shí),所以第二次刪除前最好先等待一段時(shí)間,等待同步完成,然后在刪除,這樣缺點(diǎn)也會(huì)增加線程占用時(shí)間。
通過讀取binlog的方式,異步淘汰緩存
- 好處在于業(yè)務(wù)上的侵入性低,將緩存和數(shù)據(jù)庫的不一致時(shí)間盡量縮小。
- binlog介紹:mysql的binlog日志作用在于記錄mysql內(nèi)部的增刪改查等對(duì)mysql有更新操作的內(nèi)容的記錄,對(duì)數(shù)據(jù)的select已經(jīng)show不會(huì)被binlog記錄,主要用于數(shù)據(jù)庫的主從復(fù)制,以及增量恢復(fù)。
- binlog日志模式:
- STATEMENT模式(SBR):每條修改數(shù)據(jù)庫的sql都會(huì)記錄到binlog中,有點(diǎn)事并不需要記錄每條sql和每一行數(shù)據(jù)的變化,有點(diǎn)在于減少binlog日志,缺點(diǎn)是某些情況下master-slave數(shù)據(jù)不一致比如,sleep()函數(shù),last_insert_id()
- ROW模式(RBR):不記錄每條sql的上下文信息,僅需要記錄那條數(shù)據(jù)被修改了,修改成什么樣,不會(huì)出現(xiàn)某些特定的情況下的存儲(chǔ)過程或者function或者targger的調(diào)用和出發(fā)無法被復(fù)制的問題,但是會(huì)產(chǎn)生大量的日志
- MIXED模式(MBR)以上兩種模式的混合使用,一般復(fù)制使用STATEMENT模式保持binlog,對(duì)于STATEMENT模式無法復(fù)制的操作使用ROW模式保存binlog,mysql會(huì)根據(jù)執(zhí)行的sql語句選擇日志保持方式
mysql的UDF
- 這種方法思路是通過數(shù)據(jù)庫中的Targger調(diào)用自定義的函數(shù)庫來觸發(fā)對(duì)redis的操作,但是這個(gè)有一定學(xué)習(xí)成本,需要基于mysql的APi進(jìn)行開發(fā)使用的C++語言,阿里早期的解決方案
binlog具體實(shí)施方案
- 通過使用open-replicator解析binlog
- 使用canal進(jìn)行同步—阿里框架
canal介紹(http://www.cnblogs.com/duanxz/p/5062833.html)
- mysql主從負(fù)責(zé)工作原理
- 負(fù)責(zé)分為三步
- canal工作原理
canal官網(wǎng)
- quickStart:https://github.com/alibabatech/canal/wiki/QuickStart
- 項(xiàng)目代碼:https://github.com/alibabatech/canal
- 阿里升級(jí)版本otter:https://github.com/alibaba/otter
總結(jié)
以上是生活随笔為你收集整理的Redis和DB数据一致性解决方案的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Redis数据结构以及对应存储策略
- 下一篇: Rx2.0后台开发分享