Redis與MySQL雙寫一致性如何保證？ （美團二面）

##.markdown-body{word-break:break-word;line-height:1.75;font-weight:400;font-size:16px;overflow-x:hidden;color:#252933 } .markdown-body h1,.markdown-body h2,.markdown-body h3,.markdown-body h4,.markdown-body h5,.markdown-body h6{line-height:1.5;margin-top:35px;margin - bottom:10px;padding-bottom:5px}.markdown-body h1{font-size:24px;line-height:38px;margin-bottom:5px}.markdown-body h2{font-size:22px;line-height : 34px;padding-bottom:12px;border-bottom:1pxsolid #ececec}.markdown-body h3{font-size:20px;line-height:28px}.markdown-body h4{font-size:18px;line-高度： 26px}.markdown-body h5{font-size:17px;line-height:24px}.markdown-body h6{font-size:16px;line-height:24px}.markdown-body p{line-height:繼承; margin-top:22px;margin-bottom:22px}.markdown-body img{max-width:100%}.markdown-body hr{border:none;border-top:1pxsolid #ddd;margin-top: 32px;margin -bottom:32px}.markdown-body程式碼{word-break:break-word;border-radius:2px;overflow-x:auto;background-color:#fff5f5;color:#ff502c;font-size: .87em;填充:.065em .4em}.markdown-body程式碼,.markdown-body pre{font-family:Menlo,Monaco,Consolas,Courier New,monospace}.markdown-body pre{overflow:auto;position:relative ;line- height:1.75}.markdown-body pre>code{font-size:12px;padding:15px 12px;margin:0;word-break:normal;display:block;overflow-x:auto;color:#333 ;背景： #f8f8f8}.markdown-body a{text-decoration:none;color:#0269c8;border-bottom:1pxsolid #d1e9ff}.markdown-body a:active,.markdown-body a:hover{顏色: #275b8c}. markdown-body table{display:inline-block!important;font-size:12px;width:auto;max-width:100%;overflow:auto;border:1pxsolid #f6f6f6}.markdown-body thead {背景:#f6f6f6 ;顏色:#000;text-align:left}.markdown-body tr:nth-child(2n){背景顏色:#fcfcfc}.markdown-body td,.markdown-body th{填充:12px 7px;line- height:24px}.markdown-body td{min-width:120px}.markdown-body blockquote{color:#666;padding:1px 23px;margin:22px 0;border-left:4pxsolid # cbcbcb; }.markdown-body blockquote:after{display:block;content:""}.markdown-body blockquote>p{margin:10px 0}.markdown-body ol,.markdown-body ul {padding-left:28px}. markdown-body ol li,.markdown-body ul li{margin-bottom:0;list-style:inherit}.markdown-body ol li .task-list-item,.markdown-body ul li .task-list-item {list-style:none}.markdown-body ol li .task-list-item ol,.markdown-body ol li .task-list-item ul,.markdown-body ul li. 任務清單項目ol,.markdown- body ul li .任務清單項目ul{margin-top:0}.markdown-body ol ol,.markdown-body ol ul,.markdown-body ul ol,.markdown -body ul ul{margin-top:3px}. markdown-body ol li{padding-left:6px}.markdown-body .contains-task-list{padding-left:0}.markdown-body .task-list- item{list-style:none}@media (max -width:720px){.markdown-body h1{font-size:24px}.markdown-body h2{font-size:20px}.markdown-body h3{font-大小:18px}}. markdown-body pre,.markdown-body pre>code.hljs{顏色:#333;背景:#f8f8f8}.hljs-comment,.hljs-quote{顏色:# 998;字體樣式:斜體}.hljs-關鍵字,.hljs-選擇器-標籤,.hljs-subst{顏色:#333;字體粗細:700}.hljs-文字,.hljs-數字,.hljs-標籤.hljs-attr,.hljs-模板變數,. hljs-變數{顏色:青色}.hljs-doctag,.hljs-string{顏色:#d14}.hljs-section,.hljs-selector-id,.hljs -標題{顏色:#900;字體權重:700} .hljs-subst{字型權重:400}.hljs-class .hljs-title,.hljs-type{顏色:#458;字型權重:700} .hljs-attribute,.hljs-name,.hljs-tag{color :navy;font-weight:400}.hljs-link,.hljs-regexp{color:#009926}.hljs-bullet,.hljs-symbol{color:#990073}.hljs-built_in,.hljs-builtin-name {顏色:#0086b3}.hljs-meta{顏色:#999;font-weight:700}.hljs-deletion{背景:#fdd}.hljs -addition{background:#dfd}.hljs-emphasis{font-style :italic}.hljs-strong{font-weight:700}前言

四月份的時候，有位去美團面試，他說被問到Redis與MySQL雙寫一致性如何保證？這題其實就是在問伺服器和資料庫在雙寫場景下，一致性是如何保證的？本文將跟大家一起來如何回答這個問題。

• #github位址，感謝每一顆星星

談談一致性

一致性就是資料保持一致，在多元化系統中，可以理解為多個節點中資料的值是一致的。

