限流-令牌桶限流-Guava RateLimiter

信仰_273993243

已于 2022-01-27 17:10:29 修改

阅读量1.2k

点赞数

分类专栏：高并发问题文章标签： java http

于 2022-01-27 11:41:37 首次发布

原文链接：https://zhuanlan.zhihu.com/p/60979444

版权

高并发问题专栏收录该内容

6 篇文章 0 订阅

订阅专栏

一、Guava的 RateLimiter提供了令牌桶算法实现

1、平滑突发限流(SmoothBursty)
2、平滑预热限流(SmoothWarmingUp)

public abstract class RateLimiter {
	//平滑突发限流
	static RateLimiter create(double permitsPerSecond, SleepingStopwatch stopwatch) {
	  	RateLimiter rateLimiter = new SmoothBursty(stopwatch, 1.0 /* maxBurstSeconds */);
	  	rateLimiter.setRate(permitsPerSecond);
	  	return rateLimiter;
	}
	//平滑预热限流
	static RateLimiter create(double permitsPerSecond,long warmupPeriod,
	                           TimeUnit unit,double coldFactor,SleepingStopwatch stopwatch) {
	  	RateLimiter rateLimiter = new SmoothWarmingUp(stopwatch, warmupPeriod, unit, coldFactor);
	  	rateLimiter.setRate(permitsPerSecond);
	  	return rateLimiter;
	}
}

二、平滑突发限流

1、使用 RateLimiter的静态方法创建一个限流器，设置每秒放置的令牌数为5个。返回的RateLimiter对象可以保证1秒内不会给超过5个令牌，并且以固定速率进行放置，达到平滑输出的效果。

原理：创建的时候，记录当前时间，当需要获取令牌的时候，拿当前请求时间，减去创建时记录的时间，得到时间差除以速率，得到已经产生的令牌数，然后判断如果当前需要使用的令牌数和产生的令牌数对比
1、如果小于当前的令牌，OK没有问题，直接执行。
2、如果大于当前的令牌数，那就得到需要额外预先支付的令牌数量，通过速率得到超出的令牌所需要的时间，加上记录的时间，得到下次获取令牌的时间
3、当新的获取令牌的请求进来，活进行判断，如果记录的时间大于当前请求的时间，那就说明，上一个请求拿了太多的令牌，此时你需要等待。

public void testSmoothBursty() {
	RateLimiter r = RateLimiter.create(5);
	while (true) {
		System.out.println("get 1 tokens: " + r.acquire() + "s");
	}
	/**
	 * output: 基本上都是0.2s执行一次，符合一秒发放5个令牌的设定。
	 * get 1 tokens: 0.0s 
	 * get 1 tokens: 0.182014s
	 * get 1 tokens: 0.188464s
	 * get 1 tokens: 0.198072s
	 * get 1 tokens: 0.196048s
	 * get 1 tokens: 0.197538s
	 * get 1 tokens: 0.196049s
	 */
}

2、RateLimiter使用令牌桶算法，会进行令牌的累积，如果获取令牌的频率比较低，则不会导致等待，直接获取令牌。

public void testSmoothBursty2() {
	RateLimiter r = RateLimiter.create(2);
	while (true)
	{
		System.out.println("get 1 tokens: " + r.acquire(1) + "s");
		try {
			Thread.sleep(2000);
		} catch (Exception e) {}
		System.out.println("get 1 tokens: " + r.acquire(1) + "s");
		System.out.println("get 1 tokens: " + r.acquire(1) + "s");
		System.out.println("get 1 tokens: " + r.acquire(1) + "s");
		System.out.println("end");
		/**
		 * output:
		 * get 1 tokens: 0.0s
		 * get 1 tokens: 0.0s
		 * get 1 tokens: 0.0s
		 * get 1 tokens: 0.0s
		 * end
		 * get 1 tokens: 0.499796s
		 * get 1 tokens: 0.0s
		 * get 1 tokens: 0.0s
		 * get 1 tokens: 0.0s
		 */
	}
}

3、RateLimiter由于会累积令牌，所以可以应对突发流量。在下面代码中，有一个请求会直接请求5个令牌，但是由于此时令牌桶中有累积的令牌，足以快速响应。 RateLimiter在没有足够令牌发放时，采用滞后处理的方式，也就是前一个请求获取令牌所需等待的时间由下一次请求来承受，也就是代替前一个请求进行等待。

public void testSmoothBursty3() {
	RateLimiter r = RateLimiter.create(5);
	while (true)
	{
		System.out.println("get 5 tokens: " + r.acquire(5) + "s");
		System.out.println("get 1 tokens: " + r.acquire(1) + "s");
		System.out.println("get 1 tokens: " + r.acquire(1) + "s");
		System.out.println("get 1 tokens: " + r.acquire(1) + "s");
		System.out.println("end");
		/**
		 * output:
		 * get 5 tokens: 0.0s
		 * get 1 tokens: 0.996766s 滞后效应，需要替前一个请求进行等待
		 * get 1 tokens: 0.194007s
		 * get 1 tokens: 0.196267s
		 * end
		 * get 5 tokens: 0.195756s
		 * get 1 tokens: 0.995625s 滞后效应，需要替前一个请求进行等待
		 * get 1 tokens: 0.194603s
		 * get 1 tokens: 0.196866s
		 */
	}
}

