redis作為記憶體資料庫，其資料總會有失效的時候，資料失效引起的問題主要有三個
key對應的資料在資料來源並不存在，每次針對此key的請求從快取獲取不到，請求都會到資料來源，從而可能壓垮資料來源。比如用乙個不存在的使用者id獲取使用者資訊，不論快取還是資料庫都沒有，若黑客利用此漏洞進行攻擊可能壓垮資料庫。
乙個一定不存在快取及查詢不到的資料，由於快取是不命中時被動寫的，並且出於容錯考慮，如果從儲存層查不到資料則不寫入快取，這將導致這個不存在的資料每次請求都要到儲存層去查詢，失去了快取的意義。
有很多種方法可以有效地解決快取穿透問題，最常見的則是採用布隆過濾器，將所有可能存在的資料雜湊到乙個足夠大的bitmap中，乙個一定不存在的資料會被 這個bitmap攔截掉，從而避免了對底層儲存系統的查詢壓力。
另外也有乙個更為簡單粗暴的方法（我們採用的就是這種），如果乙個查詢返回的資料為空（不管是資料不存在，還是系統故障），我們仍然把這個空結果進行快取，但它的過期時間會很短，最長不超過五分鐘。
key對應的資料存在，但在redis中過期，此時若有大量併發請求過來，這些請求發現快取過期一般都會從後端db載入資料並回設到快取，這個時候大併發的請求可能會瞬間把後端db壓垮。
（乙個或多個）熱點key過期，大量併發請求打到資料庫，造成資料庫宕機。
業界比較常用的做法，是使用mutex。簡單地來說，就是在快取失效的時候（判斷拿出來的值為空），不是立即去請求資料庫，而是先使用快取工具的某些帶成功操作返回值的操作（比如redis的setnx或者memcache的add）去set乙個mutex key，當操作返回成功時，再進行load db的操作並回設快取；否則，就重試整個get快取的方法。
當快取伺服器重啟或者大量快取集中在某乙個時間段失效，這樣在失效的時候，也會給後端系統(比如db)帶來很大壓力。
快取資料的過期時間設定隨機，防止同一時間大量資料過期現象發生。
如果快取資料庫是分布式部署，將熱點資料均勻分布在不同搞得快取資料庫中。
設定熱點資料永遠不過期。
redis快取失效
redis快取的使用極大的提公升了應用程式的效能和效率，特別是資料查詢方面，但同時，它也帶來了一些問題。其中，最要害的問題，就是一些資料的一致性問題，從嚴格意義上講，這個問題不好解決。如果對資料的一致性要求很高，那麼不能是用快取。另外的問題就是快取穿透，快取雪崩和快取擊穿。快取穿透是指快取和資料庫中...
redis的快取穿透 快取併發 快取失效
學習 截選乙個集體快取失效解決辦法 引起這個問題的主要原因還是高併發的時候，平時我們設定乙個快取的過期時間時，可能有一些會設定1分鐘啊，5分鐘這些，併發很高時可能會出在某乙個時間同時生成了很多的快取，並且過期時間都一樣，這個時候就可能引發一當過期時間到後，這些快取同時失效，請求全部 到db，db可能...
快取失效的經典問題
指查詢的資料，在資料庫不存在的情況。這樣程式會先訪問cache，沒有找到資料，再查詢資料庫，也沒有找到，然後返回空。如果惡意大量的訪問資料庫中不存在的資料，造成資源浪費，對資料庫造成壓力，甚至會導致業務不可用，甚至壓垮資料庫。空值快取，即如果資料庫查詢的時候，沒有查詢到資料，也將空值快取到cache...