Redis快取穿透方案

2021-09-11 19:08:58 字數 1204 閱讀 1106

**:

解決redis快取穿透方案

快取技術可以用來減輕資料庫的壓力,提公升訪問效率。目前在企業專案中對快取也是越來越重視。但是快取不是說隨隨便便加入專案就可以了。將快取整合到專案中,這才是第一步。而快取帶來的穿透問題,進而導致的雪蹦問題都是我們迫切需要解決的問題。本篇文章將我平時專案中的解決方案分享給大家,以供參考。

一、快取穿透的原理

1、先從快取中取資料,如果能取到,則直接返回資料給使用者。這樣不用訪問資料庫,減輕資料庫的壓力。

2、如果快取中沒有資料,就會訪問資料庫。

快取就像是資料庫的一道防火牆,將請求比較頻繁的資料放到快取中,從而減輕資料庫的壓力。 但是如果有人惡意攻擊,那就很輕鬆的穿透你的快取,將所有的壓力都給資料庫。比如上圖,你快取的key都是正整數,但是我偏偏使用負數作為key訪問你的快取,這樣就會導致穿透快取,將壓力直接給資料庫。

二、導致快取穿透的原因

快取穿透的問題,肯定是再大併發情況下。依此為前提,我們分析快取穿透的原因如下:

1、惡意攻擊,猜測你的key命名方式,然後估計使用乙個你快取中不會有的key進行訪問。

2、第一次資料訪問,這時快取中還沒有資料,則併發場景下,所有的請求都會壓到資料庫。

3、資料庫的資料也是空,這樣即使訪問了資料庫,也是獲取不到資料,那麼快取中肯定也沒有對應的資料。這樣也會導致穿透。

如上圖所示,解決的步驟如下:

1、再web伺服器啟動時,提前將有可能被頻繁併發訪問的資料寫入快取。—這樣就規避大量的請求在第3步出現排隊阻塞。

2、規範key的命名,並且統一快取查詢和寫入的入口。這樣,在入口處,對key的規範進行檢測。–這樣儲存惡意的key被攔截。

3、synchronized雙重檢測機制,這時我們就需要使用同步(synchronized)機制,在同步**塊前查詢一下快取是否存在對應的key,然後同步**塊裡面再次查詢快取裡是否有要查詢的key。 這樣「雙重檢測」的目的,還是避免併發場景下導致的沒有意義的資料庫的訪問(也是一種嚴格避免穿透的方案)。

這一步會導致排隊,但是第一步中我們說過,為了避免大量的排隊,可以提前將可以預知的大量請求提前寫入快取。

4、不管資料庫中是否有資料,都在快取中儲存對應的key,值為空就行。–這樣是為了避免資料庫中沒有這個資料,導致的平凡穿透快取對資料庫進行訪問。空值如果太多,也會導致記憶體耗盡。導致不必要的記憶體消耗。這樣需要給key設定較短的過期時間,避免記憶體被惡意佔滿。導致正常的功能不能快取資料。

5、布隆過濾,檢視key是否存在

redis 快取穿透 快取雪崩處理方案

一 快取穿透 什麼是快取穿透 訪問某一key的時候,該key不在redis中,也不在db中,因此當非法使用者頻繁請求該key的時候,每一次請求,都直接穿過了redis,都最終落在的db上,從而造成宕機,影響整個系統,這種現象稱之為快取穿透 處理方案 二 快取雪崩 什麼是快取雪崩 每乙個key存在過期...

快取 redis 快取穿透

哪一些因素 考慮使用redis,畢竟 redis 也要增加成本 1 熱點資料 2 讀的成本非常大 3 讀多寫少 4 對資料一致性要求 沒有那麼嚴格 可以出現資料與資料庫不一致 1 秒殺場景 3 物流查詢軌跡 熱點資料 啟用的資料是被快取到redis 當中 快取key 乙個時間點過期的時候,如果快取資...

redis 快取穿透

1 在高併發的場景下本應該查詢快取的,都去查詢資料庫了 情況1例如 if map.isempty else此種情況下在高併發的情況下,多個程序會同時訪問資料庫並向redis放資料 情況1解決的辦法是新增關鍵字 1 synchronized 效率太低了 2 雙重檢測的新增 string userfun...