1 前言
昨天晚上接到阿里的電面電話，過程中就問到了關於快取相關的問題。雖然以前接觸過，多多少少了解了一些。但是之前自己並沒有好好記錄這些內容，在真正面試的時候，並沒有回答得出來。今天記錄一下，長長記性。
在我們的平常的專案中多多少少都會使用到快取，因為一些資料我們沒有必要每次查詢的時候都去查詢到資料庫。特別是高 QPS 的系統，每次都去查詢資料庫，對於你的資料庫來說將是災難。
今天我們不牽涉多級快取的知識，就把系統使用到的快取方案，不管是一級還是多級的都統稱為快取，主要是為了講述使用快取的時候可能會遇到的一些問題以及一些解決辦法。
我們使用快取時，我們的業務系統大概的呼叫流程如下圖：
當我們查詢一條資料時，先去查詢快取，如果快取有就直接返回，如果沒有就去查詢資料庫，然後返回。這種情況下就可能會出現一些現象。
2 快取穿透
2.1 什麼是快取穿透
正常情況下，我們去查詢資料都是存在。那麼請求去查詢一條壓根資料庫中根本就不存在的資料，也就是快取和資料庫都查詢不到這條資料，但是請求每次都會打到資料庫上面去。
這種查詢不存在資料的現象我們稱為快取穿透。
2.2 穿透帶來的問題
試想一下，如果有黑客會對你的系統進行攻擊，拿一個不存在的id 去查詢資料，會產生大量的請求到資料庫去查詢。可能會導致你的資料庫由於壓力過大而宕掉。
2.3 解決辦法
2.3.1 快取空值
之所以會發生穿透，就是因為快取中沒有儲存這些空資料的key。從而導致每次查詢都到資料庫去了。
那麼我們就可以為這些key 設定的值設定為null 丟到快取裡面去。後面再出現查詢這個key 的請求的時候，直接返回null ,就不用在到 資料庫中去走一圈了。但是別忘了設定過期時間。
2.3.2 BloomFilter
BloomFilter 類似於一個hase set 用來判斷某個元素（key）是否存在於某個集合中。具體概念
這種方式在大資料場景應用比較多，比如 Hbase 中使用它去判斷資料是否在磁碟上。還有在爬蟲場景判斷url 是否已經被爬取過。
這種方案可以加在第一種方案中，在快取之前在加一層 BloomFilter ，在查詢的時候先去 BloomFilter 去查詢 key 是否存在，如果不存在就直接返回，存在再走查 快取 -> 查 DB。
流程圖如下：
2.4 如何選擇
針對於一些惡意攻擊，攻擊帶過來的大量key 是不存在的，那麼我們採用第一種方案就會快取大量不存在 key 的資料。此時我們採用第一種方案就不合適了，我們完全可以先對使用第二種方案進行過濾掉這些key。
針對這種key 異常多，請求重複率比較低的資料，我們就沒有必要進行快取，使用第二種方案直接過濾掉。
對於空資料的key 有限的，重複率比較高的，我們則可以採用第一種方式進行快取。
3 快取擊穿
3.1 什麼是擊穿
快取擊穿是我們可能遇到的第二個使用快取方案可能遇到的問題。
在平常高併發的系統中，大量的請求同時查詢一個 key 時，此時 這個key 正好失效了，就會導致大量的請求都打到資料庫上面去。這種現象我們成為擊穿。
3.2 會帶來什麼問題
會造成某一時刻資料庫請求量過大，壓力劇增。
3.3 如何解決
上面的現象是多個執行緒同時去查詢資料庫的這條資料，那麼我們可以在第一個查詢資料的請求上使用一個 互斥鎖來鎖住它。其他的執行緒走到這一步拿不到鎖就等著，等第一個執行緒查詢到了資料，然後做快取。後面的執行緒進來發現已經有快取了，就直接走快取。
4、快取雪崩
4.1 什麼是快取雪崩
快取的情況是說，當某一時刻發生大規模的快取失效的情況。比如你的快取服務當機了，會有大量的請求進來直接打到DB上面。結果就是DB 稱不住，掛掉。
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 互斥鎖
結合上面的擊穿的情況，在第一個請求去查詢資料庫的時候對他加一個互斥鎖，其餘的查詢請求都會被阻塞住，直到鎖被釋放，從而保護資料庫。但是也是由於它會阻塞其他的執行緒，此時系統吞吐量會下降。需要結合實際的業務去考慮是否要這麼做。
參考資料：
快取世界中的三大問題及解決方案
中華石杉老師的Java突擊面試資料
轉自公眾號：喬二爺
原文地址：https://mp.weixin.qq.com/s/kllwx6mRNIScChG...
本作品系原創（除文中說明外）， 採用《CC 協議》許可，轉載必須註明作者和本文連結