Dubbo生态之sentinel限流

1. 限流算法

我们知道，在分布式架构中，当服务请求量过大时，容易对服务器造成不可预知的压力，因此，我们在客户端请求的时候，进行限流，起到一个保护的作用

常见的限流算法有: 计数器限流，滑动窗口限流、漏桶限流、令牌桶限流算法

1.1 计数器限流

计数器算法是限流算法里最简单也是最容易实现的一种算法。比如我们规定，对于A接口来说，我们1分钟的访问次数不能超过100个。那么我们可以这么做：在一开 始的时候，我们可以设置一个计数器counter，每当一个请求过来的时候，counter就加1，如果counter的值大于100并且该请求与第一个请求的间隔时间还在1分钟之内，那么说明请求数过多；如果该请求与第 一个请求的间隔时间大于1分钟，且counter的值还在限流范围内，那么就重 置 counter

具体算法的示意图如下:

 

 假设有一个恶意用户，他在0：59时，瞬间发送了100个请求，并且1：00又瞬间发送了100个请求，这种情况，其实是符合我们上述规则的。因为在0:00-0:59这个区间用户确实没有超过我们设置的100这个最大范围

临界值问题，如下图:

 因此，滑动窗口限流就对这个问题进行了改进

1.2 滑动窗口限流

发送和接受方都会维护一个数据帧的序列，这个序列被称作窗口。发送方的窗口大小由接受方确定，目的在于控制发送速度，以免接受方的缓存不够大，而导致溢出，同时控制流量也可以避免网络拥塞。下面图中的4,5,6号数据帧已经被发送出去，但是未收到关联的ACK，7,8,9帧则是等待发送。可以看出发送端的窗口大小为6，这是由接受端告知的。此时如果发送端收到4号ACK，则窗口的左边缘向右收缩，窗口的右边缘则向右扩展，此时窗口就向

前“滑动了”，即数据帧10也可以被发送

 

 滑动窗口演示地址:Selective Repeat Protocol (pearsoncmg.com)

1.3 漏桶限流

漏桶算法思路是，不断的往桶里面注水，无论注水的速度是大还是小，水都是按固定的速率往外漏水；如果桶满了，水会溢出；

 桶本身具有一个恒定的速率往下漏水，而上方时快时慢的会有水进入桶内。

当桶还未满时，上方的水可以加入。一旦水满，上方的水就无法加入。桶满

正是算法中的一个关键的触发条件（即流量异常判断成立的条件）。

 在桶满水之后，常见的有两种处理方式为:

• 暂时拦截住上方水的向下流动，等待桶中的一部分水漏走后，再放行上方水。
• 溢出的上方水直接抛弃

特点:

• 漏水的速率是固定的
• 即使存在注水burst(突然注水量变大)的情况，漏水的速度也是固定的

1.4 令牌桶限流

令牌桶算法是网络流量整形（Traffic Shaping）和速率限制（Rate Limiting）中最常使用的一种算法。典型情况下，令牌桶算法用来控制发送到网络上的数据的数目，并允许突发数据的发送。

令牌桶是一个存放固定容量令牌（token）的桶，按照固定速率往桶里添加令牌; 令牌桶算法实际上由三部分组成：两个流和一个桶，分别是令牌流、数据流和令牌桶

• 令牌流与令牌桶 

系统会以一定的速度生成令牌，并将其放置到令牌桶中，可以将令牌桶想象成一个缓冲区（可以用队列这种数据结构来实现），当缓冲区填满的时候，新生成的令牌会被扔掉。这里有两个变量很重要:

第一个是生成令牌的速度，一般称为 rate 。比如，我们设定 rate = 2 ，即每秒钟生成 2 个令牌，也就是每 1/2 秒生成一个令牌；

第二个是令牌桶的大小，一般称为 burst 。比如，我们设定 burst = 10 ，即令牌桶