简单的活动抽奖算法&方案

只要是有营销的场景，抽奖可以说几乎是必不可少的功能，如何基于一个简单的抽奖逻辑去支撑种类繁多的抽奖方案，结合之前的经验，总结如下。

其实不论上层的抽奖方案是什么（例如，大转盘，刮刮乐，扎气球、砸金蛋等），都只是展示层的提现形式不一样，底层都可以使用同一个抽奖算法。

想想，如果是线下举办抽奖，一般会有哪些方案？

可预估奖品数 主动式，抽奖券500份，其中有奖品的只有10份，然后给用户抽，抽中就是你的。例如：买汽水的瓶盖抽奖，刮刮乐。 被动式，带ID的抽奖券500份，给用户抽，然后系统随机抽取10个ID发放奖品。例如：发布会入场券抽奖

不可预估奖品数 用户自己填信息的抽奖券，到时候由系统随机生成一个数，比对一致的就即为中奖者。例如：彩票。

其实线上的抽奖算法，基本上也是基于模拟线下场景方案来模拟的。但绝大多数场景都是黑盒操作，执行抽奖，中间的过程用户是无法获知的。

1、随机区间法 这个方法随机度高，根据概率论来计算，每个用户的单次中奖概率为中奖概率=奖品数/预估抽奖用户人数 如图所示，上面是一个奖品的分配区间，例如预计抽奖100W人，1等级1个，2等奖3个，3等奖5个，4等奖10个，其余999981都是谢谢惠顾。用户抽奖的时候，获得一个随机数，判断是否在中奖区间即可。发放奖品，则区间内的奖品剩余数-1；回收奖品，则区间内的奖品+1。

当一个奖品被抽完之后，从奖品区间移除（谢谢惠顾一般不算奖品），其余继续抽奖，例如上图的10个4等奖被抽光了。而当所有奖品都抽光了，就会只剩下一个谢谢惠顾的区间，这样用户不论怎么抽，都只会是谢谢惠顾，直到活动日结束。如果需要限制总抽奖次数，则将谢谢惠顾的部分也纳入库存，最终库存全部消耗完，随即提示用户抽奖结束即可。

需要注意的是，评估预计抽奖的人数比较重要（影响到随即数生成区间），我们可以根据历史数据评估，如果不是很清楚，建议评估人数大一些，这样奖品不至于很快被抽完。

2、自增匹配法

此方法简单至极，先设一个全局自增数，然后每个奖品我们设一个数字，有几个奖品设几个数，每次用户抽奖，自增数加一返回，如果自增数此时与奖品的数字一致，则中奖。 好处是，不用记录奖品的剩余数，只用记录自增数。 缺点是，由于不用记录奖品的剩余数，是因为提前进行了分布，所以奖品多的情况不适用。

曾经使用mysql的时候，需要使用事务、消息队列，来保证并发导致的数据一致性问题。直到后来改为使用redis。 得益于redis的原子性操作和极高的性能，在高并发情况下也能很快的处理相应的库存增减操作（redis同样适用于秒杀场景）。