這篇文章主要講解了“如何理解redis雪崩、擊穿、穿透、預熱、降級”，文中的講解內(nèi)容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“如何理解Redis雪崩、擊穿、穿透、預熱、降級”吧!
站在用戶的角度思考問題，與客戶深入溝通，找到鳳縣網(wǎng)站設計與鳳縣網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：成都做網(wǎng)站、網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、域名申請、虛擬主機、企業(yè)郵箱。業(yè)務覆蓋鳳縣地區(qū)。
緩存擊穿根據(jù)名字根本無法看懂是什么意思，并且很容易和另一個詞——緩存穿透搞混。緩存擊穿指的是某個 key 一直在扛著高并發(fā)，所謂扛著高并發(fā)就是說大量的請求都是獲取這個 key 對應的值。
而這個 key 在某個時間突然失效了，那是不是就意味著大量的請求就無法在緩存中獲取數(shù)據(jù)了，而是去請求數(shù)據(jù)庫了，這樣很有可能導致數(shù)據(jù)庫被擊垮。這就是緩存擊穿。
那現(xiàn)在問題知道了，該如何應對呢？這個就比較簡單了，既然這個 key 這個受歡迎，那么就不要設置過期時間了，如果該key的數(shù)據(jù)更新了，那么就通過互斥鎖的方式將其更新。
為什么要用互斥鎖的方式？如果不使用互斥鎖的方式很容易導致數(shù)據(jù)不一致的情況，這里為了保證緩存和數(shù)據(jù)庫的一致性，就只能犧牲一點點的效率了。
不知道各位小伙伴都是來自哪里，我們那邊有句方言叫“雪崩”，表示事情砸了的意思。這里的Redis 雪崩似乎有點異曲同工之妙。首先我們需要知道什么是 Redis雪崩，
Redis雪崩我們一般都稱為緩存雪崩，意思就是說在某個時間節(jié)點，大量的 key 失效，導致大量的請求從緩存中獲取不到數(shù)據(jù)而去請求數(shù)據(jù)庫。根據(jù)上面的那張圖，我們再來畫下雪崩的情況的是什么樣子的：
上面的黑色的部分表示緩存無效了，也就意味著所有的請求都需要到數(shù)據(jù)庫中去查詢數(shù)據(jù)。那這對于數(shù)據(jù)庫的壓力必然是劇增的，如果是在一線互聯(lián)網(wǎng)這樣超高并發(fā)的場景下，數(shù)據(jù)庫直接宕機。
重啟也沒有用，因為重啟了還會有巨大的流量涌進來，然后繼續(xù)被搞宕機。所以對于預防緩存雪崩這種情況的發(fā)生意義還是很大的的。
緩存雪崩解決方案之加隨機值
上面已經(jīng)詳細介紹了什么是緩存雪崩，他是怎么發(fā)生的，那如果防止緩存雪崩呢？
很簡單，因為上面剛剛說到，緩存雪崩是由于某個時間節(jié)點大量的 key 失效而導致的問題，那現(xiàn)在的問題不就是變成了如何防止同一個時間節(jié)點大量的 key 失效這種情況發(fā)生嗎？
最簡單的情況就是把key的過期時間分散開，也就是在設置key的過期時間的時候再加一個隨機值，就這樣就能完美的解決緩存雪崩的問題。
但是你以為我說到這里就完事了？既然是一次全安排，那么我一定不會僅僅告訴你一種解決方案就完事的。繼續(xù)看
緩存雪崩解決方案之加鎖
可能很多人看到這個方案表示不接受，加鎖那不是限制了并發(fā)？加鎖必然導致阻塞。如果是加鎖，那么執(zhí)行就成就是這個樣子了：
流程是這樣子的，在多個請求同時到達業(yè)務系統(tǒng)時候，只能有一個線程能獲取到鎖，然后才能繼續(xù)去緩存或者是數(shù)據(jù)庫中查詢數(shù)據(jù)，然后后面的流程和之前的是一樣的，執(zhí)行完成后釋放鎖，然后其他線程再爭搶鎖，然后重復前面的流程。
這個方案的優(yōu)點是可以很好的保護數(shù)據(jù)庫不會被打掛，缺點就是并發(fā)度極低。
上面這個方案其實還是可以再優(yōu)化下的：
這個就是在緩存中如果獲取不到，再去串行的訪問數(shù)據(jù)看，這里不一定非要串行，可以配合線程池，控制一定的并發(fā)數(shù)。
這個缺點雖然很多，但是也是一種解決方案。用不用就看實際的業(yè)務場景了。畢竟沒有沒用技術(shù)方案，只有不適合業(yè)務場景的技術(shù)方案（手動狗頭）。
緩存穿透意思就是某個不存在的key一直被訪問，結(jié)果發(fā)現(xiàn)數(shù)據(jù)庫中也沒有這樣的數(shù)據(jù)，最終導致訪問該key的所有請求都直接請求到數(shù)據(jù)庫了。如果是并發(fā)高的場景下就容易搞垮數(shù)據(jù)庫。大家有沒有發(fā)現(xiàn)我們做的一些事情都是在保護“弱小的數(shù)據(jù)庫”。
那現(xiàn)在問題已經(jīng)知道了，我們該如何去解決這個問題呢？
啥叫緩存空數(shù)據(jù)？就是假設某個key數(shù)據(jù)并不存在，那么就存一個 NULL 就好了，但是一定不要忘記設置過期時間，因為假設id=3的記錄不存在，然后本次訪問沒有查詢到數(shù)據(jù)，緩存中存的是null如果過一會兒新增了一條記錄為3的數(shù)據(jù)，如果緩存不設置過期時間，那么這條數(shù)據(jù)就永遠獲取不到。
布隆過濾器？這玩意到底什么意思？
布隆過濾器是一種數(shù)據(jù)結(jié)構(gòu)，更準確的說是一種概率型的數(shù)據(jù)結(jié)構(gòu)，因為它能判斷某個元素一定不存在或者是可能存在。
就這句話，搞蒙了很多人，今天我非要把你說明白了。布隆過濾器是一個bit數(shù)組，一個很長的bit數(shù)組和一系列的hash函數(shù)構(gòu)成。先看下圖
我們現(xiàn)在來舉個例子，假設現(xiàn)在有小強和旺財兩個人，他們分別經(jīng)過三次hash得到的下標是這樣子的（布隆過濾器不存儲元素，僅僅是為一個元素是否存在打一個標志）
小強經(jīng)過上面的三個hash后得到的下標分別為：2、4、5，那么該數(shù)組的2、4、5位置就會被置為1，也就是此時是這樣子的
同樣旺財經(jīng)過上面的三個hash后得到的下標分別為：3、7、11，那么該數(shù)組的3、7、11位置就會被置為1，也就是此時是這樣子的
現(xiàn)在假設來一個 007 經(jīng)過上面的三個hash后得到的下標分別為：11、13、15因為13、和15位置是0，所以一定可以判斷007 一定不存在。但是現(xiàn)在又來了一個
9527經(jīng)過上面的三個hash后得到的下標分別為：2、5、7，但是你會發(fā)現(xiàn)257三個位置全部是1，那這個到底說明9527是存在還是不存在呢？
從我們上面的講解可以 9527 之前并不存在，但是由于hash沖突，但是9527的三個下標值也剛好落在已經(jīng)被置為1的下標位置，這就導致此時是無法判斷9527是否存在的。這就是布隆過濾器的原理。
要不來段代碼壓壓驚？
我們來使用 google 包下的類來測試。首先要添加依賴
com.google.guava guava 30.1-jre
代碼如下（詳細的解釋我已經(jīng)寫在注釋中了，這個是可以用于實際生產(chǎn)的代碼）
重慶分公司
重慶分公司
public class BloomFilterDemo { public static void main(String[] args) { /** * 創(chuàng)建一個插入對象為一億，誤報率為0.01%的布隆過濾器 * 不存在一定不存在 * 存在不一定存在 */ BloomFilter<CharSequence> bloomFilter = BloomFilter.create(Funnels.stringFunnel(Charset.forName("utf-8")), 100000000, 0.0001); bloomFilter.put("死"); bloomFilter.put("磕"); bloomFilter.put("Redis"); System.out.println(bloomFilter.mightContain("Redis")); System.out.println(bloomFilter.mightContain("死")); System.out.println(bloomFilter.mightContain("磕")); System.out.println(bloomFilter.mightContain("Java")); } }
結(jié)果
完。
等等……緩存穿透、預熱、降級你還沒說呢。哦，我真的以為本文結(jié)束了。
那布隆過濾器是如何解決緩存穿透的問題的呢？既然已經(jīng)知道了布隆過濾器的原理，那么就可以通過布隆過濾器來快速的判斷出一個key是否存在數(shù)據(jù)庫中，如果可能存在再去數(shù)據(jù)庫查詢，如果布隆過濾器中不存在那么就需要再去數(shù)據(jù)庫查詢了。
這又是什么鬼？怎么搞一個緩存還有這么多問題，那還要緩存干啥？
所謂緩存預熱就是將一些可能經(jīng)常使用數(shù)據(jù)在系統(tǒng)啟動的時候預先設置到緩存中，這樣可以避免在使用到的時候先去數(shù)據(jù)庫中查詢。
這就是緩存預熱，名氣高大上，實際上很簡單有木有，這個緩存預熱我在實際場景是經(jīng)常使用的。
還有一種方式就是添加一個緩存刷新頁，這樣通過人工干預的方式將一些可能為熱點的key添加到緩存中。
當訪問量突然劇增（例如下班的點，大家都在地鐵上刷手機呢）、服務出現(xiàn)問題（如響應時間慢或不響應）或非核心服務影響到核心流程的性能時，仍然需要保證服務還是可用的，即使是有損服務。
系統(tǒng)可以根據(jù)一些關鍵數(shù)據(jù)進行自動降級，降級的最終目的是保證核心服務可用，即使是有損的。但是有的一些業(yè)務的核心服務是不能降級的。這是一種丟卒保帥的思想。
感謝各位的閱讀，以上就是“如何理解Redis雪崩、擊穿、穿透、預熱、降級”的內(nèi)容了，經(jīng)過本文的學習后，相信大家對如何理解Redis雪崩、擊穿、穿透、預熱、降級這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關知識點的文章，歡迎關注！
