SmoothBursty

主要思想

记录 1秒内的微秒数/permitsPerSencond = 时间间隔interval,每一个interval可获得一个令牌

根据允许使用多少秒内的令牌参数,计算出maxPermits

setRate时初始化下次interval时间,及storedPermits

acquire时,计算当前nowMicros,如果大于下次interval时间时间,则更新storedPermits和下次interval时间,计算storedPermits能否满足此次acquire,如果能,则需要等待的时间为0,如果不能,则计算还需要多少微秒等待,并在非同步块外执行sleep操作

如果其他线程已经刷新了nextFreeTicketMicros,会如下情况acquire是无timeout的

Thread 1: acquire 11 -> storedPermits不能满足要求 -> waitTime = (acquire - stored) * stableIntervalMicros -> nextFreeTicketMicros += waitMicros ----->  out lock sleep
Thread 2: acquire 2 -> nowMicros < nextFreeTicketMicros , stored = 0,被线程1消耗完了 -> freshPermits = requiredPermits - storedPermitsToSpend 即 = requiredPermits -> waitTime = freshPermits * stableIntervalMicros
-> nextFreeTicketMicros += waitTime,此时的nextFreeTicketMicros包含了Thread1需要等待的时间 -------> out lock sleep a longer time

tryAquire(num,timeout)逻辑

timeoutMicros = timeout.toMicros
lock()
nowMicros = ...
canAcquire = nextFreeTicketMicros <= nowMicros + timeoutMicros
if(!canAcquire){
return false;
}
else{
microsToWait = ...
}
unlock()
sleep(microsToWait)
return true;

SmoothWarmingUp

主要思想和SmoothBursty相似,由于带预热过程,刚开始由于availablePermitsAboveThreshold>0.0,速率会较慢,如果持续获取令牌,则会使availablePermitsAboveThreshold=0,速率变快

  • 从0->thresholdPermits,生成一个令牌的时间:stableIntervalMicros

  • 从thresholdPermits-> maxPermits ,生成一个令牌的时间:stableIntervalMicros + permits * slope;

    @Override

    final long reserveEarliestAvailable(int requiredPermits, long nowMicros) {

    resync(nowMicros);

    long returnValue = nextFreeTicketMicros;

    //当前需要且尽最大可能消费的

    double storedPermitsToSpend = min(requiredPermits, this.storedPermits);

    //新鲜permits个数,这些个数是一定会产生等待的,除了0

    double freshPermits = requiredPermits - storedPermitsToSpend;

    //计算需要wait的总时间

    long waitMicros =

    //非busty类型的storedPermitsToWaitTime直接返回0

    storedPermitsToWaitTime(this.storedPermits, storedPermitsToSpend)

    + (long) (freshPermits * stableIntervalMicros);

    //下次有票时间

    this.nextFreeTicketMicros = LongMath.saturatedAdd(nextFreeTicketMicros, waitMicros);

    this.storedPermits -= storedPermitsToSpend;

    return returnValue;

    }

     //已知permitsToTake <= storedPermits
    @Override
    long storedPermitsToWaitTime(double storedPermits, double permitsToTake) {
    //减去预热需要保留的permits,剩下的可消耗的数量
    double availablePermitsAboveThreshold = storedPermits - thresholdPermits;
    long micros = 0;
    // measuring the integral on the right part of the function (the climbing line)
    //如果有剩余可用的令牌
    if (availablePermitsAboveThreshold > 0.0) {
    //剩余可用的和需要获取的个数取小值
    double permitsAboveThresholdToTake = min(availablePermitsAboveThreshold, permitsToTake);
    // TODO(cpovirk): Figure out a good name for this variable.
    //用可消耗的数量 + (可消耗的数量 - 实际消耗的数量)permitsToTime
    //在预热阶段从thresholdPermits到maxPermits的耗时并非是stableIntervalMicros * n
    //会耗费更多的时间,其计算规则不同,所以才需要把permitsAboveThresholdToTake从permitsToTake减去
    //length 可能作为一个经验值,相当于补充permitsAboveThresholdToTake个令牌需要的平均时间值*2
    //剩余可用的-实际需要且最大能消耗的令牌,得到最终剩余的令牌个数,可能是0
    double length = permitsToTime(availablePermitsAboveThreshold)
    + permitsToTime(availablePermitsAboveThreshold - permitsAboveThresholdToTake);
    //这里确实不好理解,从语义环境来说,它是从 thresholdPermits 到 maxPertmis 过程中
    //生成 permitsAboveThresholdToTake 个令牌需要耗费的时间
    //并且带coldFactor的构造函数不是public,SmoothWarmingUp也是private-package的
    micros = (long) (permitsAboveThresholdToTake * length / 2.0);
    //从permitsToTake中减去保留预热需留下个数后最终消耗的个数,这部分个数由于是提前存在的、富余的
    //因此不需要计算到wait时间
    permitsToTake -= permitsAboveThresholdToTake;
    }
    // measuring the integral on the left part of the function (the horizontal line)
    //如果没有剩余可用令牌,走的是stableIntervalMicros * n
    micros += (stableIntervalMicros * permitsToTake);
    return micros;
    }

