一、前言
「Redis 是一個(gè)開源(BSD許可)的,內(nèi)存中的數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)系統(tǒng),它可以用作數(shù)據(jù)庫、緩存和消息中間件?!?/p>
Redis在緩存應(yīng)用中還是很廣泛的,項(xiàng)目中也經(jīng)常使用?;旧厦嬖囍锌隙ǘ紩?huì)問到,總結(jié)一下增強(qiáng)記憶哈!
在享受緩存帶來的好處的同時(shí),當(dāng)然要防止這些不好的方面。
下面我們一起來看看這三種情況的產(chǎn)生原因和解決方案!
「總結(jié): 這三種情況都是在大量請求來的時(shí)候,Redis沒有命中,請求直接打到數(shù)據(jù)庫,從而導(dǎo)致數(shù)據(jù)庫掛掉!」
Redis緩存簡圖:
二、緩存穿透
1、產(chǎn)生原因
「大量請求的 key 是不合理的,緩存中根本不存在(數(shù)據(jù)庫中一般也不存在),導(dǎo)致這些請求繞過緩存直接訪問數(shù)據(jù)庫,給數(shù)據(jù)庫造成了巨大的壓力,隨時(shí)可能宕機(jī)。」
- 惡意查詢,如查詢id為負(fù)數(shù)等等。
- key過期,突然來了大量請求時(shí)。
- key沒有提前預(yù)熱,突然來了大量請求時(shí)。
2、解決方案
- 設(shè)置緩存空值:查詢數(shù)據(jù)庫沒有結(jié)果,將空值緩存,但必須設(shè)置一個(gè)合理的過期時(shí)間。
- 布隆過濾器:是一種用于判斷一個(gè)元素是否屬于一個(gè)集合的數(shù)據(jù)結(jié)構(gòu)。
- 合理判斷參數(shù)的范圍:非負(fù)數(shù)等等。
- 限制并發(fā)查詢:保證只有一個(gè)線程去查詢底層數(shù)據(jù)源,其他線程等待查詢結(jié)果。
3、具體方案
「設(shè)置緩存空值:」
redis有一個(gè)配置,可以把從數(shù)據(jù)庫查詢出來為空的也緩存到Redis中,也可以自己在代碼中寫,順便加上過期時(shí)間,也可以配置過期時(shí)間,這樣是全局都是這個(gè)過期時(shí)間了,不太建議這樣!
spring:
cache:
redis:
cache-null-value: true
time-to-live: 30s
「限制并發(fā)查詢:」
@Cacheable(value={"category"},key = "#root.methodName",sync = true)
?
sync = true:表示多個(gè)線程在嘗試獲取緩存數(shù)據(jù)的時(shí)候會(huì)被阻塞,直到第一個(gè)線程從數(shù)據(jù)庫加載數(shù)據(jù)并放入緩存后,其他線程才能獲取到緩存中的數(shù)據(jù)。這樣可以避免多個(gè)線程同時(shí)查詢底層數(shù)據(jù)庫,減輕數(shù)據(jù)庫負(fù)載,但會(huì)降低并發(fā)性能。 默認(rèn)為false,不開啟
?
「布隆過濾器:」
布隆過濾器(Bloom Filter)是一種用于判斷一個(gè)元素是否屬于一個(gè)集合的數(shù)據(jù)結(jié)構(gòu)。它的主要特點(diǎn)是高效地判斷元素是否存在于集合中,且具有空間和時(shí)間效率高的優(yōu)點(diǎn)。布隆過濾器不會(huì)存儲(chǔ)實(shí)際的數(shù)據(jù),而是通過一系列的哈希函數(shù)和位數(shù)組來判斷元素的存在。
「當(dāng)布隆過濾器判斷元素不存在時(shí),元素一定不存在,元素存在時(shí),元素不一定存在!」
是不是有點(diǎn)繞,我們在詳細(xì)說一下:
布隆過濾器有一定的假陽性概率,即在判斷元素存在時(shí),有可能出現(xiàn)錯(cuò)誤的結(jié)果。這是因?yàn)槎鄠€(gè)元素可能產(chǎn)生相同的哈希值,導(dǎo)致位數(shù)組中的位被設(shè)置為1。
「布隆過濾器一旦添加了元素,就不能刪除,因?yàn)閯h除元素會(huì)影響其他元素的判斷結(jié)果。」
一般引入guava中的BloomFilter來實(shí)現(xiàn)布隆過濾器!如果喜歡用Hutool,也是有實(shí)現(xiàn)的!
下面小編給大家簡單的寫個(gè)demo,大家感受一下!
「引入依賴」
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>30.1-jre</version>
</dependency>
「配置布隆過濾器」
/**
* @author wangzhenjun
* @date 2023/11/7 17:08
*/
@Configuration
public class BloomFilterConfig {
// 預(yù)期插入的元素個(gè)數(shù),從配置文件里拿
private static final Integer EXPECTED_INSERTIONS = 100000;
// 期望的誤判率,值越低,布隆過濾器計(jì)算時(shí)間越長,從配置文件里拿
private static final Double FPP = 0.03;
@Bean
public BloomFilter<String> bloomFilter(){
BloomFilter<String> filter = BloomFilter.create(Funnels.stringFunnel(Charset.forName("utf-8")), EXPECTED_INSERTIONS,FPP);
return filter;
}
}
「簡單測試」
為了簡單,直接寫在啟動(dòng)類上了,大家不要學(xué)哈!
@EnableAsync
@MapperScan("com.example.demonew.demo.mapper")
@EnableTransactionManagement
@SpringBootApplication
public class DemoNewApplication {
@Autowired
private BloomFilter bloomFilter;
public static void main(String[] args) {
SpringApplication.run(DemoNewApplication.class, args);
}
@PostConstruct
public void init(){
bloomFilter.put("123");
boolean b = bloomFilter.mightContain("123");
System.out.println("是否存在:" + b);
}
}
三、緩存擊穿
1、產(chǎn)生原因
「緩存擊穿是指當(dāng)緩存中某個(gè)熱點(diǎn)key剛剛過期(一般和緩存穿透區(qū)別在于熱點(diǎn)數(shù)據(jù)存在于數(shù)據(jù)庫中),在熱點(diǎn)數(shù)據(jù)重新放入緩存之前,瞬間大量的請求繞過緩存,直接打到數(shù)據(jù)庫,數(shù)據(jù)庫隨時(shí)宕機(jī)!」
并發(fā)訪問熱點(diǎn)key:多個(gè)并發(fā)請求同時(shí)訪問相同的緩存鍵
緩存策略問題:設(shè)置了過于短的緩存過期時(shí)間,容易導(dǎo)致緩存頻繁失效。
「一般出現(xiàn)在秒殺中,秒殺都會(huì)提前預(yù)熱,設(shè)置key直到活動(dòng)結(jié)束才會(huì)過期!」
2、解決方案
- 緩存預(yù)熱:系統(tǒng)啟動(dòng)或緩存過期之前,預(yù)先加載常用數(shù)據(jù)到緩存中。
- key永不過期或者使用期間內(nèi)不過期。
- 限制并發(fā)查詢:保證只有一個(gè)線程去查詢底層數(shù)據(jù)源,其他線程等待查詢結(jié)果。
- 接口限流、熔斷、降級(jí)。
3、具體方案
「緩存預(yù)熱:」
在項(xiàng)目啟動(dòng)時(shí),或者定時(shí)任務(wù)掃描進(jìn)行預(yù)熱!
「限制并發(fā)查詢:」
@Cacheable(value={"category"},key = "#root.methodName",sync = true)、
詳細(xì)解釋上面已經(jīng)說過了哈!
「接口限流、熔斷、降級(jí)」
可以引入:Sentinel來幫助我們更好的限流、熔斷、降級(jí),這里就不詳細(xì)演示了!
四、緩存雪崩
1、產(chǎn)生原因
「緩存雪崩是指緩存中大量key到了過期時(shí)間,導(dǎo)致大量的請求直接打到數(shù)據(jù)庫上,數(shù)據(jù)庫隨時(shí)宕機(jī)!」
- redis服務(wù)宕機(jī):redis掛了,所有的key都無法訪問
- 批量設(shè)置大量key相同的過期時(shí)間
2、解決方案
- redis搭建集群或者哨兵。
- 隨機(jī)設(shè)置緩存的失效時(shí)間(合理范圍內(nèi)的隨機(jī)時(shí)間),或者用不過期(不建議)。
- 限制并發(fā)查詢:保證只有一個(gè)線程去查詢底層數(shù)據(jù)源,其他線程等待查詢結(jié)果。
- 接口限流、熔斷、降級(jí)。
- 多級(jí)緩存
「這個(gè)多級(jí)緩存,能不加不加,加了就需要考慮一致性,增加很多復(fù)雜度!」
其實(shí)緩存擊穿和緩存雪崩是很相似的,解決方案,大家也可以看出來很多相同的!這就引出下一個(gè)經(jīng)常問到的問題:
3、具體解決方案
關(guān)于Redis的哨兵搭建可以看一下之前寫的文章,這里就不演示了!
關(guān)于多級(jí)緩存,可以引入本地緩存Caffeine。
4、補(bǔ)充
「緩存擊穿和緩存雪崩的區(qū)別?」
緩存擊穿是緩存中某個(gè)熱點(diǎn)key不存在了,緩存雪崩是緩存中大量或者所有key都不存在了
他倆的根本區(qū)別在于一個(gè)是單個(gè)key,一個(gè)是多個(gè)甚至全部key!
五、緩存污染
這里補(bǔ)充一下,關(guān)于緩存污染的吧!
1、產(chǎn)生原因
緩存污染指緩存中一些訪問次數(shù)很少的key,甚至只有一次!但是緩存中會(huì)存儲(chǔ)著,占用內(nèi)存空間。隨著時(shí)間越來越久,內(nèi)存很快被占滿,就需要開啟淘汰策略去額外處理這些多余的key,影響redis性能。
2、解決方案
- 對與key進(jìn)行監(jiān)控,不常用key不需要加入緩存。
- 分析出key訪問次數(shù)很少,設(shè)置過期時(shí)間短一些。
- 配置淘汰策略:LRU(最近最少使用)淘汰策略。
最主要還是要把不常用的key找到,后面不在加入緩存,從根本上解決!
還會(huì)出現(xiàn)在多個(gè)節(jié)點(diǎn)之間的數(shù)據(jù)同步出現(xiàn)數(shù)據(jù)不統(tǒng)一時(shí)產(chǎn)生,這個(gè)東西不好避免,因?yàn)镽edis 是AP(可用性和分區(qū)容忍性)
,在多節(jié)點(diǎn)時(shí),一半以上同步完成時(shí),就認(rèn)為同步成功了!
六、緩存一致性
引入了緩存就必須要保持緩存的一致性,不然加了緩存沒有任何意義!
網(wǎng)上關(guān)于緩存一致性的文章很多,什么延遲雙刪等等。
這些都不如阿里Canal,這個(gè)是通過監(jiān)聽MySQL的Bin Log日志,來去更新到緩存中!
七、總結(jié)
今天我們深入具體的討論了Redis緩存穿透、緩存擊穿、緩存雪崩的產(chǎn)生原因和解決方案,補(bǔ)充了緩存污染和緩存一致性。
是不是有了深刻的印象,這些東西在企業(yè)級(jí)還是挺常見的,在面試過程中更加常見。 相信大家從頭看到尾,對于面試肯定是沒有任何問題的。
在企業(yè)級(jí)應(yīng)用中,一定要具體情況具體分析,不要盲目照搬,不一定適合你們的需求。