之前接了一个 Agent 平台的项目上线前压测一切正常结果刚上生产就连续报警。排查下来发现真正的瓶颈不在底层模型也不在业务数据库而在于 Agent 接口本身的流量特征——它和传统 REST 接口完全不一样同样的并发量Agent 接口能把后端服务打穿。后来我把整个防护体系总结成四层缓存、限流、负载均衡、熔断。这套组合拳对 Agent 服务的高并发防护非常有效。本文会完整拆解这套方案的原理、代码实现和踩坑记录适合正在做 Agent 应用后端、AI 应用平台开发或者对高并发系统设计感兴趣的开发者。1. 背景Agent 接口为什么高并发压力更大1.1 什么是 Agent 接口先明确概念。这里的 Agent 接口不是单纯的 HTTP CRUD 接口而是提供给上层应用调用的智能体服务接口。它的典型特征是一个请求进来服务端不是立刻返回结果而是经历多轮内部推理、工具调用、上下文组装最后才返回一个完整结果。很多 Agent 服务还支持流式输出也就是请求一旦建立连接会长时间保持数据不断从服务端推向客户端。这和传统的“请求-响应”模式有本质区别。换句话说Agent 接口的核心单元是“一次完整的智能任务执行”而不是“一次简短的数据库查询”。1.2 Agent 与普通接口的流量特征差异普通接口的流量特点通常是高频、单次耗时短、无状态、可水平扩展。比如一个商品列表接口QPS 可以做到几千甚至上万因为它每次请求就是一次查询几毫秒就返回。Agent 接口则完全相反特征普通接口Agent 接口单次耗时毫秒级秒级甚至分钟级QPS高相对低但并发数可能很高连接占用短长连接或流式连接状态通常无状态需维护会话上下文下游依赖数据库、缓存模型服务、工具服务、知识库等正因如此Agent 接口出现高并发时压力会被放大一个用户的 Agent 请求可能同时触发多个工具调用每个工具调用又依赖一个下游服务。如果 100 个用户同时发起请求后端实际产生的下游调用可能是 300 到 500 次。这就是标题里说的“比普通接口猛多了”的根本原因。1.3 为什么 Agent 场景更容易引发雪崩雪崩的本质是某个环节的故障被流量放大导致整个链路崩溃。在 Agent 场景中这个放大效应尤其明显个别 Agent 请求超时后客户端往往会自动重试重试流量再次涌入。Agent 执行过程中调用模型服务模型服务响应变慢线程池被占满。线程池占满后新的请求排队等待触发新的超时形成恶性循环。如果缓存集中失效所有请求同时打到数据库或下游工具服务系统瞬间被打垮。所以Agent 服务不能只靠“加机器”来抗压。必须从入口到出口设计一套完整的防护机制让每一层都有自己的降级预案。2. 环境准备与项目结构2.1 技术选型与版本说明本文示例以 Java Spring Boot 为主配合 Redis、Sentinel、Resilience4j 和 Nginx 来讲解。这不是唯一方案Python FastAPI、Go Gin 同样可以实现类似思想关键要看 Agent 服务本身的技术栈。版本方面需要特别说明不同版本的框架配置差异较大以下示例基于常见环境你在实际项目中需要按自己的版本调整。例如JDK8 或 17 Spring Boot2.7.x 或 3.x Redis6.x / 7.x Sentinel1.8.x Resilience4j2.x Nginx1.20 / 1.24如果项目里已有现成的依赖管理不要强行升级保持和团队一致即可。2.2 示例项目结构为了便于阅读我建议采用下面的目录结构agent-platform/ ├── pom.xml └── src/main/java/com/example/agent/ ├── AgentApplication.java ├── cache/ │ ├── AgentCacheService.java │ └── CacheKeyConstant.java ├── limiter/ │ └── SlidingWindowRateLimiter.java ├── circuit/ │ └── AgentInvokeService.java ├── controller/ │ └── AgentController.java └── model/ ├── AgentRequest.java └── AgentReply.java2.3 核心依赖在pom.xml中添加关键依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdcom.github.ben-manes.caffeine/groupId artifactIdcaffeine/artifactId /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-sentinel/artifactId /dependency dependency groupIdio.github.resilience4j/groupId artifactIdresilience4j-spring-boot2/artifactId /dependency这里要注意Spring Cloud Alibaba 版本和 Spring Boot 版本有对应关系如果启动报错优先检查版本兼容。3. 第一层防护缓存3.1 Agent 场景缓存的关键点很多人觉得 Agent 接口耗时那么长缓存能有什么用其实 Agent 服务里有大量可以被缓存的“中间结果”。常见可缓存点Agent 配置信息每个 Agent 的系统提示词、工具列表、模型参数。这些配置变化频率很低但每次请求都要加载。会话上下文快照多轮对话中用户的上下文可以按会话维度缓存避免每次从数据库重新组装。工具调用的幂等结果比如某些查询类工具输入相同参数时结果可以短时间复用。模型前置计算的 Token 结果如果同一个问题在短时间内反复出现可以直接复用已生成的 Token 序列减少模型调用。这里要注意缓存不是越久越好。Agent 配置缓存可以分钟级会话上下文缓存要按会话生命周期控制工具结果缓存时间要短避免返回过时数据。3.2 本地缓存 Redis 多级缓存Agent 服务里我强烈建议做“本地缓存 分布式缓存”两级结构。本地缓存用 Caffeine访问速度最快适合高并发场景下的热点配置。分布式缓存用 Redis解决多实例之间的数据共享和失效通知。下面是一个简化示例// 文件路径src/main/java/com/example/agent/cache/AgentCacheService.java Component public class AgentCacheService { private static final String AGENT_CONFIG_KEY agent:config:; private final CacheString, AgentConfig localCache; private final StringRedisTemplate redisTemplate; public AgentCacheService(StringRedisTemplate redisTemplate) { this.redisTemplate redisTemplate; this.localCache Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(5, TimeUnit.MINUTES) .build(); } public AgentConfig getAgentConfig(String agentId) { // 1. 先查本地缓存 AgentConfig config localCache.getIfPresent(agentId); if (config ! null) { return config; } // 2. 再查 Redis String key AGENT_CONFIG_KEY agentId; String json redisTemplate.opsForValue().get(key); if (StrUtil.isNotBlank(json)) { AgentConfig remoteConfig JSON.parseObject(json, AgentConfig.class); localCache.put(agentId, remoteConfig); return remoteConfig; } // 3. 最后查数据库并回填两级缓存 config loadFromDb(agentId); redisTemplate.opsForValue().set(key, JSON.toJSONString(config), 10, TimeUnit.MINUTES); localCache.put(agentId, config); return config; } private AgentConfig loadFromDb(String agentId) { // 通过配置中心或数据库加载 Agent 配置 // 示例代码真实场景替换为业务查询逻辑 return new AgentConfig(agentId, 你是一个智能助手, default-tools); } }实现要点先查本地再查 Redis最后查库逐级回填。本地缓存一定要设置最大条数防止内存溢出。Redis 的过期时间要加上随机偏移避免同一时间集中失效。3.3 缓存穿透、击穿、雪崩与 Redis 配置缓存有三大经典问题Agent 场景一个都躲不掉缓存穿透大量请求查询一个不存在的 Agent ID缓存和数据库都查不到请求直接打到数据库。解决思路对空结果也做短时间缓存或使用布隆过滤器前置校验。缓存击穿某个热点 Agent 配置的缓存刚好过期大量请求同时回源数据库。解决思路加互斥锁只有一个请求回源并更新缓存。缓存雪崩大量配置在同一时刻过期数据库瞬间压力飙升。解决思路过期时间加随机值例如10 RandomUtil.randomInt(0, 60)秒。Redis 侧还需要关注两个点对热点 key 开启持久化或提前预热避免重启后缓存全空。给 Redis 配置好合理的最大内存和淘汰策略Agent 服务的会话数据量通常不小优先使用allkeys-lru或volatile-lru。4. 第二层防护限流4.1 限流算法对比限流的目的是控制进入 Agent 服务的流量速率避免瞬时流量打垮线程池。四种常见算法各有适用场景算法特点适用场景固定窗口实现简单但窗口边界会出现双倍流量简单限制不要求精确滑动窗口解决固定窗口边界问题精度更高对流量抖动敏感的场景漏桶恒定速率流出能削峰但无法应对突发下游有明确速率要求的场景令牌桶允许一定程度的突发流量大部分后端接口场景Agent 接口有一个特点突发性很强。用户可能在某个瞬间集中发起请求如果使用漏桶算法反而会把正常请求拒掉。所以 Agent 服务更推荐滑动窗口或令牌桶。4.2 滑动窗口限流实现关于“滑动窗口限流存在什么问题”经典的回答是它虽然解决了固定窗口的临界突变问题但实现复杂度更高而且如果窗口切分不够细依然有微小误差另外滑动窗口只是限制总次数并不能保证服务端的处理能力。下面给出一个基于本地内存的滑动窗口限流器可用于单实例场景// 文件路径src/main/java/com/example/agent/limiter/SlidingWindowRateLimiter.java Component public class SlidingWindowRateLimiter { private final ConcurrentHashMapString, DequeLong records new ConcurrentHashMap(); /** * 判断请求是否允许通过 * * param key 限流标识例如用户ID或Agent ID * param maxCount 窗口内最大请求数 * param windowMillis 窗口时间单位毫秒 */ public boolean tryAcquire(String key, int maxCount, long windowMillis) { long now System.currentTimeMillis(); DequeLong deque records.computeIfAbsent(key, k - new ConcurrentLinkedDeque()); synchronized (deque) { // 清理窗口之外的时间戳 while (!deque.isEmpty() now - deque.peekFirst() windowMillis) { deque.pollFirst(); } if (deque.size() maxCount) { deque.addLast(now); return true; } return false; } } }在 Controller 中使用RestController RequestMapping(/agent) public class AgentController { private final SlidingWindowRateLimiter limiter; public AgentController(SlidingWindowRateLimiter limiter) { this.limiter limiter; } PostMapping(/invoke) public AgentReply invoke(RequestBody AgentRequest request) { // 限制单个用户每秒最多 5 次请求 if (!limiter.tryAcquire(user: request.getUserId(), 5, 1000)) { throw new RateLimitException(请求过于频繁请稍后再试); } // 执行 Agent 调用逻辑 return new AgentReply(处理成功); } }需要强调本地限流只适合单实例如果服务部署了多个节点必须把计数放到 Redis 里或者直接使用 Sentinel 的集群限流能力。否则每个节点各自的计数会导致整体限流失效。4.3 Sentinel 接入示例生产环境里我更推荐直接使用 Sentinel。它不仅能做 QPS 限流还能做并发线程数限流和熔断降级。在 Spring Boot 中接入 Sentinel 主要是配置和定义资源。以限流为例# 文件路径src/main/resources/application.yml spring: application: name: agent-platform cloud: sentinel: transport: dashboard: localhost:8080 eager: true在代码中可以用注解定义资源SentinelResource(value agent-invoke, blockHandler invokeBlockHandler) public AgentReply invokeBySentinel(AgentRequest request) { return new AgentReply(处理成功); } public AgentReply invokeBlockHandler(AgentRequest request, BlockException ex) { return new AgentReply(系统繁忙请稍后重试); }然后在 Sentinel Dashboard 上为agent-invoke资源配置 QPS 阈值即可。Dashboard 的规则配置是实时的不需要重启服务这在调整限流参数时非常方便。5. 第三层防护负载均衡5.1 Agent 服务负载均衡策略当 Agent 服务有多个实例时负载均衡决定了流量如何分配。常见的策略包括轮询请求均匀分发适合处理能力接近的实例。最少连接把请求分给当前连接数最少的实例适合 Agent 这种长耗时、连接占用高的场景。IP 哈希基于用户 IP 路由保证同用户会话固定到同一实例但扩展性差。对于 Agent 服务最少连接策略通常比轮询更合适。因为 Agent 请求的耗时差异巨大有些请求可能几秒就返回有些可能持续几分钟。轮询可能导致某些实例还在处理长任务新的请求又不断进来压力失衡。5.2 Nginx 配置与预热Nginx 层面的配置示例如下# 文件路径/etc/nginx/conf.d/agent-platform.conf upstream agent_cluster { least_conn; server 192.168.1.11:8081 max_fails3 fail_timeout30s; server 192.168.1.12:8082 max_fails3 fail_timeout30s; keepalive 32; } server { listen 80; server_name agent.example.com; location /agent/ { proxy_pass http://agent_cluster; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 5s; proxy_read_timeout 300s; proxy_send_timeout 300s; } }这里有两个关键细节一是超时时间。Agent 接口耗时较长Nginx 默认的 60 秒超时肯定不够所以把proxy_read_timeout调大。但要注意这个值不能盲目调到无限大否则服务端故障时客户端会一直等待反而占用连接资源。二是预热。服务刚启动时JVM 的即时编译器还没有完全优化缓存也是空的如果直接放大量流量很容易超时。建议在负载均衡中加入预热机制让新节点的流量在 1 到 2 分钟内逐步增加到正常水平。6. 第四层防护熔断6.1 熔断器原理熔断器的原理类似电路保险丝当错误率或耗时超过阈值时直接切断请求不再调用下游服务避免把故障扩散到整个系统。熔断器有三个状态关闭正常调用但统计错误率。打开错误率超阈值直接拒绝请求快速失败。半开经过一段冷却时间后放少量请求试探下游是否恢复。Agent 服务中熔断主要保护两类下游模型服务调用和工具服务调用。只要其中一个下游出现问题链路就可以快速失败而不是让所有线程阻塞等待。6.2 Resilience4j 接入示例Resilience4j 是 Spring Boot 生态里比较轻量的熔断库。先看基础配置# 文件路径src/main/resources/application.yml resilience4j: circuitbreaker: instances: agentInvoke: registerHealthIndicator: true slidingWindowSize: 100 minimumNumberOfCalls: 10 permittedNumberOfCallsInHalfOpenState: 5 automaticTransitionFromOpenToHalfOpenEnabled: true waitDurationInOpenState: 30s failureRateThreshold: 50 slowCallRateThreshold: 50 slowCallDurationThreshold: 10s各参数含义slidingWindowSize统计最近 100 次调用。minimumNumberOfCalls最少统计 10 次后才判断是否熔断。failureRateThreshold错误率超过 50% 时熔断。slowCallDurationThreshold调用耗时超过 10 秒算慢调用。waitDurationInOpenState熔断打开后等待 30 秒再进入半开状态。在代码中加上熔断注解// 文件路径src/main/java/com/example/agent/circuit/AgentInvokeService.java Service public class AgentInvokeService { CircuitBreaker(name agentInvoke, fallbackMethod invokeFallback) public AgentReply invoke(AgentRequest request) { // 这里调用 Agent 核心执行逻辑可能包含模型调用和工具调用 return doInvoke(request); } private AgentReply invokeFallback(AgentRequest request, Throwable t) { // 降级返回的结果不抛异常 return AgentReply.degradedReply(Agent 服务暂时不可用请稍后重试); } private AgentReply doInvoke(AgentRequest request) { // 模拟耗时操作 try { Thread.sleep(2000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } return new AgentReply(Agent 执行完成); } }熔断降级时要返回一个业务上可理解的降级结果而不是直接抛异常。如果前端能感知到降级就可以提示用户稍后重试而不是白屏等待。7. 完整实战四层防护整合7.1 核心接口代码下面把四层防护整合到同一个 Agent 调用接口中。这里要说明的是缓存、限流、熔断需要共同作用而不是各自独立。// 文件路径src/main/java/com/example/agent/controller/AgentController.java RestController RequestMapping(/agent) public class AgentController { private final AgentCacheService agentCacheService; private final SlidingWindowRateLimiter rateLimiter; private final AgentInvokeService agentInvokeService; public AgentController(AgentCacheService agentCacheService, SlidingWindowRateLimiter rateLimiter, AgentInvokeService agentInvokeService) { this.agentCacheService agentCacheService; this.rateLimiter rateLimiter; this.agentInvokeService agentInvokeService; } PostMapping(/invoke) public AgentReply invoke(RequestBody AgentRequest request) { // 第一层限流 if (!rateLimiter.tryAcquire(user: request.getUserId(), 10, 1000)) { return AgentReply.degradedReply(访问过于频繁请稍后再试); } // 第二层缓存 Agent 配置 AgentConfig config agentCacheService.getAgentConfig(request.getAgentId()); request.setAgentConfig(config); // 第三层熔断保护 return agentInvokeService.invoke(request); } }这个示例虽然简短但已经体现了分层思想先挡流量再走缓存最后进入核心执行链路。7.2 缓存 限流 熔断组合三者组合时有几个顺序问题值得注意限流要在最前面。如果请求已经被限流拦截就不要去查缓存、不要创建线程、不要调用下游。这样可以最大程度保护系统。熔断要保护核心执行链路。熔断不适合放在最外层否则会把所有类型的请求都一刀切包括一些本来可以降级处理的请求。更合适的做法是给不同的下游分别设置熔断器。缓存要兜底核心配置和中间结果。即使下游模型服务故障Agent 配置、会话上下文这些数据仍然可以从缓存读取降级响应会更快。7.3 运行与验证启动项目后可以用下面的命令做一次简单压测# 使用 curl 模拟普通请求 curl -X POST http://localhost:8080/agent/invoke \ -H Content-Type: application/json \ -d {userId:1001,agentId:agent_demo}如果需要压测可以使用 JMeter 或 wrk。一个简单的 wrk 命令如下wrk -t4 -c100 -d30s -s post.lua http://localhost:8080/agent/invokepost.lua需要自行构造 POST 请求体。压测时重点关注三个指标请求成功率是否下降。平均响应时间是否在可接受范围。线程池是否有排队下游服务是否有连接超时。如果压测中触发了限流或熔断会看到降级响应。这其实说明防护策略生效了而不是系统出错了。8. 常见问题与排查思路问题现象常见原因解决思路缓存穿透数据库压力大大量不存在的 Agent ID 查询空值缓存或布隆过滤器缓存击穿热点配置过期热点 key 失效瞬间大量回源互斥锁或本地缓存兜底缓存雪崩Redis 大面积失效过期时间设置过于集中过期时间增加随机偏移限流误伤正常用户窗口参数过小或本地限流在多节点下失效调大阈值改用 Redis 或 Sentinel 集群限流熔断频繁触发阈值设置过低或下游确实故障调大阈值优先排查下游服务Agent 执行超时模型服务响应慢模型限流增加超时时间异步化增加重试机制线程池耗尽长耗时请求占用线程又不断涌入新请求隔离线程池信号量隔离拒绝策略降级Agent 服务重启后流量过大缓存为空服务未预热预加载缓存负载均衡预热这里单独说一下“the agent execution provider did not respond in time”这类报错。它的本质是 Agent 执行引擎在等待下游提供方响应时超时。排查方向一是确认模型服务本身是否过载二是检查网络连接和超时配置三是看是不是熔断后连续快速失败导致的级联不可用。不要只盯着错误文案本身要从链路层面分析。9. 最佳实践与工程建议9.1 缓存一致性Agent 场景里缓存一致性的核心是“配置类数据允许短暂不一致会话数据不能错乱”。Agent 配置更新频率低可以通过“先更新数据库再删除缓存”的方式保证最终一致。也就是经典的 Cache Aside Pattern。更新缓存本身没有意义因为配置变更后旧缓存已经是脏数据。会话上下文数据则要注意同一个会话的上下文必须严格串行。多轮对话中如果用户连续发送消息后一条消息的处理必须等待前一条完成。这里推荐按会话维度加锁而不是无脑并发处理。9.2 限流参数调整限流参数没有标准答案需要结合压测结果调整。有几个原则先定下游能力再定入口阈值。比如模型服务最多支持每分钟 60 个请求那入口 QPS 就必须低于这个值。多维度限流。不仅要按用户限还要按 Agent 限、按来源应用限。限流触发时要返回明确的错误码方便客户端识别是做重试还是提示用户。9.3 生产环境注意事项生产环境至少要关注四件事第一是安全边界。Agent 接口可以被外部网络直接访问时必须有身份认证和权限校验。限流不能替代鉴权否则攻击者可以伪造大量请求消耗配额。对 Agent 输入内容做好校验和脱敏防止提示词注入。第二是超时治理。给整个调用链配置明确的超时时间从 Nginx 到应用层从应用层到模型服务。每个环节的超时要递减保证整体可控。第三是可观测性。每个 Agent 请求都要有唯一的 traceId记录模型调用的耗时、Token 消耗、工具调用次数。没有这些数据高并发下的问题几乎无法定位。第四是优雅降级。降级不是报错。用户请求过来时如果检测到系统容量不足应该返回“当前咨询人数较多请稍后重试”而不是让用户长时间等待后超时。对于非核心功能比如推荐追问、知识库检索可以降级为固定回复。9.4 关于 Agent 开发的方向抛开这次的四层防护如果你正在做 Agent 平台还需要关注下面这些工程问题Agent 的记忆管理、工具调用的安全审计、上下文窗口的 Token 控制、多 Agent 协作时的链路追踪。这些都是 Agent 从 Demo 走向生产时必须补齐的能力。高并发只是其中一环系统的优雅性来自每一层的克制。缓存、限流、负载均衡、熔断最终目标不是“不让系统出问题”而是“出问题时系统还能优雅地继续服务绝大多数用户”。如果你想继续深入可以学习 Redis 分布式锁与缓存一致性、Sentinel 源码级限流实现、Kubernetes HPA 自动扩容等方向。建议先把本文的示例在本地跑通再逐步增加压力测试观察每一层防护触发时系统的表现。亲手看过限流生效和熔断打开时的日志比记住任何参数都更有价值。