length/2可以理解为下图

	//permits值越小,需要的时间就越少,值越大,需要的时间就越大
private double permitsToTime(double permits) {
//double coldIntervalMicros = stableIntervalMicros * coldFactor;
// thresholdPermits = 0.5 * warmupPeriodMicros / stableIntervalMicros;
//maxPermits =
thresholdPermits + 2.0 * warmupPeriodMicros / (stableIntervalMicros + coldIntervalMicros);
//slope带比率的时间,可以理解为增长因子
//slope = (coldIntervalMicros - stableIntervalMicros) / (maxPermits - thresholdPermits)
//return表示成这样更易于理解 stableIntervalMicros + (coldIntervalMicros - stableIntervalMicros) * (permits/(maxPermits - thresholdPermits))
return stableIntervalMicros + permits * slope;
}

RateLimiter的 SmoothBursty(非warmup预热)及SmoothWarmingUp(预热,冷启动)的更多相关文章

  1. 超详细的Guava RateLimiter限流原理解析

    超详细的Guava RateLimiter限流原理解析  mp.weixin.qq.com 点击上方“方志朋”,选择“置顶或者星标” 你的关注意义重大! 限流是保护高并发系统的三把利器之一,另外两个是 ...

  2. RateLimiter 源码分析(Guava 和 Sentinel 实现)

    作者javadoop,资深Java工程师.本文已获作者授权发布. 原文链接https://www.javadoop.com/post/rate-limiter 本文主要介绍关于流控的两部分内容. 第一 ...

  3. 高并发之限流RateLimiter(二)

    Guava RateLimiter提供了令牌桶算法实现:平滑突发限流(SmoothBursty)和平滑预热限流(SmoothWarmingUp)实现. SmoothBursty:令牌生成速度恒定 @T ...

  4. 面试官:来谈谈限流-RateLimiter源码分析

    RateLimiter有两个实现类:SmoothBursty和SmoothWarmingUp,其都是令牌桶算法的变种实现,区别在于SmoothBursty加令牌的速度是恒定的,而SmoothWarmi ...

  5. 使用Guava RateLimiter限流入门到深入

    前言 在开发高并发系统时有三把利器用来保护系统:缓存.降级和限流 缓存: 缓存的目的是提升系统访问速度和增大系统处理容量 降级: 降级是当服务出现问题或者影响到核心流程时,需要暂时屏蔽掉,待高峰或者问 ...

  6. RateLimiter源码解析

    RateLimiter是Guava包提供的限流器,采用了令牌桶算法,特定是均匀地向桶中添加令牌,每次消费时也必须持有令牌,否则就需要等待.应用场景之一是限制消息消费的速度,避免消息消费过快而对下游的数 ...

  7. Java技术开发专题系列之【Guava RateLimiter】针对于限流器的入门到精通(针对于源码分析介绍)

    Guava包中限流实现分析 RateLimiter 之前的文章中已经介绍了常用的限流算法,而google在Java领域中使用Guava包中的限流工具进行服务限流. 回顾使用案例 Google开源工具包 ...

  8. 常用限流算法与Guava RateLimiter源码解析

    在分布式系统中,应对高并发访问时,缓存.限流.降级是保护系统正常运行的常用方法.当请求量突发暴涨时,如果不加以限制访问,则可能导致整个系统崩溃,服务不可用.同时有一些业务场景,比如短信验证码,或者其它 ...

  9. RateLimiter令牌桶算法

    限流,是服务或者应用对自身保护的一种手段,通过限制或者拒绝调用方的流量,来保证自身的负载. 常用的限流算法有两种:漏桶算法和令牌桶算法 漏桶算法 思路很简单,水(请求)先进入到漏桶里,漏桶以一定的速度 ...

