当接入大模型 API（如 OpenAI/DeepSeek/文心一言/阿里千问）时，最令人头疼的错误之一就是：429 Too Many Requests 或国内模型的 439 Request Blocked。

如何在高并发、长耗时、多请求的场景下优雅处理限流？如何做到不浪费计算、不阻塞线程、还能最大化吞吐？

本文从工程角度介绍：

• 限流的本质

• 延迟重试（Delay Retry）的核心思想

• 两种架构模式：单请求延迟重试 与 全量请求同步延迟重试（群体退避）

• 如何避免阻塞线程池

• 最推荐的限流方案

• 可直接使用的 Java 完整代码（含 CompletableFuture）

---

一、限流本质：为什么你会被 429/439

大模型 API 普遍会对以下维度限流：

1. QPS（每秒请求数）

2. 并发连接数

3. Token 每分钟限制（TPM）

4. Key 级别限流 / 帐号级别限流

当你：

• 并发过高

• 请求时间过长（导致连接堆积）

• 数百条任务瞬间一起请求模型

后台就会直接拒绝请求，返回 429/439。

注意：模型限流不是"固定时间窗"，是动态限流，在模型负载高的时刻，随时可能触发。

---

二、延迟请求处理（Delay Retry）的核心思想

延迟请求处理，是一个非常成熟的反限流技术。

核心原则：

不要在限流期间硬撞接口 → 等一段时间 → 再发

优点：

• 避免无意义的重试风暴

• 避免线程阻塞

• 请求可继续高并发，只是执行时间整体后移

延迟策略常见形式：

策略	描述
固定延迟（Fixed Delay）	每次延迟固定时间，如 30 秒
指数退避（Exponential Backoff）	1s → 2s → 4s → 8s，提高系统稳定性
群体退避（Global Backoff）	一旦出现 429/439，全系统统一延迟

---

三、架构模式：两种延迟策略

模式一：单请求延迟重试（最常见）

每个请求独立处理，如果被限流，则单独延迟。

请求 A → 429 → 延迟 30s → 重试
请求 B → 正常

优点：实现简单、不影响其他请求

缺点：如果模型持续高负载，会有大量请求分别重试，依然会撞到限流

---

模式二：全量同步延迟（群体退避，全局 Backoff）

思路：

只要一个请求收到 439，则规定系统所有请求都必须延迟 X 秒。

请求 A → 439 → 设置 globalDelay = 当前时间 + 30 秒
请求 B/C/D/E → 发现 globalDelay 未过去 → 统统延迟执行

优点：极大减少限流次数，非常稳定

缺点：所有请求都会被整体“拖后”，但吞吐率更稳定

适用于：

• 高并发调用大模型

• 大模型经常 429/439

• 任务量大且耗时高

---

四、避免线程阻塞：必须使用 CompletableFuture

这是最关键的部分。

错误示例：

Thread.sleep(30_000); // ❌ 会阻塞线程池，越积越多

必须改为：

return CompletableFuture.supplyAsync(() -> {
    // 30s 后执行
}, scheduledExecutorAfterDelay)

---

五、完整 Java 代码：支持限流延迟、群体退避、可配置重试

以下 Java 代码可直接复制使用。

1. 全局延迟器（AtomicLong）

// 下次可执行时间（时间戳 ms）
private final AtomicLong globalNextTime = new AtomicLong(0);

2. 任务执行方法

public CompletableFuture<String> callWithRetry(Supplier<String> apiCall,
                                               int maxAttempts,
                                               long delayMillis) {
    return attempt(apiCall, maxAttempts, delayMillis, 1);
}

3. 核心 attempt 实现

private CompletableFuture<String> attempt(Supplier<String> apiCall,
                                          int maxAttempts,
                                          long delayMillis,
                                          int attempt) {

    long now = System.currentTimeMillis();
    long next = globalNextTime.get();

    // 如果全局延迟还没过去，则延迟执行
    if (now < next) {
        long wait = next - now;
        return delayed(wait).thenCompose(v -> attempt(apiCall, maxAttempts, delayMillis, attempt));
    }

    return CompletableFuture.supplyAsync(apiCall)
            .handleAsync((result, ex) -> {
                if (ex == null) {
                    return CompletableFuture.completedFuture(result);
                }

                String msg = ex.getMessage().toLowerCase();

                // 判断限流类错误
                boolean isRateLimit = msg.contains("429") || msg.contains("439");

                if (isRateLimit && attempt < maxAttempts) {
                    // 设置全局退避时间
                    globalNextTime.set(System.currentTimeMillis() + delayMillis);

                    return delayed(delayMillis)
                            .thenCompose(v -> attempt(apiCall, maxAttempts, delayMillis, attempt + 1));
                }

                // 其他错误或重试用尽
                return CompletableFuture.failedFuture(ex);
            })
            .thenCompose(f -> f);
}

4. 延迟工具

private CompletableFuture<Void> delayed(long millis) {
    CompletableFuture<Void> future = new CompletableFuture<>();
    scheduler.schedule(() -> future.complete(null), millis, TimeUnit.MILLISECONDS);
    return future;
}

---

六、实际效果分析

场景 1：瞬时并发 100 个任务

• 假设第 3 个任务触发 439

• 系统立即进入“群体退避 30 秒”

• 所有其他任务都延迟 30 秒执行

结果：

• 避免了 100 个请求分别撞限流

• 大模型稳定响应

• 不阻塞线程池

场景 2：大模型持续高负载（连续 429）

• globalNextTime 会不断往后推

• 所有请求都会统一等待

• 性能稳定、不报错

---

七、最佳实践建议

1. 不要疯狂重试，推荐 2~3 次

因为大模型限流不是短暂的，很可能持续几十秒。

2. 建议全局 Backoff，而不是每个请求自己延迟

单请求延迟会导致限流风暴：很多请求一起撞 → 一起延迟 → 一起撞

3. 多个 key 轮询不能本质解决限流

只是把总量切片，无法真正增加配额。

4. 必须采用 CompletableFuture，不要阻塞线程池

阻塞会导致：

• 新任务无法提交

• 线程池打满

• 服务自爆

5. 建议结合“排队 + 速率控制器”进一步优化

例如：

• 使用 Disruptor

• 使用 Guava RateLimiter

• 使用 Redis + Lua 自定义限流

---

八、可选升级：分布式版本

如果你的服务是多副本部署：

• globalNextTime 可放到 Redis，一个节点限流 → 全集群进入延迟

• 可避免单节点限流导致的集群不一致

---

九、总结

延迟请求处理（Delay Retry）是应对大模型限流最有效、最稳定、最易落地的方案。

本文从限流本质、架构理念、线程池安全性、群体退避机制等多方面介绍了完整实践，并提供了可直接复制使用的 Java 实战代码。