但有些高手，并不会像我们一样老老实实，通过秒杀页面点击秒杀按钮，抢购商品。他们可能在自己的服务器上，模拟正常用户登录系统，跳过秒杀页面，直接调用秒杀接口。
如果是我们手动操作，一般情况下，一秒钟只能点击一次秒杀按钮。
但是如果是服务器，一秒钟可以请求成上千接口。
这种差距实在太明显了，如果不做任何限制，绝大部分商品可能是被机器抢到，而非正常的用户，有点不太公平。
所以，我们有必要识别这些非法请求，做一些限制。那么，我们该如何现在这些非法请求呢？
目前有两种常用的限流方式：
1. 基于nginx限流
2. 基于redis限流
9.1 对同一用户限流为了防止某个用户，请求接口次数过于频繁，可以只针对该用户做限制。
限制同一个用户id，比如每分钟只能请求5次接口。
9.2 对同一ip限流有时候只对某个用户限流是不够的，有些高手可以模拟多个用户请求，这种nginx就没法识别了。
这时需要加同一ip限流功能。
限制同一个ip，比如每分钟只能请求5次接口。
但这种限流方式可能会有误杀的情况，比如同一个公司或网吧的出口ip是相同的，如果里面有多个正常用户同时发起请求，有些用户可能会被限制住。
9.3 对接口限流别以为限制了用户和ip就万事大吉，有些高手甚至可以使用代理，每次都请求都换一个ip。
这时可以限制请求的接口总次数。
在高并发场景下，这种限制对于系统的稳定性是非常有必要的。但可能由于有些非法请求次数太多，达到了该接口的请求上限，而影响其他的正常用户访问该接口。看起来有点得不偿失。
9.4 加验证码相对于上面三种方式，加验证码的方式可能更精准一些，同样能限制用户的访问频次，但好处是不会存在误杀的情况。
通常情况下，用户在请求之前，需要先输入验证码。用户发起请求之后，服务端会去校验该验证码是否正确。只有正确才允许进行下一步操作，否则直接返回，并且提示验证码错误。
此外，验证码一般是一次性的，同一个验证码只允许使用一次，不允许重复使用。
普通验证码，由于生成的数字或者图案比较简单，可能会被破解。优点是生成速度比较快，缺点是有安全隐患。