当前,我们遇到一个问题,就是每秒请求1500次相同脚本的流量激增.
情况是访问脚本的前X个用户赢得了奖励.
奖品是表“奖品”上的一条记录,该表中有#个已声明的编号和#个已分配编号的计数.
一旦使用的金额> =分配的金额,我们将停止奖励.
发生的情况是,在脚本的其他实例可以更新该行之前,对该脚本的许多请求正在同时读取该行,从而向他们显示仍然还有一定数量的奖金需要领取.这导致我们奖励的金额超过了所分配的金额.
关于如何规避这一点的任何想法？
最佳答案
正确,您描述的是经典比赛条件.
一种解决方案是在更新之前,使用SELECT … FOR UPDATE在奖品表中的行上建立锁定. InnoDB将建立对锁的请求顺序,使每个请求等待其轮到它可以获取锁为止.
但是,这不是一个好的解决方案,因为它将导致每个用户的浏览器旋转并旋转,等待响应.在服务器上,您将迅速获得每秒1500个锁定请求的排队.即使每个会话仅花费10毫秒来执行SELECT FOR UPDATE和后续UPDATE(这已经非常雄心勃勃),每秒仍需要15.0秒的工作.到第二秒,您将有30.0秒的工作要做.
同时,用户正在查看他们的浏览器是否挂起,直到转向.这几乎是一项设计的突破.
基本上,您需要一些解决方案来建立请求的顺序,即：
>全球
>原子
>快速
>异步
您可以让每个并发请求使用AUTO_INCREMENT键对表进行INSERT,这将保证其顺序.然后,一旦有X行,后续请求就不会再插入任何行了.
另一种方法是使用消息队列.每个请求只是将自己的请求推入队列.然后,一个消费者从队列中拉出前X个请求,并向他们奖励.队列中的其余请求将被转储,并且不会获得奖励.