guava限流超限问题

最新推荐文章于 2024-10-17 14:58:07 发布
最新推荐文章于 2024-10-17 14:58:07 发布
阅读量810 收藏 2
点赞数 1
分类专栏： java 文章标签： guava 限流 高并发 令牌桶 RateLimiter
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u010597819/article/details/117201971
版权

问题描述

前期测试期间设置：线程池fix大小3，限速2，但是出现了同时3个线程获取到令牌的场景，日志如下

2021-05-20 10:50:51.325 [0b17349516214790512533803e2612] [SystemReport-TP-0] INFO  c.d.m.manager.IAcsClientManager:65 - returnAcsClient=client-1, rate=2.0
2021-05-20 10:50:51.325 [0b17349516214790512533803e2612] [SystemReport-TP-2] INFO  c.d.m.manager.IAcsClientManager:65 - returnAcsClient=client-1, rate=2.0
2021-05-20 10:50:51.325 [0b17349516214790512533803e2612] [SystemReport-TP-1] INFO  c.d.m.manager.IAcsClientManager:65 - returnAcsClient=client-1, rate=2.0
2021-05-20 10:50:51.959 [0b17349516214790512533803e2612] [SystemReport-TP-2] INFO  c.d.m.manager.IAcsClientManager:65 - returnAcsClient=client-2, rate=2.0
2021-05-20 10:50:52.194 [0b17349516214790512533803e2612] [SystemReport-TP-0] INFO  c.d.m.manager.IAcsClientManager:65 - returnAcsClient=client-1, rate=2.0
2021-05-20 10:50:52.349 [0b17349516214790512533803e2612] [SystemReport-TP-1] INFO  c.d.m.manager.IAcsClientManager:65 - returnAcsClient=client-2, rate=2.0
2021-05-20 10:50:53.459 [0b17349516214790512533803e2612] [SystemReport-TP-0] INFO  c.d.m.manager.IAcsClientManager:65 - returnAcsClient=client-1, rate=2.0
2021-05-20 10:50:53.504 [0b17349516214790512533803e2612] [SystemReport-TP-2] INFO  c.d.m.manager.IAcsClientManager:65 - returnAcsClient=client-2, rate=2.0
2021-05-20 10:50:53.559 [0b17349516214790512533803e2612] [SystemReport-TP-1] INFO  c.d.m.manager.IAcsClientManager:65 - returnAcsClient=client-1, rate=2.0
2021-05-20 10:50:54.164 [0b17349516214790512533803e2612] [SystemReport-TP-2] INFO  c.d.m.manager.IAcsClientManager:65 - returnAcsClient=client-2, rate=2.0
2021-05-20 10:50:54.167 [0b17349516214790512533803e2612] [SystemReport-TP-1] INFO  c.d.m.manager.IAcsClientManager:65 - returnAcsClient=client-1, rate=2.0
2021-05-20 10:50:54.209 [0b17349516214790512533803e2612] [SystemReport-TP-0] INFO  c.d.m.manager.IAcsClientManager:65 - returnAcsClient=client-2, rate=2.0
2021-05-20 10:50:54.664 [0b17349516214790512533803e2612] [SystemReport-TP-2] INFO  c.d.m.manager.IAcsClientManager:65 - returnAcsClient=client-1, rate=2.0
2021-05-20 10:50:54.668 [0b17349516214790512533803e2612] [SystemReport-TP-1] INFO  c.d.m.manager.IAcsClientManager:65 - returnAcsClient=client-2, rate=2.0
2021-05-20 10:50:54.702 [0b17349516214790512533803e2612] [SystemReport-TP-2] INFO  c.d.m.manager.IAcsClientManager:65 - returnAcsClient=client-1, rate=2.0
2021-05-20 10:50:54.709 [0b17349516214790512533803e2612] [SystemReport-TP-1] INFO  c.d.m.manager.IAcsClientManager:65 - returnAcsClient=client-2, rate=2.0
2021-05-20 10:50:54.959 [0b17349516214790512533803e2612] [SystemReport-TP-2] INFO  c.d.m.manager.IAcsClientManager:65 - returnAcsClient=client-1, rate=2.0
2021-05-20 10:50:55.164 [0b17349516214790512533803e2612] [SystemReport-TP-2] INFO  c.d.m.manager.IAcsClientManager:65 - returnAcsClient=client-2, rate=2.0
2021-05-20 10:50:55.791 [0b17349516214790512533803e2612] [SystemReport-TP-2] INFO  c.d.m.manager.IAcsClientManager:65 - returnAcsClient=client-1, rate=2.0

