不僅僅是memcached做快取時存在，快取系統都存在這種問題隱患。
快取穿透
什麼是快取穿透？
一般的快取系統，都是按照key去快取查詢，如果不存在對應的value，就應該去後端系統查詢（比如db）。如果key對應的value是一定不存在的，並且對該key併發請求量很大，就會對後端系統造成很大的壓力。這就叫做快取穿透。
如何避免？
1：對查詢結果為空的情況也進行快取，快取時間設定短一點，或者該key對應的資料insert了之後清理快取。
2：對一定不存在的key進行過濾。可以把所有的可能存在的key放到乙個大的bitmap中，查詢時通過該bitmap過濾。【感覺應該用的不多吧】
快取雪崩
什麼是快取雪崩？
當快取伺服器重啟或者大量快取集中在某乙個時間段失效，這樣在失效的時候，也會給後端系統(比如db)帶來很大壓力。
如何避免？
1：在快取失效後，通過加鎖或者佇列來控制讀資料庫寫快取的執行緒數量。比如對某個key只允許乙個執行緒查詢資料和寫快取，其他執行緒等待。
2：不同的key，設定不同的過期時間，讓快取失效的時間點盡量均勻。
分布式快取系統
分布式快取系統面臨的問題
快取一致性問題
1：快取系統與底層資料的一致性。這點在底層系統是「可讀可寫」時，寫得尤為重要
2：有繼承關係的快取之間的一致性。為了盡量提高快取命中率，快取也是分層：全域性快取，二級快取。他們是存在繼承關係的。全域性快取可以有二級快取來組成。
3：多個快取副本之間的一致性。為了保證系統的高可用性，快取系統背後往往會接兩套儲存系統（如memcache，redis等）
快取穿透和快取雪崩
上面有講述。
快取資料的淘汰
快取淘汰的策略有兩種： (1) 定時去清理過期的快取。 （2）當有使用者請求過來時，再判斷這個請求所用到的快取是否過期，過期的話就去底層系統得到新資料並更新快取。
兩者各有優劣，第一種的缺點是維護大量快取的key是比較麻煩的，第二種的缺點就是每次使用者請求過來都要判斷快取失效，邏輯相對比較複雜，具體用哪種方案，大家可以根據自己的應用場景來權衡。
1. 預估失效時間 2. 版本號（必須單調遞增，時間戳是最好的選擇）3. 提供手動清理快取的介面。
快取穿透和雪崩
一般的快取系統，都是按照key去快取查詢，如果不存在對應的value，就應該去後端系統查詢 比如db 如果key對應的value是一定不存在的，並且對該key併發請求量很大，就會對後端系統造成很大的壓力。這就叫做快取穿透。1 對查詢結果為空的情況也進行快取，快取時間設定短一點，或者該key對應的資料...
Redis 穿透和雪崩
就是訪問redis中乙個不存在的key的時候,會直接穿過快取,去資料庫中進行查詢.如果是黑客,進行惡意攻擊的時候,每次都請求超過2000個 秒的時候,這個時候mysql基本上就掛了.解決辦法是 每次從資料庫中查詢到乙個不存在的key的時候,就寫乙個空值到快取庫中,有惡意攻擊的時候,直接從快取中取到這...
redis的穿透和雪崩
redis穿透 正常的執行路徑是這樣的，請求資料，首先會從redis快取中拿資料，如果快取沒有的話才去查資料庫，再寫到redis快取中。那麼如果有人請求一條根本不存在的資料時，redis裡面肯定沒有嘛，它就會去訪問資料庫，但是資料庫沒有，所以它也沒把資料寫回redis快取。所以它每次請求這個資料的時...