緩存

首頁的訪問量非常大，而首頁中的商品類目訪問量更大，鼠標移動就在訪問，查詢所有的數據，如果每次訪問都實時到數據庫獲取數據，數據庫的訪問壓力太大。

而這些信息一般更新的頻率比較低，短時間內不會發生改變。因此，我們可以考慮在前臺系統中，增加一層緩存，把這些數據緩存起來，請求到來時，不再調用數據接口，而是直接讀取緩存中的數據。

這樣就能大大減少首頁分類加載所需時間，提高并發性能。

?

加不加緩存的標準：

變化頻率低

訪問頻繁

實現：使用Redis實現緩存。

?

如何實現

先讀緩存，緩存有，直接返回。

緩存沒有，再讀數據庫

寫：

雙寫模式：寫數據庫，寫緩存

失效模式：緩存失效（刪除緩存），寫數據庫

讀取緩存步驟數據一致性一般沒有什么問題，但是一旦涉及到數據更新：數據庫和緩存更新，就容易出現緩存(Redis)和數據庫（MySQL）間的數據一致性問題。

不管先保存到MySQL，還是先保存到Redis都面臨著一個保存成功而另外一個保存失敗的情況。

不管是先寫MySQL數據庫，再刪除Redis緩存；還是先刪除緩存，再寫庫，都有可能出現數據不一致的情況。舉一個例子：

1.如果刪除了緩存Redis，還沒有來得及寫庫MySQL，另一個線程就來讀取，發現緩存為空，則去數據庫中讀取數據寫入緩存，此時緩存中為臟數據。

2.如果先寫了庫，在刪除緩存前，寫庫的線程宕機了，沒有刪除掉緩存，則也會出現數據不一致情況。

因為寫和讀是并發的，沒法保證順序,就會出現緩存和數據庫的數據不一致的問題。

?

解決：

基于mysql的binlog日志（canal）

消息隊列

總結

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

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