原文出處:https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/redis-caching-avalanche-and-caching-penetration.md
歡迎 star 關(guān)注 GitHub 項目最新動態(tài)返劲!
面試題
了解什么是 redis 的雪崩塞淹、穿透和擊穿窟蓝?redis 崩潰之后會怎么樣?系統(tǒng)該如何應(yīng)對這種情況饱普?如何處理 redis 的穿透运挫?
面試官心理分析
其實這是問到緩存必問的,因為緩存雪崩和穿透套耕,是緩存最大的兩個問題谁帕,要么不出現(xiàn),一旦出現(xiàn)就是致命性的問題冯袍,所以面試官一定會問你匈挖。
面試題剖析
緩存雪崩
對于系統(tǒng) A碾牌,假設(shè)每天高峰期每秒 5000 個請求,本來緩存在高峰期可以扛住每秒 4000 個請求儡循,但是緩存機(jī)器意外發(fā)生了全盤宕機(jī)舶吗。緩存掛了,此時 1 秒 5000 個請求全部落數(shù)據(jù)庫择膝,數(shù)據(jù)庫必然扛不住誓琼,它會報一下警,然后就掛了肴捉。此時腹侣,如果沒有采用什么特別的方案來處理這個故障,DBA 很著急每庆,重啟數(shù)據(jù)庫筐带,但是數(shù)據(jù)庫立馬又被新的流量給打死了。
這就是緩存雪崩缤灵。
大約在 3 年前伦籍,國內(nèi)比較知名的一個互聯(lián)網(wǎng)公司,曾因為緩存事故腮出,導(dǎo)致雪崩帖鸦,后臺系統(tǒng)全部崩潰,事故從當(dāng)天下午持續(xù)到晚上凌晨 3~4 點胚嘲,公司損失了幾千萬作儿。
緩存雪崩的事前事中事后的解決方案如下。
- 事前:redis 高可用馋劈,主從+哨兵攻锰,redis cluster,避免全盤崩潰妓雾。
- 事中:本地 ehcache 緩存 + hystrix 限流&降級娶吞,避免 MySQL 被打死。
- 事后:redis 持久化械姻,一旦重啟妒蛇,自動從磁盤上加載數(shù)據(jù),快速恢復(fù)緩存數(shù)據(jù)楷拳。
用戶發(fā)送一個請求绣夺,系統(tǒng) A 收到請求后,先查本地 ehcache 緩存欢揖,如果沒查到再查 redis陶耍。如果 ehcache 和 redis 都沒有,再查數(shù)據(jù)庫浸颓,將數(shù)據(jù)庫中的結(jié)果物臂,寫入 ehcache 和 redis 中旺拉。
限流組件,可以設(shè)置每秒的請求棵磷,有多少能通過組件蛾狗,剩余的未通過的請求,怎么辦仪媒?走降級沉桌!可以返回一些默認(rèn)的值,或者友情提示算吩,或者空白的值留凭。
好處:
- 數(shù)據(jù)庫絕對不會死,限流組件確保了每秒只有多少個請求能通過偎巢。
- 只要數(shù)據(jù)庫不死蔼夜,就是說,對用戶來說压昼,2/5 的請求都是可以被處理的求冷。
- 只要有 2/5 的請求可以被處理,就意味著你的系統(tǒng)沒死窍霞,對用戶來說匠题,可能就是點擊幾次刷不出來頁面,但是多點幾次但金,就可以刷出來一次韭山。
緩存穿透
對于系統(tǒng)A,假設(shè)一秒 5000 個請求冷溃,結(jié)果其中 4000 個請求是黑客發(fā)出的惡意攻擊钱磅。
黑客發(fā)出的那 4000 個攻擊,緩存中查不到似枕,每次你去數(shù)據(jù)庫里查续搀,也查不到。
舉個栗子菠净。數(shù)據(jù)庫 id 是從 1 開始的,結(jié)果黑客發(fā)過來的請求 id 全部都是負(fù)數(shù)彪杉。這樣的話毅往,緩存中不會有,請求每次都“視緩存于無物”派近,直接查詢數(shù)據(jù)庫攀唯。這種惡意攻擊場景的緩存穿透就會直接把數(shù)據(jù)庫給打死。
解決方式很簡單渴丸,每次系統(tǒng) A 從數(shù)據(jù)庫中只要沒查到侯嘀,就寫一個空值到緩存里去另凌,比如 set -999 UNKNOWN
。然后設(shè)置一個過期時間戒幔,這樣的話吠谢,下次有相同的 key 來訪問的時候,在緩存失效之前诗茎,都可以直接從緩存中取數(shù)據(jù)工坊。
緩存擊穿
緩存擊穿,就是說某個 key 非常熱點敢订,訪問非常頻繁王污,處于集中式高并發(fā)訪問的情況,當(dāng)這個 key 在失效的瞬間楚午,大量的請求就擊穿了緩存昭齐,直接請求數(shù)據(jù)庫,就像是在一道屏障上鑿開了一個洞矾柜。
解決方式也很簡單阱驾,可以將熱點數(shù)據(jù)設(shè)置為永遠(yuǎn)不過期;或者基于 redis or zookeeper 實現(xiàn)互斥鎖把沼,等待第一個請求構(gòu)建完緩存之后啊易,再釋放鎖,進(jìn)而其它請求才能通過該 key 訪問數(shù)據(jù)饮睬。