在第一秒出现了超速现象，3个线程获取到了资源开始执行任务。。。

问题分析

代码实现，并发场景下3个线程读取的lastIndex可能为同一个值，也就是说获取到了同一个限流器，理应只有两个线程执行任务，一个线程等待，但事实上我们看到第一批次出现了超速

// 限流器构造方法
RateLimiter.create(2);
// 获取客户端
private IAcsClient getClientInner() {
  for (int i = 0; i < QueryEagleeyeConstant.WAIT_CLIENT_THRESHOLD; i++) {
    for (int j = 0; j < CLIENT_CACHE.size(); j++) {
      ClientLimiterDTO clientLimiter = CLIENT_CACHE.get(j);
      if (clientLimiter.getRateLimiter()
          // 5 ms
          .tryAcquire(QueryEagleeyeConstant.WAIT_PERMIT_THRESHOLD, TimeUnit.MILLISECONDS)) {
        log.info("returnAcsClient={}, rate={}",
            ((DefaultAcsClient) clientLimiter.getIAcsClient()).getProfile()
                .getCredential().getAccessKeyId(),
            clientLimiter.getRateLimiter().getRate());
        return clientLimiter.getIAcsClient();
      }
    }
    try {
      // 休眠 5 ms 后重试
      Thread.sleep(QueryEagleeyeConstant.WAIT_PERMIT_THRESHOLD);
    } catch (InterruptedException e) {
      // do nothing
    }
  }
  return null;
}

源码看一波

限流器创建

guava采用令牌桶算法，提供两种实现：Bursty（尖刺）/warmUp（预热），默认构造器使用的限流类型为：尖刺版本，也就是说请求同时来，只要有令牌都放行，另外一个类型则是warmUp版本，即存在一个冷启动阶段，避免服务被瞬间流量打垮

public static RateLimiter create(double permitsPerSecond) {
  /*
   * 为了避免并发失速问题，生产未使用的令牌的时间可能会超过1秒，例如：限流1qps，4个线程同时访问
   * The default RateLimiter configuration can save the unused permits of up to one second.
   * This is to avoid unnecessary stalls in situations like this: A RateLimiter of 1qps,
   * and 4 threads, all calling acquire() at these moments:
   *
   * T0 at 0 seconds
   * T1 at 1.05 seconds
   * T2 at 2 seconds
   * T3 at 3 seconds
   * 由于T1线程延迟了，所以T2应该延迟至2.05秒放行，T3也应延迟至3.05秒放行
   * Due to the slight delay of T1, T2 would have to sleep till 2.05 seconds,
   * and T3 would also have to sleep till 3.05 seconds.
   */
    // 创建计时器用于构造限流实例
  return create(SleepingStopwatch.createFromSystemTimer(), permitsPerSecond);
}
static RateLimiter create(SleepingStopwatch stopwatch, double permitsPerSecond) {
  RateLimiter rateLimiter = new SmoothBursty(stopwatch, 1.0 /* maxBurstSeconds */);
  rateLimiter.setRate(permitsPerSecond);
  return rateLimiter;
}

设置速率

public final void setRate(double permitsPerSecond) {
  checkArgument(
      permitsPerSecond > 0.0 && !Double.isNaN(permitsPerSecond), "rate must be positive");
  // 互斥锁
  synchronized (mutex()) {
    // 设置速率
    doSetRate(permitsPerSecond, stopwatch.readMicros());
  }
}
final void doSetRate(double permitsPerSecond, long nowMicros) {
  // 基于当前时间nowMicros更新令牌数，以及下次生产令牌的时间
  // 如果当前时间大于nextFreeTicketMicros则将nextFreeTicketMicros更新为当前时间nowMicros
  resync(nowMicros);
  double stableIntervalMicros = SECONDS.toMicros(1L) / permitsPerSecond;
  this.stableIntervalMicros = stableIntervalMicros;
  doSetRate(permitsPerSecond, stableIntervalMicros);
}
void doSetRate(double permitsPerSecond, double stableIntervalMicros) {
  double oldMaxPermits = this.maxPermits;
  // 最大令牌数，1s * 每秒生产令牌数
  maxPermits = maxBurstSeconds * permitsPerSecond;
  // storedPermits初始化为0
  if (oldMaxPermits == Double.POSITIVE_INFINITY) {
    // if we don't special-case this, we would get storedPermits == NaN, below
    storedPermits = maxPermits;
  } else {
    storedPermits = (oldMaxPermits == 0.0)
        ? 0.0 // initial state
        : storedPermits * maxPermits / oldMaxPermits;
  }
}

