Redis和數(shù)據(jù)庫同步問題

緩存充當(dāng)數(shù)據(jù)庫

比如說Session這種訪問非常頻繁的數(shù)據(jù)，就適合采用這種方案；當(dāng)然了，既然沒有涉及到數(shù)據(jù)庫，那么也就不會存在一致性問題；

緩存充當(dāng)數(shù)據(jù)庫熱點(diǎn)緩存

讀操作

目前的讀操作有個固定的套路，如下：

客戶端請求服務(wù)器的時候，發(fā)現(xiàn)如果服務(wù)器的緩存中存在，則直接取服務(wù)器的；

如果緩存中不存在，則去請求數(shù)據(jù)庫，并且將數(shù)據(jù)庫計算出來的數(shù)據(jù)回填給緩存；

返回數(shù)據(jù)給客戶端；

寫操作

各種情況會導(dǎo)致數(shù)據(jù)庫和緩存出現(xiàn)不一致的情況，這就是緩存和數(shù)據(jù)庫的雙寫一致性問題；

目前緩存存在三種策略，分別是

• Cache Aside 更新策略：同時更新緩存和數(shù)據(jù)庫；

• Read/Write Through 更新策略：先更新緩存，緩存負(fù)責(zé)同步更新數(shù)據(jù)庫；

• Write Behind Caching 更新策略：先更新緩存，緩存定時異步更新數(shù)據(jù)庫；

三種策略各有優(yōu)缺點(diǎn)，可以根據(jù)業(yè)務(wù)場景使用；

Cache Aside 更新策略

該策略大概的流程就是請求過來時先從緩存中取，如果命中緩存的話，則直接返回讀取的數(shù)據(jù)；相反如果沒有命中的話，接著會從數(shù)據(jù)庫中成功獲取到數(shù)據(jù)后，再去清除緩存中的數(shù)據(jù)；具體流程圖如下：

但是以上在某些特殊的情況下是存在問題：

問題1：先更新數(shù)據(jù)庫，后更新緩存

兩個線程在高并發(fā)的情況下就會可能出現(xiàn)數(shù)據(jù)臟讀的情況：

線程A執(zhí)行寫操作，成功更新數(shù)據(jù)庫；

線程B同樣執(zhí)行和線程A一樣的操作，但是在線程A執(zhí)行更新緩存的過程中，線程B更新了新的數(shù)據(jù)庫數(shù)據(jù)到緩存中；

線程A在線程B全部操作完成以后才將相對老的數(shù)據(jù)又更新到了緩存中；

問題2：先刪除緩存，后更新數(shù)據(jù)庫

同樣的，在高并發(fā)場景下同樣會出現(xiàn)臟讀的情況：

線程A成功刪除了緩存，等待更新數(shù)據(jù)庫；

線程B進(jìn)行讀操作，由于此時緩存已經(jīng)被刪除了，因此線程B重新從數(shù)據(jù)庫中獲取老的數(shù)據(jù)并且更新到了緩存中；

線程A在線程B完成了整個的讀操作以后，才更新數(shù)據(jù)庫，此時緩存中的數(shù)據(jù)依舊是老的數(shù)據(jù)；

問題3：先更新數(shù)據(jù)庫，后刪除緩存

目前這是比較普遍的操作，即使它還是有可能會出現(xiàn)臟讀的情況：

線程A進(jìn)行讀操作，此時正好沒有命中緩存，接著請求數(shù)據(jù)庫；

線程B進(jìn)行寫操作，在線程A沒有從數(shù)據(jù)庫中獲取到數(shù)據(jù)之前，把數(shù)據(jù)寫入到數(shù)據(jù)庫中，并且還成功刪除了緩存；

線程A在線程B完成了整個的寫操作以后，才將相對老的數(shù)據(jù)更新到緩存中；

但是以上的情況比較不會出現(xiàn)，這是因?yàn)樯鲜銮闆r需要滿足線程A的讀操作要慢于線程B的寫操作，但是在現(xiàn)實(shí)過程中，讀操作通常都是要快于寫操作得多的，但是為了避免發(fā)生以上的情況，通常都是要給緩存加上一個過期的時間；

但是設(shè)想一下，如果上面的刪除緩存失敗了怎么辦呢，這樣顯然會導(dǎo)致數(shù)據(jù)臟讀的情況，我覺得方案如下：

設(shè)置緩存的過期時間（必須要做）；

提供一個保障重試機(jī)制，將哪些刪除失敗的key提供給消息隊列去消費(fèi)；

從消息隊列取出這些key再次進(jìn)行刪除，失敗再次加入到消息隊列中，超過一定次數(shù)以上則人工介入；

但是以上情況需要在業(yè)務(wù)代碼中進(jìn)行操作，顯然得需要進(jìn)行解耦；

目前我們公司就是使用該方案，具體過程為在更新數(shù)據(jù)庫數(shù)據(jù)的時候，數(shù)據(jù)庫會以binlog日志的形式保存下來，通過canal開源軟件將binlog解析成程序語言可以解析的地步，接著訂閱程序獲取到這些數(shù)據(jù)以后，嘗試刪除緩存操作，如果操作失敗的話，則將其加入到消息隊列中，重復(fù)消費(fèi)，當(dāng)刪除操作的失敗次數(shù)到達(dá)一定的次數(shù)以后，還是得人工介入。

Read/Write Through 更新策略

該模式下，程序只需要維護(hù)緩存即可，數(shù)據(jù)庫的同步工作交由緩存來同步更新；

該策略具體又分為兩種：

Read Through：在查詢的過程中更新緩存；

Write Through：在寫操作的過程中如果命中緩存，則直接更新緩存，數(shù)據(jù)庫則由緩存自己同步去更新；

Write Behind Caching 更新策略

該策略只更新緩存，不會立馬更新數(shù)據(jù)庫，只會在一定的時間異步的批量去操作數(shù)據(jù)庫；這樣的好處在于直接操作緩存，效率極高，并且操作數(shù)據(jù)是異步的，還可以將多次的操作數(shù)據(jù)庫語句合并到一個事務(wù)中一起提交，因此效率很客觀；

但是，該策略沒有辦法做到數(shù)據(jù)強(qiáng)一致性，并且實(shí)現(xiàn)邏輯相對是比較復(fù)雜的，因?yàn)樗枰_認(rèn)哪些是需要更新到數(shù)據(jù)庫的，哪些是僅僅想要存儲在緩存中的；

比較

目前通常使用的是第一種策略中的先更新數(shù)據(jù)庫，后更新緩存；其他的相較比起來實(shí)現(xiàn)都比較復(fù)雜；

最后想說的是，緩存本來就是為了犧牲強(qiáng)一致性來提高性能的，所以肯定會存在一定的延遲時間，我們只需要保證最終的數(shù)據(jù)一致性即可；

最后

以上是我在學(xué)習(xí)過程中的總結(jié)（其中很多內(nèi)容都用了其他博客的內(nèi)容），感恩～

【原創(chuàng)】分布式之?dāng)?shù)據(jù)庫和緩存雙寫一致性方案解析

面試前必須要知道的Redis面試題

使用緩存的正確姿勢

轉(zhuǎn)載于:https://www.cnblogs.com/George1994/p/10601244.html

總結(jié)

以上是生活随笔為你收集整理的Redis和数据库 数据同步问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。