Sentinel限流算法：滑动时间窗算法、漏桶算法、令牌桶算法。拦截器定义资源实现原理

已于 2024-07-12 15:29:37 修改
阅读量1.3k 收藏 16
点赞数 27
分类专栏： 框架源码 深入学习总结笔记 文章标签： sentinel 算法 python
于 2024-07-12 15:26:27 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_44027353/article/details/140380440
版权

文章目录



滑动时间窗算法

基本知识

限流算法最简单的实现就是使用一个计数器法。比如对于A接口来说，我要求一分钟之内访问量不能超过100，那么我们就可以这样来实现：

  • 最开始的时候就设置一个count值，每当一个请求过来我就count++
  • 如果count的值大于了100，并且与第一个请求的时间间隔小于1分钟，那么就表示请求数过多
  • 如果该请求与第一个请求的间隔时间大于1分钟，且count的值还在限流范围内，那么就重置count。

在这里插入图片描述

/**
 * @Description: 限流算法之计数器法，伪代码的实现
 * @Author 胡尚
 * @Date: 2024/7/12 8:50
 */
public class Count {
    // 当前时间
    private Long timeStamp = System.currentTimeMillis();
    // 请求数量
    private int count = 0;
    // 时间窗口的最大请求数
    private final int limit = 100;
    // 时间窗口ms
    private final long interval = 1000 * 60;

    /**
     * 限流校验，校验是否成功
     * @return true表示允许请求，false表示校验未通过
     */
    public boolean check(){
        long now = System.currentTimeMillis();
        // 还在一分钟 时间窗口之内
        if (now <= timeStamp + interval){
            count++;
            return count <= limit;
        } else {
            timeStamp = System.currentTimeMillis();
            // 超时后重置请求数
            count = 1;
        }

        return true;
    }
}



计数法的实现有一个缺点，那就是限流的时间精度不准确。比如第一个时间窗口的前半分钟只有十个请求，后半分钟有90个请求；第二个时间窗口的前半分钟有90个请求，后半分钟只有十个请求。这种情况下，限流器是不会出现限流的，但是我在在一个时间段中的请求却有180个了。

在这里插入图片描述



为了解决计算器法统计时间精度不够的问题，进而引入了滑动时间窗

滑动时间窗算法的基本原理是维护一个固定大小的时间窗口，‌窗口内的数据被认为是当前分析的有效数据。‌随着时间的推移，‌新的数据点进入窗口，‌而旧的数据点则被移出窗口，‌从而形成了一个滑动的时间窗口。‌

在这里插入图片描述


在上图中，一个红色窗格就是一个时间窗口，我们把一个时间窗口分为了6个小格子。就拿时间窗口为一分钟举例，上面每一个小格子就是10秒；每过10秒，我们的时间窗口就会往右移动一格。每一个格子都有自己的计数器count，比如当一个请求 在0:35秒的时候到达，那么0:30~0:39对应的counter就会加1。



在具体实现上，‌滑动时间窗算法可以通过多种数据结构来实现，‌例如使用环形数组、‌哈希表等。‌例如，‌可以使用一个环形数组来存储时间窗口内的数据点，‌数组的大小等于时间窗口的大小（‌以时间单位为单位）‌。‌每当有新的数据点进入时，‌旧的对应时间点的数据将被覆盖，‌从而实现滑动时间窗的效果。‌此外，‌还可以使用哈希表来记录每个时间点上的数据变化情况，‌其中键为时间点，‌值为该时间点的数据值或变化量。‌



/**
 * @Description: 限流算法之滑动时间窗算法的伪代码实现
 * 假设每秒的请求不能超过100，我们设置一个1s的时间窗口，时间窗口中共有10个小格子，
 * 每个格子记录100ms的请求数，每100毫秒移动一次，每次移动都需要记录当前服务请求数
 * 我这里就简单实现，只有一个计数器，最新的小窗口永远存储最新访问请求总数。当然也可以每个小窗口都有自己的计数器。
 * @Author 胡尚
 * @Date: 2024/7/12 9:23
 */
public class SlidingTimeWindow {

