sentinel自适应限流算法问题探讨

[chenquanzhen]

Issue Description

Type: feature request

sentinel中的自适应限流采用的是BBR算法，蚂蚁Mosn，淘宝的noah都有自适应限流产品，有以下几个问题，盼解答

1. 蚂蚁Mosn 介绍也是在sentinel基础上实现了自适应限流，Mosn用的也是BBR算法吗？有什么改进吗？
2. 淘宝noah采用了PID算法，这和sentinel BBR算法有没什么场景上侧重或者说二者优缺点是什么？
3. 自适应限流有没什么实践上的建议？
4. 后续sentinel会支持更多的自适应限流算法吗？

[ansiz]

Issue Description

Type: feature request

sentinel中的自适应限流采用的是BBR算法，蚂蚁Mosn，淘宝的noah都有自适应限流产品，有以下几个问题，盼解答

1. 蚂蚁Mosn 介绍也是在sentinel基础上实现了自适应限流，Mosn用的也是BBR算法吗？有什么改进吗？
2. 淘宝noah采用了PID算法，这和sentinel BBR算法有没什么场景上侧重或者说二者优缺点是什么？
3. 自适应限流有没什么实践上的建议？
4. 后续sentinel会支持更多的自适应限流算法吗？

我来解答一下 MOSN 这块的自适应限流算法和 Sentinel 的区别吧，MOSN 这边没有采用 BBR 的算法，但其根本原理差不多，都是基于排队论控制并发量，Sentinel 采用了 BBR 的方式，而 MOSN 则是采用按比例逐步调节，更像是一种 PID 算法。

MOSN 的改进之处在于会记录每个资源点一分钟的 Histogram 数据，当满足自适应限流的条件时，逐个接口比对当前的并发量和历史数据，判断是否有明显的异常，对于没有异常和本身并发量较小的资源点不会进行自适应限流。通过这种方式尽量减少杀伤范围。除此之外 MOSN 还加入了压测流量直接熔断的特性，当触发自适应限流时，会直接阻断所有的压测流量腾挪资源给线上流量。

[chenquanzhen]

@ansiz > MOSN 这边没有采用 BBR 的算法，但其根本原理差不多，都是基于排队论控制并发量，Sentinel 采用了 BBR 的方式，而 MOSN 则是采用按比例逐步调节

关于MOSN的自适应流控，有如下几个问题，盼解答 1、MOSN没有直接采用BBR算法的原因是？是实践中遇到什么问题吗? 2、MOSN 控制算法（采用按比例逐步调节//是指以一个固定的比例，减少当前的并发数？），这块的控制算法能介绍一下吗？

[ansiz]

@ansiz > MOSN 这边没有采用 BBR 的算法，但其根本原理差不多，都是基于排队论控制并发量，Sentinel 采用了 BBR 的方式，而 MOSN 则是采用按比例逐步调节

关于MOSN的自适应流控，有如下几个问题，盼解答 1、MOSN没有直接采用BBR算法的原因是？是实践中遇到什么问题吗? 2、MOSN 控制算法（采用按比例逐步调节//是指以一个固定的比例，减少当前的并发数？），这块的控制算法能介绍一下吗？

---

之所以没有采用跟Sentinel一样的策略有以下原因：

1. BBR 算法严格来说是需要采样理想情况下的 RT，但这在实际情况下是比较难准确采样的，因为高负载的情况下 RT 已经出现了失真，并且随着限流的调节这个 RT 还会出现一定程度的波动
2. 跟业务解释起来比较费劲
3. 业务有更精细化的诉求，希望能够按接口识别是否需要限流

关于控制算法： 我们是以触发限流时的并发量作为基线往下调整，按固定比例来减少并发量，秒级调整

[chenquanzhen]

我们是以触发限流时的并发量作为基线往下调整，按固定比例来减少并发量，秒级调整

@ansiz 谢谢回答，还有点问题: 1、这里能进行秒级调整，是根据秒级的cpu使用率情况去调整接口的并发量？ 2、做自适应限流的时候看着都是在服务端进行限流，那么在下游负载高时对上游客户端进行限流是否可行？ 有什么弊端吗？

[ansiz]

我们是以触发限流时的并发量作为基线往下调整，按固定比例来减少并发量，秒级调整

@ansiz 谢谢回答，还有点问题: 1、这里能进行秒级调整，是根据秒级的cpu使用率情况去调整接口的并发量？ 2、做自适应限流的时候看着都是在服务端进行限流，那么在下游负载高时对上游客户端进行限流是否可行？ 有什么弊端吗？

1. 这个我们目前支持三种模式，按并发量、CPU、Load1，实际使用中并发量用得最多
2. 你是指在客户端对出口流量做熔断处理吗？是可行的，但是一般而言业务不太能理解和接受，除非能够明确出该服务调用是弱依赖。

[dozer47528]

@ansiz

请教一个问题，如果基于 BBR 算法，为什么 sentinel 内部没有实现排空过程？

如果不实现排空逻辑，在 QPS 不变的时候，响应增加，最后也会允许更多的并发过来。但此时并不是最高效的。

我猜测有2个原因：

1. Java Server 的线程模型在服务端吞吐达到上限的，并发增加，QPS 也会下来（多线程的损耗）。所以不实现排空也可以感知到当前并发能力达到了上限。
2. 如果要实现排空，那必须让到来的请求等待一会儿，而这个在 Java Server 的线程模型中实现起来会比较困难，也会影响服务端的性能，最终效果会不好。

所以想请教一下，你们没实现排空具体的原因是什么？有做过相关的调研和测试吗？

[ansiz]

@dozer47528 我这边是 MOSN 限流的同学，Sentinel内部的实现请 @sczyh30 帮忙解答一下

[yejialiango]

Issue Description

Type: feature request sentinel中的自适应限流采用的是BBR算法，蚂蚁Mosn，淘宝的noah都有自适应限流产品，有以下几个问题，盼解答

1. 蚂蚁Mosn 介绍也是在sentinel基础上实现了自适应限流，Mosn用的也是BBR算法吗？有什么改进吗？
2. 淘宝noah采用了PID算法，这和sentinel BBR算法有没什么场景上侧重或者说二者优缺点是什么？
3. 自适应限流有没什么实践上的建议？
4. 后续sentinel会支持更多的自适应限流算法吗？

我来解答一下 MOSN 这块的自适应限流算法和 Sentinel 的区别吧，MOSN 这边没有采用 BBR 的算法，但其根本原理差不多，都是基于排队论控制并发量，Sentinel 采用了 BBR 的方式，而 MOSN 则是采用按比例逐步调节，更像是一种 PID 算法。

MOSN 的改进之处在于会记录每个资源点一分钟的 Histogram 数据，当满足自适应限流的条件时，逐个接口比对当前的并发量和历史数据，判断是否有明显的异常，对于没有异常和本身并发量较小的资源点不会进行自适应限流。通过这种方式尽量减少杀伤范围。除此之外 MOSN 还加入了压测流量直接熔断的特性，当触发自适应限流时，会直接阻断所有的压测流量腾挪资源给线上流量。

老哥你好，借个楼，mosn有提供默认的自适应限流方式吗？我看了下代码，只看到了在pkg/filter/stream/flowcontrol中提供了扩展，限流的SlotChain需要自己实现的吧？这里讨论的mosn自适应限流方式具体是哪块代码

[ansiz]

@yejialiango 是扩展的SlotChain实现的，不过这部分代码一直没精力提到社区来，所以你目前没看到，我这边只分享了大致的实现思路

[yejialiango]

了解了，多谢老哥解答