• 強一致性：這種一致性等級是最符合使用者直覺的，它要求系統寫入什麼，讀出來的也會是什麼，使用者體驗好，但實現起來往往對系統的效能影響大
• 弱一致性：這種一致性等級約束了系統在寫入成功後，不承諾立即可以讀到寫入的值，也不承諾多久之後資料能夠達到一致，但會盡可能地保證到某個時間等級（例如秒等級）後，資料能夠達到一致狀態
• 最終一致性：最終一致性是弱一致性的一個特例，系統會保證在一定時間內，能夠達到一個數據一致的狀態。這裡之所以將最終一致性單獨提出來，是因為它是弱一致性中非常推崇的一種一致性模型，也是業界在大型分散式系統的數據一致性上比較推崇的模型

#三個經典的快取模式

快取可以提升效能、緩解資料庫壓力，但使用快取也會導致資料不一致性的問題。一般我們是如何使用快取呢？有三種經典的快取模式：

• Cache-Aside Pattern
• Read-Through/Write through
• Write behind

#Cache -Aside Pattern

Cache-Aside Pattern，即旁路快取模式，它的提出是為了盡可能解決快取與資料庫的資料不一致問題。

Cache-Aside讀取流程

Cache-Aside Pattern#的讀取請求流程如下：

# #讀的時候，先讀緩存，緩存命中的話，直接返回數據
1. 緩存沒有命中的話，就去讀數據庫，從數據庫取出數據，放入緩存後，同時返回響應。

Cache-Aside 寫入流程

Cache-Aside Pattern的寫入請求流程如下：

更新的時候，先

更新資料庫，再刪除快取。

Read-Through/Write-Through（讀寫穿透）

#Read/Write Through模式中，服務端把快取作為主要資料儲存。應用程式跟資料庫快取交互，都是透過抽象快取層完成的。

Read-Through

Read-Through的簡要流程如下

##從快取讀取數據，讀到直接返回

1. 如果讀取不到的話，從資料庫加載，寫入快取後，再回傳回應。
2. 這個簡單流程是不是跟

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

模式。 有些小夥伴可能會問， Cache-Aside在寫入請求的時候，為什麼是刪除快取而不是更新快取呢？

我們在操作快取的時候，到底該刪除快取還是更新快取呢？我們先來看個範例：

1. 執行緒A先發起一個寫入操作，第一步先更新資料庫
2. 執行緒B再發起一個寫入操作，第二步更新了資料庫
3. 由於網路等原因，線程B先更新了快取
4. #線程A更新快取。

這時候，快取保存的是A的資料（舊資料），資料庫保存的是B的資料（新資料），資料不一致了，髒資料出現啦。如果是刪除快取取代更新快取則不會出現這個髒資料問題。

更新快取相對於刪除快取，還有兩點劣勢：

• 如果你寫入的快取值，是經過複雜計算才得到的話。更新快取頻率高的話，就浪費效能啦。
• 在寫資料庫場景多，讀資料場景少的情況下，資料很多時候還沒被讀取到，又被更新了，這也浪費了效能呢(實際上，寫多的場景，用快取也不是很划算了)

雙寫的情況下，先操作資料庫還是先操作快取？

Cache-Aside快取模式中，有些小夥伴還是有疑問，在寫入請求的時候，為什麼是先操作資料庫呢？為什麼不先操作快取？

假設有A、B兩個請求，請求A做更新操作，請B做查詢讀取操作。

1. 線程A發起一個寫入操作，第一步del cache
2. 此時線程B發起一個讀取操作，cache miss
3. 線程B繼續讀DB，讀出來一個老資料
4. 然後執行緒B把舊資料設定入cache
5. #執行緒A寫入DB最新的資料

醬紫就有問題啦，快取和資料庫的資料不一致了。快取保存的是舊數據，資料庫保存的是新數據。因此，Cache-Aside快取模式，選擇了先操作資料庫而不是先操作快取。

快取延時雙刪

有些小夥伴可能會說，不一定要先操作資料庫呀，採用快取延時雙刪策略就好啦？什麼是延時雙刪呢？

1. 先刪除快取
2. 再更新資料庫
3. 休眠一會（例如1秒），再刪除快取。

這個休眠一會，通常多久呢？都是1秒？

這個休眠時間 =  讀業務邏輯資料的耗時 幾百毫秒。為了確保讀取請求結束，寫入請求可以刪除讀取請求可能帶來的快取髒資料。

刪除快取重試機制

不管是延時雙刪還是Cache-Aside的先操作資料庫再刪除快取，如果第二步驟的刪除快取失敗呢，刪除失敗會導致髒資料哦~

刪除失敗就多刪除幾次呀,保證刪除快取成功呀~ 所以可以引入刪除緩存重試機制

1. 寫入請求更新資料庫
## 快取因為某些原因，刪除失敗
2. #把刪除失敗的key放到訊息佇列
3. 消費訊息佇列的訊息，取得要刪除的key
4. #重試刪除快取作業
5. ##讀取biglog非同步刪除快取

重試刪除快取機制還可以，就是會造成好多業務程式碼入侵。其實，還可以透過

資料庫的binlog來非同步淘汰key

。

以mysql為例可以使用阿里的canal將binlog日誌擷取傳送到MQ佇列裡面，然後透過ACK機制確認處理這條更新訊息，刪除緩存，保證數據快取一致性

推薦學習：《

Redis影片教學

》

以上是Redis與MySQL雙寫一致性如何保證？ （美團二面）的詳細內容。更多資訊請關注PHP中文網其他相關文章！