    /**
     * 服务器访问次数，可以放在redis中实现分布式系统访问
     */
    private Long count = 0L;
    /**
     * 滑动时间窗，使用linkedList来记录滑动窗口的10个格子
     */
    private LinkedList<Long> slots = new LinkedList<>();

    public static void main(String[] args) throws InterruptedException {
        SlidingTimeWindow timeWindow = new SlidingTimeWindow();

        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    timeWindow.onCheck();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();

        // 模拟一直都有请求数，随机休眠几毫秒
        while(true){
            // TODO 限流校验
            timeWindow.count++;
            Thread.sleep(new Random().nextInt(15));
        }

    }

    private void onCheck() throws InterruptedException {
        while (true){
            // 把当前访问总数存入时间小窗口中
            slots.add(count);

            // 时间窗口的剔除操作
            if (slots.size() > 10){
                slots.removeFirst();
            }

            // 最新的时间小窗口的数和最老的时间小窗口数进行比较，是否要限流
            if (slots.peekLast() - slots.peekFirst() > 100 ){
                // TODO 限流标识
            } else{
                // TODO 解除限流标识
            }

            Thread.sleep(100);
        }
    }


}



源码算法分析

我们接下来看看Sentinel它的滑动时间窗是怎么实现的。我们从StatisticSlot类的entry()方法开始看，因为它每次都会记录请求通过/请求拒绝相关的计数

public void entry (...) throws Throwable {
    ...
        // 请求通过，我们详细看看这个方法的处理逻辑
        node.addPassRequest(count);
}

// 调用到StatisticNode类的addPassRequest()方法中
public void addPassRequest(int count) {
    // 一个记录秒级
    // 它的创建语句 ：Metric rollingCounterInSecond = new ArrayMetric(SampleCountProperty.SAMPLE_COUNT,IntervalProperty.INTERVAL);
    // 小窗口总数SampleCountProperty.SAMPLE_COUNT = 2   滑动时间窗总时间数IntervalProperty.INTERVAL=1000 这两个数在下面的方法中会用到
    rollingCounterInSecond.addPass(count);
    // 一个记录分钟级
    rollingCounterInMinute.addPass(count);
}

// 进入到addPass()方法中
public void addPass(int count) {
    // 获取到当前时间小窗口
    WindowWrap<MetricBucket> wrap = data.currentWindow();
    // 往时间小窗口中进行相加操作
    // wrep.value()获取的是MetricBucket对象，它存储了一个LongAdder[] counters数组
    // 所以这里的添加操作应该是往LongAdder[]数组中对应的某一个小标进行相加操作
    wrap.value().addPass(count);
}



我们首先详细分析data.currentWindow();这里是如何根据当前时间获取到对应的时间小窗口的

  • 计算出当前请求时间对应的小窗口下标idx
  • 计算出当前请求的小窗口起始时间
  • 取出idx对应的老的小窗口对象
    • 如果老的小窗口对象为null，那么就直接创建一个小窗口对象，并存入滑动窗口对应的小窗口位置
    • 如果老的小窗口对象所代表的小窗口起始时间 = 当前请求的小窗口起始时间 ，那么就返回老的小窗口对象
    • 如果老的小窗口对象所代表的小窗口起始时间 < 当前请求的小窗口起始时间，那么就会替换覆盖掉老的小窗口对象
    • 时钟回拨的处理，创建一个新的无关紧要的小窗口对象返回
