高并发场景-秒杀问题简答

秒杀痛点：

1、瞬时并发量的增大

        大量用户同一时间进入

        网站瞬时访问量激增

2、库存不足

        访问请求数量远大于库存量

        只允许部分用户秒杀成功

思路

访问层——页面展示

秒杀页面如果动态展示，会给服务器无形中造成压力：

将页面静态化，降低开销

访问层——增加按钮设计

秒杀开始前，禁用按钮变灰，检查不必要的访问请求，

秒杀开始后，点击一次后禁用按钮，防止重复提交，

秒杀按钮点击后，增加滑动验证码，减少提交压力，防止人为破坏公平性，

完成秒杀后，增加用户排队体验，加入倒计时展示，防止用户不明所以刷新页面重复点击，增加服务器压力。

中间转发层

多级负载均衡——限流——自动伸缩

访问层后进入到中间转发层，单台大致可以处理两三万时，超过就需要采用Nginx集群搭建了（同时上层可以采用硬件级别的负载均衡搭建，如：F5/LVS），然后通过Nginx负载均衡到网关之后，采用客户端的负载均衡器Rabbin负载分发，经过如上，大致可以处理十万QPS并发量，这时就可以参考如上设计不同的QPS了，通常结果docker/k8s进行云服务器部署，动态伸缩扩容节点数量，因为秒杀的场景不是实时的，有效利用服务器资源。另外还需要做限流，除了正常用户外，访问还会掺杂（爬虫/羊毛党/恶意攻击等）需要在网关层使用Sentinel对不同的服务节点设置限流熔断机制，也可以网关层通过MQ进行削峰填谷，来减轻下游的压力，防止激增的访问，对数据库造成可预见性的压力。

服务层——redis缓存

来到服务端，不允许直接访问数据库的，而是采用redis进行缓存，这样减轻服务器的一个压力，可以通过定时器讲需要参与秒杀的商品预热到redis中，防止redis击穿，防止直接落到数据库，

同时通过LUA脚本操作库存，因为在用户进行秒杀下单时，分几步进行操作，第一判断库存是否大于0，当有库存时，将已有的库存进行-1处理，再替换已有的库存数量，这样保证了原子性，

还有就是防重，前面说到可以通过按钮置灰，验证码登，防止重复提交，但是一些绕过前端的恶意请求，这时，可以通过redis set NX命令，通过用户的 token+ip+url就可以保证同一时间，同一个商品只能有一个有效。

另外除了lua脚本外，还可以使用分布式锁保证请求的原子性，当请求过来后，把信息放到mq服务器，进行异步下单，从而达到削峰填谷，让请求保持一个平稳的状态，最后在数据库中进行读写分离即可，当然如果数据量很大的情况下也可以采用分库分表的手段进行操作。