1、緩存預熱

1、定義

緩存預熱就是系統上線后，提前將相關的緩存數據直接加載到緩存系統。

避免在用戶請求的時候，先查詢數據庫，然后再將數據緩存的問題！用戶直接查詢事先被預熱的緩存數據！


2、解決方案

1）直接寫個緩存刷新頁面，上線時手工操作下。
2）數據量不大，可以在項目啟動的時候自動進行加載。
3）定時刷新緩存。

2、緩存雪崩

發生原因
redis主機掛了，redis全面崩潰，偏硬件運維
redis中有大量key同時過期大面積失效，偏軟件開發


預防和解決
redis中key設置為永不過期or過期時間錯開
redis緩存集群實現高可用
    主從+哨兵
    redis cluster
    開啟redis持久化機制aof/rdb,盡快恢復緩存集群
多緩存結合預防雪崩
    ehcache本地緩存+redis緩存
服務降級
    Hystrix或者阿里sentinel限流&降級

3、緩存擊穿

3.1、是什么

請求去查詢一條記錄，先查redis無，后查mysql無，都查詢不到該條記錄
但是請求每次都會打到數據庫上面去，導致后臺數據庫壓力暴增，這種現象稱為緩存穿透，rendis變成了一個擺設


簡單來說，本來無一物，兩庫都沒有
即不在redis緩存庫，也不在mysql，數據庫存在被多次暴擊風險

3.2、解決

方案1:空對象緩存或者缺省值

第一種解決方案，回寫增強
如果發生了緩存穿透，我們可以針對要查詢的數據，在Redis里存一個和業務部門商量后確定的缺省值(比如，零、負數、defaultNull等)。
比如，鍵uid:abcdxxx，值defaultNull作為案例的key和value
先去redis查鍵uid:abcdxxx沒有，再去mysql查沒有獲得 ，這就發生了一次穿透現象。


but，可以增強回寫機制
mysql也查不到的話也讓redis存入剛剛查不到的key并保護mysql。
第一次來查詢uid:abcdxxx，redis和mysql都沒有，返回null給調用者，但是增強回寫后第二次來查uid:abcdxxx，此時redis就有值了。
可以直接從Redis中讀取default缺省值返回給業務應用程序，避免了把大量請求發送給mysql處理，打爆mysql。


但是，此方法架不住黑客的惡意攻擊，有缺陷......，只能解決key相同的情況


黑客或惡意攻擊
黑客會對你的系統進行攻擊，拿一個不存在的id去查詢數據，會產生大量的請求到數據庫去查詢，可能會導致你的數據庫由于壓力過大而宕掉


key相同打你系統
  第一次打到mysql空對象緩存后第二次就返回default Null缺省值
  避免mysql被攻擊，不用再到數據庫中去走一圈了
key不同打你系統
  由于存在空對象緩存和緩存會寫(看自己業務不限死)
  redis中的無關緊要的key也會越寫越多(記得設置redis過期時間)

方案2:Google布隆過濾器Guava解決緩存穿透

白名單架構

布隆過濾器說明

誤判問題，但是概率小可以接受，不能從布隆過濾器刪除
全部合法的key都需要放入Guava版布隆過濾器和redis里面，不然數據就是返回null

4、緩存穿透

4.1、是什么

大量的請求同時查詢一個key時，此時這個key正好失效了，導致大量的請求都打到數據庫上面去
簡單說就是熱點key突然失效了，暴打mysql

4.1、危害

會造成某一時刻數據庫請求量過大，壓力劇增
一般技術部門需要知道熱點key時那些，防止擊穿

4.1、解決

熱點key失效
時間到了自然清除但還被訪問到
delete掉的key，剛巧又被訪問


方案1：
差異失效時間，對于訪問頻繁的熱點key，干脆就不設置過期時間
方案2：
互斥更新，采用雙檢加鎖策略


多個線程同時去查詢數據庫的這條數據，那么我們可以在第一個查詢數據的請求上使用一個 互斥鎖來鎖住它。
其他的線程走到這一步拿不到鎖就等著，等第一個線程查詢到了數據，然后做緩存。后面的線程進來發現已經有緩存了，就直接走緩存。

5、總結

好了，今天的小知識你學會了嗎？

鏈接：https://blog.51cto.com/u_13236892/8955597

審核編輯：劉清