public WindowWrap<T> currentWindow(long timeMillis) {
    // 当前时间戳基本上不会小于0
    if (timeMillis < 0) {
        return null;
    }

    // 获取当前时间对应的小窗口的下标数： timeMillis / 小窗口总时间数 % 小窗口数
    // 比如当前限流时间是1秒，移动窗口的小窗口数是2，那么每个小窗口总时间数就是500ms。
    // 假如当前时间为700ms。那么就是 700 / 500 = 1 ，然后1%2 = 1  最终得到我当时间所在的小窗口是下标为1的小窗口
    int idx = calculateTimeIdx(timeMillis);
    
    // Calculate current bucket start time.
    // 计算当前小窗口的启动时间：timeMillis - timeMillis % 小窗口总时间数
    // 还是上面的案例： 700 - 700%500 = 500。 那么700ms这个时间对应的小窗口启动时间为500
    // 假如当前时间为1600ms：1600 - 1600%500 = 1500。  那么1600md对应小窗口的启动时间是1500
    long windowStart = calculateWindowStart(timeMillis);

    while (true) {
        // 取出老小窗口对象WindowWrap，根据上面得到的当前时间对应的小窗口的下标数
        WindowWrap<T> old = array.get(idx);
        
        // 如果滑动时间窗口中，该小窗口为null
        if (old == null) {
            // 那么就创建一个小窗口对象WindowWrap，参数有小窗口的总时长、小窗口的起始时间、当前请求时间戳
            WindowWrap<T> window = new WindowWrap<T>(windowLengthInMs, windowStart, newEmptyBucket(timeMillis));
            // 再用CAS算法存入时间窗口中
            if (array.compareAndSet(idx, null, window)) {
                return window;
            } else {
                Thread.yield();
            }


            // 如果当前时间对应的小窗口起始时间 = 老小窗口的起始时间。那么就直接返回老的小窗口对象
            // 可能有一个700ms的请求先过来，创建了一个WindowWrap小窗口对象。然后来了一个750ms的请求，这时它们的小窗口的起始时间就是一样的
        } else if (windowStart == old.windowStart()) {
            return old;


            // 如果当前时间对应的小窗口起始时间 > 老的小窗口的起始时间。那么就把老的小窗口对象给覆盖掉
            // 可能有一个700ms的请求先过来，创建了一个WindowWrap小窗口对象。
            // 然后来了一个1600ms的请求，这时它们的小窗口的起始时间就是500 和 1500
            // 这里就会调用resetWindowTo(old, windowStart);方法进行滑动时间窗，剔除掉老的小窗口
        } else if (windowStart > old.windowStart()) {

            if (updateLock.tryLock()) {
                try {
                    // 重置小窗口
                    return resetWindowTo(old, windowStart);
                } finally {
                    updateLock.unlock();
                }
            } else {
                Thread.yield();
            }

            
            // 时钟回拨的处理逻辑，直接返回一个新的小窗口WindowWrap对象，它和滑动窗口都没有关系
        } else if (windowStart < old.windowStart()) {
            // Should not go through here, as the provided time is already behind.
            return new WindowWrap<T>(windowLengthInMs, windowStart, newEmptyBucket(timeMillis));
        }
    }
}



我们再看看往时间小窗口中进行相加操作的具体实现wrap.value().addPass(count);

// 往时间小窗口中进行相加操作
// wrep.value()获取的是MetricBucket对象，它存储了一个LongAdder[] counters数组
// 所以这里的添加操作应该是往LongAdder[]数组中对应的某一个小标进行相加操作
wrap.value().addPass(count);

// 方法调用
public void addPass(int n) {
    // 这里就传了一个代码pass通过的枚举对象
    add(MetricEvent.PASS, n);
}

// 往代码Pass通过的数组下标对应位置进行相加操作
public MetricBucket add(MetricEvent event, long n) {
    // event.ordinal()获取的其实就是当前对象在枚举中的下标数
    // 官方解释：返回此枚举常量的序号(其在枚举声明中的位置，其中初始常量被赋值为0的序数)
    counters[event.ordinal()].add(n);
    return this;
}



通过上方的代码我们就已经知道了Sentinel在滑动窗口上的具体实现。我们现在再看看限流FlowSlot流程中，从时间窗口中取值的流程。

快速失败方式 --> DefaultController.canPass()

public boolean canPass(Node node, int acquireCount, boolean prioritized) {
    // 当前时间窗口中取统计指标数据
    int curCount = avgUsedTokens(node);
    // 当前qps > count阈值，那么就要返回false
    if (curCount + acquireCount > count) {
        // 因为prioritized默认情况下都是false，所以下面if不需要花太多精力去看
        if (prioritized && grade == RuleConstant.FLOW_GRADE_QPS) {
            ...
        }
        return false;
    }
    return true;
}


