事故背景

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

什么原因造成的？

搶購活動計(jì)劃是零點(diǎn)準(zhǔn)時(shí)開始，

22：00 運(yùn)營人員通過后臺將商品上線

23：00后臺小哥已經(jīng)將商品導(dǎo)入緩存中，提前預(yù)熱

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

緩存命中

如上圖預(yù)期大部分請求會命中緩存，但是由于后臺小哥預(yù)熱緩存的時(shí)候?qū)⑺猩唐返木彺鏁r(shí)間都設(shè)置為2小時(shí)過期，所有的商品在同一個(gè)時(shí)間點(diǎn)全部失效，瞬間所有的請求都落在數(shù)據(jù)庫上，導(dǎo)致數(shù)據(jù)庫扛不住壓力崩潰，用戶所有的請求都超時(shí)報(bào)錯(cuò)。

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

緩存雪崩

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

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

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

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

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

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

首先通過API Gateway（網(wǎng)關(guān)）限制大部分流量進(jìn)來?

接著將宕機(jī)的數(shù)據(jù)庫服務(wù)重啟?

再重新預(yù)熱緩存?

確認(rèn)緩存和數(shù)據(jù)庫服務(wù)正常后將網(wǎng)關(guān)流量正常放開，大約01：30 搶購活動恢復(fù)正常。

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

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

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

• 均勻過期

• 加互斥鎖

• 緩存永不過期

（1）均勻過期

設(shè)置不同的過期時(shí)間，讓緩存失效的時(shí)間點(diǎn)盡量均勻。通?？梢詾橛行谠黾与S機(jī)值或者統(tǒng)一規(guī)劃有效期。

緩存key過期時(shí)間均勻分布

（2）加互斥鎖

跟緩存擊穿解決思路一致，同一時(shí)間只讓一個(gè)線程構(gòu)建緩存，其他線程阻塞排隊(duì)。

互斥訪問

（3）緩存永不過期

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

異步更新緩存

復(fù)盤總結(jié)

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

（1）均勻過期

（2）加互斥鎖

（3）緩存永不過期

希望技術(shù)人能夠敬畏每一行代碼！

往期推薦

《大廠內(nèi)部資料》Redis 性能優(yōu)化的 13 條軍規(guī)！全網(wǎng)首發(fā)

2020-03-24

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

2020-03-26

史上最全的 SQL 優(yōu)化方案！建議收藏

2020-04-13

關(guān)注我，每天陪你進(jìn)步一點(diǎn)點(diǎn)！

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。