深入理解分布式之數據庫和緩存雙寫一致性方案剖析

2024-09-07 22:12:47

字體：大中小

來源：轉載

供稿：網友

　　為什么寫這篇文章？
　　首先，緩存由于其高并發和高性能的特性，已經在項目中被廣泛使用。在讀取緩存方面，大家沒啥疑問，都是按照下圖的流程來進行業務操作。
　　深入理解分布式之數據庫和緩存雙寫一致性方案解析cdn2.b0.upaiyun.com/2018/05/efb54ba1306999e884c5f44d35db7380.png">
　　但是在更新緩存方面，對于更新完數據庫，是更新緩存呢，還是刪除緩存。又或者是先刪除緩存，再更新數據庫，其實大家存在很大的爭議。目前沒有一篇全面的博客，對這幾種方案進行解析。于是博主戰戰兢兢，頂著被大家噴的風險，寫了這篇文章。

　　同時有請求A和請求B進行更新操作，那么會出現
　　（1）線程A更新了數據庫
　　（2）線程B更新了數據庫
　　（3）線程B更新了緩存
　　（4）線程A更新了緩存
　　這就出現請求A更新緩存應該比請求B更新緩存早才對，但是因為網絡等原因，B卻比A更早更新了緩存。這就導致了臟數據，因此不考慮。
　　原因二（業務場景角度）
　　有如下兩點：
　　（1）如果你是一個寫數據庫場景比較多，而讀數據場景比較少的業務需求，采用這種方案就會導致，數據壓根還沒讀到，緩存就被頻繁的更新，浪費性能。
　　（2）如果你寫入數據庫的值，并不是直接寫入緩存的，而是要經過一系列復雜的計算再寫入緩存。那么，每次寫入數據庫后，都再次計算寫入緩存的值，無疑是浪費性能的。顯然，刪除緩存更為適合。

　　接下來討論的就是爭議最大的，先刪緩存，再更新數據庫。還是先更新數據庫，再刪緩存的問題。

　　(2)先刪緩存，再更新數據庫
　　該方案會導致不一致的原因是。同時有一個請求A進行更新操作，另一個請求B進行查詢操作。那么會出現如下情形:
　　（1）請求A進行寫操作，刪除緩存
　　（2）請求B查詢發現緩存不存在
　　（3）請求B去數據庫查詢得到舊值
　　（4）請求B將舊值寫入緩存
　　（5）請求A將新值寫入數據庫
　　上述情況就會導致不一致的情形出現。而且，如果不采用給緩存設置過期時間策略，該數據永遠都是臟數據。
　　那么，如何解決呢？采用延時雙刪策略。

（編輯：武林網）

上一篇：數據庫的那些事

下一篇：主鍵id自增長配置