秒杀----问题点及解决方案

 目录

客户视角要注意

商品列表和详情----静态页面+缓存+第三方云加速

重复点击

恶意防刷----图形验证码

查询秒杀结果：

程序员视角

秒杀控制----库存token放redis

限流----Google工具类RateLimter

接口的熔断降级，主要是对接口进行保护

订单和用户关系的存储----消息中间件MQ

秒杀成功，修改DB库存----MQ异步修改库存

Q1:  若单台服务器能接受的最大并发请求为5000万，同一时刻有7000万的请求访问进来打到服务上，服务器抗不住会怎样，怎么办？

答：支付宝【双十一】的QPS是百万级，你举的例子并发太大；

       nginx支持数以“百万级”别的TCP连接，高达 5万 个并发响应，够用；

       若真有这么大的并发，你限流一下；

https://blog.csdn.net/jovisoft/article/details/118213957   这个很理论

客户视角要注意

• 商品列表和详情----静态页面+缓存+第三方云加速

做成静态页面，

商品列表缓存：使用redis缓存，有分页的缓存个1-3页就OK了，一般用户也就点个几页就不点了；

详情页缓存：1、使用nginx对页面进行缓存配置；2、直接利用浏览器端缓存；

此外：可将静态资源放到第三方云服务中进行CDN加速，减轻秒杀时的带宽压力，比如阿里云、七牛云等等

• 重复点击

点击秒杀按钮后，记得将按钮禁用。 主要是为了防止重复点击提交；

• 恶意防刷----图形验证码

使用验证码恶意防刷，你几乎每次在最后一秒点击的时候都会弹出比较复杂的图形验证码，感官上好像是耽误了你一两秒的时间，实际上这种简单的方式不仅分散了流量，而且防止有恶意刷秒杀接口的行为，十分好用。

• 查询秒杀结果：

在前端通过一个定时器不断轮询服务端接口，查询秒杀结果最终返回是成功或失败；

程序员视角

• 秒杀控制----库存token放redis

       Redis 的性能非常高，号称单机 QPS 能抗 10W 的并发；

       Redis官方压测每秒10万每秒，如果线上Redis集群规模是128片，在流量均匀的场景，每次请求我们按3次Redis交互，那么能抗的量为128*10/3=426W

       所以用redis抗秒杀的QPS；

将和库存数量一致的token令牌放入redis(这个放令牌的操作是在后台完成的)，每一个令牌都承接一个秒杀请求，请求获取到令牌就返回秒杀成功，没获取到就返回秒杀失败，这样就防止大量请求来访问接口并且对数据库进行操作，很大程度上提高了性能和接口响应速度；

• 限流----Google工具类RateLimter

网关一般在微服务中用来做认证鉴权以及限流操作，限流算法有很多，比如redis限流、nginx、hystrix等等，实际工作中使用最多的还是令牌桶算法，可以基于这个算法自己写一个注解，也可以使用Google工具类已经实现的RateLimter，两三行就能实现效果

• 接口的熔断降级，主要是对接口进行保护

• 订单和用户关系的存储----消息中间件MQ

• 秒杀成功，修改DB库存----MQ异步修改库存