Redis高級(jí)系列-緩存雙寫一致性

1. 什么叫做緩存雙寫一致性？

Redis緩存雙寫一致性是指在更新數(shù)據(jù)庫數(shù)據(jù)后，同時(shí)更新緩存數(shù)據(jù)以保持?jǐn)?shù)據(jù)一致性的策略，總的來說，就是寫入redis和寫入數(shù)據(jù)庫的數(shù)據(jù)要保持一致

2. 緩存雙寫一致性有那些解決方案？

2.1 Cache Aside Pattern(旁路緩存模式)

旁路緩存模式，字面意思理解：緩存是旁路，緩存相對(duì)與應(yīng)用程序和數(shù)據(jù)庫是旁路，應(yīng)用程序可以直接繞過緩存訪問數(shù)據(jù)庫

在Cache Aside模式中，應(yīng)用程序首先從緩存中讀取數(shù)據(jù)，如果緩存中不存在，則從數(shù)據(jù)庫中讀取數(shù)據(jù)，并將數(shù)據(jù)寫入緩存中。在更新數(shù)據(jù)時(shí)，應(yīng)用程序首先更新數(shù)據(jù)庫中的數(shù)據(jù)，然后刪除緩存中的數(shù)據(jù)。當(dāng)下一次請(qǐng)求到來時(shí)，應(yīng)用程序會(huì)從數(shù)據(jù)庫中讀取最新的數(shù)據(jù)，并將其寫入緩存中

那為什么要先更新數(shù)據(jù)庫在刪除緩存了？我們?cè)倏纯磶追N更新策略

延遲雙刪

經(jīng)過我們對(duì)Cache Aside Pattern四種方案的八種場(chǎng)景進(jìn)行仔細(xì)分析，我們大體上確定了先更數(shù)據(jù)庫再刪緩存的方案。但是這種方案也并不完美，假設(shè)我們更新數(shù)據(jù)庫成功了，刪除緩存失敗了，那么同樣會(huì)出現(xiàn)一致性問題。為了解決這種場(chǎng)景下的一致性問題，我們進(jìn)一步引入了延遲雙刪方案來解決。

• 為什么要做兩次緩存刪除呢？

從上圖“延遲雙刪”中我們可以很清晰地看到，數(shù)據(jù)庫的更新是在首次的緩存刪除成功后進(jìn)行的，這樣就有效避地免了“先更數(shù)據(jù)庫再刪緩存”方案中可能出現(xiàn)的數(shù)據(jù)庫更新成功緩存刪除失敗導(dǎo)致的一致性問題。第二次的緩存刪除是為了避免在執(zhí)行更新數(shù)據(jù)庫操作完成之前其它線程讀取數(shù)據(jù)庫并更新緩存而導(dǎo)致的一致性問題。

• 為什么第二次緩存刪除又要延遲執(zhí)行呢？

試想，如果我們不做第二次的延遲刪除，而是更新數(shù)據(jù)庫后立即刪除會(huì)出什么問題？有沒有可能其它讀請(qǐng)求線程在更新數(shù)據(jù)庫之前讀取了數(shù)據(jù)，并在第二次立即刪除緩存之后更新了緩存。很明顯，延遲刪除就是為了讓可能存在的其它讀請(qǐng)求線程盡可能地在更新完緩存后再執(zhí)行緩存刪除操作。這樣一通操作后，數(shù)據(jù)庫是最新的數(shù)據(jù)了，緩存里沒有數(shù)據(jù)，后面的讀請(qǐng)求線程又可以拿到數(shù)據(jù)庫的最新數(shù)據(jù)寫入緩存了。

• 延遲刪除具體需要延遲多長(zhǎng)時(shí)間？

