redis快取的場景
客戶端請求在快取層命中就直接返回，如果miss就去讀取儲存層，儲存層讀取到就寫入快取層，然後再返回到客戶端
redis的優缺點
快取穿透
引發原因
在查詢乙個一定不存在的資料，由於快取是不命中時被動寫入，並且處於容錯考慮，如果從儲存層查不到資料則不寫入快取，這將導致這個不存在的資料每次請求都要到儲存層去查詢，快取層失去意義。
當在大流量流入時，可能因為頻繁訪問儲存層導致db直接宕機，這樣會形成被人利用不存在的key頻繁攻擊應用的漏洞。
解決方法
有多種方法能有效解決快取穿透的問題
最為常簡的是採用布隆過濾器，將所有可能存在的資料雜湊到乙個足夠發的 bigmap 中，乙個一定不存在的資料會被該 bigmap 攔截掉，從而避免對底層儲存系統造成查詢壓力。
另一種更為簡單的方法，如果乙個查詢返回的資料為空（無論資料為空，或是系統故障），將空結果進行快取，設定乙個最長不超過五分鐘的過期時間。
快取雪崩
引發原因
設定快取時採用了相同的過期時間，導致快取在某時刻同時失效，請求全部轉向db，db瞬時壓力過重雪崩。
redis宕機，導致客戶端的請求之間流向db，拖垮db。
解決方發
有多種方法能有效解決快取雪崩的問題
問題一的解決方案
在快取失效後，通過加鎖或者佇列來控制讀資料庫寫快取的執行緒數量。比如對某個key只允許乙個執行緒查詢資料和寫快取，其他執行緒等待。
簡單方案就是將快取失效時間分散開，我們可以在原有的失效時間基礎上增加乙個隨機值，比如1-5分鐘隨機，這樣每乙個快取的過期時間的重複率就會降低，就很難引發集體失效的事件。
問題二的解決方案
保持快取層伺服器的高可用。
–監控、集群、哨兵。當乙個集群裡面有一台伺服器有問題，讓哨兵踢出去。
依賴隔離元件為後端限流並降級。
比如推薦服務中，如果個性化推薦服務不可用，可以降級為熱點資料。
提前演練。
演練 快取層crash後，應用以及後端的負載情況以及可能出現的問題。 對此做一些預案設定。
Redis快取穿透 快取雪崩
把redis作為快取使用已經是司空見慣，但是使用redis後也可能會碰到一系列的問題，尤其是資料量很大的時候，經典的幾個問題如下 一 快取和資料庫間資料一致性問題 分布式環境下 單機就不用說了 非常容易出現快取和資料庫間的資料一致性問題，針對這一點的話，只能說，如果你的專案對快取的要求是強一致性的，...
Redis 快取穿透 快取雪崩
目錄 1.快取穿透 如何避免？如何選擇？2 快取擊穿 如何解決 3.快取雪崩 如何解決？快取穿透 一般的快取系統，都是按照key去快取查詢，如果不存在對應的value，就應該去後端系統查詢 比如db 一些惡意的請求會故意查詢不存在的key，請求量很大，就會對後端系統造成很大的壓力，或導致資料庫異常。...
redis快取穿透 快取雪崩
什麼是快取雪崩 在同一時間內大量的快取資料失效，大量的請求都會去資料庫查詢，造成快取雪崩。解決方法 這個沒有完美的解決方法，但是可以分析使用者行為，盡量讓失效時間點均勻分布，還有就是在快取失效後，通過加鎖或者佇列來控制讀資料庫寫快取的執行緒數量，比如對某國key只允許乙個執行緒查詢資料庫和快取，其他...