如何解決秒殺系統(tǒng)掛了的問題

這篇文章主要介紹“如何解決秒殺系統(tǒng)掛了的問題”，在日常操作中，相信很多人在如何解決秒殺系統(tǒng)掛了的問題問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”如何解決秒殺系統(tǒng)掛了的問題”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

什么原因造成的?

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

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

• 23：00，后臺小哥已經(jīng)將商品導入緩存中，提前預熱。

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

緩存命中

如上圖預期大部分請求會命中緩存，但是由于后臺小哥預熱緩存的時候將所有商品的緩存時間都設置為 2 小時過期。

因此所有的商品在同一個時間點全部失效，瞬間所有的請求都落在數(shù)據(jù)庫上，導致數(shù)據(jù)庫扛不住壓力崩潰，用戶所有的請求都超時報錯。

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

緩存雪崩

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

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

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

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

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

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

• 首先通過 API Gateway(網(wǎng)關)限制大部分流量進來。

• 接著將宕機的數(shù)據(jù)庫服務重啟。

• 再重新預熱緩存。

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

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

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

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

• 均勻過期

• 加互斥鎖

• 緩存永不過期

均勻過期

設置不同的過期時間，讓緩存失效的時間點盡量均勻。通常可以為有效期增加隨機值或者統(tǒng)一規(guī)劃有效期。

緩存 key 過期時間均勻分布

加互斥鎖

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

互斥訪問

緩存永不過期

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

異步更新緩存

到此，關于“如何解決秒殺系統(tǒng)掛了的問題”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>