服务限流 #

限流类型 #

目前平台包含两种类型的限流：分布式限流、自适应限流。

在治理中心概览或平台概览中，我们可以看到平台的资源预警事件，通过点击具体的事件数字，我们可以查看服务或平台的资源预警列表。其展现形式如下：

目前包含两种限流类型：分布式限流和自适应限流。

Tips
为了服务和系统的稳定，默认会给所有服务开启自适应限流。

系统默认给服务开启自适应限流。

通过“添加限流规则”或“编辑”按钮，我们可以对分布式限流规则进行配置：

其中各参数解释如下

参数	说明
服务识别号	需要配置分布式限流的服务识别号信息
周期内限流次数	该参数和“限流周期”配合使用，指定限流周期内达到访问次数，即满足限流条件
限流周期	该参数和“周期内限流次数”配合使用，指定限流周期内达到访问次数，即满足限流条件
是否开启针对单个API限流	针对单个 API 限流时，需要配置具体的 path
规则是否打开	是否开启自适应限流

codel （ Controlled Delay）是⼀种⽤于过载检测的“受控延迟”算法，提供了⼀种在过载时释放负载的机制。即使在下⾏速率动态变化的情况下，它也可以优化延迟，同时保持较⾼的吞吐量。

codel 通过在请求等待时间较⻓时预先减少⼀些负载，从⽽即使在严重过载时也可以保持较低的等待时间。在负载突发时，系统不能及时处理所有的请求，使⽤codel可以主动丢弃排队时间久的请求，从⽽可以减少处理队列中条⽬在队列中的等待时间。

在10秒内模拟1000条请求/秒的传⼊，服务以500条请求/秒速率运⾏，并发量设置在10时，这是使⽤队列和使⽤ codel 的相应吞吐量和延迟。可以看出在服务吞吐量基本持平情况下， codel 对于请求延时有较好程度的改进。

CoDel是tcp拥塞控制的算法之⼀，它的运⾏仅仅需要两个参数，即target和interval：

target：理想情况下，数据包的最⻓排队延时。

interval：在触发CoDel开始丢包前，持续的数据包排队时间超过target的最⻓忍耐时间。

CoDel算法并没有严格限制数据包在队列⾥⾯待的时间，即排队延时不超过target。⽽是给予了⼀个interval时间段

的窗⼝，CoDel完全没有使⽤队列⻓度区间阈值或者排队时间区间阈值。⽽是限制了⼀个理想的排队延时，同时给

了⼀个排队延时万⼀超过理想排队延时后的良性收敛机会，只要在给定的机会内收敛了流量，便不会触发CoDel丢

弃请求，如果流量依旧不收敛，那么CoDel算法将会对队列⾥⾯的数据包所属的流量进⾏越来越严厉的惩罚（丢

包）促使系统回归到正常处理速率！

本段描述，已经有了BBR是否还需要CoDel

队列的缓冲⼤⼩和处理速率之间不匹配是导致缓冲膨胀的本质。它会产⽣较⼤的延迟，但不会提⾼吞吐量。CoDel

不是通过队列⼤⼩⽽是通过服务处理性能来进⾏限制的。

BBR采集了时间窗⼝(⽤于⽼化数据样本)的历史中最⼤带宽，以及最⼩的RTT，并且在另⼀个时间窗⼝内“坚持使⽤

该最⼩RTT”，这就意味着在⼀个时间窗⼝内，BBR估算的BDP是不变的，BBR由于采集到了真实的带宽和RTT数据

并基于此数据调节发送速率，这便不再需要盲⽬探测的过程了。BBR采集到的最⼩RTT便是不排队的RTT。因此在

系统正常处理所有请求情况下，队列缓存不会被使⽤，CoDel算法也⼏乎不会触发丢包。

当流量持续增加，BBR会根据硬件使⽤及最⼩的RTT预估系统所能处理的最⼤流量值，作为缓冲队列的⻓度，对请

求进⾏缓冲，当请求到来时，超过缓冲队列的⻓度时，请求就会被丢弃。我们以⼀张图来表示这个过程：

第⼀类缓存是系统处理请求的真正耗时，记为时间C。.第⼆类缓存是⾃适应流量控制中认为还可以处理的流量，在

真正被处理之前会在队列中进⾏排队，排队时间记为C2。这样⼀个请求对于客户端来说，请求耗时就是

C=C1+C2。对于BBR来说，其⽬的在于计算第⼆类缓存缓存多少数据是合理的。对于CoDel来说，其⽬的在于计

算，在正常请求情况下，优先丢弃哪些流量能够在处理总流量不变情况下，丢弃的都是“⽼”流量，通过减少排队时

间C2改善单次请求时间。

另⼀⽅⾯，由于BBR基于时间窗⼝来计算，在这个时间窗⼝中，BBR需要⼀定时间来感知状态，codel对状态的感

知会更快⼀些。即使BBR跟codel联合使⽤，也会是codel先启动，流量上升幅度减慢，从⽽减缓BBR的触发时机。

CoDel旨在解决Bufferbloat，BBR也是解决了Bufferbloat，⽬标相同，侧重点不同，可以相当好的携⼿紧密配

合。

通过以下的测试数据也能看出，CoDel策略⽆论是单独使⽤还是配合BBR使⽤，都可以起到⽐较好的效果。