前言
四月份的時候，有位朋友去美團面試，他說被問到Redis與MySQL雙寫一致性如何保證？ 這道題其實就是在問緩存和數據庫在雙寫場景下，一致性是如何保證的？本文將跟大家一起來探討如何回答這個問題。談談一致性
一致性就是數據保持一致，在分佈式系統中，可以理解爲多個節點中數據的值是一致的。
- 強一致性：這種一致性級別是最符合用戶直覺的，它要求系統寫入什麼，讀出來的也會是什麼，用戶體驗好，但實現起來往往對系統的性能影響大
- 弱一致性：這種一致性級別約束了系統在寫入成功後，不承諾立即可以讀到寫入的值，也不承諾多久之後數據能夠達到一致，但會盡可能地保證到某個時間級別（比如秒級別）後，數據能夠達到一致狀態
- 最終一致性：最終一致性是弱一致性的一個特例，系統會保證在一定時間內，能夠達到一個數據一致的狀態。這裏之所以將最終一致性單獨提出來，是因爲它是弱一致性中非常推崇的一種一致性模型，也是業界在大型分佈式系統的數據一致性上比較推崇的模型
三個經典的緩存模式
緩存可以提升性能、緩解數據庫壓力，但是使用緩存也會導致數據不一致性的問題。一般我們是如何使用緩存呢？有三種經典的緩存模式：
- Cache-Aside Pattern
- Read-Through/Write through
- Write behind
Cache-Aside Pattern
Cache-Aside Pattern，即旁路緩存模式，它的提出是爲了儘可能地解決緩存與數據庫的數據不一致問題。
Cache-Aside讀流程
Cache-Aside Pattern的讀請求流程如下：
讀的時候，先讀緩存，緩存命中的話，直接返回數據
緩存沒有命中的話，就去讀數據庫，從數據庫取出數據，放入緩存後，同時返回響應。
Cache-Aside 寫流程
Cache-Aside Pattern的寫請求流程如下：
更新的時候，先更新數據庫，然後再刪除緩存。
Read-Through/Write-Through（讀寫穿透）
Read/Write Through模式中，服務端把緩存作爲主要數據存儲。應用程序跟數據庫緩存交互，都是通過抽象緩存層完成的。
Read-Through
Read-Through的簡要流程如下
從緩存讀取數據，讀到直接返回
如果讀取不到的話，從數據庫加載，寫入緩存後，再返回響應。
這個簡要流程是不是跟Cache-Aside很像呢？其實Read-Through就是多了一層Cache-Provider，流程如下：
Read-Through實際只是在Cache-Aside之上進行了一層封裝，它會讓程序代碼變得更簡潔，同時也減少數據源上的負載。
Write-Through
Write-Through模式下，當發生寫請求時，也是由緩存抽象層完成數據源和緩存數據的更新,流程如下：
Write behind （異步緩存寫入）
Write behind跟Read-Through/Write-Through有相似的地方，都是由Cache Provider來負責緩存和數據庫的讀寫。它兩又有個很大的不同：Read/Write Through是同步更新緩存和數據的，Write Behind則是隻更新緩存，不直接更新數據庫，通過批量異步的方式來更新數據庫。
這種方式下，緩存和數據庫的一致性不強，對一致性要求高的系統要謹慎使用。但是它適合頻繁寫的場景，MySQL的InnoDB Buffer Pool機制就使用到這種模式。
操作緩存的時候，刪除緩存呢，還是更新緩存？
一般業務場景，我們使用的就是Cache-Aside模式。
我們在操作緩存的時候，到底應該刪除緩存還是更新緩存呢？我們先來看個例子：
線程A先發起一個寫操作，第一步先更新數據庫
線程B再發起一個寫操作，第二步更新了數據庫
由於網絡等原因，線程B先更新了緩存
線程A更新緩存。
這時候，緩存保存的是A的數據（老數據），數據庫保存的是B的數據（新數據），數據不一致了，髒數據出現啦。如果是刪除緩存取代更新緩存則不會出現這個髒數據問題。
更新緩存相對於刪除緩存，還有兩點劣勢：
如果你寫入的緩存值，是經過複雜計算纔得到的話。更新緩存頻率高的話，就浪費性能啦。
在寫數據庫場景多，讀數據場景少的情況下，數據很多時候還沒被讀取到，又被更新了，這也浪費了性能呢(實際上，寫多的場景，用緩存也不是很划算了)
雙寫的情況下，先操作數據庫還是先操作緩存？
Cache-Aside緩存模式中，有些小夥伴還是有疑問，在寫入請求的時候，爲什麼是先操作數據庫呢？爲什麼不先操作緩存呢？
假設有A、B兩個請求，請求A做更新操作，請求B做查詢讀取操作。
- 線程A發起一個寫操作，第一步del cache
- 此時線程B發起一個讀操作，cache miss
- 線程B繼續讀DB，讀出來一個老數據
- 然後線程B把老數據設置入cache
- 線程A寫入DB最新的數據
醬紫就有問題啦，緩存和數據庫的數據不一致了。緩存保存的是老數據，數據庫保存的是新數據。因此，Cache-Aside緩存模式，選擇了先操作數據庫而不是先操作緩存。
緩存延時雙刪//加入Java開發交流君樣：756584822一起吹水聊天
先刪除緩存
再更新數據庫
休眠一會（比如1秒），再次刪除緩存。
這個休眠一會，一般多久呢？都是1秒？
這個休眠時間 = 讀業務邏輯數據的耗時 + 幾百毫秒。 爲了確保讀請求結束，寫請求可以刪除讀請求可能帶來的緩存髒數據。
刪除緩存重試機制
不管是延時雙刪還是Cache-Aside的先操作數據庫再刪除緩存，如果第二步的刪除緩存失敗呢，刪除失敗會導致髒數據哦~
刪除失敗就多刪除幾次呀,保證刪除緩存成功呀~ 所以可以引入刪除緩存重試機制
寫請求更新數據庫
緩存因爲某些原因，刪除失敗
把刪除失敗的key放到消息隊列
消費消息隊列的消息，獲取要刪除的key
重試刪除緩存操作
讀取biglog異步刪除緩存
重試刪除緩存機制還可以，就是會造成好多業務代碼入侵。其實，還可以通過數據庫的binlog來異步淘汰key。
以mysql爲例 可以使用阿里的canal將binlog日誌採集發送到MQ隊列裏面，然後通過ACK機制確認處理這條更新消息，刪除緩存，保證數據緩存一致性緩存因爲某些原因，刪除失敗
把刪除失敗的key放到消息隊列
作者：撿田螺的小男孩
鏈接：https://juejin.cn/post/6964531365643550751
來源：掘金
[圖片上傳失敗...(image-9e8b1d-1621690328268)]
最後希望大家可以給我一個三連也算是對我的一個小小的支持，我們都是CSDN一家人啊