陪玩原始碼下單介面調優實戰,提高效能的好辦法

雲豹科技程式設計師發表於2021-12-27

概述

當陪玩原始碼下單介面慢的時候,我們就需要對其進行優化了,但最好不要大改,因為下單介面太複雜了,如果改動太大,怕有風險。另外開發成本和測試成本也非常大。我們需要在解決問題的過程中,學習很多東西。
當時我只是知道下單介面慢,但是沒人告訴我慢在哪裡,也即是說,哪些瓶頸導致下單介面慢了。其實沒人知道也沒關係的,因為我們可以通過壓測來找到具體的瓶頸。
下面會詳細介紹一下,在本次壓測中遇到的問題以及如何解決,期間用了什麼工具。

用到的工具和環境

工具
  • Jmeter
  • JAVA自帶的jvisualvm
  • JMX
  • nmon
環境
  • 騰訊雲Mysql
  • 騰訊雲2核4g的伺服器1臺
找瓶頸
陪玩原始碼中的下單屬於寫介面,大部分情況下,瓶頸都出在DB裡,陪玩原始碼可能都在等待DB鎖的釋放。為了驗證這個想法,我們可以使用Jmeter和jvisualvm來驗證一下。
為了監控陪玩原始碼伺服器和伺服器中JAVA程式,我們需要開啟JMX,可以在JAVA程式啟動的時候,新增如下幾個引數:
JMX_OPTS="-Dcom.sun.management.jmxremote.port=7969 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=xx.xx.xx.xx"
nohup java ${JMX_OPTS} -jar xxxxx.jar
Djava.rmi.server.hostname填寫JAVA程式所在伺服器的IP地址,-Dcom.sun.management.jmxremote.port=7969是指定JMX監控埠的,這裡是7969。
重新啟動程式後,開啟本地的(我用的是Window10)jvisualvm,新增JMX配置。配置成功後,可以點選執行緒那個tab,因為我們要做執行緒dump,觀察執行緒的執行情況。
陪玩原始碼下單介面調優實戰,提高效能的好辦法
陪玩原始碼下單介面調優實戰,提高效能的好辦法
好了,現在我們可以使用Jmeter來對陪玩原始碼下單介面進行壓測了。可以先用50執行緒併發壓,執行時間是1分鐘。
陪玩原始碼下單介面調優實戰,提高效能的好辦法
在壓測的過程中,做一下執行緒dump,同時利用nmon觀察應用伺服器CPU的負載情況。
陪玩原始碼下單介面調優實戰,提高效能的好辦法
負載很低,將執行緒併發調整到100後,CPU還是上不去,這樣的話,初步可以判斷,陪玩原始碼裡有鎖。 通過觀察dump檔案,發現如下資訊:
- locked <22f6e7f3> (a com.mysql.cj.core.io.ReadAheadInputStream)
- at com.sun.proxy.$Proxy231.reduceSkuStock(Unknown Source)
觸發這個lock的業務程式碼是reduceSkuStock方法。通過閱讀程式碼,發現reduceSkuStock被包在一個大事務裡面。
@Transactional(rollbackFor = {Exception.class})
 createOrder() {
 //1、扣減庫存
 reduceSkuStock();
 //2、建立訂單
 insertOrder();
 //3、其他寫操作
  。。。。
}
庫存記錄通常存在一張獨立的庫存表,由於建立訂單的方法,是一個大事務,這樣就會導致某條庫存記錄只有當整個createorder()方法執行完後,資料庫行鎖才會被釋放,在這個期間,其他執行緒是無法對這條庫存記錄進行寫操作的。因此我們可以在reduceSkuStock()中,再開一個事務,操作完這條庫存記錄後,趕緊釋放鎖,這樣應該可以提高一些效能。為了驗證是否是因為事務的原因導致陪玩原始碼下單介面慢,我們可以直接將createOrder()方法的事務去掉,再壓測一下。
壓測結果發現,下單介面的TPS提高了一倍,CPU也上去了不少,但是仍然不夠理想,程式碼裡,應該還有其他的鎖。再次做執行緒dump,又發現了一個鎖。
- locked <438be230> (a org.apache.http.pool.AbstractConnPool$2)
- at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
導致鎖的程式碼是HttpClient的execute方法,該方法在執行的時候,一直在等待獲取HTTP連線,通過檢視原始碼,發現居然沒有使用連線池,醉了。趕緊加上如下程式碼:
 PoolingHttpClientConnectionManager pool = new PoolingHttpClientConnectionManager();
 pool.setDefaultMaxPerRoute(400);
 httpClient = HttpClients.custom().setConnectionManager(pool).build();
再次壓測後,發現程式碼裡已經沒有鎖了。TPS提升了5倍。但是接下來還得做幾件事情:
1、列印下單介面的所有SQL,然後逐一進行explain操作,看看有沒有全表掃描的語句或者沒用到索引的SQL語句; 2、觀察下單介面執行的過程中,FULL GC發生的次數; 3、增加陪玩原始碼的MYSQL連線數;
好了,到了這地方,我們可以回到前面,來解決庫存問題了。由於不能大改,因此我就在reduceSkuStock方法上,再開一個事務。
@Transactional(propagation = Propagation.REQUIRES_NEW)
reduceSkuStock(){}
讓執行庫存操作的執行緒執行完後,趕緊釋放行鎖。這樣做也有個風險,就是庫存扣減成功後,下單失敗了。不過這種情況比較少,因為當時的下單介面中,大部分業務邏輯都在前面做好判斷了,到達插入訂單的程式碼時,就只是單獨的insert了,除非陪玩原始碼資料庫掛了,不然不會出現下單失敗的情況。
在開發環境下,經過調優後,陪玩原始碼下單介面的TPS提升了3倍左右,當然由於開發環境的資料庫和應用伺服器都比較差,也會對TPS有影響的。當時優化完後,在生產上進行了壓測,發現TPS提升了10倍。

總結

這個是陪玩原始碼下單介面的邏輯不能大改的情況下的優化方案,一般來說,庫存操作應該是單獨的服務,可以單獨優化的。而單純的下單邏輯也是可以優化的。
本文轉載自網路,轉載僅為分享乾貨知識,如有侵權歡迎聯絡雲豹科技進行刪除處理 原文連結:https://blog.csdn.net/linsongbin1/article/details/82656887


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69996194/viewspace-2849544/,如需轉載,請註明出處,否則將追究法律責任。

相關文章