事故背景

公司最近安排了一波商品搶購活動，由於後臺小哥操作失誤最終導致活動效果差，被使用者和代理商投訴了。經理讓我帶同事們一起復盤這次線上事故。

什麼原因造成的？

搶購活動計劃是零點準時開始，

22：00 運營人員通過後臺將商品上線

23：00後臺小哥已經將商品匯入快取中，提前預熱

搶購開始的瞬間流量非常大，按計劃是透過Redis承擔大部分使用者查詢請求，避免請求全部落在資料庫上。

快取命中

如上圖預期大部分請求會命中快取，但是由於後臺小哥預熱快取的時候將所有商品的快取時間都設定為2小時過期，所有的商品在同一個時間點全部失效，瞬間所有的請求都落在資料庫上，導致資料庫扛不住壓力崩潰，使用者所有的請求都超時報錯。

實際上所有的請求都直接落到資料庫，如下圖：

快取雪崩

什麼時候發現的？

凌晨01:02 SRE 收到系統告警，登入運維管理系統發現數據庫節點 CPU和記憶體飆升超過閾值，迅速聯絡後臺開發人員定位排查。

為什麼沒有早點發現？

由於快取設定過期時間是2小時，凌晨1點前快取可以命中大部分請求，資料庫服務處於正常狀態。

發現時採取了什麼措施？

後臺小哥透過日誌定位排查發現問題後，進行了一系列操作：

首先透過API Gateway（閘道器）限制大部分流量進來

接著將宕機的資料庫服務重啟

再重新預熱快取

確認快取和資料庫服務正常後將閘道器流量正常放開，大約01：30 搶購活動恢復正常。

如何避免下次出現？

這次事故的原因其實就是出現了快取雪崩，查詢資料量巨大，請求直接落到資料庫上，引起資料庫壓力過大宕機。

在業界解決快取雪崩的方法其實比較成熟了，比如有：

均勻過期加互斥鎖快取永不過期

（1）均勻過期

設定不同的過期時間，讓快取失效的時間點儘量均勻。通常可以為有效期增加隨機值或者統一規劃有效期。

快取key過期時間均勻分佈

（2）加互斥鎖

跟快取擊穿解決思路一致，同一時間只讓一個執行緒構建快取，其他執行緒阻塞排隊。

互斥訪問

（3）快取永不過期

跟快取擊穿解決思路一致，快取在物理上永遠不過期，用一個非同步的執行緒更新快取。

非同步更新快取

（1）均勻過期

（2）加互斥鎖

（3）快取永不過期

希望技術人能夠敬畏每一行程式碼！