获取令牌

public boolean tryAcquire(int permits, long timeout, TimeUnit unit) {
  long timeoutMicros = max(unit.toMicros(timeout), 0);
  checkPermits(permits);
  long microsToWait;
  // 互斥锁
  synchronized (mutex()) {
    // 当前时间 - 限流器构建时间点 毫秒数
    long nowMicros = stopwatch.readMicros();
    // 根据超时参数判断是否可以获取令牌
    // queryEarliestAvailable返回nextFreeTicketMicros初始值为限流器创建时间
    // nextFreeTicketMicros令牌库存大于等于令牌申请数时为申请令牌时的时间
    // nextFreeTicketMicros令牌库存小于令牌申请数时为：
    // nextFreeTicketMicros+缺口令牌数生产需要花费的时间
    // nextFreeTicketMicros - timeoutMicros <= nowMicros 则返回true
    // 即：nextFreeTicketMicros - nowMicros <= timeoutMicros
    // 查看reserveAndGetWaitLength代码，最大等待值一定<=timeoutMicros
    if (!canAcquire(nowMicros, timeoutMicros)) {
      return false;
    } else {
      // 预定令牌并获取获取令牌需要等待的时间
      microsToWait = reserveAndGetWaitLength(permits, nowMicros);
    }
  }
  // 如果令牌供求小于需求，等待令牌生产
  stopwatch.sleepMicrosUninterruptibly(microsToWait);
  return true;
}

限流器放行规则图解

  1. 时间点A获取令牌失败，不放行
  2. 时间点B获取令牌成功，放行
  3. 分界线为超时时间左边界

1

预定令牌并获取获取令牌需要等待的时间

final long reserveAndGetWaitLength(int permits, long nowMicros) {
  // momentAvailable = nextFreeTicketMicros
  long momentAvailable = reserveEarliestAvailable(permits, nowMicros);
  // nextFreeTicketMicros - nowMicros <= timeoutMicros
  // 最大等待值一定<=timeoutMicros
  return max(momentAvailable - nowMicros, 0);
}
final long reserveEarliestAvailable(int requiredPermits, long nowMicros) {
  // 基于当前时间nowMicros更新令牌数，以及下次生产令牌的时间
  // 如果当前时间大于nextFreeTicketMicros则将nextFreeTicketMicros更新为当前时间nowMicros
  // 因为令牌数已经满足需求数，可以直接返回
  resync(nowMicros);
  long returnValue = nextFreeTicketMicros;
  double storedPermitsToSpend = min(requiredPermits, this.storedPermits);
  double freshPermits = requiredPermits - storedPermitsToSpend;
  // 1. 令牌库存 >= 需求，不需要等待，waitMicros=0，storedPermitsToWaitTime，预热版本存在冷启动时间
  // 2. 令牌库存 < 需求，需要等待，等待时间为缺口数量*生产单个令牌时间，预热版本会额外增加预热时间storedPermitsToWaitTime
  long waitMicros = storedPermitsToWaitTime(this.storedPermits, storedPermitsToSpend)
      + (long) (freshPermits * stableIntervalMicros);
  try {
    this.nextFreeTicketMicros = LongMath.checkedAdd(nextFreeTicketMicros, waitMicros);
  } catch (ArithmeticException e) {
    this.nextFreeTicketMicros = Long.MAX_VALUE;
  }
  // 如果存在库存递减令牌数
  this.storedPermits -= storedPermitsToSpend;
  // 返回nextFreeTicketMicros
  return returnValue;
}

无并发问题，那么为什么会超速呢？-_-!!!
查看官网已经有人发现了限速不精确的问题（https://github.com/google/guava/issues/5296），但是与我的场景不符

复现问题

模拟线上场景尝试复现问题

