限流处理大量的并发请求

限流处理大量的并发请求


第一种方法：在容器中配置最大请求数，如果大于改请求数，则客户端阻塞。该方法有效的阻止了大量的请求同时访问业务系统，但对用户不友好。



nginx连接数限流
tomcat连接数限流
过滤器连接数限流


限流目的：保护系统，限制访问次数


保护系统，如果系统处理不过来，但又有太多请求进入，如连接池，就会使得太多的线程阻塞，线程太多就会处理慢，内存消耗大，大到一定程度就会系统报错死机,或造成访问太慢交互性差.


不进行限流,会使服务进程占用太多的内存，达到系统不能再申请时，系统就会kill掉进程，引起服务崩溃

进程CPU时间占用过久也是会被系统杀掉,所以要进行限流保护系统


服务端限流(在服务中进行限流处理)
如果在服务端做限流，无论有多少个客户端，总的提供能力是固定的，所以不会因为客户端数量过多而导致资源不足，因为处理不过来的请求会被阻塞等待获取资源（阻塞等待过多会导致服务慢或服务崩溃）。

缺点
缺点也比较明显，由于服务提供者整体设置了最大限流数，此时所有的客户端共享同一份限流数据，那么有可能导致有的服务能分配到资源有些服务请求分配不到资源导致无法请求的情况(请求超时)。


客户端限流(在客户端(调用服务者)中进行限流处理)
客户端限流解决上服务端限流提到的问题，它能保证每个客户端都能得到响应。但是从其它方面考虑，必须针对不同的客户端做不同的限流策略：
请求量大，但时效性不高，此时将限流数控制小一些会比较合适
请求量大，但时效性高，此时将限流数适当调高
响应时间长，即慢接口，适当降低
主流业务，核心业务，适当调高
非主流业务，适当降低

缺点
如果客户端的数量不固定，那么有可能导致客户端数量过多造成大量请求打到服务端导致处理不了的结果，所以需要严格监控客户端的调用情况。
配置复杂，需要针对每个客户端做相对精准的判断




漏桶、令牌桶、计数器、信号量、锁


分布式限流可以通过redis、或每个服务设定来实现


限流可以通过过滤器、AOP方式实现





Hystrix(客户端限流)
在一个分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，如何能够保证在一个依赖出问题的情况下，不会导致整体服务失败，这个就是Hystrix需要做的事情。Hystrix提供了熔断、隔离、Fallback、cache、监控等功能，能够在一个、或多个依赖同时出现问题时保证系统依然可用。


服务雪崩效应是一种因 服务提供者 的不可用导致 服务调用者 的不可用,并将不可用 逐渐放大 的过程


流量控制 的具体措施包括:
网关限流
用户交互限流
关闭重试
因为Nginx的高性能, 目前一线互联网公司大量采用Nginx+Lua的网关进行流量控制, 由此而来的OpenResty也越来越热门.
用户交互限流的具体措施有: 1. 采用加载动画,提高用户的忍耐等待时间. 2. 提交按钮添加强制等待时间机制.
改进缓存模式 的措施包括:
缓存预加载
同步改为异步刷新
服务自动扩容 的措施主要有:
AWS的auto scaling
服务调用者降级服务 的措施包括:
资源隔离
对依赖服务进行分类
不可用服务的调用快速失败
资源隔离主要是对调用服务的线程池进行隔离.









https://blog.csdn.net/abc592328292/article/details/80295837(Java高并发系统的限流策略)

https://blog.csdn.net/varyall/article/details/78976655（系统限流实践 - 应用限流）

https://www.cnblogs.com/ASPNET2008/p/7712974.html（简易RPC框架-客户端限流配置）


https://segmentfault.com/a/1190000005988895(防雪崩利器：熔断器 Hystrix 的原理与使用)