在PHP中使用innoDB表和mysqli包装器进行查询.
当前,我们遇到一个问题,就是每秒请求1500次相同脚本的流量激增.
情况是访问脚本的前X个用户赢得了奖励.
奖品是表“奖品”上的一条记录,该表中有#个已声明的编号和#个已分配编号的计数.
一旦使用的金额> =分配的金额,我们将停止奖励.
发生的情况是,在脚本的其他实例可以更新该行之前,对该脚本的许多请求正在同时读取该行,从而向他们显示仍然还有一定数量的奖金需要领取.这导致我们奖励的金额超过了所分配的金额.
关于如何规避这一点的任何想法？
解决方法:
正确,您描述的是经典比赛条件.
一种解决方案是在更新之前,使用SELECT … FOR UPDATE在奖品表中的行上建立锁定. InnoDB将建立对锁的请求顺序,使每个请求等待其轮到它可以获取锁为止.
但是,这不是一个好的解决方案,因为它将导致每个用户的浏览器旋转并旋转,等待响应.在服务器上,您将迅速获得每秒1500个锁定请求的排队.即使每个会话仅花费10毫秒来执行SELECT FOR UPDATE和后续UPDATE(这已经非常雄心勃勃),每秒仍需要15.0秒的工作.到第二秒,您将有30.0秒的工作要做.
同时,用户正在查看他们的浏览器是否挂起,直到转向.这几乎是一项设计的突破.
基本上,您需要一些解决方案来建立请求的顺序,即：
>全球
>原子
>快速
>异步
您可以让每个并发请求使用AUTO_INCREMENT键对表进行INSERT,这将保证其顺序.然后,一旦有X行,后续请求就不会再插入任何行了.
另一种方法是使用消息队列.每个请求只是将自己的请求推入队列.然后,一个消费者从队列中拉出前X个请求,并向他们奖励.队列中的其余请求将被转储,并且不会获得奖励.
标签：mysql,php,database 来源： https://codeday.me/bug/20191211/2105892.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。