第四季度運營活動頻頻，雙11雙 12等等，在這幾次活動測試中，感觸比較深刻的還是在抽獎活動的送獎問題上。曾經出現過一次尷尬的事故：紅包送多了，假設每天本來限量100W，結果送出去了150W，多送了50W。且拋開該活動是否有帶來多大的宣傳效果，牽扯到支損，還是一件需要引起重視的事，得想些方法來避免這種故障發生。

下面是某活動中在統計剩余獎池數量截取的一段代碼：

實現的是更新剩余二等獎獎數，及時統計到tair的工作，低流量下一般不會有問題，但是并發量大的時候，若同時有2個用戶抽到二等獎均取到同個SECOND_PRIZE_AMOUNT值，均需對其進行減1的工作，上次未操作完畢，后一次已經取到開始處理，兩次操作后，只讓SECOND_PRIZE_AMOUNT值減了1， 但應該是要減2，這樣累積多個用戶并發操作后，便會出現少算剩余獎數而多送獎的事故了。

通過類似這種事故啟發，并發的問題我們可以通過性能壓測模擬來測試這個問題，防止此類事故發生。以我們曾經一活動為例，來說下如何通過簡單的性能壓測來驗證是否多送獎的問題。

活動的內容大概是這樣：購買一本電子書，將有機會獲得單筆購買的電子書價的1倍、或10倍、或100倍的紅包。活動開始前，在后臺配好中獎的概率和不中獎的概率，再包括中獎概率中分別中1倍、中10倍、中100倍的概率，每天限制總金額M，不限數量，總金額一到，后面一律不中獎。

測試目標：

1.      保證全部獎項抽完后，實際中1倍、10、100的概率與后臺配置一致；

2.      保證實際送出去的紅包總金額不超過每天限制總金額；

按照做數學題的方式，

設后臺配置中獎的概率為p_中，中獎機會中中1倍概率為P₁，中10倍、100倍分別為P₁₀,P₁₀₀,

實際中獎概率為p’_中，中1倍概率為P’₁，中10倍、100倍分別為P’₁₀,P’₁₀₀,

第n個中1倍紅包的金額為y_1n,

第n個中10倍紅包的金額為y_10n,

第n個中100倍紅包的金額為y_100n,

中1倍紅包個數為c_1,

中10倍紅包個數為c_10,

中100倍紅包個數為c_100,

實際中紅包總個數為C ,

每天限制總金額為M

實際發送紅包總金額為M’;

開始進行抽獎接口的壓測工作（具體性能測試方法與普通的接口性能壓測一樣），但需要注意：

1.      并發用戶數盡量多些，讓每個隊列數至少有2到3個用戶（并發用戶數如果太少，上面提到的計數器統計故障可能無法測試出來）；

2.      壓測時間盡量長，目的是讓總transactions 個數盡量把所有獎覆蓋到，讓獎盡量全部抽完；

壓測結束后，中獎的金額與個數情況均可通過埋點日志記錄統計得到，再由活動內容可得：

P’₁ = c₁ / C ,    

P’₁₀ = c₁₀ / C 

P’₁₀₀ = c₁₀₀ / C

結果比對下M’->M, P’₁ ->P₁, P’₁₀ -> P_10, P’₁₀₀ -> P₁₀₀ 。

如果統計結果出來，幾個實際概率值與配置的概率值仍有所偏差，可以再嘗試加長壓測時間，以努力將所有獎項全部抽完，多嘗試幾次壓測，記錄每次的抽獎情況。

正常情況下，最后一個獎抽到的時間點之前所有事務數假設為T1,p’_{中  = C/T1, p’中 -> p中} ; 壓測時間夠長，當M’無限趨近M，此時統計出來的各倍數概率正常會無限逼近配置值，若相差太大，便可能是問題了。

后面以上述的這個性能壓測方法測試了幾個類似活動的抽獎概率和發獎情況，均有些幫助，也希望對大家有所啟發。每次的大型活動結束后，總是會留下一些可以對后續工作有所幫助的教訓，目前在活動測試中，除了送多的問題外，還有許多值得思考的問題，例如如何防惡意刷獎，這塊的測試與風險預防感覺做得還不是很到位，也許也是個值得深究的方向