第四季度运营活动频频，双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，此时统计出来的各倍数概率正常会无限逼近配置值，若相差太大，便可能是问题了。

后面以上述的这个性能压测方法测试了几个类似活动的抽奖概率和发奖情况，均有些帮助，也希望对大家有所启发。每次的大型活动结束后，总是会留下一些可以对后续工作有所帮助的教训，目前在活动测试中，除了送多的问题外，还有许多值得思考的问题，例如如何防恶意刷奖，这块的测试与风险预防感觉做得还不是很到位，也许也是个值得深究的方向