對(duì)于這個(gè)具體需要延遲多長(zhǎng)時(shí)間，其實(shí)沒有絕對(duì)的標(biāo)準(zhǔn)，唯一的標(biāo)準(zhǔn)就是根據(jù)讀請(qǐng)求的耗時(shí)來確定，讀請(qǐng)求越耗時(shí)，延遲時(shí)間越長(zhǎng)。一般情況下我們?cè)O(shè)置的延遲時(shí)間為1秒。

重試刪除

在上面的延遲雙刪方案中，如果我們思考，其實(shí)還是有諸多問題的。比如：在延遲雙刪的讀寫場(chǎng)景中，如果第二次緩存刪除失敗了，同樣會(huì)出現(xiàn)一致性問題。那么刪除失敗了，重試幾次不就好了嗎？基于這個(gè)思想我們進(jìn)一步引入了重試刪除方案來解決

重試刪除確實(shí)很大程度上解決了一致性問題，并且邏輯非常簡(jiǎn)單。唯一的不足可能就是需要引入消息隊(duì)列，并且業(yè)務(wù)代碼也會(huì)有一定的侵入。那么有沒有既能夠保證最終一致性，又能夠解耦的方案呢？我們繼續(xù)往下面看

binlog訂閱異步刪除

binlog訂閱異步刪除確實(shí)也能解決一致性問題，對(duì)代碼也無任何侵入，但是整個(gè)架構(gòu)復(fù)雜，中小項(xiàng)目一般都用不上。

2.2 Read Through/Write Through(讀寫穿透)

該策略又被稱為讀穿/寫穿策略，和CacheAside策略的緩存數(shù)據(jù)與數(shù)據(jù)庫數(shù)據(jù)為準(zhǔn)不同，該策略的核心是用戶只與緩存層交互(應(yīng)用程序只與緩存或者中間層、緩存抽象層交互)，由緩存層與數(shù)據(jù)庫通信，寫入或讀取數(shù)據(jù)。

在讀取數(shù)據(jù)時(shí)，通過緩存層進(jìn)行讀取，若緩存存在則直接返回，若不存在則由緩存層拉取數(shù)據(jù)庫數(shù)據(jù)到緩存中并返回。
在寫數(shù)據(jù)時(shí)，通過緩存層進(jìn)行寫入，若緩存存在則直接寫入緩存中并同步到數(shù)據(jù)庫，若不存在則寫入數(shù)據(jù)庫中。

使用場(chǎng)景

適用于讀多寫多的場(chǎng)景，數(shù)據(jù)一致性要求較高的場(chǎng)景。

2.3 Write Behind(后寫或異步寫)

Write Behind Caching是一種將緩存和數(shù)據(jù)庫異步寫入的緩存模式。在Write Behind Caching模式中，應(yīng)用程序首先將更新操作寫入緩存中，然后異步地將更新操作寫入數(shù)據(jù)庫中。當(dāng)下一次請(qǐng)求到來時(shí)，應(yīng)用程序會(huì)從緩存中讀取數(shù)據(jù)，并將其寫入數(shù)據(jù)庫中。

使用場(chǎng)景

適用于寫多讀少的場(chǎng)景，數(shù)據(jù)一致性要求不高的場(chǎng)景

3. 總結(jié)

在使用Redis緩存時(shí)，應(yīng)根據(jù)具體的業(yè)務(wù)場(chǎng)景和需求選擇合適的緩存模式。Cache Aside模式簡(jiǎn)單易用，適用于讀多寫少的場(chǎng)景；Read/Write Through模式完全解耦緩存和數(shù)據(jù)庫，適用于讀多寫多的場(chǎng)景；Write Behind Caching模式可以提高寫入性能，適用于寫多讀少的場(chǎng)景。在實(shí)際應(yīng)用中，可以根據(jù)具體的業(yè)務(wù)需求和性能要求，選擇合適的緩存模式，以提高系統(tǒng)的性能和穩(wěn)定性。文章來源地址http://www.zghlxwxcb.cn/news/detail-808057.html

到了這里，關(guān)于Redis高級(jí)系列-緩存雙寫一致性的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！