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

緩存穿透

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

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

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

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

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

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

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

緩存擊穿

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

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

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

緩存雪崩

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

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

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

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

緩存一致性

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

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

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

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

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

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

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

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

我們上面提到的數(shù)據(jù)庫的更新動(dòng)作，和緩存刪除動(dòng)作，明顯是不在一個(gè)事務(wù)里的。可能造成數(shù)據(jù)庫的內(nèi)容和緩存里的內(nèi)容在更新的過程有不一致。

在面試中，只要你把這個(gè)問題給點(diǎn)出來，面試官都會(huì)蹺起大拇指。

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

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