緩存系統設計有哪些性質

這篇文章主要講解了“緩存系統設計有哪些性質”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“緩存系統設計有哪些性質”吧！

Previously

緩存系統涉及的問題和知識點是比較多的，我主要分為以下幾個方面來跟大家探討：

• 穩定性

• 正確性

• 可觀測性

• 規范落地和工具建設

緩存正確性

數據更新常見做法

首先，我們講數據一致性的前提是我們DB的更新和緩存的刪除不會當成一個原子操作來看待，因為在高并發的場景下，我們不可能引入一個分布式鎖來把這兩者綁定為一個原子操作，如果綁定的話就會很大程度上影響并發性能，而且增加系統復雜度，所以我們只會追求數據的最終一致性，且本文只針對非追求強一致性要求的高并發場景，金融支付等同學自行判斷。

常見數據更新方式有兩大類，其余基本都是這兩類的變種：

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

這種做法是遇到數據更新，我們先去刪除緩存，然后再去更新DB，如左圖。讓我們來看一下整個操作的流程：

• A請求需要更新數據，先刪除對應的緩存，還未更新DB

• B請求來讀取數據

• B請求看到緩存里沒有，就去讀取DB并將舊數據寫入緩存（臟數據）

• A請求更新DB

可以看到B請求將臟數據寫入了緩存，如果這是一個讀多寫少的數據，可能臟數據會存在比較長的時間（要么有后續更新，要么等待緩存過期），這是業務上不能接受的。

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

上圖的右側部分可以看到在A更新DB和刪除緩存之間B請求會讀取到老數據，因為此時A操作還沒有完成，并且這種讀到老數據的時間是非常短的，可以滿足數據最終一致性要求。

上圖可以看到我們用的是刪除緩存，而不是更新緩存，原因如下圖：

上圖我用操作代替了刪除或更新，當我們做刪除操作時，A先刪還是B先刪沒有關系，因為后續讀取請求都會從DB加載出最新數據；但是當我們對緩存做的是更新操作時，就會對A先更新緩存還是B先更新緩存敏感了，如果A后更新，那么緩存里就又存在臟數據了，所以 go-zero 只使用刪除緩存的方式。

我們來一起看看完整的請求處理流程：

注意：不同顏色代表不同請求。

• 請求1更新DB

• 請求2查詢同一個數據，返回了老的數據，這個短時間內返回舊數據是可以接受的，滿足最終一致性

• 請求1刪除緩存

• 請求3再來請求時緩存里沒有，就會查詢數據庫，并回寫緩存再返回結果

• 后續的請求就會直接讀取緩存了

另外留一個問題大家可以思考下，對于下圖的場景，我們該怎么應對？

感謝各位的閱讀，以上就是“緩存系統設計有哪些性質”的內容了，經過本文的學習后，相信大家對緩存系統設計有哪些性質這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！