作者:周二鴨
來源:https://www.cnblogs.com/jojop/p/14106671.html
Redis經(jīng)常用于系統(tǒng)中的緩存,這樣可以解決目前IO設(shè)備無法滿足互聯(lián)網(wǎng)應(yīng)用海量的讀寫請求的問題。一、緩存穿透
緩存穿透是指緩存和數(shù)據(jù)庫中都沒有的數(shù)據(jù),而用戶不斷發(fā)起請求,如發(fā)起id為-1的數(shù)據(jù)或者特別大的不存在的數(shù)據(jù)。有可能是黑客利用漏洞攻擊從而去壓垮應(yīng)用的數(shù)據(jù)庫。1. 常見解決方案
對于緩存穿透問題,常見的解決方案有以下三種:- 驗證攔截:接口層進(jìn)行校驗,如鑒定用戶權(quán)限,對ID之類的字段做基礎(chǔ)的校驗,如id<=0的字段直接攔截;
- 緩存空數(shù)據(jù):當(dāng)數(shù)據(jù)庫查詢到的數(shù)據(jù)為空時,也將這條數(shù)據(jù)進(jìn)行緩存,但緩存的有效性設(shè)置得要較短,以免影響正常數(shù)據(jù)的緩存;
Copy
public Student getStudentsByID(Long id) { // 從Redis中獲取學(xué)生信息 Student student = redisTemplate.opsForValue() .get(String.valueOf(id)); if (student != null) { return student; } // 從數(shù)據(jù)庫查詢學(xué)生信息,并存入Redis student = studentDao.selectByStudentId(id); if (student != null) { redisTemplate.opsForValue() .set(String.valueOf(id), student, 60, TimeUnit.MINUTES); } else { // 即使不存在,也將其存入緩存中 redisTemplate.opsForValue() .set(String.valueOf(id), null, 60, TimeUnit.SECONDS); } return student;}
- 使用布隆過濾器:布隆過濾器是一種比較獨特數(shù)據(jù)結(jié)構(gòu),有一定的誤差。當(dāng)它指定一個數(shù)據(jù)存在時,它不一定存在,但是當(dāng)它指定一個數(shù)據(jù)不存在時,那么它一定是不存在的。
2. 布隆過濾器
布隆過濾器是一種比較特殊的數(shù)據(jù)結(jié)構(gòu),有點類似與HashMap,在業(yè)務(wù)中我們可能會通過使用HashMap來判斷一個值是否存在,它可以在O(1)時間復(fù)雜度內(nèi)返回結(jié)果,效率極高,但是受限于存儲容量,如果可能需要去判斷的值超過億級別,那么HashMap所占的內(nèi)存就很可觀了。而BloomFilter解決這個問題的方案很簡單。首先用多個bit位去代替HashMap中的數(shù)組,這樣的話儲存空間就下來了,之后就是對 Key 進(jìn)行多次哈希,將 Key 哈希后的值所對應(yīng)的 bit 位置為1。當(dāng)判斷一個元素是否存在時,就去判斷這個值哈希出來的比特位是否都為1,如果都為1,那么可能存在,也可能不存在(如下圖F)。但是如果有一個bit位不為1,那么這個Key就肯定不存在。注意: BloomFilter并不支持刪除操作,只支持添加操作。這一點很容易理解,因為你如果要刪除數(shù)據(jù),就得將對應(yīng)的bit位置為0,但是你這個Key對應(yīng)的bit位可能其他的Key也對應(yīng)著。
3. 緩存空數(shù)據(jù)與布隆過濾器的比較
上面對這兩種方案都進(jìn)行了簡單的介紹,緩存空數(shù)據(jù)與布隆過濾器都能有效解決緩存穿透問題,但使用場景有著些許不同;- 當(dāng)一些惡意攻擊查詢查詢的key各不相同,而且數(shù)量巨多,此時緩存空數(shù)據(jù)不是一個好的解決方案。因為它需要存儲所有的Key,內(nèi)存空間占用高。并且在這種情況下,很多key可能只用一次,所以存儲下來沒有意義。所以對于這種情況而言,使用布隆過濾器是個不錯的選擇;
- 而對與空數(shù)據(jù)的Key數(shù)量有限、Key重復(fù)請求效率較高的場景而言,可以選擇緩存空數(shù)據(jù)的方案。
二、緩存擊穿
緩存擊穿是指當(dāng)前熱點數(shù)據(jù)存儲到期時,多個線程同時并發(fā)訪問熱點數(shù)據(jù)。因為緩存剛過期,所有并發(fā)請求都會到數(shù)據(jù)庫中查詢數(shù)據(jù)。解決方案
- 將熱點數(shù)據(jù)設(shè)置為永不過期;
- 加互斥鎖:互斥鎖可以控制查詢數(shù)據(jù)庫的線程訪問,但這種方案會導(dǎo)致系統(tǒng)的吞吐量下降,需要根據(jù)實際情況使用。
public String get(key) { String value = redis.get(key); if (value == null) { // 代表緩存值過期 // 設(shè)置3min的超時,防止del操作失敗的時候,下次緩存過期一直不能load db if (redis.setnx(key_mutex, 1, 3 * 60) == 1) { // 代表設(shè)置成功 value = db.get(key); redis.set(key, value, expire_secs); redis.del(key_mutex); } else { // 這個時候代表同時候的其他線程已經(jīng)load db并回設(shè)到緩存了,這時候重試獲取緩存值即可 sleep(50); get(key); // 重試 } } else { return value; }}
Copy
三、緩存雪崩
緩存雪崩發(fā)生有幾種情況,比如大量緩存集中在或者緩存同時在大范圍中失效,出現(xiàn)了大量請求去訪問數(shù)據(jù)庫,從而導(dǎo)致CPU和內(nèi)存過載,甚至停機。一個簡單的雪崩過程:- Redis 集群產(chǎn)生了大面積故障;
- 緩存失敗,此時仍有大量請求去訪問 Redis 緩存服務(wù)器;
- 在大量 Redis 請求失敗后,這些請求將會去訪問數(shù)據(jù)庫;
- 由于應(yīng)用的設(shè)計依賴于數(shù)據(jù)庫和 Redis 服務(wù),很快就會造成服務(wù)器集群的雪崩,最終導(dǎo)致整個系統(tǒng)的癱瘓。
解決方案
- 【事前】高可用緩存:高可用緩存是防止出現(xiàn)整個緩存故障。即使個別節(jié)點,機器甚至機房都關(guān)閉,系統(tǒng)仍然可以提供服務(wù),Redis 哨兵(Sentinel) 和 Redis 集群(Cluster) 都可以做到高可用;
- 【事中】緩存降級(臨時支持):當(dāng)訪問次數(shù)急劇增加導(dǎo)致服務(wù)出現(xiàn)問題時,我們?nèi)绾未_保服務(wù)仍然可用。在國內(nèi)使用比較多的是 Hystrix,它通過熔斷、降級、限流三個手段來降低雪崩發(fā)生后的損失。只要確保數(shù)據(jù)庫不死,系統(tǒng)總可以響應(yīng)請求,每年的春節(jié) 12306 我們不都是這么過來的嗎?只要還可以響應(yīng)起碼還有搶到票的機會;
- 【事后】Redis備份和快速預(yù)熱:Redis數(shù)據(jù)備份和恢復(fù)、快速緩存預(yù)熱。
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!