github緩存穿透的解決方法是什么

這篇文章主要介紹“github緩存穿透的解決方法是什么”，在日常操作中，相信很多人在github緩存穿透的解決方法是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對(duì)大家解答”github緩存穿透的解決方法是什么”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

使用緩存時(shí)有三個(gè)目標(biāo)：

• 第一，加快用戶訪問速度，提高用戶體驗(yàn)

• 第二，降低后端負(fù)載，減少潛在的風(fēng)險(xiǎn)，保證系統(tǒng)平穩(wěn)

• 第三，保證數(shù)據(jù)“盡可能”及時(shí)更新

緩存穿透原因

緩存穿透是指查詢一個(gè)根本不存在的數(shù)據(jù)，緩存層和存儲(chǔ)層都不會(huì)命中，但是出于容錯(cuò)的考慮，如果從存儲(chǔ)層查不到數(shù)據(jù)則不寫入緩存層

• 緩存層不命中

• 存儲(chǔ)層不命中，所以不將空結(jié)果寫回緩存

• 返回空結(jié)果

緩存穿透將導(dǎo)致不存在的數(shù)據(jù)每次請求都要到存儲(chǔ)層去查詢，失去了緩存保護(hù)后端存儲(chǔ)的意義。

緩存穿透問題可能會(huì)使后端存儲(chǔ)負(fù)載加大，由于很多后端存儲(chǔ)不具備高并發(fā)性，甚至可能造成后端存儲(chǔ)宕掉。通?？梢栽诔绦蛑蟹謩e統(tǒng)計(jì)總調(diào)用數(shù)、緩存層命中數(shù)、存儲(chǔ)層命中數(shù)，如果發(fā)現(xiàn)大量存儲(chǔ)層空命中，可能就是出現(xiàn)了緩存穿透問題。

造成緩存穿透的基本有兩個(gè)：

• 業(yè)務(wù)自身代碼或者數(shù)據(jù)出現(xiàn)問題

• 一些惡意攻擊、爬蟲等造成大量空命中

緩存穿透的解決方法

1）緩存空對(duì)象

當(dāng)存儲(chǔ)層不命中后，仍然將空對(duì)象保留到緩存層中，之后再訪問這個(gè)數(shù)據(jù)將會(huì)從緩存中獲取，保護(hù)了后端數(shù)據(jù)源。

緩存空對(duì)象會(huì)有兩個(gè)問題：

• 空值做了緩存，意味著緩存層中存了更多的鍵，需要更多的內(nèi)存空間 ( 如果是攻擊，問題更嚴(yán)重 )，比較有效的方法是針對(duì)這類數(shù)據(jù)設(shè)置一個(gè)較短的過期時(shí)間，讓其自動(dòng)剔除。

• 緩存層和存儲(chǔ)層的數(shù)據(jù)會(huì)有一段時(shí)間窗口的不一致，可能會(huì)對(duì)業(yè)務(wù)有一定影響。例如過期時(shí)間設(shè)置為 5 分鐘，如果此時(shí)存儲(chǔ)層添加了這個(gè)數(shù)據(jù)，那此段時(shí)間就會(huì)出現(xiàn)緩存層和存儲(chǔ)層數(shù)據(jù)的不一致，此時(shí)可以利用消息系統(tǒng)或者其他方式清除掉緩存層中的空對(duì)象。

2）布隆過濾器攔截

在訪問緩存層和存儲(chǔ)層之前，將存在的 key 用布隆過濾器提前保存起來，做第一層攔截。例如： 一個(gè)個(gè)性化推薦系統(tǒng)有 4 億個(gè)用戶 ID，每個(gè)小時(shí)算法工程師會(huì)根據(jù)每個(gè)用戶之前歷史行為做出來的個(gè)性化放到存儲(chǔ)層中，但是最新的用戶由于沒有歷史行為，就會(huì)發(fā)生緩存穿透的行為，為此可以將所有有個(gè)性化推薦數(shù)據(jù)的用戶做成布隆過濾器。如果布隆過濾器認(rèn)為該用戶 ID 不存在，那么就不會(huì)訪問存儲(chǔ)層，在一定程度保護(hù)了存儲(chǔ)層。

可以利用 Redis 的 Bitmaps 實(shí)現(xiàn)布隆過濾器

這種方法適用于數(shù)據(jù)命中不高，數(shù)據(jù)相對(duì)固定實(shí)時(shí)性低（通常是數(shù)據(jù)集較大）的應(yīng)用場景，代碼維護(hù)較為復(fù)雜，但是緩存空間占用少。

緩存雪崩問題優(yōu)化

