您好,登錄后才能下訂單哦!
這篇文章給大家分享的是有關SQL導致購物車服務無法使用怎么辦的內容。小編覺得挺實用的,因此分享給大家做個參考,一起跟隨小編過來看看吧。
概述
之前處理過一個購物車故障,覺得還挺經典的,在這里跟大家分享一下。這個故障直接導致前端添加購物車、獲取用戶購物車列表等操作都失敗了。購物車是入口,一旦出現問題,影響極其嚴重。
臨時處理
購物車服務所有接口,是有打印響應時間的,發現比平時慢了很多。由于情況已是十萬火急了,我只能先重啟購物車,緩沖一下,然后利用這段緩沖時間,趕緊定位問題。
問題定位
之前對購物車應用基于Spring Cloud
微服務化了,已經穩定運行了幾個月了,且當時上線前也經過壓測,接口性能是沒問題的。怎么突然之間就有問題了呢?根據以往的經驗,大部分故障都是SQL
語句引起的,因此首先導出數據庫的所有慢SQL
(騰訊云有導出慢SQL的工具)語句,發現大部分慢查詢都是來自庫存查詢的SQL
語句,有些甚至是10秒鐘才執行完。
后來仔細一看,庫存慢查詢語句,要查詢庫存的商品比平時多很多。商品個數少的話,這條語句還是非常快的,一旦多了就開始慢了。
解決方案
由于庫存計算體系的歷史原因,這條SQL
是很難優化的。情況又是十萬火急的,大老板一直在問咋回事。因此臨時改代碼,將商品庫存放到Redis
緩存起來。購物車服務的話,是允許庫存數據不實時的,因為后面的結算和支付會實時計算庫存,庫存不足的時候,會提示用戶的。
注意:
由于購物車是入口,流量很大,而從購物車到結算頁再到支付,由于有一個操作步驟,因此結算頁和支付頁的流量是沒有購物車那么大的;
部分用戶購物車上的商品數據是非常多的,但是未必都會買,用戶也可以勾選要買的商品,然后下單;
部分用戶沒有清理購物車失效商品的習慣,導致購物車上的商品非常多。
終極解決方案
將庫存服務獨立出去,將商品庫存數據放置到緩存,并引入實時刷新緩存中庫存數據的機制,讓緩存中的數據盡量保證新鮮。這樣的話,查詢庫存的時候,大部分都可以從緩存中獲取,不會穿透到數據庫上。
補充
我們對接口進行壓測的時候,部分場景下,要考慮入參的個數,不能簡單的用幾個數據壓測,覺得性能OK就不管了。
感謝各位的閱讀!關于“SQL導致購物車服務無法使用怎么辦”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,讓大家可以學到更多知識,如果覺得文章不錯,可以把它分享出去讓更多的人看到吧!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。