redis系列之數據庫與緩存數據一致性解決方案
??????????????????????????????????????????????????????????????????????????????????-- 來自中華石杉老師視頻

數據庫與緩存讀寫模式策略
寫完數據庫后是否需要馬上更新緩存還是直接刪除緩存？

（1）、如果寫數據庫的值與更新到緩存值是一樣的，不需要經過任何的計算，可以馬上更新緩存，但是如果對于那種寫數據頻繁而讀數據少的場景并不合適這種解決方案，因為也許還沒有查詢就被刪除或修改了，這樣會浪費時間和資源

（2）、如果寫數據庫的值與更新緩存的值不一致，寫入緩存中的數據需要經過幾個表的關聯計算后得到的結果插入緩存中，那就沒有必要馬上更新緩存，只有刪除緩存即可，等到查詢的時候在去把計算后得到的結果插入到緩存中即可。

所以一般的策略是：

當更新數據時，先刪除緩存數據，然后更新數據庫，而不是更新緩存，等要查詢的時候才把最新的數據更新到緩存

數據庫與緩存雙寫情況下導致數據不一致問題

場景一

當更新數據時，如更新某商品的庫存，當前商品的庫存是100，現在要更新為99，先更新數據庫更改成99，然后刪除緩存，發現刪除緩存失敗了，這意味著數據庫存的是99，而緩存是100，這導致數據庫和緩存不一致。

場景一解決方案
?

這種情況應該是先刪除緩存，然后在更新數據庫，如果刪除緩存失敗，那就不要更新數據庫，如果說刪除緩存成功，而更新數據庫失敗，那查詢的時候只是從數據庫里查了舊的數據而已，這樣就能保持數據庫與緩存的一致性。

場景二

在高并發的情況下，如果當刪除完緩存的時候，這時去更新數據庫，但還沒有更新完，另外一個請求來查詢數據，發現緩存里沒有，就去數據庫里查，還是以上面商品庫存為例，如果數據庫中產品的庫存是100，那么查詢到的庫存是100，然后插入緩存，插入完緩存后，原來那個更新數據庫的線程把數據庫更新為了99，導致數據庫與緩存不一致的情況

場景二解決方案

遇到這種情況，可以用隊列的去解決這個問，創建幾個隊列，如20個，根據商品的ID去做hash值，然后對隊列個數取摸，當有數據更新請求時，先把它丟到隊列里去，當更新完后在從隊列里去除，如果在更新的過程中，遇到以上場景，先去緩存里看下有沒有數據，如果沒有，可以先去隊列里看是否有相同商品ID在做更新，如果有也把查詢的請求發送到隊列里去，然后同步等待緩存更新完成。
這里有一個優化點，如果發現隊列里有一個查詢請求了，那么就不要放新的查詢操作進去了，用一個while（true）循環去查詢緩存，循環個200MS左右，如果緩存里還沒有則直接取數據庫的舊數據，一般情況下是可以取到的。

---

在高并發下解決場景二要注意的問題

（1）讀請求時長阻塞
?由于讀請求進行了非常輕度的異步化(隊列)，所以一定要注意讀超時的問題，每個讀請求必須在超時間內返回，該解決方案最大的風險在于可能數據更新很頻繁，導致隊列中擠壓了大量的更新操作在里面，然后讀請求會發生大量的超時，最后導致大量的請求直接走數據庫，像遇到這種情況，一般要做好足夠的壓力測試，如果壓力過大，需要根據實際情況添加機器。

（2）請求并發量過高
?這里還是要做好壓力測試，多模擬真實場景，并發量在最高的時候QPS（每秒查詢率QPS是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準。）多少，扛不住就要多加機器，還有就是做好讀寫比例是多少

（3）多服務實例部署的請求路由
可能這個服務部署了多個實例，那么必須保證說，執行數據更新操作，以及執行緩存更新操作的請求，都通過nginx服務器路由到相同的服務實例上

也即是說，部署了多臺redis，緩存更新要更新到正確的機器上！

（4）熱點商品的路由問題，導致請求的傾斜
某些商品的讀請求特別高，全部打到了相同的機器的相同隊列里了，可能造成某臺服務器壓力過大，因為只有在商品數據更新的時候才會清空緩存，然后才會導致讀寫并發，所以更新頻率不是太高的話，這個問題的影響并不是很大，但是確實有可能某些服務器的負載會高一些。

總結

以上是生活随笔為你收集整理的数据库：redis和MySQL如何做到数据的一致性？的全部內容，希望文章能夠幫你解決所遇到的問題。

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