如何设计抽奖活动
抽奖的意义
抽奖是一个很好的运营手段，通过抽奖，能够短时间内吸引大量用户，让用户集中使用产品。
是运营活动中最常用的方法。
抽奖中的注意事项
设计一个完美的抽奖活动，需要思考很多细节，最本质只有一个词「可控」。
所有的细节都是围绕着可控来实行的。
概率可控
这是最基本的，抽奖要能控制概率。大奖概率低，小奖甚至不中奖概率高。如果人人可中，那是福利。如果人人都不中，就成了耍猴。
在设计抽奖奖品的时候，要有抽中概率字段。一般直观想到的是按百分比，例如有两个奖品。配置表如下：
A 25%
B 25%
但是这种配置方法是不对的。为什么呢？扩展性不强。
因为把概率总和定位100了，每次增减或修改奖品概率，都要保证百分比加起来是100%，增加了运算逻辑。
最好的方法是用权重，如果一个奖品不想让有人抽中，直接调为0，其他的奖品项也不用更改。
数量可控
每个奖品只有概率约束还不完整，还要加上每个奖品的数量，控制奖品的产出。即使有概率控制，百万分之一，一百万人抽奖，也不一定只有一个人中，理论上存在一百万人都中的情况。所以除了有权重，还要有奖品的数量控制。
怎么确定奖品发光了呢？
一种是每发一个奖品，给奖品数减少，另外一种是加个抽了多少个的字段，每抽到一个，给「已抽数量」加一。
好处是后面增加奖品库存时不存在写冲突，而且经过多次加减抽奖数量，也知道实际发送了多少。
如果奖品抽光了，可以有多种策略：
1、该奖品的权重自动降为0，从其他奖开始抽。
2、当有奖品数为0时被抽到，找剩余有奖品权重最大的那个给他。
时间可控
抽奖有时效，有活动时间控制。要能后端修改，就能立即终止或开启抽奖活动。当系统有故障时，这是一个很好的开关。
发奖也要有时间控制，防止由于其他人把程序启动，活动都过了，还能继续发奖。
预算可控
每个活动都有预算，发出去的奖品都是有价值的，发现发送的奖品累计价值超过了预算，要及时告警，停止发送。而且接近预算也要告警，人工确定到底是奖品快抽光了，还是程序有问题发多了。
满足抽奖资格组合模式
活动会对积极抽奖，或积极参加的用户给予一些优惠。例如游戏中的十连抽比重高级卡牌。当满足九次抽奖时，第十次的奖池就是一个单独奖池了。要支持多奖池配置，逻辑能根据用户的状态选择不同的奖池。
防止多抽
很多程序都是分布式的，会导致并发，产生抽奖次数变多。例如一个人只能有一次抽奖机会。但是如果并发产生了两个请求，两个进程分别处理，会都读到有一次抽奖机会，然后都能抽成功，就造成了多了一次抽奖机会。如果用程序产生更多的并发，抽的更多。
这里要加锁处理。对于一个用户的抽奖次数加锁。大多数都用乐观锁，
一种是加抽奖状态：未抽奖、抽奖中；
一个用户要想抽奖，必须先把用户的状态从未抽奖变为抽奖中，此时其他并发的进程发现已经是抽奖中了，就返回失败。
还有一种是控制抽奖数量，当抽完奖品后，并不马上返回前端，而是去更新抽奖数量，更新时要判断是否有超过最大数量，如果超过，直接算作失败，回滚抽到的奖品，返回前端。
发放奖励
有些活动是抽完马上发奖，有的是抽完隔一段时间发奖。本质也是一样的。只是间隔的时间长短。发奖和抽奖是两种事情，也要慎重对待。
先标记，再发送
判断一个奖品是否已经发送，都会有一条记录表，有个字段表示是否已发送。是先发送奖品，再更新发送字段，还是先标记字段，再发奖呢？
先标记，再发送。
因为在标记和发送中间，会有程序突然crash的情况。先发再标，会导致多发；先标再发，会少发。
对于活动举办方，肯定是少发最好，少发了可以补，多发想要回来就难了。
大奖发送要慎重
对于一些金额比较大的奖品，发送要慎重，要经过审核。因为本身奖品数就不多，审核包括是否有多发，是否抽奖人符合资格，是否程序有问题……
防止多发
在发奖环节，也有类似与多抽的并发问题。也要有锁，保证一条发奖记录，不会被发送多次。通常也是加发送状态。未发送、发送中、已发送。先用发送中抢到发送资格，再慢慢发送这条，发完标记为已发送。如果发现有发送中，证明没有处理完，要人工检查下为什么。
多发有在一个机器或多台机器启动多个进程，导致多发。
还有同样一个请求，两次发送，导致多发。这种要用唯一id保证幂等性，及时相同的请求出现多次，也不会造成多发情况。唯一id要用能唯一标识发送记录的字段，而不应该用时间戳，随机值等每次都变的变量。
发送通知也要防止多发
防止一个人发送了多条通知消息；
防止把通知消息发送给未中的人。
这些都要控制好发送逻辑，要经过细心review才能发现。
对账机制
对于发奖，要有对账机制，实际用户抽到的奖励，和发送的要有数量价值比对。做好风控和审计。
总结
抽奖和发奖，想做好并不容易。要多思考很多细节才能做好。
本质上就是让程序可控，一切尽在控制。
程序的并发、幂等性，产品逻辑的扩展性，奖品数量调整，概率调整，都需要经过推敲。