數據庫緩存雙寫一致性的一些個人想法

有這么個問題，還是經典面試題：

說我們有個數據庫，他的讀請求特別多，以至于要在數據庫上加一層緩存來抗壓，這個都能理解吧。
這里的緩存，可能是和數據庫一樣的數據，也可能是數據庫的數據經過一系列復雜運算，得出的結果。
但是涉及到更新數據庫內容的時候，如何能保證緩存也能同時更新呢

先說說網友的說法：

1、先刪除緩存，再更新數據庫，再更新緩存（容易造成臟讀）

2、先刪除緩存，再更新數據庫，然后等若干毫秒，再刪除緩存，再更新緩存（降低吞吐量）

3、先刪除緩存，再更新數據庫，同時把這個更新的請求放在隊列中，后面有讀這個即將更新的數據的請求，如果發現緩存沒數據，會再隊列中看一眼，發現這條數據正在更新的話，就輪詢著查緩存，直到查到數據，否則一段時間后，要么超時返回，要么返回舊數據。

4、還有一些反例的說法，比如先更新緩存再更新數據庫之類的，我這里就不多解釋這樣做的問題了。

關于這個問題，現在我說下我的理解，可能與網上其他說法略有差異

1、首先確認一點，什么時候應該用緩存，那就是讀多寫少的情況。一般應用都是這樣，如果你的場景不是讀多寫少的，我還是不建議使用緩存的，因為寫操作一多，就涉及到事務相關了，數據庫已經把事務做的那么完善了，你非要在上面加個緩存自己再實現一遍，出了問題不是自找么。

2、還有，如果你的系統，對準確性要求特別高，比如涉及到錢的計算，比如轉賬，那也不建議用緩存，直接加機器吧，把數據庫分片，分的片越多，性能越好，而且這種情況一般都有唯一id，比如賬號，而對于同一個賬號，基本不會出現什么并發，所以老老實實用數據庫就行了。

3、除了以上這兩種情況，那數據庫緩存雙寫一致性，那還說個啥。想要數據庫緩存一致，就必須犧牲吞吐率，而加緩存的原因，就是讀請求太多，吞吐率跟不上了，那為了解決一致性，反而把吞吐量又降低了，這不有點自相矛盾么。

總結：

有時候，我們發現問題，就一定要解決，當然這是一個很好的習慣。

但如果你作為一個項目的負責人或者技術負責人，在技術層面加了時間觀念，就是不僅要把技術搞好，還要把項目搞好，要盡快搞好，那就不能單純的看技術了，還要多方面考慮。

因為有些問題，其實是可以繞過的，就比如這個數據庫緩存一致性，如果你的項目實在是解決不了這個一致性，不妨不要解決了，退一步，試試不用緩存，還有沒有其他方案，比如增加數據庫抗壓能力等等。

當然，以上都是我的個人一些想法，不一定都對，如果你有任何想法，歡迎交流。

總結

以上是生活随笔為你收集整理的数据库缓存双写一致性的一些个人想法的全部內容，希望文章能夠幫你解決所遇到的問題。

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