-
服务端承受高并发请求,会出现响应过慢或失败等情况;
-
数据库承受高并发请求,会导致连接池耗尽和响应缓慢;
-
如果数据库更新设计的不合理,可能会出现超卖的情况;
秒杀界面CDN
=======
秒杀开始之前,用户都会请求秒杀界面,有的用户甚至会不断的刷新秒杀界面,100W用户可能产生上千万次秒杀界面请求。秒杀界面往往包含很多静态资源,如果这些界面请求全部通过服务器获取,会造成大量的带宽消耗,甚至造成秒杀还没开始服务器就崩了的情况。
对于网页这种静态资源的并发访问,业内早就有成熟的解决方案:内容分发网络(CDN)。我们可以在秒杀开始前,预先把网页的静态资源存放在CDN节点,用户在刷新界面时直接从CDN获取静态资源,从而降低刷新秒杀界面对服务器造成的压力。添加了CDN服务之后,秒杀界面有大量用户同时访问和刷新并不会给服务端带来多大压力。
秒杀按钮优化
======
我们知道,秒杀系统往往会有一个秒杀按钮,如果不对按钮限制,可能存在以下问题:
-
用户在秒杀开始前点击按钮,造成很多无用请求;
-
用户在秒杀开始后多次点击按钮,造成很多重复请求;
所以我们可以对按钮做一些限制:秒杀开始前按钮不可用,用户点击一次秒杀按钮后,按钮也进入不可用状态。这种方式无法限制通过脚本请求后端的情况,但是可以限制正常用户的多次无效点击,大大降低请求量。
秒杀链接优化
======
普通情况下,用户在点击秒杀按钮的时候,前端会请求一个固定的URL,这个URL可以在前端界面查到。对于普通不懂技术的用户来说,这没有什么问题,如果用户稍微懂点Http协议,就可以在秒杀开始前拿到URL,在秒杀开始前或开始的毫秒级时间内请求秒杀链接,不仅会给服务端带来很大的压力,还会造成不公平现象:商品都被开脚本的人抢走了。
为了避免这种现象,我们可以将URL动态化,即使秒杀系统的开发人员也无法在知晓在秒杀开始时的URL。具体实现方法是在获取秒杀URL的接口中,返回一个服务器端生成的随机数,并在下单URL中传递该参数完成下单。
《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》无偿开源 威信搜索公众号【编程进阶路】
秒杀验证码
=====
虽然说我上面通过动态URL避免了用户在秒杀开始前请求秒杀链接,但是用户还是可以通过脚本在秒杀开始的那一刻去请求秒杀连接,普通用户基本没有办法和脚本秒杀进行竞争。
我们可以引入机器难以识别的验证码,用户在请求秒杀链接之前,需要填写验证码识别的结果,验证码错误的请求直接拒绝。使用验证码不仅可以增加脚本秒杀的难度,还可以降低请求的QPS,因为请求不再是在秒杀那一刻进来,而会被分散到填写验证码的时间段内。
过滤请求
====
通过上面的步骤,我们可以减少很多重复请求和脚本请求,可以保证秒杀活动中一个人大致只会请求一次(脚本还是可以请求多次)。但是100W人参与秒杀,每人请求一次秒杀链接也有将近100W次请求,服务器还是扛不住。
仔细分析之后可以发现,秒杀的商品只有100个,最后成功的也只有100个,那么我们100W的请求是不是都有必要请求到秒杀服务器上呢?显而易见,我们没有必要把所有请求都打到秒杀服务器上,我们只需要保证有大于100个请求打到秒杀服务器就可以保证秒杀的正常进行,所以我们可以在用户端和服务端添加一层过滤层,过滤层只要保证有100个以上的请求能打到秒杀服务器端。
我们可以使用Nginx服务器来构建过滤层,一个Nginx服务器也没法抗100W的请求,我们假设每个Nginx服务器可以处理10W的请求,那么我们就需要10台Nginx。那么怎么用保证至少有100个请求可以请求到后端呢?我们可以简单的让每个Nginx服务器只通过前100个请求,后续请求直接返回降级界面。通过Nginx过滤,我们可以把100W的请求过滤为1000个请求,大大减少了服务器端的压力。