分析并总结秒杀场景

积累知识，胜过积蓄金银！毕竟在##column_title##开发的过程中，会遇到各种各样的问题，往往都是一些细节知识点还没有掌握好而导致的，因此基础知识点的积累是很重要的。下面本文《分析并总结秒杀场景》，就带大家讲解一下MySQL、秒杀知识点，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

业务介绍

每人相对于每件商品同一个价格不能重复

如何解决

快速响应

快速响应我觉得也可以理解为减少请求，因为同一场活动当中能够秒杀的数量是有限的，在十倍甚至更多的用户来请求的时候其中大部分都是无效的（不能抢到商品），只需要通过简单的条件判断之后告诉他们结果，不继续走后面的流程就解决了一部分问题。

降低DB压力

在并发写入的时候我没办法（也许有其他办法）保证准确的插入DB，因为一组语句在执行的过程中都存在时间差

当只有一个商品的时候，A和B同时进来，同时抢购。貌似条件都符合，结果却是商品成了-1
出现了超卖现象。在DB层面有多表操作且存在延迟，目前是使用redis用队列来处理这个问题，可以快速存取，减少多次操作DB
同时，在数据写入redis的时候，通过库存等其他条件判断，不符合的直接返回失败，并且队列长度的（比如控制库存量就是一个队列长度的最大值）直接丢弃并返回失败来降低DB压力

依靠策略

如果出现预估人数非常大的时候，可以考虑在入队之前 使用rand 来过滤一部分人。

php

if(rand(1,99) 

几行代码搞定一群人（话说也是在社区里和人家学的）。。。。。
不过抢购成功的人群总是有规律可以寻找或者设置的，有很多办法可以控制

数据可靠

将数据入队之后依靠后端单个进程处理，然后通过事务和索引保证一致性，处理完之后看需求同步修改队列中的数据（之所以使用单个进程是因为考虑可能出现死锁等待，以及并发写入问题，因为总量不大，一个进程肯定跑得过来）。具体的并发上限没有测试过，但是在本机的并发测试下数据都是美美的~

关于前端

我觉得总共有两点，第一是控制流量，第二是获得响应
1. 当流量过大的时候，加一个验证码可以在单位时间内有效的控制住合法用户（不合法的暂时不讨论主要也是没经验╮(╯3╰)╭）
2. 因为数据入队之后是后台异步处理的，前端直接获得response，所以我的处理办法是通过
轮询，控制合理的时间，当用户刚刚入队，后台的程序肯定就已经在处理了，这个时候队列中的用户几乎都是成功的用户，所以通过请求DB（命中率几乎是100%）来判断是否成功。

这是之后看到的一篇文章，里面说到了一些我没有考虑到的点
互联网秒杀业务设计

今天关于《分析并总结秒杀场景》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！