// 我们看看avgUsedTokens(node)方法是怎么从时间窗口中取值的。最终会调用至	ArrayMetric.pass()方法中
public long pass() {
    data.currentWindow();
    long pass = 0;
    // data.values()其实就是从滑动时间窗口中取所有的小窗口对象中存的MetricBucket对象
    List<MetricBucket> list = data.values();

    for (MetricBucket window : list) {
        // 求总和
        pass += window.pass();
    }
    return pass;
}



漏桶算法

漏桶算法，又称leaky bucket。

在这里插入图片描述


从图中我们可以看到，整个算法其实十分简单。首先，我们有一个固定容量的桶，有水流进来，也有水流出去。对于流进来的水来说，我们无法预计一共有多少水会流进来，也无法预计水流的速度。但是对于流出去的水来说，这个桶可以固定水流出的速率。而且，当桶满了之后，多余的水将会溢出。


我们将算法中的水换成实际应用中的请求，我们可以看到漏桶算法天生就限制了请求的速度。当使用了漏桶算法，我们可以保证接口会以一个常速速率来处理请求。所以漏桶算法天生不会出现临界问题。



/**
 * @Description: 限流算法之漏桶算法  伪代码实现
 * @Author 胡尚
 * @Date: 2024/7/12 11:57
 */
public class LeakyBucket {
    /**
     * 当前时间
     */
    private long timeStamp = System.currentTimeMillis();
    /**
     * 桶的容量
     */
    private long capacity;
    /**
     * 水漏出的速度(每秒系统能处理的请求数)
     */
    private long rate;
    /**
     * 当前水量(当前累积请求数)
     */
    private long water;

    public boolean check() {
        long now = System.currentTimeMillis();
        // 当前水量
        water = Math.max(0, capacity - ((now - timeStamp) / 1000) * rate); 
        // 更新timeStamp
        timeStamp = now;
        if (water + 1 > capacity){
            // 水满了，直接拒绝
            return false;
        }else{
            // 还能装水
            water++;
            return true;
        }
    }
}



我们接下来看看sentinel，它在流控规则中的排队等待是怎么实现漏桶算法的。

  • 计算出两次请求应该的间隔时间costTime
  • 计算出下一次请求期望的时间点expectedTime
  • 如果currentTime > currentTime 就返回true，放行
    • 否则计算当前请求需要等待时间waitTime
    • 判断waitTime > 最大超时时间 就返回false
    • 否则再又重新计算一次等待时间，重新判断一次是否超过最大等待时间，再去进入等待sleep()
// 排队等待 --> RateLimiterController.canPass() ---> 漏桶算法
public boolean canPass(Node node, int acquireCount, boolean prioritized) {
    if (acquireCount <= 0) {
        return true;
    }

    if (count <= 0) {
        return false;
    }

    // 获取当前请求的当前时间
    long currentTime = TimeUtil.currentTimeMillis();

    // acquireCount一般就是一次请求，也就是1   count就是我们在控制台界面中设置的阈值
    // costTime就是算出两次请求之间应该的间隔时间，比如我1s中只能允许10个请求。那么这里就是 1.0 / 10 * 1000 = 100ms。
    // 也就是说我两次请求的间隔时间应该是100毫秒
    long costTime = Math.round(1.0 * (acquireCount) / count * 1000);
    
    // expectedTime就是一个期望时间。 期望时间 = 两次请求间隔时间 + 上一次请求时间
    // 比如我上一个请求的时间为300ms，那么我期望下一个请求应该是400ms
    long expectedTime = costTime + latestPassedTime.get();

    // 假如我当前的请求时间 比期望时间还要大，那么就直接更新最后一次请求时间，并返回true放行当前请求
    // 比如我期望下一个请求的时间是400ms。但我现在请求的时间已经是450ms了，我比你期望的时间还要长，那你是不是肯定要给我放行了
    if (expectedTime <= currentTime) {
        latestPassedTime.set(currentTime);
        return true;
    } else {
        // 接下来就是我当前的请求时间，比期望的时间要小的处理逻辑

        // 重新算出来的期望时间 - 当前请求的时间 = 我当前这个请求需要等待的时间
        long waitTime = costTime + latestPassedTime.get() - TimeUtil.currentTimeMillis();
        
        // 如果我这个请求要等待的时间，超过了控制台界面设置的最大超时时间那么就直接返回false
        if (waitTime > maxQueueingTimeMs) {
            return false;
        } else {
            // 接下来是我当前请求需要进行等待的处理逻辑

            // 修改上一次请求时间，上一次请求时间 + 间隔时间 = oldTime(其实就是重新算出来的期望时间)
            long oldTime = latestPassedTime.addAndGet(costTime);
            try {
                // 重新计算一次，期望时间 - 当前请求的时间 = 当前请求要等待的时间
                waitTime = oldTime - TimeUtil.currentTimeMillis();
                // 当前请求要等待的时间 是否大于了最大超时时间，如果大于了就把上一次请求时间改回来，在直接返回false
                if (waitTime > maxQueueingTimeMs) {
                    latestPassedTime.addAndGet(-costTime);
                    return false;
                }
                // 当前线程进入等待
                if (waitTime > 0) {
                    Thread.sleep(waitTime);
                }
                return true;
            } catch (InterruptedException e) {
            }
        }
    }
    return false;
}



