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

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

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

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

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

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

那為什么要先更新數(shù)據(jù)庫在刪除緩存了？我們再看看幾種更新策略

延遲雙刪

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

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

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

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

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

• 延遲刪除具體需要延遲多長時間？

對于這個具體需要延遲多長時間，其實沒有絕對的標準，唯一的標準就是根據(jù)讀請求的耗時來確定，讀請求越耗時，延遲時間越長。一般情況下我們設(shè)置的延遲時間為1秒。

重試刪除

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

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

binlog訂閱異步刪除

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

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

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

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

使用場景

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

2.3 Write Behind(后寫或異步寫)

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

使用場景

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

3. 總結(jié)

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

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

最新評論