緩存

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

而這些信息一般更新的頻率比較低，短時間內(nèi)不會發(fā)生改變。因此，我們可以考慮在前臺系統(tǒng)中，增加一層緩存，把這些數(shù)據(jù)緩存起來，請求到來時，不再調(diào)用數(shù)據(jù)接口，而是直接讀取緩存中的數(shù)據(jù)。

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

?

加不加緩存的標(biāo)準(zhǔn)：

變化頻率低

訪問頻繁

實現(xiàn)：使用Redis實現(xiàn)緩存。

?

如何實現(xiàn)

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

緩存沒有，再讀數(shù)據(jù)庫

寫：

雙寫模式：寫數(shù)據(jù)庫，寫緩存

失效模式：緩存失效（刪除緩存），寫數(shù)據(jù)庫

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

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

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

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

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

因為寫和讀是并發(fā)的，沒法保證順序,就會出現(xiàn)緩存和數(shù)據(jù)庫的數(shù)據(jù)不一致的問題。

?

解決：

基于mysql的binlog日志（canal）

消息隊列

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。