参考地址常用的限流算法 ：https://www.cnblogs.com/exceptioneye/p/4783904.html

参考地址常用的限流算法2：https://baijiahao.baidu.com/s?id=1683132526024888395&wfr=spider&for=pc

参考地址如何健壮你的后端服务？

：https://www.cnblogs.com/LBSer/p/4753112.html

### 1 Nginx前端限流

按照一定的规则如帐号、IP、系统调用逻辑等在Nginx层面做限流

### 2 业务应用系统限流

- 1、客户端限流

- 2、服务端限流

#### 2.1 漏桶算法

漏桶(Leaky Bucket)算法思路很简单,水(请求)先进入到漏桶里,漏桶以一定的速度出水(接口有响应速率),当水流入速度过大会直接溢出(访问频率超过接口响应速率),然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率.示意图如下:

可见这里有两个变量,一个是桶的大小,支持流量突发增多时可以存多少的水(burst),另一个是水桶漏洞的大小(rate)。

因为漏桶的漏出速率是固定的参数,所以,即使网络中不存在资源冲突(没有发生拥塞),漏桶算法也不能使流突发(burst)到端口速率.因此,漏桶算法对于存在突发特性的流量来说缺乏效率

#### 2.2 令牌桶算法

令牌桶算法(Token Bucket)和 Leaky Bucket 效果一样但方向相反的算法,更加容易理解.随着时间流逝,系统会按恒定1/QPS时间间隔(如果QPS=100,则间隔是10ms)往桶里加入Token(想象和漏洞漏水相反,有个水龙头在不断的加水),如果桶已经满了就不再加了.新请求来临时,会各自拿走一个Token,如果没有Token可拿了就阻塞或者拒绝服务.

令牌桶的另外一个好处是可以方便的改变速度. 一旦需要提高速率,则按需提高放入桶中的令牌的速率. 一般会定时(比如100毫秒)往桶中增加一定数量的令牌, 有些变种算法则实时的计算应该增加的令牌的数量.

#### 2.3 降级开关

- 当合法的请求量瞬间爆满，服务接口api的性能严重下降时，自动或手动打开降级开关至返回影片的正片信息，而相关片段（周边视频）就可以暂时不返回数据

- 当服务器压力减弱时，关闭降级开关在返回相关片段数据。

#### 2.4 依赖于第三方服务接口场景

- 1、设置合理的超时时间

- 如果超时就应该断掉请求连接，把业务处理的线程让给别的请求，加快处理同时也减轻了所依赖服务的压力。

- 2、合理使用重试机制

- 根据所依赖服务接口返回的信息合理的使用重试机制，如果所依赖的服务返回业务处理异常在使用重试机制也毫无意义，只会徒增所依赖服务器的压力。

- 3、异步调用服务接口

- 我们的服务接口中都会穿插着业务逻辑，如果使用httpsyncclient异步调用服务接口数据，此时处理自己的业务逻辑在结合异步返回的数据组织最终的业务数据。从而提高了服务接口处理能力。

- 4、依赖服务接口

- 如果所依赖的服务接口crash，那么自己的服务接口也无法正常提供数据。

- 根据依赖的服务接口数据的时效性，做出相应的处理策略：

- a、数据时效性不高，可以对依赖接口返回的数据做缓存处理。通过定时任务刷新缓存数据或者定义缓存数据失效时间等方式。

- b、数据时效性非常高，对于这种情况 --- 痛点。 如果您有好的处理策略请指点。

#### 2.5 控制资源使用

1 计算算法优化

- a 算法

- b 锁

- c 习惯问题 https://www.cnblogs.com/ITtangtang/p/3966467.html

- d 尽量使用线程池

- e jvm参数调优 https://www.cnblogs.com/LBSer/p/3703967.html

2 内存资源限制

a jvm参数设置

b 初始化java集合类大小

c 内存池和对象池

d 线程池队列最大长度

e 数据较大避免使用本地缓存

f 缓存数据压缩

3 网络资源限制

a 减少调用次数

b 减少传输的数据量

4 磁盘资源限制

a 只打关键日志

b 定期日志清理

### 3 数据库限流

红线区，力保数据库