像我們?nèi)ッ嬖囈恍┐蠊镜臅r(shí)候,就會遇到一些關(guān)于緩存的問題??赡芎芏嗤瑢W(xué)都是接觸過,多多少少了解一些,但是如果沒有好好記錄這些內(nèi)容,不熟練精通的話,在真正面試的時(shí)候,就很難答出來了。
創(chuàng)新互聯(lián)專注于鷹手營子網(wǎng)站建設(shè)服務(wù)及定制,我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠為您提供鷹手營子營銷型網(wǎng)站建設(shè),鷹手營子網(wǎng)站制作、鷹手營子網(wǎng)頁設(shè)計(jì)、鷹手營子網(wǎng)站官網(wǎng)定制、重慶小程序開發(fā)服務(wù),打造鷹手營子網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供鷹手營子網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。
在我們的平常的項(xiàng)目中多多少少都會使用到緩存,因?yàn)橐恍?shù)據(jù)我們沒有必要每次查詢的時(shí)候都去查詢到數(shù)據(jù)庫。
特別是高 QPS 的系統(tǒng),每次都去查詢數(shù)據(jù)庫,對于你的數(shù)據(jù)庫來說將是災(zāi)難。?
今天我們不牽涉多級緩存的知識,就把系統(tǒng)使用到的緩存方案,不管是一級還是多級的都統(tǒng)稱為緩存,主要是為了講述使用緩存的時(shí)候可能會遇到的一些問題以及一些解決辦法。
我們使用緩存時(shí),我們的業(yè)務(wù)系統(tǒng)大概的調(diào)用流程如下圖:?
當(dāng)我們查詢一條數(shù)據(jù)時(shí),先去查詢緩存,如果緩存有就直接返回,如果沒有就去查詢數(shù)據(jù)庫,然后返回。這種情況下就可能會出現(xiàn)一些現(xiàn)象。
正常情況下,我們?nèi)ゲ樵償?shù)據(jù)都是存在。
那么請求去查詢一條壓根兒數(shù)據(jù)庫中根本就不存在的數(shù)據(jù),也就是緩存和數(shù)據(jù)庫都查詢不到這條數(shù)據(jù),但是請求每次都會打到數(shù)據(jù)庫上面去。
這種查詢不存在數(shù)據(jù)的現(xiàn)象我們稱為緩存穿透。
試想一下,如果有***會對你的系統(tǒng)進(jìn)行擾亂,拿一個(gè)不存在的id 去查詢數(shù)據(jù),會產(chǎn)生大量的請求到數(shù)據(jù)庫去查詢??赡軙?dǎo)致你的數(shù)據(jù)庫由于壓力過大而宕掉。
2.3.1 緩存空值
之所以會發(fā)生穿透,就是因?yàn)榫彺嬷袥]有存儲這些空數(shù)據(jù)的key。從而導(dǎo)致每次查詢都到數(shù)據(jù)庫去了。
那么我們就可以為這些key對應(yīng)的值設(shè)置為null 丟到緩存里面去。后面再出現(xiàn)查詢這個(gè)key 的請求的時(shí)候,直接返回null 。
這樣,就不用在到數(shù)據(jù)庫中去走一圈了,但是別忘了設(shè)置過期時(shí)間。
2.3.2 BloomFilter
BloomFilter 類似于一個(gè)hbase set 用來判斷某個(gè)元素(key)是否存在于某個(gè)集合中。
這種方式在大數(shù)據(jù)場景應(yīng)用比較多,比如 Hbase 中使用它去判斷數(shù)據(jù)是否在磁盤上。還有在爬蟲場景判斷url 是否已經(jīng)被爬取過。
這種方案可以加在第一種方案中,在緩存之前在加一層 BloomFilter ,在查詢的時(shí)候先去 BloomFilter 去查詢 key 是否存在,如果不存在就直接返回,存在再走查緩存 -> 查 DB。
流程圖如下:
針對于一些惡意搗亂,搗亂帶過來的大量key 是不存在的,那么我們采用第一種方案就會緩存大量不存在key的數(shù)據(jù)。
此時(shí)我們采用第一種方案就不合適了,我們完全可以先對使用第二種方案進(jìn)行過濾掉這些key。
針對這種key異常多、請求重復(fù)率比較低的數(shù)據(jù),我們就沒有必要進(jìn)行緩存,使用第二種方案直接過濾掉。
而對于空數(shù)據(jù)的key有限的,重復(fù)率比較高的,我們則可以采用第一種方式進(jìn)行緩存。
緩存擊穿是我們可能遇到的第二個(gè)使用緩存方案可能遇到的問題。
在平常高并發(fā)的系統(tǒng)中,大量的請求同時(shí)查詢一個(gè) key 時(shí),此時(shí)這個(gè)key正好失效了,就會導(dǎo)致大量的請求都打到數(shù)據(jù)庫上面去。這種現(xiàn)象我們稱為緩存擊穿。
會造成某一時(shí)刻數(shù)據(jù)庫請求量過大,壓力劇增。
上面的現(xiàn)象是多個(gè)線程同時(shí)去查詢數(shù)據(jù)庫的這條數(shù)據(jù),那么我們可以在第一個(gè)查詢數(shù)據(jù)的請求上使用一個(gè) 互斥鎖來鎖住它。
其他的線程走到這一步拿不到鎖就等著,等第一個(gè)線程查詢到了數(shù)據(jù),然后做緩存。后面的線程進(jìn)來發(fā)現(xiàn)已經(jīng)有緩存了,就直接走緩存。
緩存雪崩的情況是說,當(dāng)某一時(shí)刻發(fā)生大規(guī)模的緩存失效的情況,比如你的緩存服務(wù)宕機(jī)了,會有大量的請求進(jìn)來直接打到DB上面。結(jié)果就是DB 稱不住,掛掉。
4.2.1 事前:
這種方案就是在發(fā)生雪崩前對緩存集群實(shí)現(xiàn)高可用,如果是使用 redis,可以使用 主從+哨兵 ,Redis Cluster 來避免 Redis 全盤崩潰的情況。
4.2.2 事中:
使用 ehcache 本地緩存的目的也是考慮在 Redis Cluster 完全不可用的時(shí)候,ehcache 本地緩存還能夠支撐一陣。
使用 Hystrix進(jìn)行限流 & 降級 ,比如一秒來了5000個(gè)請求,我們可以設(shè)置假設(shè)只能有一秒 2000個(gè)請求能通過這個(gè)組件,那么其他剩余的 3000 請求就會走限流邏輯。
然后去調(diào)用我們自己開發(fā)的降級組件(降級),比如設(shè)置的一些默認(rèn)值呀之類的。以此來保護(hù)最后的 MySQL 不會被大量的請求給打死。
4.2.3 事后:
一旦重啟,就能從磁盤上自動加載數(shù)據(jù)恢復(fù)內(nèi)存中的數(shù)據(jù)。
防止雪崩方案如下圖所示:
我們在設(shè)置緩存的時(shí)候,一般會給緩存設(shè)置一個(gè)失效時(shí)間,過了這個(gè)時(shí)間,緩存就失效了。
對于一些熱點(diǎn)的數(shù)據(jù)來說,當(dāng)緩存失效以后會存在大量的請求過來,然后打到數(shù)據(jù)庫去,從而可能導(dǎo)致數(shù)據(jù)庫崩潰的情況。
5.1.1 設(shè)置不同的失效時(shí)間
為了避免這些熱點(diǎn)的數(shù)據(jù)集中失效,那么我們在設(shè)置緩存過期時(shí)間的時(shí)候,我們讓他們失效的時(shí)間錯(cuò)開。
比如在一個(gè)基礎(chǔ)的時(shí)間上加上或者減去一個(gè)范圍內(nèi)的隨機(jī)值。
5.1.2 互斥鎖
結(jié)合上面的擊穿的情況,在第一個(gè)請求去查詢數(shù)據(jù)庫的時(shí)候?qū)λ右粋€(gè)互斥鎖,其余的查詢請求都會被阻塞住,直到鎖被釋放,從而保護(hù)數(shù)據(jù)庫。
但是也是由于它會阻塞其他的線程,此時(shí)系統(tǒng)吞吐量會下降。需要結(jié)合實(shí)際的業(yè)務(wù)去考慮是否要這么做。
當(dāng)前題目:Redis高級應(yīng)用解析:緩存穿透、擊穿、雪崩
文章起源:http://aaarwkj.com/article34/igjpse.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供響應(yīng)式網(wǎng)站、微信小程序、品牌網(wǎng)站制作、網(wǎng)站策劃、動態(tài)網(wǎng)站、域名注冊
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)