1.我們使用快取時的業務流程大概為：
當我們查詢一條資料時，先去查詢快取，如果快取有就直接回傳，如果沒有就去查詢資料庫，然后回傳，這種情況下就可能出現下面的一些現象，
2.快取穿透
2.1什么是快取穿透
快取穿透是指查詢一個一定不存在的資料，由于快取是不命中時被動寫的，并且出于容錯考慮，如果從存盤層查不到資料則不寫入快取，這將導致這個不存在的資料每次請求都要到存盤層去查詢，失去了快取的意義，在流量大時，可能DB就掛掉了，要是有人利用不存在的key頻繁攻擊我們的應用，這就是漏洞，
2.2快取穿透帶來的問題
試想一下，如果有黑客對你的系統進行攻擊，拿一個不存在的id去查詢資料，會產生大量的請求到你的資料庫去查詢，可能會導致你的資料庫由于壓力過大而宕掉，
2.3解決的辦法
2.3.1快取空值
之所以會發生穿透，就是因為快取中沒有儲存這些空資料的key，從而導致每次查詢都到資料庫去了，
那么我們就可以為這些key對應的值設定為null丟到快取里面去，后面出現查詢這個key的請求的時候直接回傳null，
這樣就不用再到資料庫中去走一圈了，但是別忘了設定過期時間，
快取空物件會有兩個問題：
第一，空值做了快取，意味著快取層中存了更多的鍵，需要更多的記憶體空間 ( 如果是攻擊，問題更嚴重 )，比較有效的方法是針對這類資料設定一個較短的過期時間，讓其自動剔除，
第二，快取層和存盤層的資料會有一段時間視窗的不一致，可能會對業務有一定影響，例如過期時間設定為 5分鐘，如果此時存盤層添加了這個資料，那此段時間就會出現快取層和存盤層資料的不一致，此時可以利用訊息系統或者其他方式清除掉快取層中的空物件，
2.3.2用布隆過濾器BloomFilter
BloomFilter類似于一個hbase set用來判斷某個元素(key)是否存在于某個集合中，
這種方式在大資料場景應用比較多，比如Hbase中使用它去判斷資料是否在磁盤上，還有在爬蟲場景判斷url是否已經被爬取過，
這種方案可以加在第一種方案中，在快取之前加一層BloomFilter，在查詢的時候先去BloomFilter去查詢key是否存在，如果不存在就直接回傳，存在再去查快取-------->差資料庫，
流程圖如下：
2.4如何選擇
針對于一些惡意攻擊，攻擊帶來大量key是不存在的，那么我們采用第一種方案就會快取大量不存在的資料，此時我們采用第一種方案就不合適了，我們完全可以先使用第二種方案過濾掉這些key，
針對這些key例外多，請求多，重復率比較低的資料，我們就沒有必要進行快取，使用第二種方案直接過濾掉，
而對于空資料的key有限的，重復率比較高的，我們則可以采用第一種方式進行快取，
3.快取擊穿
3.1什么是快取擊穿
快取擊穿是我們使用快取可能遇到的第二個問題，
在平時高并發的系統中，大量的請求同時查詢一個key時，此時這個key正好失效了，就會導致大量的請求都打到資料庫上面去，這種現象我們稱為快取擊穿，
3.2會帶來什么問題
會造成某一時刻資料請求量過大，壓力劇增，
3.3如何解決
上面現象是多個執行緒同時去查詢資料庫的這一條資料，那么我們可以在第一個查詢資料的請求上使用一個互斥鎖來鎖住它，（如果是單機，可以用synchronized或者lock來處理，如果是分布式環境可以用分布式鎖就可以了（分布式鎖，可以用memcache的add, redis的setnx, zookeeper的添加節點操作））
其他執行緒走到這一步拿不到鎖就等著，等待第一個執行緒查詢到了資料，然后做快取，后面的執行緒進來發現已經有了快取，就直接走快取，
4.快取雪崩
4.1什么是快取雪崩
快取雪崩的情況是指：當某一時刻發生大規模的快取失效的情況，比如你的快取服務宕機了，會有大量的請求進來直接打到資料庫上面，結果就是資料庫掛掉，
4.2解決辦法
4.2.1雪崩前：使用集群快取，保證快取服務的高可用
這種方案就是在發生雪崩前對快取集群，實作高可用，如果是使用Redis，可以使用（主從 + 哨兵），Redis Cluster來避免Redis全盤崩潰的情況，
4.2.2雪崩中：ehcache本地快取 + Hystrix限流 & 降級，避免MySQl被打死
使用ehcache本地快取的目的也是考慮Redis Cluster完全不可用的時候，ehcache本地快取還能夠支撐一陣，
使用Hystrix進行限流 & 降級，比如一秒來了5000個請求，我們可以設定假設一秒只能有2000個請求可以通過這個組件，那么其他剩余的3000請求就會走限流邏輯，
然后去呼叫我們自己開發的降級組件（降級）,比如設定的一些默認值等等之類的，以此來保護最后的MySQl不會被大量的請求打死，
4.2.3雪崩后：開啟Redis持久化，盡快恢復快取集群，
5.解決熱點資料集中失效問題
我們在設定快取的時候，一般會給快取設定一個失效的時間，過了這個時間，快取就失效了，
對于一些熱點資料來說，當快取失效后會存在大量的請求到資料庫上來，從而可能導致資料庫崩潰的情況，
5.1解決辦法
5.1.1設定不同的失效時間
為了避免這些熱點資料集體失效，那么我們在設定快取過期時間的時侯，讓他們失效的時間錯開，比如我們可以在原有的失效時間基礎上增加一個隨機值，
5.1.2互斥鎖
結合上面的擊穿情況，在第一個請求去查詢資料庫的時候對它加一個互斥鎖，其余的查詢請求都會被阻塞住，直到鎖被釋放，從而保護資料庫，
但是也是由于它會阻塞其他執行緒，此時系統的吞吐量會下降，需要結合實際業務去考慮，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/103166.html
標籤：MySQL