分布式緩存系統(tǒng)是三高架構(gòu)中不可或缺的部分，極大地提高了整個項目的并發(fā)量、響應(yīng)速度，但它也帶來了新的需要解決的問題，分別是： 緩存穿透、緩存擊穿、緩存雪崩和緩存一致性問題。

緩存穿透

第一個比較大的問題就是緩存穿透。這個概念比較好理解，和命中率有關(guān)。如果命中率很低，那么壓力就會集中在數(shù)據(jù)庫持久層。

假如能找到相關(guān)數(shù)據(jù)，我們就可以把它緩存起來。但問題是，本次請求，在緩存和持久層都沒有命中，這種情況就叫緩存的穿透。

舉個例子，如上圖，在一個登錄系統(tǒng)中，有外部攻擊，一直嘗試使用不存在的用戶進行登錄，這些用戶都是虛擬的，不能有效地被緩存起來，每次都會到數(shù)據(jù)庫中查詢一次，最后就會造成服務(wù)的性能故障。

解決這個問題有多種方案，我們來簡單介紹一下。

第一種就是把空對象緩存起來。不是持久層查不到數(shù)據(jù)嗎？那么我們就可以把本次請求的結(jié)果設(shè)置為 null，然后放入到緩存中。通過設(shè)置合理的過期時間，就可以保證后端數(shù)據(jù)庫的安全。

緩存空對象會占用額外的緩存空間，還會有數(shù)據(jù)不一致的時間窗口，所以第二種方法就是針對大數(shù)據(jù)量的、有規(guī)律的鍵值，使用布隆過濾器進行處理。

一條記錄存在與不存在，是一個 Bool 值，只需要使用 1 比特就可存儲。布隆過濾器就可以把這種是、否操作，壓縮到一個數(shù)據(jù)結(jié)構(gòu)中。比如手機號，用戶性別這種數(shù)據(jù)，就非常適合使用布隆過濾器。

緩存擊穿

緩存擊穿，指的也是用戶請求落在數(shù)據(jù)庫上的情況，大多數(shù)情況，是由于緩存時間批量過期引起的。

我們一般會對緩存中的數(shù)據(jù)，設(shè)置一個過期時間。如果在某個時刻從數(shù)據(jù)庫獲取了大量數(shù)據(jù)，并設(shè)置了同樣的過期時間，它們將會在同一時刻失效，造成和緩存的擊穿。

對于比較熱點的數(shù)據(jù)，我們就可以設(shè)置它不過期；或者在訪問的時候，更新它的過期時間；批量入庫的緩存項，也盡量分配一個比較平均的過期時間，避免同一時間失效。

緩存雪崩

雪崩這個詞看著可怕，實際情況也確實比較嚴(yán)重。緩存是用來對系統(tǒng)加速的，后端的數(shù)據(jù)庫只是數(shù)據(jù)的備份，而不是作為高可用的備選方案。

當(dāng)緩存系統(tǒng)出現(xiàn)故障，流量會瞬間轉(zhuǎn)移到后端的數(shù)據(jù)庫。過不了多久，數(shù)據(jù)庫將會被大流量壓垮掛掉，這種級聯(lián)式的服務(wù)故障，可以形象地稱為雪崩。

緩存的高可用建設(shè)是非常重要的。Redis 提供了主從和 Cluster 的模式，其中 Cluster 模式使用簡單，每個分片也能單獨做主從，可以保證極高的可用性。

另外，我們對數(shù)據(jù)庫的性能瓶頸有一個大體的評估。如果緩存系統(tǒng)當(dāng)?shù)?，那么流向?shù)據(jù)庫的請求，就可以使用限流組件，將請求攔截在外面。

緩存一致性

引入緩存組件后，另外一個老大難的問題，就是緩存的一致性。

我們首先來看問題是怎么發(fā)生的。對于一個緩存項來說，常用的操作有四個：寫入、更新、讀取、刪除。

• 寫入：緩存和數(shù)據(jù)庫是兩個不同的組件，只要涉及雙寫，就存在只有一個寫成功的可能性，造成數(shù)據(jù)不一致。
• 更新：更新的情況類似，需要更新兩個不同的組件。
• 讀取：讀取要保證從緩存中讀到的信息是最新的，是和數(shù)據(jù)庫中的是一致的。
• 刪除：當(dāng)刪除數(shù)據(jù)庫記錄的時候，如何把緩存中的數(shù)據(jù)也刪掉？

由于業(yè)務(wù)邏輯大多數(shù)情況下，是比較復(fù)雜的。其中的更新操作，就非常昂貴，比如一個用戶的余額，就是通過計算一系列的資產(chǎn)算出來的一個數(shù)。如果這些關(guān)聯(lián)的資產(chǎn)，每個地方改動的時候，都去刷新緩存，那代碼結(jié)構(gòu)就會非常混亂，以至于無法維護。

我推薦使用觸發(fā)式的緩存一致性方式，使用懶加載的方式，可以讓緩存的同步變得非常簡單：

• 當(dāng)讀取緩存的時候，如果緩存里沒有相關(guān)數(shù)據(jù)，則執(zhí)行相關(guān)的業(yè)務(wù)邏輯，構(gòu)造緩存數(shù)據(jù)存入到緩存系統(tǒng)；
• 當(dāng)與緩存項相關(guān)的資源有變動，則先刪除相應(yīng)的緩存項，然后在數(shù)據(jù)庫中對資源進行更新，最后再刪除相應(yīng)的緩存項。

這種操作，除了編程模型簡單，有一個明顯的好處。我只有在用到這個緩存的時候，才把它加載到緩存系統(tǒng)中。如果每次修改 都創(chuàng)建、更新資源，那緩存系統(tǒng)中就會存在非常多的冷數(shù)據(jù)。這實際上是實現(xiàn)了邊緣緩存模式(Cache-Aside Pattern)，即按需將數(shù)據(jù)從數(shù)據(jù)存儲加載到緩存中，最大的作用就是提高性能減少不必要的查詢。

但這樣還是有問題。接下來介紹的場景，也是面試中經(jīng)常提及的問題。

我們上面提到的數(shù)據(jù)庫的更新動作，和緩存刪除動作，明顯是不在一個事務(wù)里的?？赡茉斐蓴?shù)據(jù)庫的內(nèi)容和緩存里的內(nèi)容在更新的過程有不一致。

在面試中，只要你把這個問題給點出來，面試官都會蹺起大拇指。

可以使用分布式鎖來解決這個問題，將數(shù)據(jù)庫操作和緩存操作，與其他的緩存讀操作，使用鎖進行資源隔離即可。一般來說，讀操作是不需要加鎖的，它會在遇到鎖的時候，重試等待，直到超時。

到此這篇關(guān)于詳解Java分布式緩存系統(tǒng)中必須解決的四大問題的文章就介紹到這了,更多相關(guān)Java分布式緩存系統(tǒng)內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論