在开发高并发系统时，有三把利器用来保护系统：缓存、降级和限流。缓存这个概念是大家共识的，没有什么异议，但在好些文章中我看有人会把降级和限流两个概念混淆在一起，我认为这样理解是不对的，贴下我认为正确的解释：
服务降级：
服务降级是在服务器压力陡增的情况下，利用有限资源，根据当前业务情况，关闭某些服务接口或者页面，以此释放服务器资源以保证核心任务的正常运行。
服务限流：
流量控制本质上是减小访问量，而服务处理能力不变；而服务降级本质上是降低了部分服务的处理能力，增强另一部分服务处理能力，而访问量不变。
以下主要介绍几种常见的服务限流算法和优缺点，以及单机限流和分布式限流。没有哪种算法是最好的或者是最差的，具体要根据实际业务场景决定使用哪种实现方式，本质都是提高功能的性价比，利用尽可能小的开发成本，产生尽可能大的收益。常见的限流算法包含：计数器法，滑动窗口算法，令牌桶算法以及漏桶算法（队列限流）。
计数器法
计数器法是限流算法里最简单也是最容易实现的一种算法。假设我们规定接口A的qps是100， 即每分钟的访问次数不能超过100。那么我们可以这么做：在一开始的时候，我们可以设置一个计数器counter，初始化为0， 过期时间为1秒，即1秒后计数器失效。每当一个请求过来的时候，counter值加1，判断当前counter的值是否大于100，如果大于100则说明请求数过多，直接拒绝请求。如果请求counter计数器不存在，则重置计数器，开始新的一秒的接口限流。注意并发情况下访问计数器需要加锁。
缺点：限制粒度太低，存在临界问题。
例如：假设有一个恶意用户，他在0:59时，瞬间发送了100个请求，并且1:00又瞬间发送了100个请求，那么其实这个用户在1秒内，瞬间发送了200个请求。用户通过在时间窗口的重置节点处突发请求，可以瞬间超过我们的速率限制。用户有可能通过算法的这个漏洞，瞬间压垮我们的应用。解决这个问题的办法就是提高限流的粒度，即滑动窗口算法。
滑动窗口（rolling window）
滑动窗口的概念源于计算机网络，它的限流思想描述如下：假设一个时间窗口就是一分钟。然后我们将时间窗口进行划分，比如我们将滑动窗口划成了6格，所以每格代表的是10秒钟。每过10秒钟，我们的时间窗口就会往右滑动一格。每一个格子都有自己独立的计数器counter，比如当一个请求在0:35秒的时候到达，那么0:30~0:39对应的counter就会加1。滑动窗口能够很好的解决计数器法所存在的临界问题，并且窗口划分粒度越细，窗口滑动就越平滑，控制效果越好。滑动窗口实现较复杂，临界问题只是某种极端案例，比如恶意攻击，是否采用这种限流方式，还需取决于具体业务的要求。
令牌桶法
思想描述：系统按照恒定的时间间隔（通常是1/QPS）往桶里加入Token,每个Token代表一次接口访问权限，如果桶已经满了丢弃令牌。新请求来临时，会请求从桶中拿走一个Token,如果没有Token可拿了就阻塞或者拒绝服务请求。放入Token的时间间隔取决于限制的qps，假设接口的qps是100，则按照1/qps的速率放令牌，即每10ms放入一个令牌，令牌桶算法不存在瞬间的流量高峰，它能严格控制接口在qps内访问。
漏桶算法
漏桶算法就是我们常采用的队列限流方法，通过在请求和实际的处理服务中间加一层队列，限制高并发请求对系统造成的压力，系统将按照自己的处理能力慢慢处理请求，这种限流方法的适用于接口处理实时性要求不高的业务场景，且可靠性高，漏桶算法实现也比较简单。
以上是对四种限流方式的介绍和总结，理解了限流方式，再说下我们常提到的单机限流和分布式限流。
什么是分布式限流？
首先当我们的服务是以多实例，集群形式存在的情况下才需要分布式限流。由于redis天生能够很好的支持分布式，因此分布式限流的实现redis就成了不二选择。分布式限流是基于单机限流范围的一个扩大，能够从服务集群的整体处理能力上做一个统一的流量管理，也是我们企业中常用的限流方式。
转自：https://blog.csdn.net/dd18709200301/article/details/89714390
