服務商系統集中高頻交易CPU飆升問題解決優化過程

通過創建數據表索引，有效提升系統性能。

一、問題背景

在11月10日下午5點，出現channel非同步下發消息隊列消息積壓報警，經排查分析是因為channel請求鑫某億服務商落單時間過長，導致了channel消費消息隊列的消息變慢的情況。所以，專項對鑫某億系統相關業務進行優化。

一（1）、現場

查看當時鑫某億服務商的伺服器監控，如下所示：

圖中可見，當時鑫某億的CPU很長一段時間都是滿負荷的狀態，以至於伺服器出現了卡頓的現象，間接的導致了落單慢的問題。

一（2）、分析

鑫某億服務商系統和資料庫部署在同一臺伺服器上。CPU持續飆高一般都是由於CPU進行著滿負荷的計算：

1）程式出現了死迴圈，導致CPU一直在計算。目前來看只是大量下發的時候出現這個問題，所以可以排除死迴圈的問題；

2）程式存在大量的計算工作，導致CPU一直在計算。結合業務場景分析，可以排除這個猜想

3）資料庫進行了大量的查詢計算，導致CPU一直持續飆高。正好符合目前的場景，在大量的下發的時候必然會進行大量的資料庫操作；

一（3）、緊急修複

趕緊緊急進行排查分析，當晚發現有兩點問題待緊急優化，如下文細述。

二、問題解決（三板斧）

1、第一斧 – 增加聯合索引，讓頻繁的全表查詢變為精准定位 （全表掃描 → 索引精准定位）

服務商下發單在記賬時，會從商戶賬戶凍結交易金額，為了確保防重，會先校驗該筆訂單是否已經凍結過，如果已經凍結過，就不能重覆凍結，如下圖所示：

這個防重凍結的SQL是：

可見，使用到了order_id和type這2個欄位作為where條件去查詢記賬流水錶t_acc_detail_trans。如果有一個索引，包含了order_id和type，是不是就可以很快得到查詢結果。依據這個就建立了一個聯合索引，uni_order_id_type。這樣的話，能快速的知道符合這個條件的賬務流水存不存在，加上這個索引之後避免了全表掃描，而且P99的情況下都不會回表確認，因為索引明確的就告訴了是否存在。

2、第二斧 – 轉換查詢方式，通過等價變換利用索引 （全表掃描 → 索引範圍掃描）

在下發的時候需要判斷自由職業者有沒有與服務商簽約，所以要查服務商的簽約表T_SOHO，表中存在一個唯一索引（ unique index UNI_T_SOHO  (ID_CARD, NAME, CARD_NO, MER_ID)），在下發時需要對存在簽約信息做一個判斷，如下圖所示SQL，但是這個SQL並沒有命中這個索引：

先解釋一下這裡用到的upper函數，是因為有一部分人的身份證是帶有字母“X” 的，但是在錄入的時候沒有判斷是錄入的是“x" 還是“X”，所以這裡利用upper來做相容。由於在欄位上使用了函數，導致無法走這個欄位索引，最後只能全表掃描去判斷有沒有符合條件的簽約記錄。針對這種情況，做瞭如下更改：

通過等價轉換，將欄位上面的函數去掉，使之可以走索引，美中不足就是需要走兩次索引，不過相對於全表掃描在性能上已經是天壤之別了。

TODO：經對近期下發交易進一步分析，發現存在同人同日有多次下發的情況，考慮到T_SOHO表的簽約數據在發生後幾乎不會有變化，所以，後續可進一步優化，使用本地緩存或redis緩存，來有效減少資料庫請求次數。

3、第三斧 – 大量頻繁執行的SQL進行重點分析 （全表掃描 → 索引範圍掃描）

第二天觀察優化效果，鑫某億服務商依然存在CPU持續過高的問題，開始分析最近上的需求，發現有一個需求是增加下發時效，由於時間緊急，第一步是減少channel請求服務商查詢下髮結果的延遲隊列查詢時間，可見現在查詢的次數會變多，由於CPU過高導致的下發時效變慢，但是channel又一直查詢下髮結果，必然會雪上加霜，所以分析訂單查詢的代碼，發現存在這樣一個查詢：

這個是每次查詢都會查詢通道訂單，用於告知業務系統通道返回的詳細信息，每次channel查詢訂單狀態都會執行一下這個查詢，經查看這個查詢並沒有創建相應的索引，而是進行了全表掃描，所以加上order_id的索引，將全表掃描變為為索引範圍掃描，再少量的幾次回表。

三、優化成效驗證

11月14日下發：

11月16日下發：

四、經驗總結

1. 一定要充分理解業務和系統流程，只有知道自己在做什麼才能知道如何更好地去做；
2. 出現問題可以先從主流程上進行充分的優化，只有沒有任何優化的地方，才採取考慮引入其他框架或者擴硬體；
3. 理論知識很重要，付諸實踐更重要，不規避問題才能更好地成長；

當看到一些不好的代碼時，會發現我還算優秀；當看到優秀的代碼時，也才意識到持續學習的重要！--buguge
本文來自博客園，轉載請註明原文鏈接：https://www.cnblogs.com/buguge/p/16900966.html