关于抽奖,需要考虑的点有很多,这里稍微整理了下主要需要考虑以下三点:
用户抽奖次数限制
奖品数量限制
奖品发放的分布
中奖的概率的可控性
用户抽象次数限制
一个用户必须限制抽奖的次数,而同一个用户的并发几率其实是很小的,所以这里可以用悲观锁来控制用户的抽奖次数。
奖品数量限制
因为并发修改一个奖品的数量可能性是很大的,特别是一些安慰奖,如果这里我们再用悲观锁的话,很容易造成锁超时。所以这里我选择用乐观锁来解决可能出现的并发脏读的情况。
奖品发放的分布
为了防止用脚本来刷抽奖,所以这里需要控制一下奖品发放的一个分布,中大奖需要一个时间间隔,当然这里通过代码来控制是很容易实现的(当然这里也需要考虑一下并发中到两个大奖的情况,也可以通过乐观锁来控制)
中奖的概率的可控性
当我们开始估计抽奖大概会有10W人参加,所以我在设计概率的时候是按照10w来设计的,但是突然发现活动开始一个小时候以后抽奖人数就达到了5W,这个时候就需要可以动态来调整中奖的概率了。这里最好的方式是,不要把中奖概论写死在数据库,而是通过中奖次数/参加人数来计算出来,这样就可以方便的动态的改变中奖概率了。
关于优化
如果并发量实在是太大,导致数据库的QPS异常的高。那么可以在数据库前面加一层缓存来挡一下,把需要写进数据库的数据放入队列。当使用了这种架构架构,就需要考虑一些数据一致性的问题了,比如说
怎么保证数据库的数据和缓存的数据是一致的
如果队列挂掉了,怎么保证缓存的数据能够及时更新到数据库中。如果缓存挂掉了,怎么保证抽奖能够继续进行下去(当然这里可以进行业务妥协,如果缓存挂掉整个抽奖挂掉,如果来不及写进数据库的数据,就当做这些事情没有发生，这就会导致某些人抽奖次数超过限定次数,或者某些奖中奖次数超过了限定次数)
关于优化中我对一些异常情况的解决方法不是很了解,希望懂的朋友可以指教一下
附录(简单流程图)