令牌桶算法

令牌桶算法，又称token bucket。

在这里插入图片描述

有一个线程，会根据一定增长的预热速率往桶中放令牌，如果桶中的令牌满了那么就就直接将令牌丢弃掉。

当有请求过来时就会从桶中获取令牌，如果获取到了就放行，如果没有获取到就拒绝。



/**
 * 令牌桶限流算法  伪代码
 * 这里就没有预热、增长的速率往桶中放入令牌
 */
public class TokenBucket {
    public long timeStamp = System.currentTimeMillis();  // 当前时间
    public long capacity; // 桶的容量
    public long rate; // 令牌放入速度
    public long tokens; // 当前令牌数量
 
    public boolean grant() {
        long now = System.currentTimeMillis();
        // 先添加令牌
        tokens = Math.min(capacity, tokens + (now - timeStamp) * rate);
        timeStamp = now;
        if (tokens < 1) {
            // 若不到1个令牌,则拒绝
            return false;
        } else {
            // 还有令牌，领取令牌
            tokens--;
            return true;
        }
    }
}

对应的sentinel中，Warm Up的实现就是基于令牌桶实现的，Warm Up --> WarmUpController.canPass() --> 令牌桶算法

这里就不展开介绍sentinel具体的实现算法了

public boolean canPass(Node node, int acquireCount, boolean prioritized) {
    long passQps = (long) node.passQps();

    long previousQps = (long) node.previousPassQps();
    syncToken(previousQps);

    // 开始计算它的斜率
    // 如果进入了警戒线，开始调整他的qps
    long restToken = storedTokens.get();
    if (restToken >= warningToken) {
        long aboveToken = restToken - warningToken;
        // 消耗的速度要比warning快，但是要比慢
        // current interval = restToken*slope+1/count
        double warningQps = Math.nextUp(1.0 / (aboveToken * slope + 1.0 / count));
        if (passQps + acquireCount <= warningQps) {
            return true;
        }
    } else {
        if (passQps + acquireCount <= count) {
            return true;
        }
    }

    return false;
}



限流算法小结

计数器 VS 滑动窗口：

计数器算法是最简单的算法，可以看成是滑动窗口的低精度实现。
滑动窗口由于需要存储多份的计数器（每一个格子存一份），所以滑动窗口在实现上需要更多的存储空间。
也就是说，如果滑动窗口的精度越高，需要的存储空间就越大。

漏桶算法 VS 令牌桶算法：

漏桶算法和令牌桶算法最明显的区别是令牌桶算法允许流量一定程度的突发。
因为默认的令牌桶算法，取走token是不需要耗费时间的，也就是说，假设桶内有100个token时，那么可以瞬间允许100个请求通过。
当然我们需要具体情况具体分析，只有最合适的算法，没有最优的算法。



拦截器处理web请求

我们引入了下面的依赖，也就是我们实际使用sentinel的场景下，我们会发现我们controller层编写的http请求接口都不需要我们自己额外的定义资源开启保护。

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

会自动的把我们的http请求接口定义成一个一个的资源。具体的实现如下：

