Redis 快取穿透快取雪崩

1. 快取穿透

如何避免？

如何選擇？

2 快取擊穿

如何解決

3. 快取雪崩

如何解決？

快取穿透：一般的快取系統，都是按照key去快取查詢，如果不存在對應的value，就應該去後端系統查詢（比如db）。一些惡意的請求會故意查詢不存在的key，請求量很大，就會對後端系統造成很大的壓力，或導致資料庫異常。這就叫做快取穿透。

之所以會發生穿透，就是因為快取中沒有儲存這些空資料的key。從而導致每次查詢都到資料庫去了。那麼就可以為這些key對應的值設定為null，設定短一點的過期時間，然後存到快取裡面去。後面再出現查詢這個key 的請求的時候，直接返回null 。

布隆過濾器對查詢的key進行過濾，過濾掉不存在的key。bloomfilter就類似於乙個hash set，用於快速判某個元素是否存在於集合中，其典型的應用場景就是快速判斷乙個key是否存在於某容器，不存在就直接返回。

該方案可以加在第一種方案中，在快取之前在加一層 bloomfilter ，在查詢的時候先去 bloomfilter 去查詢 key 是否存在，如果不存在就直接返回，存在再走查快取 -> 查 db。

在平常高併發的系統中，大量的請求同時查詢乙個 key 時，此時這個key正好失效了，就會導致大量的請求都打到資料庫上面去。這種現象我們稱為快取擊穿。

快取擊穿會造成某一時刻資料庫請求量過大，壓力劇增。

使用互斥鎖排隊：上面的現象是多個執行緒同時去查詢資料庫的這條資料，那麼可以在第乙個查詢資料的請求上使用乙個互斥鎖來鎖住它。其他的執行緒走到這一步拿不到鎖就等著，等第乙個執行緒查詢到了資料，然後做快取。後面的執行緒進來發現已經有快取了，就直接走快取。

當某一時刻發生大規模的快取失效的情況，比如你的快取服務宕機了，會有大量的請求進來直接打到db上面。結果就是db 稱不住，掛掉。

這種方案就是在發生雪崩前對快取集群實現高可用，如果是使用 redis，可以使用主從+哨兵，redis cluster 來避免 redis 全盤崩潰的情況。

ehcache本地快取：直接在jvm虛擬機器中快取，速度快，效率高；使用ehcache+redis快取後，使用者傳送來乙個請求後，先查ehcache本地快取，如果沒有再查redis快取。如果ehcahe和redis快取都沒有，再查資料庫；

hystrix限流&降級：

限流元件：可以設定元件能夠接收的請求閾值；比如一秒來了5000個請求，我們可以設定假設只能有一秒 2000個請求能通過這個元件，那麼其他剩餘的 3000 請求就會走限流邏輯。呼叫降級元件處理被限流的請求。

降級元件：需要自己開發降級元件（降級），比如設定的一些預設值呀之類的。以此來保護最後的 mysql 不會被大量的請求給打死。

參考：

Redis 快取穿透 快取雪崩