秒杀场景总结

业务介绍

商品在规定时间内进行有限（较少）库存的秒杀行为并排名，秒杀成功后根据排名计算价格
同时可以继续对排名价格砍价。运营人员通过后台设置秒杀人数（即库存量），以及排名递增价格和砍价方案

跌跌撞撞

• sql处理
  最开始的方法是直连DB，秒杀与砍价都通过sql处理并进行运算，用ab测试之后发现
  一旦有并发请求，很容易出现数据重叠，排名不准确的情况，不可取换之

• 索引控制
  出现上面的情况之后我在每人相对于每件商品同一个价格不能重复业务基础上使用了唯一索引，这样可以保障数据。
  测试之后发现，确实数据的准确是有了一定的保障，但是在同一个时间下的多次请求，成功写入的概率不超过30%，貌似太低了。不可取再换之

如何解决

快速响应

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

降低DB压力

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

A	B
判断库存大于0	判断库存大于0
抢购商品	抢购商品
库存减一	库存减一

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

依靠策略

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

phpif(rand(1,99) < 90){
    return false
}

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

数据可靠

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

关于前端

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

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