搶紅包效能測試測試案例
阿新 • • 發佈:2018-12-22
場景描述:搶紅包活動,現場700人,每個人必須中獎,中獎活動開始過程中出現宕機;引數(C3P0 100連線數,超時時間30秒;tomcat 連線池4096 ;JVM記憶體 1024M 1024M 64M 512M)
處理過程:使用loaderrunning進行效能測試,對資料庫連線池數量進行,tomcat執行緒數,JVM記憶體進行引數調整,加壓測試。
發現問題:
1、 程式宕機是因為有資料庫連線未關閉的情況,導致資料庫連線沒有釋放,最終所有執行緒等待,宕機(出現數據庫連線異常)。
2、高併發環境下出現資料藏獨現象(兩個人同事中了同一個CDKEY),採取了hibernate樂觀鎖。新增方式如下:
資料庫表新增version欄位
pojo
private Integer version;
對映檔案
<class name="com.hxjr.pojo.Cdkey" table="CDKEY" <strong>optimistic-lock="version" </strong>> <id name="id" type="java.lang.String"> <column name="ID" length="40" /> <generator class="uuid.hex" /> </id> <!-- version標籤用於指定表示版本號的欄位資訊 --> <strong><version name="version" column="version" type="integer"></version> </strong>
新增樂觀鎖之後出現的新問題就是當兩條資料對同一個記錄進行操作的時候,只有一個會成功,第二個會丟擲異常。場景需要每位使用者都必須中獎,在這個基礎上做了以下優化:
1. 每次更新操作,重新整理session;
2. 異常資料接到異常在進行處理。
try{ zpList = this.activityService.meetingDoQhbRandom(peActivityId, empno, page, rows); }catch(Exception e){ try{ Thread.sleep(500); zpList = this.activityService.meetingDoQhbRandom(peActivityId, empno, page, rows); }catch(Exception e1){ Thread.sleep(500); try{ zpList = this.activityService.meetingDoQhbRandom(peActivityId, empno, page, rows); }catch(Exception e2){ zpList = this.activityService.meetingDoQhbRandom(peActivityId, empno, page, rows); } } }
資料優化了很多,但是還存在不中獎需要重新抽的情況。
後期討論了兩套解決方案:
1 才是快取或者記憶體資料庫存放cdkey
2 使用程式碼同步機制,鎖住程式碼塊。