一、普通刪除

在數(shù)據(jù)更新過程中，大家無非使用兩種方法進行緩存和數(shù)據(jù)庫的更新

• 先刪除緩存，再更新數(shù)據(jù)庫
• 先更新數(shù)據(jù)庫，再更新緩存

那這兩種方法究竟有什么不同呢？

1. 先刪除緩存

問題：此時緩存有了舊數(shù)據(jù)，在下次修改此數(shù)據(jù)之前，所有請求獲取的都是舊數(shù)據(jù)，導致讀寫不一致

2. 后刪除緩存

問題1：在小明修改數(shù)據(jù)庫到刪除緩存這段時間，所有請求都是舊數(shù)據(jù)

問題2：如果緩存刪除失敗，后續(xù)所有請求都是舊數(shù)據(jù)(這個問題開啟事務的話，就可以解決)

二、雙刪策略

在普通刪除策略中，大家會發(fā)現(xiàn)后刪緩存策略是比較好的一種，但還是存在一點問題，所以提出了雙刪策略

關于這個地方我是存在疑問的，因為我認為雙刪并不會比后刪緩存策略更好，反而增加了一次數(shù)據(jù)庫查詢的操作。但有的博客卻提了這個策略，我就在這里提一下，大家可以在評論進行交流

1. 普通雙刪

問題：因為線程調度一些問題導致查詢后寫入緩存停止，會導致舊緩存依舊存在

2. 延遲雙刪

這樣的話看似把普通雙刪的問題給解決了，但并沒有完全解決，反而引發(fā)新的問題。

問題：延時時長問題，時間太長導致性能下降，時間太短又會跟普通雙刪一樣

三、讀寫鎖

讀寫鎖根據(jù)字面意思就知道是加鎖，因此效率肯定比不加鎖效率低，但是可以完全避免舊數(shù)據(jù)讀取的發(fā)生。

• 讀寫鎖是讀讀共享，讀寫和寫寫互斥的

  

四、異步通知

1. 消息中間件異步通知

• 對于這個博主認為是把延遲雙刪的延遲給優(yōu)化了，不再占用本線程的時間，只不過部分請求會導致舊數(shù)據(jù)。

2.Canal

Canal是一個開源的數(shù)據(jù)庫數(shù)據(jù)增量訂閱和消費組件，用于實時捕獲數(shù)據(jù)庫的變更并將其傳遞給其他系統(tǒng)。具體而言，Canal主要用于解決數(shù)據(jù)庫之間的數(shù)據(jù)同步和實時數(shù)據(jù)分析需求。 Canal支持對MySQL、Oracle等主流數(shù)據(jù)庫進行增量數(shù)據(jù)訂閱和消費。它通過解析數(shù)據(jù)庫的日志（如MySQL的binlog或Oracle的redo log），實時捕獲數(shù)據(jù)庫的變更操作，然后將變更數(shù)據(jù)以事件的形式發(fā)送給訂閱者。可以將這些變更數(shù)據(jù)用于數(shù)據(jù)同步、實時數(shù)據(jù)倉庫、搜索引擎索引更新、緩存更新等應用場景。 Canal的主要特性包括：

• .數(shù)據(jù)庫無侵入：Canal通過解析數(shù)據(jù)庫日志來捕獲數(shù)據(jù)變更，不需要對數(shù)據(jù)庫進行任何修改，不會對數(shù)據(jù)庫的性能產(chǎn)生影響。
• 實時的增量數(shù)據(jù)：Canal能夠幾乎實時地捕獲到數(shù)據(jù)庫的變更操作，并以事件的形式進行傳遞，保證了數(shù)據(jù)的實時性。
• 靈活的訂閱和過濾：Canal支持基于數(shù)據(jù)庫、表、列級別的訂閱和過濾，可以按需選擇需要同步的數(shù)據(jù)，減少數(shù)據(jù)傳輸和處理的壓力。
• 多種協(xié)議支持：Canal支持多種數(shù)據(jù)傳輸協(xié)議，如基于TCP的簡單文本協(xié)議、Kafka、RocketMQ等，可以根據(jù)具體需求選擇適合的協(xié)議進行數(shù)據(jù)傳輸。
• 高可用和容錯：Canal支持多節(jié)點部署，通過主備模式或者集群模式來保證高可用性和容錯性。

五. 總結

總體來說這幾種方式各有優(yōu)缺點，不過現(xiàn)在主要用的就是普通刪除中的后刪緩存的方法，如果一致性要求比較高的話，可以用讀寫鎖的方式，如果沒有那么強的一致性要求，可以使用后刪緩存或者異步通知的方式。

結語

每個人都有自己獨特的才華和潛能，在這個廣袤的世界上，你的存在是有意義的。無論你是誰，你的背景如何，你所處的環(huán)境怎樣，只要你敢于跨出舒適區(qū)，付出努力，追求卓越，你就能夠開創(chuàng)屬于自己的輝煌。

以上就是關于Redis的讀寫一致問題的詳細內(nèi)容，更多關于Redis讀寫一致的資料請關注腳本之家其它相關文章！

最新評論