随机推荐

  1. 接口、RESTful规范、DRF

    接口 #接口:url连接,通过向链接发送不同的类型请求与参数得到相应的响应数据 #1.在视图书写处理请求的 视图函数 #2.在路由层为视图函数配置 url链接=>产生接口 #3.前台通过ajax ...

  2. 常见消息中间件之ActiveMQ

    前言 消息队列是指利用高效可靠的消息传递机制进行与平台无关的数据交流,并基于数据通信来进行分布式系统的集成.目前消息队列已经逐渐成为企业IT系统内部通信的核心手段,它具有低耦合.可靠投递.广播.流量控 ...

  3. kmt字符串匹配

    # -*- coding:utf-8 -*-class StringPattern: def findAppearance(self, A, lena, B, lenb): pos=0 tmp = 0 ...

  4. Go-注释

    什么是注释? 注释是给开发人员看的,目的是降低开发人员阅读代码的时间成本和代码阅读困难程度 Go-注释内容 1. 包注释,位于某个包下Go程序文件的顶部 2. 函数注释,位于Go函数的头部 3. 代码 ...

  5. 「ExLucas」学习笔记

    「ExLucas」学习笔记 前置芝士 中国剩余定理 \(CRT\) \(Lucas\) 定理 \(ExGCD\) 亿点点数学知识 给龙蝶打波广告 Lucas 定理 \(C^m_n = C^{m\% m ...

  6. 无所不能的Embedding 2. FastText词向量&文本分类

    Fasttext是FaceBook开源的文本分类和词向量训练库.最初看其他教程看的我十分迷惑,咋的一会ngram是字符一会ngram又变成了单词,最后发现其实是两个模型,一个是文本分类模型[Ref2] ...

  7. sublime text3配置Python2、Python3的编译环境

    由于Python2.Python3使用量都很高,Python3虽然是未来趋势,但是目前个别库还是只支持Python2.所以,很多人会选择在电脑上安装两个版本的Python,那么使用sublime执行代 ...

  8. 【题解】SP1811 LCS - Longest Common Substring

    \(\color{purple}{Link}\) \(\text{Solution:}\) 题目要求找到两个串的最长公共子串.\(LCP\) 我们将两个串中间和末尾插入终止符,并弄到一棵后缀树上去. ...

  9. SpringBoot多任务Quartz动态管理Scheduler,时间配置,页面+源码

    页面展现 后台任务处理:恢复任务 15s执行一次后台打印消息 不BB了,直接上代码 import... /** * 调度工厂类 * Created by jinyu on 2018/4/14/014. ...

  10. React Ref 其实是这样的

    大家好,我是Mokou,好久没有冒泡了,最近一直在看研究算法和数据结构方面的东西,但是似乎很多前端不喜欢看这种东西,而且目前本人算法方面也很挫,就不献丑了. 当然了,最近也开始研究React了,这篇文 ...