一條慢SQL致使購物車服務沒法使用

概述

---

以前處理過一個購物車故障，以爲還挺經典的，在這裏跟你們分享一下。這個故障直接致使前端添加購物車、獲取用戶購物車列表等操做都失敗了。購物車是入口，一旦出現問題，影響極其嚴重。

---

臨時處理

---

購物車服務全部接口，是有打印響應時間的，發現比平時慢了不少。因爲狀況已經是十萬火急了，我只能先重啓購物車，緩衝一下，而後利用這段緩衝時間，趕忙定位問題。

---

問題定位

---

以前對購物車應用基於Spring Cloud微服務化了，已經穩定運行了幾個月了，且當時上線前也通過壓測，接口性能是沒問題的。怎麼忽然之間就有問題了呢？基於以往的經驗，大部分故障都是SQL語句引發的，所以首先導出數據庫的全部慢SQL(騰訊雲有導出慢SQL的工具)語句，發現大部分慢查詢都是來自庫存查詢的SQL語句，有些甚至是10秒鐘才執行完。

後來仔細一看，庫存慢查詢語句，要查詢庫存的商品比平時多不少。商品個數少的話，這條語句仍是很是快的，一旦多了就開始慢了。

---

解決方案

---

因爲庫存計算體系的歷史緣由，這條SQL是很難優化的。狀況又是十萬火急的，大老闆一直在問咋回事。所以臨時改代碼，將商品庫存放到Redis緩存起來。購物車服務的話，是容許庫存數據不實時的，由於後面的結算和支付會實時計算庫存，庫存不足的時候，會提示用戶的。

注意：

• 因爲購物車是入口，流量很大，而從購物車到結算頁再到支付，因爲有一個操做步驟，所以結算頁和支付頁的流量是沒有購物車那麼大的；
• 部分用戶購物車上的商品數據是很是多的，可是未必都會買，用戶也能夠勾選要買的商品，而後下單；
• 部分用戶沒有清理購物車失效商品的習慣，致使購物車上的商品很是多。

---

終極解決方案

---

將庫存服務獨立出去，將商品庫存數據放置到緩存，並引入實時刷新緩存中庫存數據的機制，讓緩存中的數據儘可能保證新鮮。這樣的話，查詢庫存的時候，大部分均可以從緩存中獲取，不會穿透到數據庫上。

---

補充

---

咱們對接口進行壓測的時候，部分場景下，要考慮入參的個數，不能簡單的用幾個數據壓測，以爲性能OK就無論了。

---

原文連接

---

一條慢SQL致使購物車服務沒法使用