限流、防刷

这个没啥用

假设一台机器的极限tps是400，那我们限流到300tps，如果这300tps全部是去请求createOrder这个方法，那么这个时候我们如果不用队列泄洪，那么在这1秒内需要处理300个请求，便是有300个线程，导致cpu将会在这个300线程中来回切换，使cpu的消耗加大，所以为了更好的处理300个线程，减小cpu的切换时间开销，减小cpu处理者300个请求的时间，所以我们引入队列泄洪，减少cpu在线程间切换的时间，从而提高相应速度。

我们如果不使用队列泄洪，其实系统应该也可以解决，但是响应时间会增加。但是我们如果只使用队列泄洪，就只考虑createOrder这个接口应该也是可以解决的，但是有可能，会导致这个order类的tps过大，导致系统处理不过来。

所以，限流应该和队列泄洪是相辅相成的，只用限流可以解决流量过大的问题，但是可能会导致并发量过大，增加cpu的处理时间，所以引入队列泄洪来减少cpu处理300个请求的时间。

 tps ：  每秒处理的请求数

限流方案：

令牌桶（常用）

客户端获取令牌

定时器每秒放置固定数量令牌

限制网络流量最大值，可以有突发流量。能瞬间获取到令牌最大值。

 

漏桶

客户端 加一滴水  水能滴入桶里成功，则可以执行。没办法应对突发流量。还是每秒1次。

平滑网络流量。

 

限流力度

接口维度限流

 

总维度限流

 

限流范围

集群限流

依赖redis做计数器，会有性能瓶颈

单机限流

单机限流效果好

 

单机限流实现：单机令牌桶

guava rateLimiter 

 将时间规划到一个数组内

 

防刷

限制同一IP同一秒的请求：数量不好控制，容易误伤，不常用。

 

黄牛可以修改硬件设备信息，通过模拟器。

设备牧场作弊

人工作弊，佣金刷单。更难防。

 

设置指纹

采集终端设备各项参数，启动应用时生成唯一指纹。

根据对应设备指纹的参数猜测出模拟器等可以设备的概率。

凭证系统

 

sentinel 限流

插槽链式调用，滑动窗口 有interval 总长度和samplecount插在数目 两个重要参数

nginx

里用漏桶限流

// 接口的资源名称不要和接口路径一致，会导致限流后走不到降级方法中
@SentinelResource(value = "confirmOrderDo", blockHandler = "doConfirmBlock")