快取雪崩我們可以簡單的理解為：由於原有快取失效，新快取未到期間(例如：我們設定快取時採用了相同的過期時間，在同一時刻出現大面積的快取過期)，所有原本應該訪問快取的請求都去查詢資料庫了，而對資料庫cpu和記憶體造成巨大壓力，嚴重的會造成資料庫宕機。從而形成一系列連鎖反應，造成整個系統崩潰。
快取正常從redis中獲取，示意圖如下：
快取失效瞬間示意圖如下：
快取雪崩的解決方案：
（1）碰到這種情況，一般併發量不是特別多的時候，使用最多的解決方案是加鎖排隊，偽**如下：
加鎖排隊只是為了減輕資料庫的壓力，並沒有提高系統吞吐量。假設在高併發下，快取重建期間key是鎖著的，這是過來1000個請求999個都在阻塞的。同樣會導致使用者等待超時，這是個治標不治本的方法！
注意：加鎖排隊的解決方式分布式環境的併發問題，有可能還要解決分布式鎖的問題；執行緒還會被阻塞，使用者體驗很差！因此，在真正的高併發場景下很少使用！
（2）給每乙個快取資料增加相應的快取標記，記錄快取的是否失效，如果快取標記失效，則更新資料快取，例項偽**如下：
解釋說明：
1、快取標記：記錄快取資料是否過期，如果過期會觸發通知另外的執行緒在後台去更新實際key的快取；
2、快取資料：它的過期時間比快取標記的時間延長1倍，例：標記快取時間30分鐘，資料快取設定為60分鐘。 這樣，當快取標記key過期後，實際快取還能把舊資料返回給呼叫端，直到另外的執行緒在後台更新完成後，才會返回新快取。
關於快取崩潰的解決方法，這裡提出了三種方案：使用鎖或佇列、設定過期標誌更新快取、為key設定不同的快取失效時間，還有一各被稱為「二級快取」的解決方法，有興趣的讀者可以自行研究。
(3) 或者設定熱點資料永遠不過期，有更新操作就更新快取就好了1.快取穿透是指使用者查詢資料，在資料庫沒有，自然在快取中也不會有。這樣就導致使用者查詢的時候，在快取中找不到，每次都要去資料庫再查詢一遍，然後返回空（相當於進行了兩次無用的查詢）。這樣請求就繞過快取直接查資料庫，這也是經常提的快取命中率問題。
2.快取穿透是指快取和資料庫中都沒有的資料，而使用者不斷發起請求，我們資料庫的 id 都是1開始自增上去的，如發起為id值為 -1 的資料或 id 為特別大不存在的資料。這時的使用者很可能是攻擊者，攻擊會導致資料庫壓力過大，嚴重會擊垮資料庫。
快取穿透解決方案：
（1）採用布隆過濾器（bloom filter），將所有可能存在的資料雜湊到乙個足夠大的bitmap中，乙個一定不存在的資料會被這個bitmap攔截掉，從而避免了對底層儲存系統的查詢壓力。
（2）如果乙個查詢返回的資料為空（不管是資料不存在，還是系統故障），我們仍然把這個空結果進行快取，但它的過期時間會很短，最長不超過五分鐘。通過這個直接設定的預設值存放到快取，這樣第二次到快取中獲取就有值了，而不會繼續訪問資料庫，這種辦法最簡單粗暴！
把空結果也給快取起來，這樣下次同樣的請求就可以直接返回空了，即可以避免當查詢的值為空時引起的快取穿透。同時也可以單獨設定個快取區域儲存空值，對要查詢的key進行預先校驗，然後再放行給後面的正常快取處理邏輯。
快取擊穿嘛，這個跟快取雪崩有點像，但是又有一點不一樣，快取雪崩是因為大面積的快取失效，打崩了db，而快取擊穿不同的是快取擊穿是指乙個key非常熱點，在不停的扛著大併發，大併發集中對這乙個點進行訪問，當這個key在失效的瞬間，持續的大併發就穿破快取，直接請求資料庫，就像在乙個完好無損的桶上鑿開了乙個洞
快取穿透解決方案：
1.從快取取不到的資料，在資料庫中也沒有取到，這時也可以將對應key的value對寫為null、位置錯誤、稍後重試這樣的值具體取啥問產品，或者看具體的場景，快取有效時間可以設定短點，如30秒（設定太長會導致正常情況也沒法使用）
2.快取穿透我會在介面層增加校驗，比如使用者鑑權校驗，引數做校驗，不合法的引數直接**return，比如：id 做基礎校驗，id <=0的直接攔截等
3.快取擊穿的話，設定熱點資料永遠不過期，或者加上互斥鎖就能搞定了
4.使用布隆過濾器（bloom filter）他的原理也很簡單就是利用高效的資料結構和演算法快速判斷出你這個key是否在資料庫中存在，不存在你return就好了，存在你就去查了db重新整理kv再return。
快取預熱就是系統上線後，提前將相關的快取資料直接載入到快取系統。避免在使用者請求的時候，先查詢資料庫，然後再將資料快取的問題！使用者直接查詢事先被預熱的快取資料！
快取預熱解決方案：
（1）直接寫個快取重新整理頁面，上線時手工操作下；
（2）資料量不大，可以在專案啟動的時候自動進行載入；
（3）定時重新整理快取；
除了快取伺服器自帶的快取失效策略之外（redis預設的有6中策略可供選擇），我們還可以根據具體的業務需求進行自定義的快取淘汰，常見的策略有兩種：
（1）定時去清理過期的快取；
（2）當有使用者請求過來時，再判斷這個請求所用到的快取是否過期，過期的話就去底層系統得到新資料並更新快取。
兩者各有優劣，第一種的缺點是維護大量快取的key是比較麻煩的，第二種的缺點就是每次使用者請求過來都要判斷快取失效，邏輯相對比較複雜！具體用哪種方案，大家可以根據自己的應用場景來權衡。
當訪問量劇增、服務出現問題（如響應時間慢或不響應）或非核心服務影響到核心流程的效能時，仍然需要保證服務還是可用的，即使是有損服務。系統可以根據一些關鍵資料進行自動降級，也可以配置開關實現人工降級。
降級的最終目的是保證核心服務可用，即使是有損的。而且有些服務是無法降級的（如加入購物車、結算）。
（1）一般：比如有些服務偶爾因為網路抖動或者服務正在上線而超時，可以自動降級；
（2）警告：有些服務在一段時間內成功率有波動（如在95~100%之間），可以自動降級或人工降級，並傳送告警；
（3）錯誤：比如可用率低於90%，或者資料庫連線池被打爆了，或者訪問量突然猛增到系統能承受的最大閥值，此時可以根據情況自動降級或者人工降級；
（4）嚴重錯誤：比如因為特殊原因資料錯誤了，此時需要緊急人工降級。
一般避免以上情況發生我們從三個時間段去分析下：
上面的幾點我會在吊打系列redis篇全部講一下這個月應該可以吧redis更完，限流元件，可以設定每秒的請求，有多少能通過元件，剩餘的未通過的請求，怎麼辦？走降級！可以返回一些預設的值，或者友情提示，或者空白的值。
好處：資料庫絕對不會死，限流元件確保了每秒只有多少個請求能通過。 只要資料庫不死，就是說，對使用者來說，3/5 的請求都是可以被處理的。 只要有 3/5 的請求可以被處理，就意味著你的系統沒死，對使用者來說，可能就是點選幾次刷不出來頁面，但是多點幾次，就可以刷出來一次。
redis 快取擊穿 穿透 雪崩
一般的快取系統，都是按照key去快取查詢，如果不存在對應的value，就去後端系統查詢 比如db 一些惡意的請求會故意查詢不存在的key,請求量很大，就會對後端系統造成很大的壓力。這就叫做快取穿透。如何避免？1 對查詢結果為空的情況也進行快取，這樣，再次訪問時，快取層會直接返回空值。快取時間設定短一...
Redis快取雪崩 擊穿 穿透
目錄 三 快取擊穿 四 快取穿透 這三個問題一旦發生，就會導致大量請求進入後台的資料庫，如果有大量併發同時到達資料庫，有可能會導致資料庫宕機，影響業務，也有可能會導致一系列連鎖反映，很可能導致業務長時間無法恢復。接下來本文詳細介紹這三個問題的發生場景以及對應的解決方案。雪崩是指大量請求無法在redi...
快取雪崩 擊穿 穿透
1 快取雪崩 是指在某乙個時間段，快取集中過期失效，或者是快取宕機，所有請求全部打到db上。應對辦法 分散快取過期時間，具體做法是分別設定不同的快取時間，比如加上隨機因子。2 快取擊穿 當某個熱點key失效時，高併發直接請求資料庫對資料庫伺服器造成壓垮性的壓力，比如爆款商品。應對辦法 1 熱點資料永...