本文轉(zhuǎn)載自公眾號：喬二爺呻袭，是號主最近面試阿里的經(jīng)歷分享眨八。
正好這位同學(xué)面試前學(xué)習(xí)了筆者之前出的一套Java面試突擊教程，里面就涉及到了關(guān)于緩存的一些問題左电。
這篇文章廉侧，是這位同學(xué)對自己阿里一面的總結(jié)，大家可以參考一下篓足，同時也感謝喬二爺同學(xué)的分享段誊。
1 前言
昨天晚上接到阿里的電面電話，過程中就問到了關(guān)于緩存相關(guān)的問題栈拖。
雖然以前接觸過连舍，多多少少了解了一些。但是之前自己并沒有好好記錄這些內(nèi)容涩哟，在真正面試的時候索赏，并沒有回答得出來。今天記錄一下贴彼，長長記性潜腻。
在我們的平常的項目中多多少少都會使用到緩存，因為一些數(shù)據(jù)我們沒有必要每次查詢的時候都去查詢到數(shù)據(jù)庫器仗。
特別是高 QPS 的系統(tǒng)融涣，每次都去查詢數(shù)據(jù)庫，對于你的數(shù)據(jù)庫來說將是災(zāi)難精钮。
今天我們不牽涉多級緩存的知識暴心，就把系統(tǒng)使用到的緩存方案，不管是一級還是多級的都統(tǒng)稱為緩存杂拨，主要是為了講述使用緩存的時候可能會遇到的一些問題以及一些解決辦法专普。
我們使用緩存時，我們的業(yè)務(wù)系統(tǒng)大概的調(diào)用流程如下圖：
當(dāng)我們查詢一條數(shù)據(jù)時弹沽，先去查詢緩存檀夹，如果緩存有就直接返回筋粗，如果沒有就去查詢數(shù)據(jù)庫，然后返回炸渡。這種情況下就可能會出現(xiàn)一些現(xiàn)象娜亿。
2 緩存穿透
2.1 什么是緩存穿透
正常情況下，我們?nèi)ゲ樵償?shù)據(jù)都是存在蚌堵。
那么請求去查詢一條壓根兒數(shù)據(jù)庫中根本就不存在的數(shù)據(jù)买决，也就是緩存和數(shù)據(jù)庫都查詢不到這條數(shù)據(jù)，但是請求每次都會打到數(shù)據(jù)庫上面去吼畏。
這種查詢不存在數(shù)據(jù)的現(xiàn)象我們稱為緩存穿透督赤。
2.2 穿透帶來的問題
試想一下，如果有黑客會對你的系統(tǒng)進(jìn)行攻擊泻蚊，拿一個不存在的id 去查詢數(shù)據(jù)躲舌，會產(chǎn)生大量的請求到數(shù)據(jù)庫去查詢⌒孕郏可能會導(dǎo)致你的數(shù)據(jù)庫由于壓力過大而宕掉没卸。
2.3 解決辦法
2.3.1 緩存空值
之所以會發(fā)生穿透，就是因為緩存中沒有存儲這些空數(shù)據(jù)的key秒旋。從而導(dǎo)致每次查詢都到數(shù)據(jù)庫去了约计。
那么我們就可以為這些key對應(yīng)的值設(shè)置為null 丟到緩存里面去。后面再出現(xiàn)查詢這個key 的請求的時候迁筛，直接返回null 病蛉。
這樣，就不用在到數(shù)據(jù)庫中去走一圈了瑰煎，但是別忘了設(shè)置過期時間铺然。
2.3.2 BloomFilter
BloomFilter 類似于一個hbase set 用來判斷某個元素（key）是否存在于某個集合中。
這種方式在大數(shù)據(jù)場景應(yīng)用比較多酒甸，比如 Hbase 中使用它去判斷數(shù)據(jù)是否在磁盤上魄健。還有在爬蟲場景判斷url 是否已經(jīng)被爬取過。
這種方案可以加在第一種方案中插勤，在緩存之前在加一層 BloomFilter 沽瘦，在查詢的時候先去 BloomFilter 去查詢 key 是否存在，如果不存在就直接返回农尖，存在再走查緩存 -> 查 DB析恋。
流程圖如下：
2.4 如何選擇
針對于一些惡意攻擊，攻擊帶過來的大量key 是不存在的盛卡，那么我們采用第一種方案就會緩存大量不存在key的數(shù)據(jù)助隧。
此時我們采用第一種方案就不合適了，我們完全可以先對使用第二種方案進(jìn)行過濾掉這些key滑沧。
針對這種key異常多并村、請求重復(fù)率比較低的數(shù)據(jù)巍实，我們就沒有必要進(jìn)行緩存，使用第二種方案直接過濾掉哩牍。
而對于空數(shù)據(jù)的key有限的棚潦，重復(fù)率比較高的，我們則可以采用第一種方式進(jìn)行緩存膝昆。
3 緩存擊穿
3.1 什么是擊穿
緩存擊穿是我們可能遇到的第二個使用緩存方案可能遇到的問題丸边。
在平常高并發(fā)的系統(tǒng)中，大量的請求同時查詢一個 key 時荚孵，此時這個key正好失效了妹窖，就會導(dǎo)致大量的請求都打到數(shù)據(jù)庫上面去。這種現(xiàn)象我們稱為緩存擊穿处窥。
3.2 會帶來什么問題
會造成某一時刻數(shù)據(jù)庫請求量過大嘱吗，壓力劇增玄组。
3.3 如何解決
上面的現(xiàn)象是多個線程同時去查詢數(shù)據(jù)庫的這條數(shù)據(jù)滔驾，那么我們可以在第一個查詢數(shù)據(jù)的請求上使用一個 互斥鎖來鎖住它。
其他的線程走到這一步拿不到鎖就等著俄讹，等第一個線程查詢到了數(shù)據(jù)哆致，然后做緩存。后面的線程進(jìn)來發(fā)現(xiàn)已經(jīng)有緩存了患膛，就直接走緩存摊阀。
4、緩存雪崩
4.1 什么是緩存雪崩
緩存雪崩的情況是說踪蹬，當(dāng)某一時刻發(fā)生大規(guī)模的緩存失效的情況胞此，比如你的緩存服務(wù)宕機(jī)了，會有大量的請求進(jìn)來直接打到DB上面跃捣。結(jié)果就是DB 稱不住漱牵，掛掉。
4.2 解決辦法
4.2.1 事前：
使用集群緩存疚漆，保證緩存服務(wù)的高可用
這種方案就是在發(fā)生雪崩前對緩存集群實現(xiàn)高可用酣胀，如果是使用 Redis，可以使用 主從+哨兵 娶聘，Redis Cluster 來避免 Redis 全盤崩潰的情況闻镶。
4.2.2 事中：
ehcache本地緩存 + Hystrix限流&降級,避免MySQL被打死
使用 ehcache 本地緩存的目的也是考慮在 Redis Cluster 完全不可用的時候，ehcache 本地緩存還能夠支撐一陣丸升。
使用 Hystrix進(jìn)行限流 & 降級 铆农，比如一秒來了5000個請求，我們可以設(shè)置假設(shè)只能有一秒 2000個請求能通過這個組件狡耻，那么其他剩余的 3000 請求就會走限流邏輯顿涣。
然后去調(diào)用我們自己開發(fā)的降級組件（降級）波闹，比如設(shè)置的一些默認(rèn)值呀之類的。以此來保護(hù)最后的 MySQL 不會被大量的請求給打死涛碑。
4.2.3 事后：
開啟Redis持久化機(jī)制精堕，盡快恢復(fù)緩存集群
一旦重啟，就能從磁盤上自動加載數(shù)據(jù)恢復(fù)內(nèi)存中的數(shù)據(jù)蒲障。
防止雪崩方案如下圖所示：
5 解決熱點數(shù)據(jù)集中失效問題
我們在設(shè)置緩存的時候歹篓，一般會給緩存設(shè)置一個失效時間，過了這個時間揉阎，緩存就失效了庄撮。
對于一些熱點的數(shù)據(jù)來說，當(dāng)緩存失效以后會存在大量的請求過來毙籽，然后打到數(shù)據(jù)庫去洞斯，從而可能導(dǎo)致數(shù)據(jù)庫崩潰的情況。
5.1 解決辦法
5.1.1 設(shè)置不同的失效時間
為了避免這些熱點的數(shù)據(jù)集中失效坑赡，那么我們在設(shè)置緩存過期時間的時候烙如，我們讓他們失效的時間錯開。
比如在一個基礎(chǔ)的時間上加上或者減去一個范圍內(nèi)的隨機(jī)值毅否。
5.1.2 互斥鎖
結(jié)合上面的擊穿的情況亚铁，在第一個請求去查詢數(shù)據(jù)庫的時候?qū)λ右粋€互斥鎖，其余的查詢請求都會被阻塞住螟加，直到鎖被釋放徘溢，從而保護(hù)數(shù)據(jù)庫。
但是也是由于它會阻塞其他的線程捆探，此時系統(tǒng)吞吐量會下降然爆。需要結(jié)合實際的業(yè)務(wù)去考慮是否要這么做。
內(nèi)容補(bǔ)充（來自原內(nèi)容評論,烈日融雪回復(fù)內(nèi)容）：還可以參考Facebook之前的做法黍图，在失效后sleep(rand()) 這樣不會所有請求都去立刻查db
參考資料：
緩存世界中的三大問題及解決方案
中華石杉老師的Java突擊面試資料
作者：石杉的架構(gòu)筆記
鏈接：https://juejin.im/post/5c9a67ac6fb9a070cb24bf34
來源：掘金