入口是SentinelWebAutoConfiguration自动配置类

在这里插入图片描述



SentinelWebAutoConfiguration自动配置类它实现了WebMvcConfigurer接口，所以在SpringBoot启动过程中就会调用这个类重写的addInterceptors方法

public class SentinelWebAutoConfiguration implements WebMvcConfigurer {

	......

    // 此数组存的就是最下面创建的拦截器
	@Autowired
	private Optional<SentinelWebInterceptor> sentinelWebInterceptorOptional;

	@Override
	public void addInterceptors(InterceptorRegistry registry) {
		if (!sentinelWebInterceptorOptional.isPresent()) {
			return;
		}
		SentinelProperties.Filter filterConfig = properties.getFilter();
        // 最终下面创建的拦截器会被添加在这里来
		registry.addInterceptor(sentinelWebInterceptorOptional.get())
				.order(filterConfig.getOrder())
				.addPathPatterns(filterConfig.getUrlPatterns()); // 这里其实就是拦截所有的请求  /**
		log.info(...);
	}

    // 往Spring容器中存一个SentinelWebInterceptor拦截器
	@Bean
	@ConditionalOnProperty(name = "spring.cloud.sentinel.filter.enabled",matchIfMissing = true)
	public SentinelWebInterceptor sentinelWebInterceptor(SentinelWebMvcConfig sentinelWebMvcConfig) {
		return new SentinelWebInterceptor(sentinelWebMvcConfig);
	}
    
    ...
}

SentinelWebInterceptor extends AbstractSentinelInterceptor 这里是该类的继承关系，我们直接去看它父类中的preHandle()方法

