四月份的時候唇撬，有位朋友去美團面試，他說被問到Redis與MySQL雙寫一致性如何保證展融？ 這道題其實就是在問緩存和數(shù)據(jù)庫在雙寫場景下窖认，一致性是如何保證的？本文將跟大家一起來探討如何回答這個問題告希。
談?wù)勔恢滦?/p>
一致性就是數(shù)據(jù)保持一致扑浸，在分布式系統(tǒng)中，可以理解為多個節(jié)點中數(shù)據(jù)的值是一致的燕偶。
- 強一致性：這種一致性級別是最符合用戶直覺的喝噪，它要求系統(tǒng)寫入什么，讀出來的也會是什么指么，用戶體驗好酝惧，但實現(xiàn)起來往往對系統(tǒng)的性能影響大
- 弱一致性：這種一致性級別約束了系統(tǒng)在寫入成功后，不承諾立即可以讀到寫入的值伯诬，也不承諾多久之后數(shù)據(jù)能夠達到一致晚唇，但會盡可能地保證到某個時間級別（比如秒級別）后，數(shù)據(jù)能夠達到一致狀態(tài)
- 最終一致性：最終一致性是弱一致性的一個特例姑廉，系統(tǒng)會保證在一定時間內(nèi)缺亮，能夠達到一個數(shù)據(jù)一致的狀態(tài)。這里之所以將最終一致性單獨提出來桥言，是因為它是弱一致性中非常推崇的一種一致性模型萌踱，也是業(yè)界在大型分布式系統(tǒng)的數(shù)據(jù)一致性上比較推崇的模型
三個經(jīng)典的緩存模式
緩存可以提升性能、緩解數(shù)據(jù)庫壓力号阿，但是使用緩存也會導(dǎo)致數(shù)據(jù)不一致性的問題并鸵。一般我們是如何使用緩存呢？有三種經(jīng)典的緩存模式：
- Cache-Aside Pattern
- Read-Through/Write through
- Write behind
Cache-Aside Pattern
Cache-Aside Pattern扔涧，即旁路緩存模式园担，它的提出是為了盡可能地解決緩存與數(shù)據(jù)庫的數(shù)據(jù)不一致問題届谈。
Cache-Aside讀流程
Cache-Aside Pattern的讀請求流程如下：
1.讀的時候，先讀緩存弯汰，緩存命中的話艰山，直接返回數(shù)據(jù)
2.緩存沒有命中的話，就去讀數(shù)據(jù)庫咏闪，從數(shù)據(jù)庫取出數(shù)據(jù)曙搬，放入緩存后，同時返回響應(yīng)鸽嫂。
Cache-Aside 寫流程
Cache-Aside Pattern的寫請求流程如下：
更新的時候纵装，先更新數(shù)據(jù)庫，然后再刪除緩存据某。
Read-Through/Write-Through（讀寫穿透）
Read/Write Through模式中橡娄，服務(wù)端把緩存作為主要數(shù)據(jù)存儲。應(yīng)用程序跟數(shù)據(jù)庫緩存交互癣籽，都是通過抽象緩存層完成的挽唉。
Read-Through
Read-Through的簡要流程如下
Read-Through實際只是在Cache-Aside之上進行了一層封裝，它會讓程序代碼變得更簡潔才避，同時也減少數(shù)據(jù)源上的負載橱夭。
Write-Through
Write-Through模式下，當(dāng)發(fā)生寫請求時桑逝，也是由緩存抽象層完成數(shù)據(jù)源和緩存數(shù)據(jù)的更新,流程如下：
Write behind （異步緩存寫入）
Write behind跟Read-Through/Write-Through有相似的地方棘劣，都是由Cache Provider來負責(zé)緩存和數(shù)據(jù)庫的讀寫。它兩又有個很大的不同：Read/Write Through是同步更新緩存和數(shù)據(jù)的楞遏，Write Behind則是只更新緩存茬暇，不直接更新數(shù)據(jù)庫，通過批量異步的方式來更新數(shù)據(jù)庫寡喝。
這種方式下糙俗，緩存和數(shù)據(jù)庫的一致性不強，對一致性要求高的系統(tǒng)要謹慎使用预鬓。但是它適合頻繁寫的場景巧骚，MySQL的InnoDB Buffer Pool機制就使用到這種模式。
操作緩存的時候格二，刪除緩存呢劈彪，還是更新緩存？
一般業(yè)務(wù)場景顶猜，我們使用的就是Cache-Aside模式沧奴。
有些小伙伴可能會問， Cache-Aside在寫入請求的時候长窄，為什么是刪除緩存而不是更新緩存呢滔吠？
我們在操作緩存的時候纲菌，到底應(yīng)該刪除緩存還是更新緩存呢？我們先來看個例子：
1.線程A先發(fā)起一個寫操作疮绷，第一步先更新數(shù)據(jù)庫
2.線程B再發(fā)起一個寫操作翰舌，第二步更新了數(shù)據(jù)庫
3.由于網(wǎng)絡(luò)等原因，線程B先更新了緩存
4.線程A更新緩存矗愧。
這時候灶芝，緩存保存的是A的數(shù)據(jù)（老數(shù)據(jù)）郑原，數(shù)據(jù)庫保存的是B的數(shù)據(jù)（新數(shù)據(jù)）唉韭，數(shù)據(jù)不一致了，臟數(shù)據(jù)出現(xiàn)啦犯犁。如果是刪除緩存取代更新緩存則不會出現(xiàn)這個臟數(shù)據(jù)問題属愤。
更新緩存相對于刪除緩存，還有兩點劣勢：
如果你寫入的緩存值酸役，是經(jīng)過復(fù)雜計算才得到的話住诸。更新緩存頻率高的話，就浪費性能啦涣澡。
在寫數(shù)據(jù)庫場景多贱呐，讀數(shù)據(jù)場景少的情況下，數(shù)據(jù)很多時候還沒被讀取到入桂，又被更新了奄薇，這也浪費了性能呢(實際上，寫多的場景抗愁，用緩存也不是很劃算了)
雙寫的情況下馁蒂，先操作數(shù)據(jù)庫還是先操作緩存？
Cache-Aside緩存模式中蜘腌，有些小伙伴還是有疑問沫屡，在寫入請求的時候，為什么是先操作數(shù)據(jù)庫呢撮珠？為什么不先操作緩存呢沮脖？
假設(shè)有A、B兩個請求芯急，請求A做更新操作勺届，請求B做查詢讀取操作。
1.線程A發(fā)起一個寫操作志于，第一步del cache
2.此時線程B發(fā)起一個讀操作涮因，cache miss
3.線程B繼續(xù)讀DB，讀出來一個老數(shù)據(jù)
4.然后線程B把老數(shù)據(jù)設(shè)置入cache
5.線程A寫入DB最新的數(shù)據(jù)
醬紫就有問題啦伺绽，緩存和數(shù)據(jù)庫的數(shù)據(jù)不一致了养泡。緩存保存的是老數(shù)據(jù)嗜湃，數(shù)據(jù)庫保存的是新數(shù)據(jù)。因此澜掩，Cache-Aside緩存模式购披，選擇了先操作數(shù)據(jù)庫而不是先操作緩存。
緩存延時雙刪
有些小伙伴可能會說肩榕，不一定要先操作數(shù)據(jù)庫呀刚陡，采用緩存延時雙刪策略就好啦？什么是延時雙刪呢株汉？
1.先刪除緩存
2.再更新數(shù)據(jù)庫
3.休眠一會（比如1秒）筐乳，再次刪除緩存。
這個休眠一會乔妈，一般多久呢蝙云？都是1秒？
這個休眠時間 = 讀業(yè)務(wù)邏輯數(shù)據(jù)的耗時 + 幾百毫秒路召。 為了確保讀請求結(jié)束勃刨，寫請求可以刪除讀請求可能帶來的緩存臟數(shù)據(jù)。
刪除緩存重試機制
不管是延時雙刪還是Cache-Aside的先操作數(shù)據(jù)庫再刪除緩存股淡，如果第二步的刪除緩存失敗呢身隐，刪除失敗會導(dǎo)致臟數(shù)據(jù)哦~
刪除失敗就多刪除幾次呀,保證刪除緩存成功呀~ 所以可以引入刪除緩存重試機制
1.寫請求更新數(shù)據(jù)庫
2.緩存因為某些原因，刪除失敗
3.把刪除失敗的key放到消息隊列
4.消費消息隊列的消息唯灵，獲取要刪除的key
5.重試刪除緩存操作
讀取biglog異步刪除緩存
重試刪除緩存機制還可以贾铝，就是會造成好多業(yè)務(wù)代碼入侵。其實早敬，還可以通過數(shù)據(jù)庫的binlog來異步淘汰key忌傻。
以mysql為例 可以使用阿里的canal將binlog日志采集發(fā)送到MQ隊列里面，然后通過ACK機制確認處理這條更新消息搞监，刪除緩存水孩，保證數(shù)據(jù)緩存一致性
碼字不易 請大家給我點贊+關(guān)注+評論！一條龍
如果想要獲取學(xué)習(xí)資料琐驴，可在下方獲取聯(lián)系方式;
或者想要一起討論問題的也加入技術(shù)交流Q群
添加助手小姐姐的 VX: Mlzg5201314zz
或者加入技術(shù)交流Q群：614478470
記得備注[簡書]
