概述

之前處理過一個購物車故障，覺得還挺經(jīng)典的，在這里跟大家分享一下。這個故障直接導(dǎo)致前端添加購物車、獲取用戶購物車列表等操作都失敗了。購物車是入口，一旦出現(xiàn)問題，影響極其嚴重。

臨時處理

購物車服務(wù)所有接口，是有打印響應(yīng)時間的，發(fā)現(xiàn)比平時慢了很多。由于情況已是十萬火急了，我只能先重啟購物車，緩沖一下，然后利用這段緩沖時間，趕緊定位問題。

問題定位

之前對購物車應(yīng)用基于Spring Cloud微服務(wù)化了，已經(jīng)穩(wěn)定運行了幾個月了，且當(dāng)時上線前也經(jīng)過壓測，接口性能是沒問題的。怎么突然之間就有問題了呢？根據(jù)以往的經(jīng)驗，大部分故障都是SQL語句引起的，因此首先導(dǎo)出數(shù)據(jù)庫的所有慢SQL(騰訊云有導(dǎo)出慢SQL的工具)語句，發(fā)現(xiàn)大部分慢查詢都是來自庫存查詢的SQL語句，有些甚至是10秒鐘才執(zhí)行完。

后來仔細一看，庫存慢查詢語句，要查詢庫存的商品比平時多很多。商品個數(shù)少的話，這條語句還是非?？斓?，一旦多了就開始慢了。

解決方案

由于庫存計算體系的歷史原因，這條SQL是很難優(yōu)化的。情況又是十萬火急的，大老板一直在問咋回事。因此臨時改代碼，將商品庫存放到Redis緩存起來。購物車服務(wù)的話，是允許庫存數(shù)據(jù)不實時的，因為后面的結(jié)算和支付會實時計算庫存，庫存不足的時候，會提示用戶的。

注意：

• 由于購物車是入口，流量很大，而從購物車到結(jié)算頁再到支付，由于有一個操作步驟，因此結(jié)算頁和支付頁的流量是沒有購物車那么大的；
• 部分用戶購物車上的商品數(shù)據(jù)是非常多的，但是未必都會買，用戶也可以勾選要買的商品，然后下單；
• 部分用戶沒有清理購物車失效商品的習(xí)慣，導(dǎo)致購物車上的商品非常多。
  

終極解決方案

將庫存服務(wù)獨立出去，將商品庫存數(shù)據(jù)放置到緩存，并引入實時刷新緩存中庫存數(shù)據(jù)的機制，讓緩存中的數(shù)據(jù)盡量保證新鮮。這樣的話，查詢庫存的時候，大部分都可以從緩存中獲取，不會穿透到數(shù)據(jù)庫上。

補充

我們對接口進行壓測的時候，部分場景下，要考慮入?yún)⒌膫€數(shù)，不能簡單的用幾個數(shù)據(jù)壓測，覺得性能OK就不管了。

總結(jié)

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，謝謝大家對腳本之家的支持。如果你想了解更多相關(guān)內(nèi)容請查看下面相關(guān)鏈接