緩存的更新策略

更新數據庫和Redis本身就不是原子操作，所以無論采取何種方式都不能保證強一致性，只能保證最終一致；
只能盡可能降低不一致性發生的幾率，不能從根本上完全避免。

先更新數據庫，在更新緩存

業務角度對于讀少的場景，浪費性能資源
線程安全容易產生臟讀。比如A線程更新數據庫，B線程更新數據庫；B線程更新緩存，A線程更新緩存

先刪除緩存，再更新數據庫

線程安全
請求A進行更新操作，先刪除緩存；
請求B查詢緩存，發現緩存失效，讀取數據庫，寫入緩存；
請求A將數據寫入數據庫.
長時間讀取到的都是臟數據
解決方法
采用延時雙刪除:在A寫入數據庫后，延時一定時間，再次刪除緩存
延時時間設置：讀寫同步–讀數據的業務邏輯+幾百毫秒；讀寫分離–主從同步延時+幾百毫秒

先更新數據庫，再刪除緩存

錯誤情況
緩存失效，請求A查詢數據庫；
請求B寫入數據庫，請求B刪除緩存；
請求A將查詢的數據寫入緩存；
只有當讀比寫慢時，才會發生這種情況

解決方案
異步延遲刪除

https://www.jianshu.com/p/85a66af8a3f3

暫時不討論緩存更新和數據更新為一個事務，或者失敗的情況

Cache Aside Pattern

緩存失效
先從緩存中獲取數據，緩存失效，從數據庫獲取后，加載進緩存
緩存命中
從緩存中獲取數據，取到后返回
緩存更新
先把數據存至數據庫，成功后，失效緩存

讀請求
命中緩存，返回數據；
未命中緩存，從數據庫讀取數據，更新緩存，返回數據。
寫請求
更新數據庫，刪除就緩存

分析 該策略相對先刪除緩存再更新數據庫的方式，少了刪除緩存的動作。而是先更新了數據庫，此時緩存依然有效。所以，并發操作拿到的是老數據，但是更新操作完成后，后續的查詢操作都是獲取的新數據。不會導致，長時間使用老數據進行業務處理。
問題
一個讀操作，沒有命中緩存。從數據庫中獲取了結果；
此時，一個寫操作，寫完數據庫之后，將緩存失效；
然后，讀操作將老數據放入緩存。
解讀
這種問題出現的概率比較低。因為需要一個讀操作，并發一個寫操作。而且要求讀操作，在寫操作之前進入數據庫獲取到數據。實際上，寫操作要遠遠慢于讀操作，且會發生鎖表。讀操作讀在寫操作之前，但是更新緩存在寫操作之后，所以這些條件都具備的概率，基本不大
建議給緩存設置失效時間

Read/Write Through(讀寫穿透)

Read/Write Through中，是將緩存作為主要數據存儲。應用程序與數據庫緩存交互，通過抽象緩存層完成

Read Through

讀請求，從緩存獲取數據，如果未獲取到，從數據庫加載，存入緩存；
分析Read Through其實是在Cache-Aside之上，將緩存和數據庫之間的交互進行了封裝。

Write Through

寫請求，寫入數據時，先更新數據庫，再更新緩存
分析將Cache-Aside的寫請求處理上，將先寫入數據庫，再刪除緩存；變更為先寫入數據庫，后寫入緩存；

Write Behind(異步緩存寫入)

讀寫操作僅針對內存，再由封裝的工具進行數據庫的批量更新。緩存與數據庫的一致性較低，適合多寫少讀的場景。

問題

操作緩存時，刪除緩存呢？還是更新緩存呢？

第一種情況
A線程操作寫入，先更新了數據庫；
B線程操作吸入，先更新了數據庫，更新緩存；
A線程更新緩存
此種情況下，造成緩存與數據庫中數據不一致
第二種情況
如果緩存中存儲的是加工過的數據，更新頻率過高會影響服務性能
在寫多讀少的情況下，更新緩存的話，可能數據還沒有被讀取，又被更新了。(其實寫多讀少的情況下，用緩存的意義也不是很大)

雙寫的情況下，先操作數據庫還是先操作緩存？ 為什么不先操作緩存呢？

先操作緩存的情況
A線程發起寫操作，刪除緩存；
B線程發起讀操作，未命中，讀取數據庫，寫入緩存；
A線程將數據寫入數據庫

延時雙刪策略
刪除緩存重試機制
寫請求，寫入數據庫，刪除緩存；
刪除緩存時失敗，將刪除失敗的key放入消息隊列中；
獲取到緩存后，繼續進行緩存操作

讀取binlog異步刪除緩存
重試刪除會造成很多的代碼侵入。
所以考慮讀取binlog進行異步刪除緩存

總結

以上是生活随笔為你收集整理的缓存与数据库的数据更新的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。