使用resilience4j或其他方案对重试指定次数后的WebClient请求限流

完全可以通过Resilience4j实现你要的细粒度限流，不需要配置全局限流规则，仅针对符合条件的请求或URL生效即可，两种实现思路如下：

1. 按特定URL粒度限流 #

核心逻辑是为每个目标URL维护独立的限流器实例，仅当该URL的累计重试次数达到你设定的阈值后，才启用对应限流器控制请求速率，避免恢复时突增流量打垮服务。
改造后的示例代码如下：

import io.github.resilience4j.ratelimiter.RateLimiter;
import io.github.resilience4j.ratelimiter.RateLimiterConfig;
import io.github.resilience4j.reactor.ratelimiter.operator.RateLimiterOperator;
import io.github.resilience4j.reactor.retry.RetryOperator;
import reactor.core.publisher.Mono;
import java.time.Duration;
import java.util.concurrent.ConcurrentHashMap;

// 全局维护URL和对应限流器的映射
private final ConcurrentHashMap<String, RateLimiter> urlLimiterMap = new ConcurrentHashMap<>();
// 触发限流的重试次数阈值
private static final int RETRY_TRIGGER_THRESHOLD = 5;
// 限流器配置：可根据业务调整，例：每秒最多放10个请求到对应URL
private final RateLimiterConfig limiterConfig = RateLimiterConfig.custom()
        .limitForPeriod(10)
        .limitRefreshPeriod(Duration.ofSeconds(1))
        .timeoutDuration(Duration.ofMillis(50))
        .build();

public void sendRequest(String targetUrl, Object reqBody) {
    webClient.post()
            .bodyValue(reqBody)
            .uri(targetUrl)
            .retrieve()
            .bodyToMono(Void.class)
            // 原有重试逻辑，新增重试次数判断
            .retryWhen(Retry.backoff(96, Duration.ofMinutes(15)) // 1天共96次15分钟间隔的重试
                    .doAfterRetry(retryContext -> {
                        // 重试次数达到阈值后为该URL初始化限流器
                        if (retryContext.getTotalRetries() >= RETRY_TRIGGER_THRESHOLD) {
                            urlLimiterMap.computeIfAbsent(targetUrl, key -> RateLimiter.of(key, limiterConfig));
                        }
                    }))
            // 仅当该URL存在限流器时应用限流规则
            .transformDeferred(originalMono -> {
                RateLimiter limiter = urlLimiterMap.get(targetUrl);
                return limiter != null ? originalMono.transformDeferred(RateLimiterOperator.of(limiter)) : originalMono;
            })
            .subscribe();
}

2. 按单请求重试次数限流 #

如果不需要按URL聚合控制，仅要对已经重试x次的单个请求做限速，也可以直接在重试回调中加入动态延迟逻辑，或者给符合条件的请求单独绑定限流器，粒度比URL维度更灵活。

优化建议 #

• 可以给限流器增加过期回收逻辑：如果某个URL连续30分钟没有出现重试触发的请求，就从映射表中移除对应的限流器，恢复正常请求速率，避免不必要的性能开销。
• 也可以直接用Resilience4j自带的RateLimiterRegistry来管理不同URL的限流器，本质和自行维护ConcurrentHashMap逻辑一致，不需要额外开发映射逻辑。

该方案和熔断器能力不冲突，熔断器负责在服务不可用时切断请求避免无效重试，本方案负责在服务恢复时控制请求量级，二者可以同时启用互不干扰。

内容的提问来源于stack exchange，提问作者flamethrower