目录
接口防刷限流
接口防刷限流就是为了控制用户的访问次数
方式1:隐藏秒杀地址
需求:
现在的秒杀地址毫无保留的展示出来,我们需要进行一些处理
思路:
1、在前端发送一个请求,到后端生成一个uuid,然后存到redis2秒左右,然后再返回回来做秒杀方法的url路径拼接
2、把uuid拼接到秒杀方法的路径中
3、后端的秒杀方法的requestMapping用占位符{}接收前端
4、用注解@Pathvariable 获取到参数路径上的uuid,去和刚刚存在redis的uuid做判断,一致的话才可以继续执行秒杀方法的业务逻辑。
代码:
前端:
1、调用getpath方法到后端生成path
2、把path拼接到秒杀方法的url路径上
后端:
1、生成uuid做path值,同时存到redis中,后面通过传来的path和redis中的path值做比较
2、doseckill方法用占位符{}接收前端传来的path值,然后通过@Pathvariable注解获取到占位符中的值,拿来和一开始存在redis(存3秒)中的path做比较,一致才可以继续进行秒杀方法的业务逻辑。
参数传递中的占位符的理解
测试:
因为这个path在redis中只存在3秒,所以每次访问的path都是不一样的,符合期望
现在只是用uuid做演示,后期可以在生成path的方法上多添加一些其他规则
测试隐藏秒杀地址成功。
总结:
用来隐藏秒杀地址,其实就是在秒杀地址上面加点料,不要让其他人直接看到正确的方法路径,防止被人一直用脚本访问,用来防刷限流。
方式2:图形验证码
1、生成图形验证码
需求:
在点击秒杀之前,先进行验证码验证,用于缓解并发压力。
思路:
1、现在前端显示验证码格式
2、在需求1的那个getPath方法里面,生成验证码表达式,然后把验证码的结果存到redis中,再通过response把图片返回给浏览器。
3、在getPath方法判断验证码是否正确,正确才执行秒杀方法。
代码:
前端:
后端:
生成验证码的工具类
1、生成验证码
2、把验证码的正确结果存到redis中
3、通过response获取响应流对象,图片以流的形式返回给浏览器
因为前端是这样发送请求的。
测试:
结果符合期望,点击图片会自动切换验证码
2、校验验证码
需求:
点击秒杀的时候,先验证通过验证码再执行秒杀业务逻辑
思路:
点击秒杀的时候是先走getPath方法的,所以需要把用户自己输入的验证码结果一起作为参数带到后端进行判断,判断成功就执行秒杀方法。
代码:
前端:
获取用户输入的验证码结果,作为秒杀方法的参数之一传递过去。
后端:
后端就是对用户输入的验证码和redis中的正确的验证码结果进行判断,一致就验证通过,继续执行秒杀方法的业务逻辑。
测试:
测试成功,验证码正确验证