三、平滑预热限流

RateLimiter的SmoothWarmingUp是带有预热期的平滑限流，它启动后会有一段预热期，逐步将分发频率提升到配置的速率。比如下面代码中的例子，创建一个平均分发令牌速率为2，预热期为3分钟。由于设置了预热时间是3秒，令牌桶一开始并不会0.5秒发一个令牌，而是形成一个平滑线性下降的坡度，频率越来越高，在3秒钟之内达到原本设置的频率，以后就以固定的频率输出。这种功能适合系统刚启动需要一点时间来“热身”的场景。

public void testSmoothwarmingUp() {
	RateLimiter r = RateLimiter.create(2, 3, TimeUnit.SECONDS);
	while (true)
	{
		System.out.println("get 1 tokens: " + r.acquire(1) + "s");
		System.out.println("get 1 tokens: " + r.acquire(1) + "s");
		System.out.println("get 1 tokens: " + r.acquire(1) + "s");
		System.out.println("get 1 tokens: " + r.acquire(1) + "s");
		System.out.println("end");
		/**
		 * output:
		 * get 1 tokens: 0.0s
		 * get 1 tokens: 1.329289s
		 * get 1 tokens: 0.994375s
		 * get 1 tokens: 0.662888s  上边三次获取的时间相加正好为3秒
		 * end
		 * get 1 tokens: 0.49764s  正常速率0.5秒一个令牌
		 * get 1 tokens: 0.497828s
		 * get 1 tokens: 0.49449s
		 * get 1 tokens: 0.497522s
		 */
	}
}

四、源码分析

看完了 RateLimiter的基本使用示例后，我们来学习一下它的实现原理。先了解一下几个比较重要的成员变量的含义。

RateLimiter r = RateLimiter.create(5);

public static RateLimiter create(double permitsPerSecond) {
  return create(permitsPerSecond, SleepingStopwatch.createFromSystemTimer());
}

@VisibleForTesting
static RateLimiter create(double permitsPerSecond, SleepingStopwatch stopwatch) {
  RateLimiter rateLimiter = new SmoothBursty(stopwatch, 1.0);//得到令牌的速率
  rateLimiter.setRate(permitsPerSecond);
  return rateLimiter;
}

2、重要的属性

//添加令牌时间间隔
double storedPermits;
//最大存储令牌数
double maxPermits;
//添加令牌时间间隔
double stableIntervalMicros;
/**
 * 下一次请求可以获取令牌的起始时间
 * 由于RateLimiter允许预消费，上次请求预消费令牌后
 * 下次请求需要等待相应的时间到nextFreeTicketMicros时刻才可以获取令牌
 */
private long nextFreeTicketMicros = 0L;

RateLimiter的原理就是每次调用acquire时用当前时间和 nextFreeTicketMicros进行比较，根据二者的间隔和添加单位令牌的时间间隔 stableIntervalMicros来刷新存储令牌数 storedPermits。如果令牌为空acquire会进行休眠，直到 nextFreeTicketMicros。

acquire函数如下所示，它会调用 reserve函数计算获取目标令牌数所需等待的时间，然后使用 SleepStopwatch进行休眠，最后返回等待时间。

@CanIgnoreReturnValue
public double acquire(int permits) {
  long microsToWait = reserve(permits);//计算获取令牌数量permits所需等待的时间
  stopwatch.sleepMicrosUninterruptibly(microsToWait);//进行线程sleep
  return 1.0 * microsToWait / SECONDS.toMicros(1L);
}

final long reserve(int permits) {
  checkPermits(permits);
  synchronized (mutex()) {//由于涉及并发操作，所以使用synchronized进行并发操作
    return reserveAndGetWaitLength(permits, stopwatch.readMicros());
  }
}

final long reserveAndGetWaitLength(int permits, long nowMicros) {
  long momentAvailable = reserveEarliestAvailable(permits, nowMicros);//计算从当前时间开始，能够获取到目标数量令牌时的时间
  return max(momentAvailable - nowMicros, 0);//两个时间相减，获得需要等待的时间
}

reserveEarliestAvailable是刷新令牌数和下次获取令牌时间nextFreeTicketMicros的关键函数。
它有三个步骤:

调用 resync函数增加令牌数
计算预支付令牌所需额外等待的时间
更新下次获取令牌时间 nextFreeTicketMicros和存储令牌数 storedPermits

这里涉及 RateLimiter的一个特性，也就是可以预先支付令牌，并且所需等待的时间在下次获取令牌时再实际执行。详细的代码逻辑的解释请看注释。

