我做的一个活动,是抽奖之后向中奖用户分发卡号,卡号是已经拿到手放到db里;
当用户中奖后完善资料去获取卡密时:首先判断使用状态,得到卡号,再修改卡号状态。
在这个获取卡号的过程中,如果有高并发的情况,怎么处理合理?
表是用的innodb引擎,在获取卡号的时候判断未使用的 也无法根据主键来行锁,导致整个表锁。
我做的一个活动,是抽奖之后向中奖用户分发卡号,卡号是已经拿到手放到db里;
当用户中奖后完善资料去获取卡密时:首先判断使用状态,得到卡号,再修改卡号状态。
在这个获取卡号的过程中,如果有高并发的情况,怎么处理合理?
表是用的innodb引擎,在获取卡号的时候判断未使用的 也无法根据主键来行锁,导致整个表锁。
MySQL innodb引擎利用事务回滚功能,一旦有某条sql操作失败,则回滚。
利用队列,减轻业务逻辑服务器的负载,避免高并发带来的问题。
把未使用的卡号放在Redis的Queue里,获取一张就pop一张
你可以不给他卡号,这样是最省事的办法。中奖用户肯定有记录吧?发奖有状态吧?用户资料完善后变更一下发奖状态,然后告诉用户今天凌晨发奖就行了。然后设一个cron-job,到时候分一下肯定不会发重了。而且这么搞中奖的人至少还要再访问一次你的网站,省的有人领完奖就再也不来了。