// 前置拦截器方法
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
    try {
        String resourceName = this.getResourceName(request);
        if (StringUtil.isEmpty(resourceName)) {
            return true;
        } else if (this.increaseReferece(request, this.baseWebMvcConfig.getRequestRefName(), 1) != 1) {
            return true;
        } else {
            String origin = this.parseOrigin(request);
            String contextName = this.getContextName(request);
            ContextUtil.enter(contextName, origin);
            
            // 这里定义了资源，开启了保护
            Entry entry = SphU.entry(resourceName, 1, EntryType.IN);
            request.setAttribute(this.baseWebMvcConfig.getRequestAttributeName(), entry);
            return true;
        }
    } catch (BlockException var12) {
        // 如果出现了BlockException，则去相应的处理逻辑
        BlockException e = var12;

        try {
            this.handleBlockException(request, response, e);
        } finally {
            ContextUtil.exit();
        }

        return false;
    }
}
胡尚
关注
专栏目录
Java后端入职第七天，领导要我对活动接口限流（限流算法）
qi_ming88的博客
07-04 164
本文主要介绍接口限流，通过分析五大限流算法：计数器、固定窗口计数器、滑动窗口计数器、漏桶算法、令牌桶算法。六种限流落地方案：本地缓存实现，第三方缓存实现、Nginx限流、网关限流、Guava的令牌桶RateLimiter、微服务Alibaba的Sentinel中间件，来深入讲解接口限流，各种方案，从简单业务到微服务复杂场景，欢迎大家订阅学习。
Sentinel限流算法详解（硬啃）
自救 唯有自强
05-06 6700
文章目录常见四种限流算法固定窗口计数器滑动窗口计数器漏桶（也有称漏斗 Leaky bucket）令牌桶（ Token bucket）Sentinel源码举例滑动窗口漏桶 常见四种限流算法 固定窗口计数器 固定窗口，相比其他的限流算法，这应该是最简单的一种。 它简单地对一个固定的时间窗口内的请求数量进行计数，如果超过请求数量的阈值，将被直接丢弃。 这个简单的限流算法优缺点都很明显。优点的话就是简单，缺点举个例子来说。 比如我们下图中的黄色区域就是固定时间窗口，默认时间范围是 60 秒，限流数量是 100。 如
一文讲解在Sentinel中涉及到的限流算法
weixin_54828627的博客
03-01 2624
滑动窗口算法是将时间周期分为N个小周期（窗口），分别记录每个小周期内访问次数，然后根据时间将窗口往前滑动并删除过期的小时间窗口。最终只需要统计滑动窗口范围内的所有小时间窗口总的计数即可，如下图所示
Sentinel限流规则详解
最新发布
后端
07-23 1322
簇点链路就是项目内的调用链路（Controller -> Service -> Mapper），链路中被监控的每个接口就是一个资源。默认情况下 Sentinel 会监控 SpringMVC 的每一个**端点（Endpoint）**，因此 **SpringMVC 的每一个端点（Endpoint）就是调用链路中的一个资源**（这里指的就是 Controller 中的方法） 流控、熔断等都是**针对簇点链路中的资源**来设置的，因此我们可以点击对应资源后面的按钮来设置规则：
Sentinel 采用的是什么限流算法？
2401_84419325的博客
07-01 1196
Sentinel 是阿里巴巴开源的一款流量控制和服务保护组件，旨在解决分布式系统中的流量管理、熔断降级、系统负载保护等问题。它提供了实时的流量监控、熔断降级、系统自适应保护等功能，能够帮助开发者有效管理和保护各种规模的应用服务。
Sentinel流控限制算法
TwinkLing_Stars的博客
07-04 4921
1. Sentinel及其原理 Sentinel是阿里推出的一个流量控制平台，原理是在访问web应用时，在web引用内部会有一个拦截器，这个拦截器会对请求的url进行拦截，并将拦截到的请求读取到sentinel控制台，从而对web应用设置相应的流控规则，之后基于这个流控规则对流量进行限流操作。 2.限流算法 2.1 计数器算法 计数器算法是限流算法中最简单也最容易实现的算法。它使用计数器在周期内累加访问次数，当达到设定的限流值时，触发限流策略。下一周期开始，清零重新计...
Sentinel实现限流
weixin_59297657的博客
04-14 1307
说到滑动时间窗口算法之前，就得先说说固定窗口计数算法。什么是固定窗口计数算法呢？固定窗口计数算法：将时间分成一个个单位，对每个切割出来的时间段里面进行计数，来了一个请求，计数器counter加1，达到阈值之后就拒绝请求，直到下一个时间段计数器重置为0。滑动窗口算法是固定窗口计数算法的优化。那什么是滑动时间窗口算法呢？就是将时间以每一秒进行划分的前提，再次划分为n个更小的区间从而形成多个窗口。这里引入几个参数，一个是Interval，表示一个时间段，窗口的时间跨度，简单来说就是一个时间间隔。
Sentinel中的限流算法
u013800720的博客
04-26 575
其中漏桶作为流量容器我们可以看做一个FIFO的队列，当入口流量速率大于出口流量速率时，因为流量容器是有限的，当超出流量容器大小时，超出的流量会被丢弃。最开始，令牌桶是空的，我们以恒定速率往令牌桶里加入令牌，令牌桶被装满时，多余的令牌会被丢弃。当请求到来时，会先尝试从令牌桶获取令牌（相当于从令牌桶移除一个令牌），获取成功则请求被放行，获取失败则阻塞活拒绝请求。令牌桶算法是漏桶算法的改进版，可以支持突发流量。不过与漏桶算法不同的是，令牌桶算法的漏桶中存放的是令牌而不是流量。那么令牌桶算法是怎么突发流量的呢？
java-sentinel-限流算法
m0_61344579的博客
05-22 313
【代码】java-sentinel-限流算法。
限流算法--sentinel
javaDB_EAD的专栏
09-17 1797
常见的限流算法 计数器算法计数器算法指在一段时间内，进行计数，与阀值进行比较，如果超过了阀值则进行限流操作，到了时间临界点，将计数器清零进行重新计数，即单位时间段内可访问请求的次数进行控制。 计数器算法是一种比直观简单的限流算法，常用于应用服务对外提供的接口层面。 由于计数器算法存在时间临界点缺陷，因此在时间临界点左右的极短时间段内容易遭到攻击。 滑动窗口算法滑动窗口算法是指把固...
Sentinel服务限流原理分析
xp_xpxp的博客
11-30 3853
Sentinel(分布式系统的流量防卫兵)是阿里开源的一套用于服务容错的综合性解决方案;Sentinel是面向分布式服务架构的轻量级流量控制组件,主要以流量为切入点,从限流、流量整形、熔断降级、系统负载保护等多个维度来帮助您保障微服务的稳定性;本质要做的就是两件事:①.统计数据:统计某个资源的访问数据(QPS, RT等信息);②.规则判断:判断限流规则, 隔离规则, 降级规则, 熔断规则是否满足;这里的资源。
滑动时间窗算法matlab
05-11
滑动时间的MATLAB程序实现，里面包括了两个窗口大小的设置
基于Redis的分布式限流器Java实现
GaleZhang的博客
08-23 3184
限流、熔断与降级是系统应对海量并发时进行自我保护的三大“神器”。其中限流作为常见的业务场景，在一些小型系统中也是存在一定的需求。对于Java而言，常见的开源限流组件，如Guava RateLimiter，通过线程同步实现限流，仅适用于单机应用，而像阿里的Sentinel等，对小型应用来说又未免过重。本文通过Redis实现了分布式限流器，支持加载不同的脚本进行简单计数器、滑动窗口以及漏桶限流方案，并通过注解的方式对接口进行限流，既实现了对业务代码的极低侵入，又可以定制化限流逻辑。在这里与各位同学分享，也希望大
SpringCloud Alibaba 实战之《限流与熔断：Sentinel 在项目中的最佳实践》
小米吃辣椒的博客
05-27 477
上一讲我们讲解了微服务的雪崩效应与如何基于 Sentinel 实现初步微服务限流，掌握了部署 Sentinel Dashboard与配置 Sentinel Core 客户端的技巧。本讲咱们继续 Sentinel 这个话题，将更有针对性的讲解 Sentinel 底层的细节与限流、熔断的各种配置方式。 本讲咱们主要学习三方面内容： Sentinel 通信与降级背后的技术原理； Sentinel 限流降级的规则配置； Sentinel 熔断降级的规则配置。 下面咱们先开始第一部分。 Sentinel
Sentinel（四）限流算法-令牌桶算法
姑苏
06-10 996
Sentinel中的预热流程
【sentinel】令牌桶算法在Sentinel中的应用
热门推荐
morris
06-14 1万+
令牌桶算法，又称token bucket。从图中我们可以看到，令牌桶算法比漏桶算法稍显复杂。首先，我们有一个固定容量的桶，桶里存放着令牌（token）。桶一开始是空的，token以一个固定的速率r往桶里填充，直到达到桶的容量，多余的令牌将会被丢弃。每当一个请求过来时，就会尝试从桶里移除一个令牌，如果没有令牌的话，请求无法通过。
微服务--07--Sentienl中使用的限流算法
时光里的博客
12-13 644
提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档。
Sentinel限流算法总结
西敏寺的乐章的博客
07-02 1762
之所以叫漏桶算法，就是把请求看做水，队列看做是一个漏了的桶。因此，在使用令牌桶算法时，尽量不要将令牌上限设定到服务能承受的QPS上限。设置一个窗口的大小，然后窗口是匀速往前滑动的，在一段时间范围内，请求落在同一个窗口的数量大于窗口阈值，就拒绝该请求。在限流的时候，要统计每秒钟的QPS，同样是计数。漏桶的优势就是流量整型，不管并发量如何波动，经过漏桶处理后的请求一定是相对平滑的曲线。Sentinel中的热点参数限流正是基于令牌桶算法实现的。基于令牌桶算法，每秒产生的令牌数量基本就是QPS上限。
Sentinel 常用流控算法
u010947588的专栏
09-15 916
本文主要讲述常见的几种限流算法：计数器算法、漏桶算法、令牌桶算法。然后结合我对 Sentinel 1.8.0 的理解，给大家分享 Sentinel 在源码中如何使用这些算法进行流控判断。由于本人理解有限，如果有不正确的地方，希望大家能够留言讨论????????????。 计数器限流算法 我们可以直接通过一个计数器，限制每一秒钟能够接收的请求数。比如说 qps定为 1000，那么实现思路就是从第一个请求进来开始计时，在接下去的 1s 内，每来一个请求，就把计数加 1，如果累加的数字达到了 1000，那么后续的
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值