情況：在流量大時，如果有人利用不存在的key頻繁去訪問我們的應用，可能會導致資料庫掛掉。
原因：
查詢乙個不存在的資料，由於快取是不命中時被動寫入，並且出於容錯考慮，如果從儲存層查不到資料則不寫入快取，這導致這個不存在的資料每次請求都要到儲存層去查詢，失去了快取的意義。
解決方案：
1、布隆過濾器:將所有可能存在的資料雜湊到乙個足夠大的bitmap中，乙個一定不存在的資料會被這個bitmap攔截掉，從而避免了對底層儲存系統的查詢壓力。
2、如果乙個查詢的資料為空（不管是資料不存在還是系統故障），我們仍然把這個空的結果進行快取，但它的過期時間會很短，最長不讓他超過五分鐘。
情況：如電商中的主打產品「熱賣爆款」的關鍵字，被大量併發訪問,這時這個key的快取失效了的瞬間，大量請求通過這個key可以訪問到資料庫。
原因：
乙個key可能在某些時間點被超高的併發訪問，是一種非常「熱點」的資料。當這個key在失效的瞬間，持續的高併發就會擊穿快取，直接請求到資料庫（相當於把快取屏障鑿開了乙個洞，大量請求直接訪問資料庫。）
解決方案：
1、簡單分布式互斥鎖（mutex key）
是使用mutex。簡單地來說，就是在快取失效的時候（判斷拿出來的值為空），不是立即去load db，而是先使用快取工具的某些帶成功操作返回值的操作（比如redis的setnx或者memcache的add）去set乙個mutex key，當操作返回成功時，再進行load db的操作並回設快取；否則，就重試整個get快取的方法。
2、「提前」使用互斥鎖
在value內部設定1個超時值(timeout1), timeout1比實際的memcache timeout(timeout2)小。當從cache讀取到timeout1發現它已經過期時候，馬上延長timeout1並重新設定到cache。然後再從資料庫載入資料並設定到cache中。
3、不過期
redis 不設定過期時間，或者把過期時間存在key對應的value裡，如果發現要過期了，通過乙個後台的非同步執行緒進行快取的構建。
4、資源隔離元件hystrix
採用netflix的hystrix，可以做資源的隔離保護主線程池，如果把這個應用到快取的構建也未嘗不可。
情況：快取由於某些原因（比如 宕機、cache服務掛了或者不響應）整體crash掉了，導致大量請求到達後端資料庫，從而導致資料庫崩潰，整個系統崩潰，發生災難。
原因：
快取在某一時刻同時失效，請求全部**到資料庫，資料庫瞬時壓力過重雪崩。
解決方案：
1、大多數系統設計者考慮用加鎖或者佇列的方式保證快取的單線 程（程序）寫，從而避免失效時大量的併發請求落到底層儲存系統上。
2、就是將快取失效時間分散開，比如我們可以在原有的失效時間基礎上增加乙個隨機值，比如1-5分鐘隨機，這樣每乙個快取的過期時間的重複率就會降低，就很難引發集體失效的事件。
快取常見問題
所有這些快取的問題都是因為為使用快取查詢資料而導致的對資料庫造成的瞬間壓力 使用快取帶來的影響 以為犧牲資料一致性為代價換來了更大的併發量 顧名思義，穿透的意思是快取層永遠不起作用。1 查詢快取中是否存在這一條資料 2 如果不存在則查詢資料庫 3 如果資料庫中存在這一條資料，則將資料重新整理到快取中...
快取常見問題
快取穿透是指快取沒有發揮作用，業務系統雖然去快取中查詢資料，但快取中沒有資料，業務系統需要再次去儲存系統中查詢資料。通常情況下有兩種情況 儲存資料不存在，以及生成快取資料需要耗費大量時間或資源。快取穿透的常見解決辦法有兩種 回種空值和使用布隆過濾器。快取雪崩是指當快取失效 過期 後引起系統系統效能急...
快取常見問題總結
1.現象 request請求在cache中未找到資料，直接查詢storage 2.原因 2.1業務 自身問題 在資料庫中未找到資料，進入死迴圈 2.2惡意攻擊 爬蟲等 大量不存在資料查詢資料庫，進入死迴圈 3.如何發現 3.1業務響應時間 3.2業務本身問題 4.解決方法 4.1快取空物件 儲存層返...