接上篇。Guava的令牌桶的实现中,包括一条设计哲学,需要大家注意:它允许瞬间的流量波峰超过QPS,但瞬间过后的请求将会等待较长的时间来缓解上次的波峰,以使得平均的QPS等于预定值。
RateLimiter类提供了令牌桶的接口,它是一个抽象类,其子类有SmoothRateLimiter(也是个抽象类)以及孙子类SmoothBursty,SmoothWarmingUp。SmoothRateLimiter类实现了算法的核心部分,因次我们暂且只讨论SmoothRateLimiter和其实现类SmoothBursty。RateLimiter都是通过静态的create函数实例化。以create(double permitsPerSecond)为例。参数permitsPerSecond为配置的QPS。该方法简洁明了,屏蔽了很多用户无需关心的细节。
public static RateLimiter create(double permitsPerSecond) {
return create(permitsPerSecond, SleepingStopwatch.createFromSystemTimer());
}
接着该方法调用了create(permitsPerSecond, SleepingStopwatch.createFromSystemTimer())方法(该方法由于是包的访问权限,在实际的项目中,基本不会直接调用),同时创建了一个StopWatch,自动启动。
static RateLimiter create(double permitsPerSecond, SleepingStopwatch stopwatch) {
RateLimiter rateLimiter = new SmoothBursty(stopwatch, 1.0 /* maxBurstSeconds */);
rateLimiter.setRate(permitsPerSecond);
return rateLimiter;
}
该方法创建了SmoothBursty实例,up-casting为RateLimiter。maxBurstSeconds固定为1,说明令牌桶中所能存储的的最大令牌数是1*QPS。接着调用setRate方法,该方法初始化一些重要的参数:
public final void setRate(double permitsPerSecond) {
checkArgument(
permitsPerSecond > 0.0 && !Double.isNaN(permitsPerSecond), "rate must be positive");
synchronized (mutex()) {
doSetRate(permitsPerSecond, stopwatch.readMicros());
<