目錄
三、快取擊穿
四、快取穿透
這三個問題一旦發生，就會導致大量請求進入後台的資料庫，如果有大量併發同時到達資料庫，有可能會導致資料庫宕機，影響業務，也有可能會導致一系列連鎖反映，很可能導致業務長時間無法恢復。
接下來本文詳細介紹這三個問題的發生場景以及對應的解決方案。
雪崩是指大量請求無法在redis進行處理，原本預期在redis的中存在的資料卻在redis中不存在，緊接著這些請求被全部**到了資料庫，導致暑資料庫壓力大增。產生雪崩的原因主要有兩個：
快取中有大量的資料同時過期，導致大量請求無法在redis中無法處理。
redis宕機
針對快取中有大量的資料同時過期的應對方案
避免給大量業務資料設定相同的過期時間，業務場景中總會出現同時實效的case，比如基於訂單的下單時間。對於這種場景，可以在過期時間後面加個隨機的時間比如（1-3分鐘）。這樣既保證了業務基本在相近的時間過期，也不會在同時間集中過期。
降級，如果雪崩已經產生，可以對業務進行降級，非核心資料直接返回指定的靜態資料（快取中沒有也不去資料庫請求），只有核心資料持續訪問快取（如果快取沒有，也可以去訪問資料庫，由於限制了非核心資料的請求，這個時候db的壓力應該不大）。
針對redis宕機應對方
redis宕機就等於所有資料同時失效，等於最強雪崩，redis所能承載的qps是萬級別，而單個資料庫所能承載的qps是千級別，這個時候如果所有請求全部進入db，必然會導致db的奔潰。有兩個處理方法。
服務徹底熔斷，當前進來後直接返回，不再訪問資料庫，對服務使用方來說，整個服務是不可用的，對業務的影響最大，但是徹底保護了資料庫。
請求限流，在業務系統的請求入口控制每秒進入服務的次數，限流的比例可以基於之前的資料進行分析，比如在雪崩前入口的qps是10000，其中9000被redis承載，1000進入了資料庫（說明資料庫能承載1000的qps），那麼這個時候可以將入口的qps 限制為1000，這樣既保證了資料庫的安全，也不至於業務不可用（部分可用狀態）。限流示意圖如下。
主從集群部署，實現redis的高可用，當主節點宕機後從節點可以切換為主節點繼續提供服務。
當然宕機後的一系列處理方法同樣適用於大量key同事過期的case。
熱點資料在redis中找不到，和雪崩相比，擊穿對應的熱點資料資料量比較小，但是這些資料的請求量非常高，導致大量請求都被大到了資料庫。
擊穿發生在熱點資料失效時。
對於快取擊穿解決方案比較簡單，對於熱點資料可以設定永不過期，這樣就解決了失效問題。
快取穿透是指查詢的資料既不在快取也不在資料庫，請求redis時候發現快取缺失，再去訪問資料庫，發現資料庫也沒有，所以無法補全快取資料，導致每次查詢都會去請求資料庫，當有
大量類似的請求場景時候，也會對資料庫造成巨大的壓力。
發生穿透的場景：
業務誤操作導致本應該存在的資料被誤刪除
惡意攻擊，專門查詢資料庫中沒有的資料，利用穿透的漏洞。
設計問題，**不嚴謹，已知可能為空的資料沒有去做判斷。
有三個方法可以解決穿透問題。
給快取賦空值或者預設值，一旦發現沒有業務資料，可以賦為空置或者留乙個標示值，比如有值的時候對應的值是乙個list，如果發現沒有業務資料可以付乙個空的list，這樣等下次再來訪問時，發現redis已經有預設值，可以直接返回，避免了多次訪問資料庫。
通過業務規則判斷，如果通過某些規則就可以知道沒有資料，則可以直接不用訪問。
本文完。
redis 快取擊穿 穿透 雪崩
一般的快取系統，都是按照key去快取查詢，如果不存在對應的value，就去後端系統查詢 比如db 一些惡意的請求會故意查詢不存在的key,請求量很大，就會對後端系統造成很大的壓力。這就叫做快取穿透。如何避免？1 對查詢結果為空的情況也進行快取，這樣，再次訪問時，快取層會直接返回空值。快取時間設定短一...
快取雪崩 擊穿 穿透
1 快取雪崩 是指在某乙個時間段，快取集中過期失效，或者是快取宕機，所有請求全部打到db上。應對辦法 分散快取過期時間，具體做法是分別設定不同的快取時間，比如加上隨機因子。2 快取擊穿 當某個熱點key失效時，高併發直接請求資料庫對資料庫伺服器造成壓垮性的壓力，比如爆款商品。應對辦法 1 熱點資料永...
快取雪崩 擊穿 穿透
快取擊穿 快取穿透 在同一時間快取資料集體失效，此時大量請求訪問失效資料，導致大量併發直接訪問資料庫造成資料庫壓力 將需要快取的資料進行分散失效處理，將快取的資料的失效時間設定乙個隨機值，避免大量快取資料在同一時間集體失效 將部分經常做查詢且不經常更新的資料的快取時間設定為永不失效 對於統一個key...