Redis 快取穿透,快取擊穿,快取雪崩的解決方案分析
設計一個快取系統,不得不要考慮的問題就是:快取穿透、快取擊穿與失效時的雪崩效應。
一.什麼樣的資料適合快取?
分析一個數據是否適合快取,我們要從訪問頻率、讀寫比例、資料一致性等要求去分析.
二.什麼是快取擊穿
在高併發下,多執行緒同時查詢同一個資源,如果快取中沒有這個資源,那麼這些執行緒都會去資料庫查詢,對資料庫造成極大壓力,快取失去存在的意義.打個比方,資料庫是人,快取是防彈衣,子彈是執行緒,本來防彈衣是防止子彈打到人身上的,但是當防彈衣裡面沒有防彈的物質時,子彈就會穿過它打到人身上.
三.快取擊穿的解決辦法
方案一
後臺重新整理
後臺定義一個job(定時任務)專門主動更新快取資料.比如,一個快取中的資料過期時間是30分鐘,那麼job每隔29分鐘定時重新整理資料(將從資料庫中查到的資料更新到快取中).
- 這種方案比較容易理解,但會增加系統複雜度。比較適合那些 key 相對固定,cache 粒度較大的業務,key 比較分散的則不太適合,實現起來也比較複雜。
方案二
檢查更新
將快取key的過期時間(絕對時間)一起儲存到快取中(可以拼接,可以新增新欄位,可以採用單獨的key儲存..不管用什麼方式,只要兩者建立好關聯關係就行).在每次執行get操作後,都將get出來的快取過期時間與當前系統時間做一個對比,如果快取過期時間-當前系統時間<=1分鐘(自定義的一個值),則主動更新快取.這樣就能保證快取中的資料始終是最新的(和方案一一樣,讓資料不過期.)
- 這種方案在特殊情況下也會有問題。假設快取過期時間是12:00,而 11:59 到 12:00這 1 分鐘時間裡恰好沒有 get 請求過來,又恰好請求都在 11:30 分的時 候高併發過來,那就悲劇了。這種情況比較極端,但並不是沒有可能。因為“高 併發”也可能是階段性在某個時間點爆發。
方案三
分級快取
採用 L1 (一級快取)和 L2(二級快取) 快取方式,L1 快取失效時間短,L2 快取失效時間長。 請求優先從 L1 快取獲取資料,如果 L1快取未命中則加鎖,只有 1 個執行緒獲取到鎖,這個執行緒再從資料庫中讀取資料並將資料再更新到到 L1 快取和 L2 快取中,而其他執行緒依舊從 L2 快取獲取資料並返回。
- 這種方式,主要是通過避免快取同時失效並結合鎖機制實現。所以,當資料更 新時,只能淘汰 L1 快取,不能同時將 L1 和 L2 中的快取同時淘汰。L2 快取中 可能會存在髒資料,需要業務能夠容忍這種短時間的不一致。而且,這種方案 可能會造成額外的快取空間浪費。
方案四
加鎖
方法1
- // 方法1:
- public synchronized List<String> getData01() {
- List<String> result = new ArrayList<String>();
- // 從快取讀取資料
- result = getDataFromCache();
- if (result.isEmpty()) {
- // 從資料庫查詢資料
- result = getDataFromDB();
- // 將查詢到的資料寫入快取
- setDataToCache(result);
- }
- return result;
- }
- 這種方式確實能夠防止快取失效時高併發到資料庫,但是快取沒有失效的時候,在從快取中拿資料時需要排隊取鎖,這必然會大大的降低了系統的吞吐量.
方法2
- // 方法2:
- static Object lock = new Object();
- public List<String> getData02() {
- List<String> result = new ArrayList<String>();
- // 從快取讀取資料
- result = getDataFromCache();
- if (result.isEmpty()) {
- synchronized (lock) {
- // 從資料庫查詢資料
- result = getDataFromDB();
- // 將查詢到的資料寫入快取
- setDataToCache(result);
- }
- }
- return result;
- }
- 這個方法在快取命中的時候,系統的吞吐量不會受影響,但是當快取失效時,請求還是會打到資料庫,只不過不是高併發而是阻塞而已.但是,這樣會造成使用者體驗不佳,並且還給資料庫帶來額外壓力.
方法3
- //方法3
- public List<String> getData03() {
- List<String> result = new ArrayList<String>();
- // 從快取讀取資料
- result = getDataFromCache();
- if (result.isEmpty()) {
- synchronized (lock) {
- //雙重判斷,第二個以及之後的請求不必去找資料庫,直接命中快取
- // 查詢快取
- result = getDataFromCache();
- if (result.isEmpty()) {
- // 從資料庫查詢資料
- result = getDataFromDB();
- // 將查詢到的資料寫入快取
- setDataToCache(result);
- }
- }
- }
- return result;
- }
雙重判斷雖然能夠阻止高併發請求打到資料庫,但是第二個以及之後的請求在命中快取時,還是排隊進行的.比如,當30個請求一起併發過來,在雙重判斷時,第一個請求去資料庫查詢並更新快取資料,剩下的29個請求則是依次排隊取快取中取資料.請求排在後面的使用者的體驗會不爽.
方法4
- static Lock reenLock = new ReentrantLock();
- public List<String> getData04() throws InterruptedException {
- List<String> result = new ArrayList<String>();
- // 從快取讀取資料
- result = getDataFromCache();
- if (result.isEmpty()) {
- if (reenLock.tryLock()) {
- try {
- System.out.println("我拿到鎖了,從DB獲取資料庫後寫入快取");
- // 從資料庫查詢資料
- result = getDataFromDB();
- // 將查詢到的資料寫入快取
- setDataToCache(result);
- } finally {
- reenLock.unlock();// 釋放鎖
- }
- } else {
- result = getDataFromCache();// 先查一下快取
- if (result.isEmpty()) {
- System.out.println("我沒拿到鎖,快取也沒資料,先小憩一下");
- Thread.sleep(100);// 小憩一會兒
- return getData04();// 重試
- }
- }
- }
- return result;
- }
- 最後使用互斥鎖的方式來實現,可以有效避免前面幾種問題.
快取穿透
快取穿透是指查詢一個一定不存在的資料,由於快取是不命中時被動寫的,並且出於容錯考慮,如果從儲存層查不到資料則不寫入快取,這將導致這個不存在的資料每次請求都要到儲存層去查詢,失去了快取的意義。在流量大時,可能DB就掛掉了,要是有人利用不存在的key頻繁攻擊我們的應用,這就是漏洞。
解決方案
有很多種方法可以有效地解決快取穿透問題,最常見的則是採用布隆過濾器,將所有可能存在的資料雜湊到一個足夠大的bitmap中,一個一定不存在的資料會被 這個bitmap攔截掉,從而避免了對底層儲存系統的查詢壓力。另外也有一個更為簡單粗暴的方法(我們採用的就是這種),如果一個查詢返回的資料為空(不管是數 據不存在,還是系統故障),我們仍然把這個空結果進行快取,但它的過期時間會很短,最長不超過五分鐘。
快取雪崩
快取雪崩是指在我們設定快取時採用了相同的過期時間,導致快取在某一時刻同時失效,請求全部轉發到DB,DB瞬時壓力過重雪崩。
解決方案
快取失效時的雪崩效應對底層系統的衝擊非常可怕。大多數系統設計者考慮用加鎖或者佇列的方式保證快取的單線 程(程序)寫,從而避免失效時大量的併發請求落到底層儲存系統上。這裡分享一個簡單方案就時講快取失效時間分散開,比如我們可以在原有的失效時間基礎上增加一個隨機值,比如1-5分鐘隨機,這樣每一個快取的過期時間的重複率就會降低,就很難引發集體失效的事件。
快取擊穿
對於一些設定了過期時間的key,如果這些key可能會在某些時間點被超高併發地訪問,是一種非常“熱點”的資料。這個時候,需要考慮一個問題:快取被“擊穿”的問題,這個和快取雪崩的區別在於這裡針對某一key快取,前者則是很多key。
快取在某個時間點過期的時候,恰好在這個時間點對這個Key有大量的併發請求過來,這些請求發現快取過期一般都會從後端DB載入資料並回設到快取,這個時候大併發的請求可能會瞬間把後端DB壓垮。
解決方案
1.使用互斥鎖(mutex key)
業界比較常用的做法,是使用mutex。簡單地來說,就是在快取失效的時候(判斷拿出來的值為空),不是立即去load db,而是先使用快取工具的某些帶成功操作返回值的操作(比如Redis的SETNX或者Memcache的ADD)去set一個mutex key,當操作返回成功時,再進行load db的操作並回設快取;否則,就重試整個get快取的方法。
SETNX,是「SET if Not eXists」的縮寫,也就是隻有不存在的時候才設定,可以利用它來實現鎖的效果。在redis2.6.1之前版本未實現setnx的過期時間,所以這裡給出兩種版本程式碼參考:
- //2.6.1前單機版本鎖
- String get(String key) {
- String value = redis.get(key);
- if (value == null) {
- if (redis.setnx(key_mutex, "1")) {
- // 3 min timeout to avoid mutex holder crash
- redis.expire(key_mutex, 3 * 60)
- value = db.get(key);
- redis.set(key, value);
- redis.delete(key_mutex);
- } else {
- //其他執行緒休息50毫秒後重試
- Thread.sleep(50);
- get(key);
- }
- }
- }
最新版本程式碼:
- public String get(key) {
- String value = redis.get(key);
- if (value == null) { //代表快取值過期
- //設定3min的超時,防止del操作失敗的時候,下次快取過期一直不能load db
- if (redis.setnx(key_mutex, 1, 3 * 60) == 1) { //代表設定成功
- value = db.get(key);
- redis.set(key, value, expire_secs);
- redis.del(key_mutex);
- } else { //這個時候代表同時候的其他執行緒已經load db並回設到快取了,這時候重試獲取快取值即可
- sleep(50);
- get(key); //重試
- }
- } else {
- return value;
- }
- }
memcache程式碼:
- if (memcache.get(key) == null) {
- // 3 min timeout to avoid mutex holder crash
- if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {
- value = db.get(key);
- memcache.set(key, value);
- memcache.delete(key_mutex);
- } else {
- sleep(50);
- retry();
- }
- }
2. "提前"使用互斥鎖(mutex key):
在value內部設定1個超時值(timeout1), timeout1比實際的memcache timeout(timeout2)小。當從cache讀取到timeout1發現它已經過期時候,馬上延長timeout1並重新設定到cache。然後再從資料庫載入資料並設定到cache中。虛擬碼如下:
- v = memcache.get(key);
- if (v == null) {
- if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {
- value = db.get(key);
- memcache.set(key, value);
- memcache.delete(key_mutex);
- } else {
- sleep(50);
- retry();
- }
- } else {
- if (v.timeout <= now()) {
- if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {
- // extend the timeout for other threads
- v.timeout += 3 * 60 * 1000;
- memcache.set(key, v, KEY_TIMEOUT * 2);
- // load the latest value from db
- v = db.get(key);
- v.timeout = KEY_TIMEOUT;
- memcache.set(key, value, KEY_TIMEOUT * 2);
- memcache.delete(key_mutex);
- } else {
- sleep(50);
- retry();
- }
- }
- }
3. "永遠不過期":
這裡的“永遠不過期”包含兩層意思:
(1) 從redis上看,確實沒有設定過期時間,這就保證了,不會出現熱點key過期問題,也就是“物理”不過期。
(2) 從功能上看,如果不過期,那不就成靜態的了嗎?所以我們把過期時間存在key對應的value裡,如果發現要過期了,通過一個後臺的非同步執行緒進行快取的構建,也就是“邏輯”過期
從實戰看,這種方法對於效能非常友好,唯一不足的就是構建快取時候,其餘執行緒(非構建快取的執行緒)可能訪問的是老資料,但是對於一般的網際網路功能來說這個還是可以忍受。
- String get(final String key) {
- V v = redis.get(key);
- String value = v.getValue();
- long timeout = v.getTimeout();
- if (v.timeout <= System.currentTimeMillis()) {
- // 非同步更新後臺異常執行
- threadPool.execute(new Runnable() {
- public void run() {
- String keyMutex = "mutex:" + key;
- if (redis.setnx(keyMutex, "1")) {
- // 3 min timeout to avoid mutex holder crash
- redis.expire(keyMutex, 3 * 60);
- String dbValue = db.get(key);
- redis.set(key, dbValue);
- redis.delete(keyMutex);
- }
- }
- });
- }
- return value;
- }
4. 資源保護:
採用netflix的hystrix,可以做資源的隔離保護主執行緒池,如果把這個應用到快取的構建也未嘗不可。
四種解決方案:沒有最佳只有最合適
解決方案 | 優點 | 缺點 |
簡單分散式互斥鎖(mutex key) |
1. 思路簡單 2. 保證一致性 |
1. 程式碼複雜度增大 2. 存在死鎖的風險 3. 存線上程池阻塞的風險 |
“提前”使用互斥鎖 | 1. 保證一致性 | 同上 |
不過期(本文) |
1. 非同步構建快取,不會阻塞執行緒池 |
1. 不保證一致性。 2. 程式碼複雜度增大(每個value都要維護一個timekey)。 3. 佔用一定的記憶體空間(每個value都要維護一個timekey)。 |
資源隔離元件hystrix(本文) |
1. hystrix技術成熟,有效保證後端。 2. hystrix監控強大。 |
1. 部分訪問存在降級策略。 |
總結
針對業務系統,永遠都是具體情況具體分析,沒有最好,只有最合適。
最後,對於快取系統常見的快取滿了和資料丟失問題,需要根據具體業務分析,通常我們採用LRU策略處理溢位,Redis的RDB和AOF持久化策略來保證一定情況下的資料安全。