public static void main(String[] args) throws InterruptedException {
  ExecutorService SYSTEM_REPORT_THREAD_POOL = Executors.newFixedThreadPool(6);
  RateLimiter rateLimiter = RateLimiter.create(2);
  Thread.sleep(2000);
  for (int i = 0; i < 3; i++) {
    final int j = i;
    SYSTEM_REPORT_THREAD_POOL.submit(new Thread(() -> {
      if (rateLimiter.tryAcquire(5, TimeUnit.MILLISECONDS)) {
        log.info("do something");
      }
    }));
  }
  Thread.sleep(Integer.MAX_VALUE);
}

输出结果

11:33:24.620 [pool-1-thread-1] INFO com.....monitor.manager.IAcsClientManager - do something
11:33:24.620 [pool-1-thread-3] INFO com.....monitor.manager.IAcsClientManager - do something
11:33:24.620 [pool-1-thread-2] INFO com.....monitor.manager.IAcsClientManager - do something

问题原因

断点关注第三次放行的过程数据，发现com.google.common.util.concurrent.RateLimiter#reserveEarliestAvailable方法返回值依然等于nowMicros，该方法返回nextFreeTicketMicros值，但是由于前两次的获取令牌时，令牌库存满足，所以nextFreeTicketMicros不会递增即等于上次获取令牌的时间，第三个线程的nowMicros一定大于第二个线程的nowMicros，所以resync方法会将nextFreeTicketMicros更新为第三个线程的nowMicros。有点绕，搞个流程配个图咯

  1. 线程1 执行
  2. tryAcquire：线程1尝试获取令牌
  3. resync：nowMicros > nextFreeTicketMicros，resync将nextFreeTicketMicros更新为当前时间nowMicros，刷新令牌桶库存
  4. 计算wait时间waitMicros=令牌缺口数量*生产单个令牌所需时间**（仅考虑非预热版本，预热版本需要额外增加预热时间）**
  5. add nextFreeTicketMicros：nextFreeTicketMicros=nextFreeTicketMicros + waitMicros**（缺口数量为0时则waitMicros=0）**
  6. 令牌数-min（申请令牌数，令牌库存）
  7. 返回add前的nextFreeTicketMicros**（缺口数量为0时，则nextFreeTicketMicros为当前时间nowMicros）**
  8. 返回休眠时间=max(momentAvailable - nowMicros, 0)。momentAvailable为add nextFreeTicketMicros前的nextFreeTicketMicros时间，此时=nextFreeTicketMicros=nowMicros。因此休眠时间为0，直接返回true，获取令牌成功
  9. 线程2流程与线程1完全相同，因为排他锁，必然线程2的nowMicros>线程1的nowMicros，流程与线程1完全相同，最终nextFreeTicketMicros=线程2的nowMicros，休眠时间为0
  10. 线程3的nowMicros>线程2的nowMicros，由于缺口数量不为0，此时申请的令牌数为3，库存为2，缺口为1，nextFreeTicketMicros会被递增至nextFreeTicketMicros+waitMicros，返回递增前的nextFreeTicketMicros，此时依然为线程3的nowMicros，因为线程3的nowMicros>递增前的nextFreeTicketMicros（线程2的nowMicros）
  11. 此时出现超速为1的场景，即限速2。

2

小结

令牌桶满的时候再次进入多个线程会出现超速1的场景

解决方案

  1. 改用预热版本令牌桶 warmUp
  2. 针对于我们当前场景对限流器进行交叉使用也可以减少该问题的出现

总结

优势

  1. 相比sentinel限流，guava api用法更为简单，学习成本低。api用例如下
// 限流器构造方法
RateLimiter rateLimiter = RateLimiter.create(2);
// 获取令牌 最大等待令牌的生产时间，如果预计等待时间超出指定超时值则直接返回false，
// 否则休眠后返回获取令牌成功
// 案例为 5 ms
if (rateLimiter.tryAcquire(5, TimeUnit.MILLISECONDS)) {
    // do something
}

劣势

  1. 不能动态调整限流值
  2. 不支持分布式
  3. 限流算法单一，guava采用令牌桶算法实现

个人认为劣势中的2，3点是可接受的，分布式可以通过改造封装支持，如果服务上层负载均衡理想，那么单机的限流也未尝不可，毕竟限流值每台机器均分即可。个人拙见，欢迎大家留言讨论哦-

