快取穿透是指查詢乙個一定不存在的資料,由於快取是不命中時被動寫的,並且出於容錯考慮,如果從儲存層查不到資料則不寫入快取,這將導致這個不存在的資料每次請求都要到儲存層去查詢,失去了快取的意義。在流量大時,可能db就掛掉了,要是有人利用不存在的key頻繁攻擊我們的應用,這就是漏洞。
解決方案
有很多種方法可以有效地解決快取穿透問題,最常見的則是採用布隆過濾器,將所有可能存在的資料雜湊到乙個足夠大的bitmap中,乙個一定不存在的資料會被這個bitmap攔截掉,從而避免了對底層儲存系統的查詢壓力。另外也有乙個更為簡單粗暴的方法,如果乙個查詢返回的資料為空(不管是資料不存在,還是系統故障),我們仍然把這個空結果進行快取,但它的過期時間最好設定的短一些。
快取雪崩是指在我們設定快取時採用了相同的過期時間,導致快取在某一時刻同時失效,請求全部**到db,db瞬時壓力過重崩潰。
解決方案
快取失效時的雪崩效應對底層系統的衝擊非常可怕。大多數系統設計者考慮用加鎖或者佇列的方式保證快取的單執行緒(程序)寫,從而避免失效時大量的併發請求落到底層儲存系統上。這種方式雖然能夠在一定的程度上緩解了資料庫的壓力但是與此同時又降低了系統的吞吐量。這裡分享乙個簡單方案就是將快取失效時間分散開,比如我們可以在原有的失效時間基礎上增加乙個隨機值,比如1-5分鐘隨機,這樣每乙個快取的過期時間的重複率就會降低,就很難引發集體失效的事件。
對於一些設定了過期時間的key,如果這些key可能會在某些時間點被超高併發地訪問,是一種非常「熱點」的資料,這個時候,需要考慮乙個問題:快取被「擊穿」的問題,這個和快取雪崩的區別在於這裡針對某一key快取,前者則是很多key。快取在某個時間點過期的時候,恰好在這個時間點對這個key有大量的併發請求過來,這些請求發現快取過期一般都會從後端db載入資料並新增到快取,這個時候大併發的請求可能會瞬間把後端db壓垮。
解決方案
使用互斥鎖(mutex key)
簡單來說,就是快取失效的時候,不要立刻去load db,通過緩衝工具去設定互斥鎖,只讓當前的執行緒去查詢資料庫,同步到redis資料庫中。設定互斥鎖,比如redis的redis.setnx。
public string get(key) else
} else
}
參考: Redis快取穿透和雪崩
快取的目的是什麼?提高效能,快取查詢的速度比去資料庫查詢要快。快取會分擔部分請求,減少併發壓力。那麼快取穿透是什麼?怎麼解決快取穿透呢?一般快取系統,按key去查詢value,如果不存在相應的key,那麼就會去資料庫查詢,如果key對應的value是一定不存在的,並且對key的併發查詢很高,那麼每次...
Redis 快取穿透和雪崩
快取穿透是指快取和資料庫中都沒有的資料,而使用者不斷發起請求,如發起為id為 1 的資料或id為特別大不存在的資料。這時候就會繞過快取,每次都請求資料庫,這樣的話,大量的請求都直接到達資料庫,這種現象就叫快取穿透。list list demoservice.getdemodata demoid 防止...
Redis快取穿透和雪崩
服務的高可用問題 redis快取的使用,極大的提公升了應用程式的效能和效率,特別是資料查詢方面。但同時,它也帶來了一 些問題。其中,要害的問題,就是資料的一致性問題,從嚴格意義上講,這個問題無解。如果對資料 的一致性要求很高,那麼就不能使用快取。另外的一些典型問題就是,快取穿透 快取雪崩和快取擊穿。...