溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹“數據庫跟緩存的雙寫一致性怎么理解”，在日常操作中，相信很多人在數據庫跟緩存的雙寫一致性怎么理解問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”數據庫跟緩存的雙寫一致性怎么理解”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！
為加速系統性能一般都會引入緩存機制，比如 Redis。這種情況下當用戶讀數據時一般會按照如下流程：
先更新數據庫再更新緩存。
先刪緩存再更新數據庫。
先更新數據庫再刪緩存。
簡單直接又暴力的方法，如果有些數據不重要，我們讀完一次數據到緩存后設置個TTL即可，等待超時后緩存自動從數據庫讀取下數據。
假如我們有A、B兩個請求，A請求將age = 14，B請求將age = 12。我們看下正常執行跟非正常執行情況：
寫場景多而讀場景少的業務需求，此時緩存不是經常性的讀，卻被頻繁的更新。
如果緩存的數據是經過各種復雜計算后寫入的，那每次寫入緩存都要運算一次，此法不可取。
假如A先請求更改數據，B請求讀數據，如果因為網絡導致發生如下情況也會造成緩存臟數據，如果此時緩存沒有設置TTL那會一直是臟數據。
延時雙刪策略，他的核心執行流程如下：public void write(String key,Object value){
redis.delKey(key);
db.updateValue(value);
Thread.sleep(1000); // 再次刪除
redis.delKey(key);
}
該思路落實到流程圖上如下所示：
確保讀請求結束，寫請求可以刪除讀請求造成的緩存臟數據。當然如果用的是主從寫讀架構，那處理思路跟上面類似，無非就是休眠時間再加上主從同步的時間即可。
二次刪除前面涉及到休眠，可能導致系統性能降低，可以采用異步的方式，再起一個線程來進行異步刪除。
如果二次刪除失敗了，還是會導致緩存臟數據存在的啊！
針對緩存更新問題，老外提出了一個名為《Cache-Aside pattern》的緩存更新套路，該策略在Facebook中也廣泛使用，該策略指出：
失效：應用程序先從緩存取數據，沒有得到，則從數據庫中取數據，成功后，放到緩存中。
命中：應用程序從緩存中取數據，取到后返回。
更新：先把數據存到數據庫中，成功后，再讓緩存失效。
假如此時A、B兩個線程同時請求，正常來講不管你是讀寫分離還是單機版，讀一般比寫快。那刪除緩存一般是有效的。
如果刪除緩存失敗了都會導致緩存跟數據不一致問題！
通過消息隊列的確認消費機制來刪除緩存。
對業務線代碼造成大量的侵入，引入了中間件。
消息的延遲刪除也會造成短暫的不一致。
該方案啟動一個訂閱程序去訂閱數據庫的binlog，獲得需要操作的數據。在應用程序中，另起一段程序，獲得這個訂閱程序傳來的信息，進行刪除緩存操作。
到此，關于“數據庫跟緩存的雙寫一致性怎么理解”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