太阳伞下的阿呆
关注
专栏目录
Guava——平滑限流
ShiXueTanLang的博客
07-08 3570
1.常用限流方法对于一个应用系统来说一定会有极限并发/请求数，即总有一个TPS/QPS阀值，如果超了阀值则系统就会不响应用户请求或响应的非常慢，因此我们最好进行过载保护，防止大量请求涌入击垮系统。常见的限流方法有：容器限流常见的web容器其实也具备限流的功能。以Tomcat容器为例，其Connector 其中一种配置有如下几个参数：acceptCount：如果Tomcat的线程都忙于响应，新来的连...
限流浅析
kshzhaohui的专栏
12-07 320
前言 我们每个系统在做压测的时候，都有一个处理峰值，当接近峰值继续接受请求的时候，会导致整个系统响应缓慢；为了保护系统，需要拒绝处理过载的请求，这就是我们下面介绍的限流，通过设定一个峰值阈值，限制请求达到这个峰值，以此来保护系统；我们常见的一些中间件比如tomcat，mysql，redis等等都有类似的限制。 限流算法 做限流的时候我们有一些常用的限流算法包括：计数器限流，令牌桶限流，漏桶限流； 1.令牌桶限流 令牌桶算法的原理是系统以一定速率向桶中放入令牌，填满了就丢弃令牌；请求来时会先从桶中取出令牌
Guava限流
weixin_43589025的博客
03-19 4365
Guava限流 文章目录Guava限流为什么要做限流原理漏桶算法令牌桶算法实战 为什么要做限流 通常我们的应用在部署之前都会先进行评估，有多少的调用量，需要多少台机器，能承受多大的流量；但是难免会有流量突然增大的时候，比如某时段某个接口突然遭受攻击，这时候某些机器可能会承受不了这个压力，导致崩溃，从而导致整个系统不可用。其实就像我们生活中，电闸的保险丝一样，突然使用了大功率的电器，导致保险丝就会烧断以保护各个电器不被强电流给烧坏；而在我们的系统中，就是设置一定的阈值，保护我们的系统能正常运行。 通常我们流量
源码解析：Guava客户端限流
Diligence is the mother of success.
08-17 71
1、背景客户端限流 PK 分布式限流客户端限流：当应用为单点应用时，只要应用进行了限流，那么应用所依赖的各种服务也都得到了保护。分布式限流：线上业务出于各种原因考虑，多是分布式系统，单节点的限流仅能保护自身节点，但无法保护应用依赖的各种服务，并且在进行节点扩容、缩容时也无法准确控制整个服务的请求限制网关层限流服务网关，作为整个分布式链路中的第一道关卡，承接了所有用户来访请求。我们在网关层进行限流，...
guava限流
weixin_34318956的博客
05-30 171
<!--google guava 限流--><dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>23.0</version></dependency> ...
Guava实现限流
2301_79376376的博客
09-10 2066
网上讲解限流算法的很多，自己实践一下印象会更深刻，所以在自己项目上实现了引入Guava做限流。@Retention(RetentionPolicy.RUNTIME)//修饰注解，用来表示注解的生命周期@Target({ElementType.METHOD})//注解的作用目标，这个表示注解到方法/*** 资源的key,唯一* 作用：不同的接口，不同的流量控制*//*** 限制次数（每秒）*//*** 最大等待时间*//*** 最大等待时间的单位，默认毫秒*/
guava实现限流
qq_35137375的博客
02-29 1633
在秒杀中，我们需要实现限制客户端的流量，常用的实现限流的方式有:hystrix、nginx、guava等方式。下面我们介绍下guava如何实现限流 1.maven引入 <dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId>...
架构师成长之路之限流
surlymo的博客
03-19 567
架构师成长之路之限流 文章目录架构师成长之路之限流1. 我们为什么需要限流2. 我们常见的限流手段2.1 信号量计数2.2 线程池隔离2.3 固定窗口计数2.4 自然窗口计数2.5 滑动窗口计数2.5.1 基于共享分布式内存2.5.2 基于本地内存2.6 令牌桶和漏桶算法计数3. 微服务限流几个考虑的点3.1 机器时钟不一致或者时钟回退问题3.2 在SDK还是Server端做限流逻辑3.3 限流...
bucket4j-基于令牌桶算法的Java速率限制库
08-07
此外，库本身是高度可扩展的，可以与其他存储解决方案（如Redis、Guava Cache等）集成，实现分布式限流。 5. **版本与源码分析**：从提供的文件名"vladimir-bukhtoyarov-bucket4j-00ed906"来看，这可能是Bucket4j的...
秒杀项目的总结及面试常见问题
m0_67393413的博客
07-30 2062
做的是一个秒杀系统，首先是登录系统，采用的是用户的手机号作为用户名，登录的时候先去判断手机号是否存在，然后再判断密码是否正确。当进行密码判断时，为了保证用户的密码的安全性，我这里使用了md5进行两次加密操作，首先通过salt值对输入密码进行第一次加密md5加密从而防止网络传输的过程中密码被截取，然后在到达服务端后在进行第二次md5加密是为了防止数据库的信息泄露时用户信息被反推出来，之后再将客户端输入密码与数据库中的密码相对比。...
互联网大厂的微服务架构系统应对超大流量解决方案
msbz7的博客
09-13 541
常见的限流方式有：限制总并发数（数据库连接池、线程池等等）限制瞬时并发数（如Nginx的limit_conn模块）限制时间窗口的平均速率（如Guava的RateLimiter、Nginx的limit_req模块）限制远程接口的调用速率、限制消息系统的消费速率抗疫项目中，一般ISV会把Nginx作为业务的接入层，通过Nginx将请求分发到后端的应用集群上。接入层(流量层)是整个系统的咽喉入口, 越早挡掉请求越好，扛不住的流量越往后端传递，对后端的压力越大。1.1.1 Nginx限流官方提供两个模块:limit
SpringBoot简单的直接连接Redis数据库+操作redis数据库存取值
2401_84010061的博客
04-18 439
我们总是喜欢瞻仰大厂的大神们，但实际上大神也不过凡人，与菜鸟程序员相比，也就多花了几分心思，如果你再不努力，差距也只会越来越大。实际上，作为程序员，丰富自己的知识储备，提升自己的知识深度和广度是很有必要的。
使用Guava实现限流器
程序员囧辉
06-17 2万+
为什么需要限流？在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流。限流可以认为服务降级的一种，限流通过限制请求的流量以达到保护系统的目的。一般来说，系统的吞吐量是可以计算出一个阈值的，为了保证系统的稳定运行，一旦达到这个阈值，就需要限制流量并采取一些措施以完成限制流量的目的。比如：延迟处理，拒绝处理，或者部分拒绝处理等等。否则，很容易导致服务器的宕机。现有的方案Google的Guava工...
Guava接口限流指南
Fgdbfh的博客
03-20 308
在Java项目中使用接口限流通常是为了保护系统免受过度请求的影响，以及防止资源被滥用。
实战限流（guava的RateLimiter）
热门推荐
程序员欣宸的博客
07-18 3万+
guava的RateLimiter使用的是令牌桶算法，也就是以固定的频率向桶中放入令牌，本文实战一下RateLimiter的用法。
guava的限流器实现
最新发布
m0_50149847的博客
10-17 1004
限流器是一种控制请求流量的机制，通常用于计算机网络、API、数据库等场景，以保护系统免受过载或滥用。
Guava--限流处理
天道酬勤
05-30 563
package com.zhoujianpeng.project.Guava.monitor; import com.google.common.base.Stopwatch; import com.google.common.util.concurrent.RateLimiter; import java.util.concurrent.ThreadLocalRandom; import ...
guava本地限流
焱童鞋
03-09 280
设置每5秒内的第一个不同数据请求进入 @Aspect @Configuration @Slf4j public class LockMethodAspect { //设置每5秒中的第一个不同数据的请求可以进入 private static final Cache<String, Object> CACHE = CacheBuilder.newBuilder().maximumSize(1000).expireAfterWrite(5, TimeUnit.SECONDS)
Guava RateLimiter怎么用于接口限流
03-29
Guava RateLimiter是一个基于令牌桶算法的限流工具，可以用于接口限流。 以下是使用Guava RateLimiter实现接口限流的步骤： 1. 创建一个RateLimiter对象，设置每秒允许通过的请求数。 ``` RateLimiter ...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值