建站
咨詢
售后
建站咨詢
新聞中心
公司最近安排了一波商品搶購活動，由于后臺小哥操作失誤最終導(dǎo)致活動效果差，被用戶和代理商投訴了。經(jīng)理讓我?guī)聜円黄饛?fù)盤這次線上事故。
圖片來自 Pexels
什么原因造成的?
搶購活動計劃是零點準(zhǔn)時開始：
- 22：00，運營人員通過后臺將商品上線。
- 23：00，后臺小哥已經(jīng)將商品導(dǎo)入緩存中，提前預(yù)熱。
搶購開始的瞬間流量非常大，按計劃是通過 Redis 承擔(dān)大部分用戶查詢請求，避免請求全部落在數(shù)據(jù)庫上。
緩存命中
如上圖預(yù)期大部分請求會命中緩存，但是由于后臺小哥預(yù)熱緩存的時候?qū)⑺猩唐返木彺鏁r間都設(shè)置為 2 小時過期。
因此所有的商品在同一個時間點全部失效，瞬間所有的請求都落在數(shù)據(jù)庫上，導(dǎo)致數(shù)據(jù)庫扛不住壓力崩潰，用戶所有的請求都超時報錯。
實際上所有的請求都直接落到數(shù)據(jù)庫，如下圖：
緩存雪崩
什么時候發(fā)現(xiàn)的?
凌晨 01：02，SRE 收到系統(tǒng)告警，登錄運維管理系統(tǒng)發(fā)現(xiàn)數(shù)據(jù)庫節(jié)點 CPU 和內(nèi)存飆升超過閾值，迅速聯(lián)系后臺開發(fā)人員定位排查。
為什么沒有早點發(fā)現(xiàn)?
由于緩存設(shè)置過期時間是 2 小時，凌晨 1 點前緩存可以命中大部分請求，數(shù)據(jù)庫服務(wù)處于正常狀態(tài)。
發(fā)現(xiàn)時采取了什么措施?
后臺小哥通過日志定位排查發(fā)現(xiàn)問題后，進(jìn)行了一系列操作：
- 首先通過 API Gateway(網(wǎng)關(guān))限制大部分流量進(jìn)來。
- 接著將宕機的數(shù)據(jù)庫服務(wù)重啟。
- 再重新預(yù)熱緩存。
- 確認(rèn)緩存和數(shù)據(jù)庫服務(wù)正常后將網(wǎng)關(guān)流量正常放開，大約 01：30 搶購活動恢復(fù)正常。
如何避免下次出現(xiàn)?
這次事故的原因其實就是出現(xiàn)了緩存雪崩，查詢數(shù)據(jù)量巨大，請求直接落到數(shù)據(jù)庫上，引起數(shù)據(jù)庫壓力過大宕機。
在業(yè)界解決緩存雪崩的方法其實比較成熟了，比如有：
- 均勻過期
- 加互斥鎖
- 緩存永不過期
均勻過期
設(shè)置不同的過期時間，讓緩存失效的時間點盡量均勻。通常可以為有效期增加隨機值或者統(tǒng)一規(guī)劃有效期。
緩存 key 過期時間均勻分布
加互斥鎖
跟緩存擊穿解決思路一致，同一時間只讓一個線程構(gòu)建緩存，其他線程阻塞排隊。
互斥訪問
緩存永不過期
跟緩存擊穿解決思路一致，緩存在物理上永遠(yuǎn)不過期，用一個異步的線程更新緩存。
異步更新緩存
復(fù)盤總結(jié)
通過與同事復(fù)盤這次線上事故，大家對于緩存雪崩有了更深刻的理解。
為了避免再次出現(xiàn)緩存雪崩事故，大家一起討論了多個解決方案：
- 均勻過期
- 加互斥鎖
- 緩存永不過期
希望技術(shù)人能夠敬畏每一行代碼!
作者：雷架，華中科技大學(xué)碩士畢業(yè);浪過幾個大廠：華為、網(wǎng)易、百度……
編輯：陶家龍
出處：轉(zhuǎn)載自公眾號愛笑的架構(gòu)師(ID：DancingOnYourCode)
網(wǎng)站欄目：秒殺系統(tǒng)掛了，凌晨1點緊急救場！
文章地址：http://m.5511xx.com/article/dhpeids.html
