spring-cloud-sentinel ---流控算法---review

计数器算法

• 计数器算法，限定每个固定时间能处理的请求总数，例如1分钟100，如果在第一个一分钟，总共请求60次，接着第二个一分钟，counter又会从0 开始技术，如果在1.5分钟的时候，达到了100个，那么后面半分钟的请求将会被拒绝。
• 这种固定时间窗口的限流算法可以用在短信发送频次限制上，例如，一个用户一分钟只能收到n次短信

• 计数器算法存在的问题，如果在第一分钟的0:58 ～ 第二分钟的1:02 这个时间段内，分别出现了100 次请求，安计数器逻辑里说是都能通过的，但是这一分钟内的总请求量是超过了100 的。
  

滑动窗口

• 滑动窗口算法是一种流量控制技术，在TCP网络通信协议中，采用了 滑动窗口解决网络拥塞的情况。
• 做法是，在固定窗口中分割出多个小窗口，分别在每一个小时间窗口中记录访问次数，然后根据时间将窗口向前滑动，并且删除过期的小时间窗口。最终我们自需要统计滑动窗口范围内的所有小的时间窗口计数即可。
• 如下图，将一个时间窗口分为4个小的窗口，每个小时间窗口分配25个请求量。并且通过虚线框来作为滑动窗口的大小，同时滑动窗口随着时间前移动，比如前面15s结束后，窗口滑动到15~45 这个区间，让后在新的窗口中需要重新统计数据，这种方式很好的解决了固定窗口算法的临界值问题。

令牌桶算法

• 令牌桶是对网络整体限制 + 速率限制的一个常用算法，对于每一个请求，都需要从令牌桶中获取一个令牌，如果没有获得令牌，则需要出发限流策略

• 下图是令牌桶案例，系统已一定速率（r token/sec）往固定容量的令牌桶中放入令牌，如果此时有客户端请求过来，则需要从令牌桶中拿到令牌以获得访问资格。
  

• 假设令牌生成速度是10 个/秒，也就等于QPS = 10 ，此时请求获取令牌的时候，存在三种情况：

  • 请求速度大于令牌生成速度：持续一段时间桶中令牌消耗完，后续请求在进来会被限流
  • 请求速度等于令牌生成速度：此时正好可以平稳运行
  • 请求速度小于令牌生成速度：此时说明系统高并发不高，请求能被正常处理。

• 令牌桶算法中，有两个关键值，桶容量，令牌添加速率，两个值都必须低于系统能承载的最大QPS，

  • 例如系统能承载的最大QPS是1000 QPS，当桶中是满的，此时突然有2000请求过来，也只能在一瞬间得到1000 的令牌数量，另外的1000 需要排队等待令牌的添加，也就是等到下一秒添加的1000令牌，这样就将2000 请求平均到了2秒内正好符合系统要求。

漏桶限流算法

• 漏桶算法主要作用是控制数据注入网络的速度，平滑网络上的突发流量。
• 漏桶算法如下图，在漏桶算法内容也需要维护一个容器，他会以很定的速率出水，不管添加水流的速度多快，漏桶流出的速度都是保持不变的，实际上消息中间件就使用了漏桶限流孙风，不管生产者请求量多大，消息的处理能力取决于消费者。

• 漏桶算法存在以下几种情况：
  • 请求速度大于漏桶流水速度：也就是请求数超过服务端处理能力，将会触发限流策略
  • 请求速度小于或者等于流水速度，也就是服务器处理能力正好满足客户的的请求量，将正常执行。
• 漏桶和令牌桶原理差不多，最大区别是漏桶无法处理短时间内的突发流量，漏桶限留算法是一种恒定速度的限流算法。