預(yù)防和解決緩存雪崩問題，可以從以下三個(gè)方面進(jìn)行著手。

• 1）保證緩存層服務(wù)高可用性。

和飛機(jī)都有多個(gè)引擎一樣，如果緩存層設(shè)計(jì)成高可用的，即使個(gè)別節(jié)點(diǎn)、個(gè)別機(jī)器、甚至是機(jī)房宕掉，依然可以提供服務(wù)

• 2）依賴隔離組件為后端限流并降級(jí)。

無論是緩存層還是存儲(chǔ)層都會(huì)有出錯(cuò)的概率，可以將它們視同為資源。作為并發(fā)量較大的系統(tǒng)，假如有一個(gè)資源不可用，可能會(huì)造成線程全部 hang 在這個(gè)資源上，造成整個(gè)系統(tǒng)不可用。降級(jí)在高并發(fā)系統(tǒng)中是非常正常的：比如推薦服務(wù)中，如果個(gè)性化推薦服務(wù)不可用，可以降級(jí)補(bǔ)充熱點(diǎn)數(shù)據(jù)，不至于造成前端頁面是開天窗。

在實(shí)際項(xiàng)目中，我們需要對(duì)重要的資源 ( 例如 Redis、 MySQL、 Hbase、外部接口 ) 都進(jìn)行隔離，讓每種資源都單獨(dú)運(yùn)行在自己的線程池中，即使個(gè)別資源出現(xiàn)了問題，對(duì)其他服務(wù)沒有影響。但是線程池如何管理，比如如何關(guān)閉資源池，開啟資源池，資源池閥值管理，這些做起來還是相當(dāng)復(fù)雜的，這里推薦一個(gè) Java 依賴隔離工具 Hystrix(https://github.com/Netflix/Hystrix)

• 3）提前演練。在項(xiàng)目上線前，演練緩存層宕掉后，應(yīng)用以及后端的負(fù)載情況以及可能出現(xiàn)的問題，在此基礎(chǔ)上做一些預(yù)案設(shè)定。

緩存熱點(diǎn) key 重建優(yōu)化

開發(fā)人員使用緩存 + 過期時(shí)間的策略既可以加速數(shù)據(jù)讀寫，又保證數(shù)據(jù)的定期更新，這種模式基本能夠滿足絕大部分需求。但是有兩個(gè)問題如果同時(shí)出現(xiàn)，可能就會(huì)對(duì)應(yīng)用造成致命的危害：

• 當(dāng)前 key 是一個(gè)熱點(diǎn) key( 例如一個(gè)熱門的娛樂新聞），并發(fā)量非常大。

• 重建緩存不能在短時(shí)間完成，可能是一個(gè)復(fù)雜計(jì)算，例如復(fù)雜的 SQL、多次 IO、多個(gè)依賴等。

在緩存失效的瞬間，有大量線程來重建緩存，造成后端負(fù)載加大，甚至可能會(huì)讓應(yīng)用崩潰。

解決思路：

• 1）互斥鎖 (mutex key)

只允許一個(gè)線程重建緩存，其他線程等待重建緩存的線程執(zhí)行完，重新從緩存獲取數(shù)據(jù)即可

• 2）永遠(yuǎn)不過期，“永遠(yuǎn)不過期”包含兩層意思：

• 從緩存層面來看，確實(shí)沒有設(shè)置過期時(shí)間，所以不會(huì)出現(xiàn)熱點(diǎn) key 過期后產(chǎn)生的問題，也就是“物理”不過期。

• 從功能層面來看，為每個(gè) value 設(shè)置一個(gè)邏輯過期時(shí)間，當(dāng)發(fā)現(xiàn)超過邏輯過期時(shí)間后，會(huì)使用單獨(dú)的線程去構(gòu)建緩存。

方案比較：

• 互斥鎖 (mutex key)：這種方案思路比較簡單，但是存在一定的隱患，如果構(gòu)建緩存過程出現(xiàn)問題或者時(shí)間較長，可能會(huì)存在死鎖和線程池阻塞的風(fēng)險(xiǎn)，但是這種方法能夠較好的降低后端存儲(chǔ)負(fù)載并在一致性上做的比較好。

• " 永遠(yuǎn)不過期 "：這種方案由于沒有設(shè)置真正的過期時(shí)間，實(shí)際上已經(jīng)不存在熱點(diǎn) key 產(chǎn)生的一系列危害，但是會(huì)存在數(shù)據(jù)不一致的情況，同時(shí)代碼復(fù)雜度會(huì)增大。

到此，關(guān)于“github緩存穿透的解決方法是什么”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！