说道限流，首先得明白为什么要限流，如果不限流会有什么影响，为什么会产生这种影响，我们先围绕这几个问题来说说。
为什么要限流 ?
一台服务器的资源是有限的，无论是CPU还是内存还是IO，在一定的阈值下资源的能效比是逐渐上升得，也就是说资源利用率上升得同时产生的效益也是逐渐上升得，直观的体现就是吞吐量提升。但超过一定阈值后，能效比会迅速下降，也就是资源用的更多，但是吞吐量反而急剧下降。同时应用内如果某个服务占据的资源过多甚至某个调用方过多调用会影响其他服务的正常运行。所以无论是对应用的整体流量，还是应用内不同服务的流量，还是针对下游的调用方，都应该做限流。
如果不限流会有什么问题 ?
如果不限流，调用方的请求疯狂涌入可能会有如下问题：
- 会导致应用的响应时间越来越长
- 可能会导致进程负载飙高，同时还有CPU使用率急剧飙升
- 可能会应用的使用内存持续在高位，同时会有频繁的Full GC，最后甚至OOM
为什么会产生这种问题 ?
- 过多的线程过多的请求，CPU来不及处理，负载飙升
- 如果未对线程数做限制，或者线程池的MaxSize太高，那么疯狂的流量会瞬间将线程数彪到上限，每个线程都会在jvm堆内分配一小块空间以存储线程相关的数据，少则64K，大则1M，过多的线程首先会占用大量内存空间，导致更频繁的GC，降低吞吐量。其次CPU的运算资源是在多个线程间以时间片的形式流转的，当从一个线程切换到另一个线程时，需要先暂存上一个线程的上下文，然后加载当前线程的上下文，这些都会耗费CPU资源，过多的线程会导致这种切换变得非常频繁，将CPU资源大量的耗费在线程切换上，会进一步恶化应用的健康度。Linux下可以通过查看系统的
nvcswch，表示每秒非自愿上下文切换（non voluntary context switches）的次数这个指标来查看是否是线程数过多问题。非自愿上下文切换, 也就是上下文切换不是由IO中断等事件主动切换的线程场景。 - 过多的请求到来，没有及时的处理(相应或者快速失败)，而是用请求队列的形式缓存，每个请求都会耗费一定的内存资源，过长的请求缓冲队列会导致内存被大量占满，会更容易发生full gc，而gc也同样是一个高耗能的操作，并且是大量数据都难以回收的情况下，应用的处理能力会更进一步降低，最后可能会导致OOM。
限流可以怎么限？
- 线程池：限流最典型的方式就是线程池了，比如tomcat线程池，mysql连接池，rpc线程池，甚至是应用内的自定义线程池。定义线程池，限制线程上限，限制应用缓冲的请求数，指定超限的请求处理方式。线程池的参数要怎么设置，这是一个需要需要结合服务器资源和业务场景计算的。比如应用时一个CPU密集型的，那么线程数和CPU核心数量差不多是合适的；如果应用时一个IO密集型的，那么线程池数有两种考量。1：如果应用定义了对外提供服务的QPS上限，那么通过服务调用的IO等待和CPU使用时间的比例，计算需要的线程上限，一般这个数目会低于实际的CPU核心数目，如果不够那么用更好的服务器。2：如果未指定对外提供的QPS上限，根据服务的IO和CPU的时间比例与提供服务的物理线程数之积计算出线程池的线程池数上限。
- 服务线程：一个应用内服务之间有轻重之分，有些服务需要优先保障可用性和迅速响应，有些服务不是关键性的服务，比如当电商大促时会对一些非必要服务做降级或者关闭。可以用线程池隔离的形式对内部服务的调用做资源隔离，但这也容易导致同步的调用变异步，或者额外增加线程数，增加资源耗费。可以使用Sentinel的线程隔离，限制服务在同一时间使用的线程池数，还是比较方便的。
- 调用QPS：一根据的限流算法之漏铜桶算法，每秒生成固定个数的令牌，服务调用方拿到令牌可通过，拿不到被阻塞或者快速失败。QPS限制可以在应用的统一入口，限制所有服务的总和调用QPS；也可以对特定服务做QPS限制。使用Sentinel能很方便的做QPS限流。
- 调用方(调用参数)：售卖性的服务都会限制买方的调用QPS，不同套餐QPS上下限不同，实质就是对请求中某个参数的做了识别，限制套餐参数在不同值下的QPS，甚至也可以限制不同参数可以使用的线程数。或者一些热点参数，比如大促时的热门商品，通过对热门商品做标识，识别不同标识来限制热点参数的QPS也是一个常见的策略。
- 系统参数：实时监控系统的参数指标，比如当负载达到一定程度，或者内存使用率到了某个阈值，或者CPU使用率飙升时，触发限流。
- 集群限流：集群限流和单机限流有些不同，实时性的集群限流需要有一个流控的Server，响应流控Client的调控请求，实时统计集群服务的QPS，调用线程数，然后对调控请求做通过与否的响应。