事故背景

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

什么原因造成的？

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

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

23：00后臺小哥已經將商品導入緩存中，提前預熱

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

緩存命中

如上圖預期大部分請求會命中緩存，但是由于后臺小哥預熱緩存的時候將所有商品的緩存時間都設置為2小時過期，所有的商品在同一個時間點全部失效，瞬間所有的請求都落在數據庫上，導致數據庫扛不住壓力崩潰，用戶所有的請求都超時報錯。

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

緩存雪崩

什么時候發現的？

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

為什么沒有早點發現？

由于緩存設置過期時間是2小時，凌晨1點前緩存可以命中大部分請求，數據庫服務處于正常狀態。

發現時采取了什么措施？

后臺小哥通過日志定位排查發現問題后，進行了一系列操作：

首先通過API Gateway（網關）限制大部分流量進來?

接著將宕機的數據庫服務重啟?

再重新預熱緩存?

確認緩存和數據庫服務正常后將網關流量正常放開，大約01：30 搶購活動恢復正常。

如何避免下次出現？

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

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

• 均勻過期

• 加互斥鎖

• 緩存永不過期

（1）均勻過期

設置不同的過期時間，讓緩存失效的時間點盡量均勻。通?？梢詾橛行谠黾与S機值或者統一規劃有效期。

緩存key過期時間均勻分布

（2）加互斥鎖

跟緩存擊穿解決思路一致，同一時間只讓一個線程構建緩存，其他線程阻塞排隊。

互斥訪問

（3）緩存永不過期

跟緩存擊穿解決思路一致，緩存在物理上永遠不過期，用一個異步的線程更新緩存。

異步更新緩存

復盤總結

通過與同事復盤這次線上事故，大家對于緩存雪崩有了更深刻的理解。為了避免再次出現緩存雪崩事故，大家一起討論了多個解決方案：

（1）均勻過期

（2）加互斥鎖

（3）緩存永不過期

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

往期推薦

《大廠內部資料》Redis 性能優化的 13 條軍規！全網首發

2020-03-24

驚呆了，竟然可以用這種方式秒建Redis集群？

2020-03-26

史上最全的 SQL 優化方案！建議收藏

2020-04-13

關注我，每天陪你進步一點點！

總結

以上是生活随笔為你收集整理的报告老板：这次的缓存事故是这样的...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。