final long reserveEarliestAvailable(int requiredPermits, long nowMicros) {
	//刷新令牌数，相当于每次acquire时在根据时间进行令牌的刷新
	resync(nowMicros);
	long returnValue = nextFreeTicketMicros;
	
	//获取当前已有的令牌数和需要获取的目标令牌数进行比较，计算出可以目前即可得到的令牌数。
	double storedPermitsToSpend = min(requiredPermits, this.storedPermits);
	//freshPermits是需要预先支付的令牌，也就是目标令牌数减去目前即可得到的令牌数
	double freshPermits = requiredPermits - storedPermitsToSpend;
	// 因为会突然涌入大量请求，而现有令牌数又不够用，因此会预先支付一定的令牌数
	//waitMicros即是产生预先支付令牌的数量时间，则将下次要添加令牌的时间应该计算时间加上watiMicros
	long waitMicros = storedPermitsToWaitTime(this.storedPermits, storedPermitsToSpend)
			+ (long) (freshPermits * stableIntervalMicros);
	
	// storedPermitsToWaitTime在SmoothWarmingUp和SmoothBuresty的实现不同，用于实现预热缓冲期
	// SmoothBuresty的storedPermitsToWaitTime直接返回0，所以watiMicros就是预先支付的令牌所需等待的时间
	try {
		// 更新nextFreeTicketMicros,本次预先支付的令牌所需等待的时间让下一次请求来实际等待。
		this.nextFreeTicketMicros = LongMath.checkedAdd(nextFreeTicketMicros, waitMicros);
	} catch (ArithmeticException e) {
		this.nextFreeTicketMicros = Long.MAX_VALUE;
	}
	//更新令牌数，最低数量为0
	this.storedPermits -= storedPermitsToSpend;
	//返回旧的nextFreeTicketMicros数值，无需为预支付的令牌多加等待时间。
	return returnValue;
}
// SmoothBurest
long storedPermitsToWaitTime(double storedPermits, double permitsToTake) {
	return 0L;
}

resync函数用于增加存储令牌，核心逻辑就是 (nowMicros-nextFreeTicketMicros)/stableIntervalMicros。当前时间大于 nextFreeTicketMicros时进行刷新，否则直接返回。

//刷新令牌
void resync(long nowMicros) {
	// 当前时间晚于nextFreeTicketMicros，所以刷新令牌和nextFreeTicketMicros
	if (nowMicros > nextFreeTicketMicros) {
		// coolDownIntervalMicros函数获取每机秒生成一个令牌，SmoothWarmingUp和SmoothBuresty的实现不同
		// SmoothBuresty的coolDownIntervalMicros直接返回stableIntervalMicros
		// 当前时间减去要更新令牌的时间获取时间间隔，再除以添加令牌时间间隔获取这段时间内要添加的令牌数
		storedPermits = min(maxPermits,storedPermits + (nowMicros - nextFreeTicketMicros) / coolDownIntervalMicros());
		nextFreeTicketMicros = nowMicros;
	}
	// 如果当前时间早于nextFreeTicketMicros，则获取令牌的线程要一直等待到nextFreeTicketMicros,该线程获取令牌所需
	// 额外等待的时间由下一次获取的线程来代替等待。
}
double coolDownIntervalMicros() {
	return stableIntervalMicros;
}

下面我们举个例子，让大家更好的理解resync和reserveEarliestAvailable函数的逻辑。比如RateLimiter的stableIntervalMicros为500，也就是1秒发两个令牌，storedPermits为0，nextFreeTicketMicros为1553918495748。线程一acquire(2)，当前时间为1553918496248，首先resync函数计算，(1553918496248-1553918495748)/500=1，所以当前可获取令牌数为1，但是由于可以预支付，所以nextFreeTicketMicros=nextFreeTicketMicro+1*500=1553918496748。线程一无需等待。

紧接着，线程二也来acquire(2)，首先resync函数发现当前时间早于nextFreeTicketMicros，所以无法增加令牌数，所以需要预支付2个令牌，nextFreeTicketMicros=nextFreeTicketMicro+2*500=1553918497748。线程二需要等待1553918496748时刻，也就是线程一获取时计算的nextFreeTicketMicros时刻。同样的，线程三获取令牌时也需要等待到线程二计算的nextFreeTicketMicros时刻。

本文转载至：https://zhuanlan.zhihu.com/p/60979444

信仰_273993243

关注

0
点赞
踩
7

收藏

觉得还不错? 一键收藏
0
评论
限流-令牌桶限流-Guava RateLimiter

一、Guava的 RateLimiter提供了令牌桶算法实现1、平滑突发限流(SmoothBursty)2、平滑预热限流(SmoothWarmingUp)public abstract class RateLimiter { //平滑突发限流 static RateLimiter create(double permitsPerSecond, SleepingStopwatch stopwatch) { RateLimiter rateLimiter = new SmoothBursty(
复制链接

扫一扫