秒殺系統(tǒng)掛了，凌晨1點(diǎn)緊急救場(chǎng)！

作者：雷架 2020-11-11 09:22:21

公司最近安排了一波商品搶購(gòu)活動(dòng)，由于后臺(tái)小哥操作失誤最終導(dǎo)致活動(dòng)效果差，被用戶和代理商投訴了。經(jīng)理讓我?guī)聜円黄饛?fù)盤這次線上事故。

圖片來(lái)自 Pexels

什么原因造成的?

搶購(gòu)活動(dòng)計(jì)劃是零點(diǎn)準(zhǔn)時(shí)開始：

搶購(gòu)開始的瞬間流量非常大，按計(jì)劃是通過(guò) Redis 承擔(dān)大部分用戶查詢請(qǐng)求，避免請(qǐng)求全部落在數(shù)據(jù)庫(kù)上。

緩存命中

如上圖預(yù)期大部分請(qǐng)求會(huì)命中緩存，但是由于后臺(tái)小哥預(yù)熱緩存的時(shí)候?qū)⑺猩唐返木彺鏁r(shí)間都設(shè)置為 2 小時(shí)過(guò)期。

因此所有的商品在同一個(gè)時(shí)間點(diǎn)全部失效，瞬間所有的請(qǐng)求都落在數(shù)據(jù)庫(kù)上，導(dǎo)致數(shù)據(jù)庫(kù)扛不住壓力崩潰，用戶所有的請(qǐng)求都超時(shí)報(bào)錯(cuò)。

實(shí)際上所有的請(qǐng)求都直接落到數(shù)據(jù)庫(kù)，如下圖：

緩存雪崩

什么時(shí)候發(fā)現(xiàn)的?

凌晨 01：02，SRE 收到系統(tǒng)告警，登錄運(yùn)維管理系統(tǒng)發(fā)現(xiàn)數(shù)據(jù)庫(kù)節(jié)點(diǎn) CPU 和內(nèi)存飆升超過(guò)閾值，迅速聯(lián)系后臺(tái)開發(fā)人員定位排查。

為什么沒有早點(diǎn)發(fā)現(xiàn)?

由于緩存設(shè)置過(guò)期時(shí)間是 2 小時(shí)，凌晨 1 點(diǎn)前緩存可以命中大部分請(qǐng)求，數(shù)據(jù)庫(kù)服務(wù)處于正常狀態(tài)。

發(fā)現(xiàn)時(shí)采取了什么措施?

后臺(tái)小哥通過(guò)日志定位排查發(fā)現(xiàn)問題后，進(jìn)行了一系列操作：

首先通過(guò) API Gateway(網(wǎng)關(guān))限制大部分流量進(jìn)來(lái)。
接著將宕機(jī)的數(shù)據(jù)庫(kù)服務(wù)重啟。
再重新預(yù)熱緩存。
確認(rèn)緩存和數(shù)據(jù)庫(kù)服務(wù)正常后將網(wǎng)關(guān)流量正常放開，大約 01：30 搶購(gòu)活動(dòng)恢復(fù)正常。

如何避免下次出現(xiàn)?

這次事故的原因其實(shí)就是出現(xiàn)了緩存雪崩，查詢數(shù)據(jù)量巨大，請(qǐng)求直接落到數(shù)據(jù)庫(kù)上，引起數(shù)據(jù)庫(kù)壓力過(guò)大宕機(jī)。

在業(yè)界解決緩存雪崩的方法其實(shí)比較成熟了，比如有：