1. 什么叫做緩存雙寫(xiě)一致性？

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

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

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

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

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

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

延遲雙刪

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

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

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

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

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

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

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

重試刪除

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

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

binlog訂閱異步刪除

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

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

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

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

使用場(chǎng)景

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

2.3 Write Behind(后寫(xiě)或異步寫(xiě))

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

使用場(chǎng)景

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

3. 總結(jié)

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

到此這篇關(guān)于Redis 緩存雙寫(xiě)一致性的實(shí)現(xiàn)的文章就介紹到這了,更多相關(guān)Redis 緩存雙寫(xiě)一致性內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論