原來快取也會雪崩、擊穿、穿透啊！

在網際網路時代，大流量、海量資料、高併發是每個企業都渴望又害怕的名詞，渴望是因為它們代表著提供的服務使用者願意買單、有價值；害怕是因為一旦使用者全上來了，系統不能正常為使用者提供服務，讓使用者失望，最終選擇離開。僅靠著超高配置的伺服器資源，還是很難支撐高併發的場景。因此我們需要快取。

 

快取在計算機的世界裡無處不在，在CPU中有一級二級三級快取，在Linux操作心態中有TLB加速虛擬地址和實體地址的轉化，在應用服務中有redis資料庫進行資料快取，在瀏覽器或app中有本地快取。可以說快取是非常重要了，有了它，整個世界彷彿都變美好了，刷網頁很快就有資料的返回，再也不用一直苦苦等待了。

 

通過一個簡單的例子來看看快取是什麼？我們知道資料都是儲存在資料庫裡的，而資料庫資料一般都儲存在磁碟上。當使用者請求從前端過來時，如果直接去訪問獲取磁碟的資料庫資料，就會非常慢。如果有了快取，在使用者請求到達之後，業務執行緒就會先訪問快取，如果快取命中就直接返回使用者，如果沒有命中，則繼續請求磁碟資料庫資料，獲取後返回使用者，同時將磁碟獲取的資料結果回寫到快取系統，為下次請求做好準備。

 

 

可是這麼強大的快取系統，其實也存在很多問題呢，那便是快取雪崩、快取擊穿、快取穿透。不過也不要害怕，有問題就有解法，我們慢慢的往下看。

 

 

所謂快取雪崩，指的是快取資料同一時間大量失效，所有的請求全打到資料庫，導致資料庫在巨大壓力下掛掉。比如在雙十一的時候，使用者都會開啟淘寶買東西，有的人是真的有需要買的，有的人就是湊個熱鬧，不管怎麼樣，這時候首頁的壓力就非常大了，為了滿足所有使用者都可以訪問到資料，阿里的程式設計師們將首頁資料快取到redis裡，並設定redis失效時間是12小時。我們知道redis是記憶體資料庫，那訪問速度，槓槓的啊。資料快取後使用者們買的很開心，程式設計師們也很開心，系統都還好著呢…..慢慢的12個小時過去了，使用者購物的熱情不減啊，還是大量的使用者請求在過來，然而首頁redis快取的資料全失效了，這時候redis裡沒有資料了，使用者請求直接撲向資料庫，資料庫哪能扛得住啊，直接垮掉。

 

 

應對快取雪崩，我們也有一些辦法，比如隨機設定key的失效時間，避免大量的key同時失效，比如不要設定過期時間或把過期時間設定得很長，再比如執行定時任務，隨時監控快取情況，在失效前重新整理進新的快取。

 

所謂快取穿透，指的是快取中沒有快取到該資料，從而導致請求直接到達資料庫，資料庫在巨大壓力下掛掉。比如在雙十一的時候，有黑客經過多次攻擊測試發現混沌炸雞（假設商品ID為-1）這個商品在網站上沒有，於是便寫了一個指令碼，大量的去請求這個商品，redis快取一看我只有炸雞商品，不滿足需求啊，於是就放到資料庫那裡了，所有的請求全放給資料庫了，資料庫說我也沒有啊，但還是不斷地被接受輪詢，結果直接垮掉。

 

 

應對快取穿透，我們也有一些辦法，比如對於某些不存在的資料快取在redis時設定為null，比如對請求引數進行校驗，不合法的直接攔截，比如增加安全防護，定期掃描，有發現不正常的資料直接將該請求的IP地址加入黑名單。

 

所謂快取擊穿，指的是快取的熱點資料突然失效導致大量的請求都去訪問資料庫，資料庫扛不住壓力，直接掛掉。比如雙十一的時候，iPhone12在凌晨00:00-01:00可1分錢搶購，哇，這個可是真便宜呢，程式設計師們也預測到了商品的火爆，於是將iPhone12的商品資訊快取到redis中，設定了1小時過期。iPhone12是新推出的商品，引起了一億人的關注，男女老少全都蜂擁而至，只為了搶購一個iPhone，到了59分的時候，突然iPhone12在redis的資料過期了，這時候大量的請求都到了資料庫，資料庫直接垮掉了。

 

 

應對快取擊穿，我們也有一些辦法，比如設定熱點資料永不過期，比如給資料加鎖，當有執行緒請求不到資料時，其它的使用者執行緒也無法請求資料，直到第一個執行緒拿到資料後，去redis快取起來，其它的執行緒仍然走快取拿資料，比如服務降級，直接返回“商品太火爆了，系統暫時休息會兒”。

 

通過本文的介紹，相信你對快取、快取雪崩、快取擊穿、快取穿透也有了對應的瞭解了吧。當你所在的業務因為高併發、大資料量準備啟用快取策略時，對於快取可能帶來的雪崩、擊穿、穿透問題要做好防護措施，這樣大家都可以開開心心的玩耍了～