★ FEATURED ARTICLE 1. 为什么 AI Agent 一上缓存就翻车AI Agent 这个方向最近一年热得发烫从扣子这类低代码平台到 FastAPI LangChain LangGraph 的自研路线几乎每个团队都在琢磨怎么让 Agent 真正下地干活。但真把 Agent 推到线上跑起来的人都知道最要命的往往不是模型能力而是状态管理和缓存。一个 Agent 一次对话可能要调用十几次工具、查几十条记忆、跑好几轮推理如果每次都重新打数据库或者重新算 embedding延迟直接爆炸成本也扛不住。我最近在做一个基于 Rust 的 AI Agent 项目核心诉求很明确让 Agent 在多轮对话、工具调用、记忆检索这几个高频路径上都能吃到缓存红利同时保证缓存失效、并发安全、序列化这些坑不翻车。选 Redis 做缓存层几乎是默认答案——它支持丰富的数据类型、有成熟的分布式锁、单机十万级 QPS 起步生态工具从 redis-cli 到 Redis Desktop Manager 一应俱全。但用 Redis和用好 Redis之间隔着一条鸿沟我踩过的坑包括但不限于缓存穿透把数据库打挂、序列化格式选错导致反序列化失败、分布式锁没设过期时间导致死锁、Lettuce 连接池配置不当引发RedisCommandTimeoutException。这篇内容就是把这套东西从头到尾捋一遍。适合谁看如果你正在搭 AI Agent、准备给 Agent 加缓存层、或者线上已经出现缓存相关的性能问题那这篇基本能覆盖你 80% 的疑问。我会从整体架构思路讲起然后拆解 Redis 数据类型选型、序列化方案、分布式锁、缓存治理、并发扛压这几个核心环节最后给一份常见问题速查表。全程按我实际项目的做法来写能抄作业的地方直接给配置和代码。2. AI Agent 缓存层的整体设计与选型思路2.1 Agent 场景下缓存到底缓存什么很多人一提给 Agent 加缓存就懵因为 Agent 不像传统 Web 接口那样请求-响应结构清晰。我先把 Agent 运行时的数据流拆开看你会发现缓存点其实非常明确。一个典型 Agent 的一轮交互大致是这样用户输入进来 → 加载会话历史 → 检索长期记忆向量库→ 组装 prompt → 调 LLM 推理 → 解析出工具调用 → 执行工具 → 把工具结果塞回上下文 → 再推理 → 输出。这里面可以缓存的东西至少有五类会话上下文多轮对话的历史消息读写频繁适合用 Redis 的 List 或 Stream 存。记忆检索结果同一 query 的向量检索结果短时间内高度重复适合 String 缓存。工具调用结果比如查天气、查汇率、查数据库这类幂等工具结果可以缓存几分钟到几小时。LLM 响应相同 prompt 的推理结果尤其是 system prompt 固定的场景命中率很可观。中间计算产物embedding 向量、token 计数、prompt 模板渲染结果等。我实测下来一个日活几千的 Agent 应用光是把工具调用结果和记忆检索结果缓存住整体 P99 延迟能从 3.2s 降到 1.1s 左右LLM 调用次数能省掉 30% 以上。这个收益非常实在。2.2 为什么是 Redis 而不是本地缓存有人会问Agent 单机部署的话用进程内缓存比如 Rust 的 moka、Java 的 Caffeine不是更快吗确实快纳秒级。但问题在于第一Agent 通常要水平扩展多实例部署时本地缓存各存各的会话状态就不一致了。用户第一次请求打到 A 实例第二次打到 B 实例历史对话直接丢失体验灾难。第二本地缓存容量受限于单机内存Agent 的会话数据可能很大尤其是长对话场景几万个活跃会话就能吃掉几个 G。第三本地缓存没法做统一的失效治理。你想清某个用户的缓存得挨个实例通知运维成本高。所以我的方案是两级缓存本地缓存扛超高频只读数据比如 prompt 模板、配置Redis 扛会话状态、工具结果、分布式锁这些需要跨实例共享的数据。这个组合在延迟和一致性之间取得了不错的平衡。2.3 缓存架构分层图文字描述我的实际架构分三层接入层Agent 服务实例每个实例内置一个本地 LRU 缓存容量 10000 条TTL 60s。共享层Redis 集群主从 哨兵或直接用 Cluster承载会话、工具结果、锁。持久层PostgreSQL / 向量库作为最终数据源。读路径是本地缓存 → Redis → 数据库逐级回源并回填。写路径是先写数据库再删 Redis 缓存Cache-Aside 模式本地缓存靠短 TTL 自然过期。这个模式的好处是逻辑简单、不易出错坏处是有短暂的不一致窗口但对 Agent 场景来说完全可以接受。注意不要用 Write-Through 或 Write-Behind 模式Agent 的数据一致性要求没那么高但写入复杂度会陡增得不偿失。3. Redis 数据类型选型与序列化实战3.1 五种数据类型在 Agent 里的具体用法Redis 的数据类型是它最核心的竞争力但很多人只会用 String白白浪费了其他类型的威力。我把 Agent 场景下的选型整理成一张表数据类型Agent 场景选它的理由注意事项String工具调用结果、LLM 响应、embedding简单直接支持 SETEX 原子设过期大 value 要压缩超过 10KB 考虑拆分Hash会话元数据用户ID、状态、时间戳字段级更新不用整体读写字段别太多超过 100 个考虑拆 keyList对话历史消息队列天然有序LPUSH LRANGE 高效记得 LTRIM 控制长度否则无限增长Set用户标签、去重场景交并差运算方便大 Set 的 SMEMBERS 会阻塞用 SSCANZSet记忆重要性排序、限流按 score 排序范围查询快score 用时间戳要注意精度我重点说两个容易踩坑的。List 存对话历史很多人直接 LPUSH 不控制长度一个活跃用户聊一个月List 里几万条消息LRANGE 一次拉全量直接卡死。正确做法是每次 LPUSH 后跟一个 LTRIM只保留最近 N 条我一般设 50 条更早的历史落库。ZSet 做限流Agent 调用 LLM 很贵必须限流。用 ZSet 存请求时间戳score 就是毫秒时间戳每次请求前先 ZREMRANGEBYSCORE 清掉窗口外的再 ZCARD 看数量。这个方案比固定窗口计数器平滑比令牌桶实现简单。3.2 序列化方案别再用 JDK 序列化了序列化是缓存翻车的高发区。我见过太多项目用 JDK 原生序列化结果一是体积大同样的对象比 JSON 大 3-5 倍二是跨语言不通Rust Agent 和 Java 服务共享缓存直接歇菜三是反序列化有安全风险。我的选型优先级是MessagePack JSON Protobuf 其他。MessagePack二进制、紧凑、跨语言支持好Rust 有 rmp-serdeJava 有 msgpack-java。体积比 JSON 小 30% 左右速度还快。我现在的默认选择。JSON可读性好调试方便redis-cli 里直接能看懂。适合开发阶段或者 value 不大的场景。Protobufschema 强约束适合结构稳定的数据但改 schema 麻烦Agent 场景数据结构变化快不太适合。Rust 侧用 rmp-serde 的示例use serde::{Serialize, Deserialize}; use rmp_serde; #[derive(Serialize, Deserialize)] struct ToolResult { tool_name: String, output: String, timestamp: i64, } // 序列化 let result ToolResult { /* ... */ }; let bytes rmp_serde::to_vec(result)?; redis_conn.set_ex(key, bytes, 300)?; // 反序列化 let bytes: Vecu8 redis_conn.get(key)?; let result: ToolResult rmp_serde::from_slice(bytes)?;提示序列化格式一旦上线就别轻易改否则新旧数据混在一起反序列化必炸。要改就加版本号前缀比如v2:tool:xxx让新旧 key 共存一段时间。3.3 Key 命名规范别小看这件事Key 命名混乱是缓存治理的头号敌人。我定了一套强制规范{业务}:{实体}:{ID}:{版本}比如agent:session:u12345:v1、agent:tool:weather:beijing:v1。为什么要带版本号因为当你改了数据结构直接改 key 前缀就能让旧缓存自然失效不用写脚本批量删。这个技巧在灰度发布时特别好用——新版本服务读v2前缀老版本读v1互不干扰。另外Key 一定要设 TTL没有例外。我见过有人为了性能给会话 key 设永久结果 Redis 内存涨到 32G 报警。Agent 的会话数据本来就有生命周期设个 7 天 TTL 完全够用。4. 缓存治理穿透、击穿、雪崩一个都不能少4.1 缓存穿透查不存在的数据穿透是指查询一个数据库里也不存在的 key缓存永远不命中每次都打到数据库。Agent 场景下这个特别常见——用户问了个冷门问题记忆检索返回空如果每次都去查向量库成本很高。解决方案有两个我一般组合用方案一缓存空值。查不到就存一个特殊标记比如空字符串或__NULL__TTL 设短一点60s。这样短时间内重复查询直接命中缓存。方案二布隆过滤器。把所有合法的 key 预先加载到布隆过滤器查询前先过一遍不存在直接返回。Rust 可以用bloomcrateRedis 4.0 也有 RedisBloom 模块。布隆过滤器的缺点是误判率说存在但实际不存在但对 Agent 场景来说误判了顶多多查一次数据库可以接受。4.2 缓存击穿热点 key 过期瞬间击穿是某个热点 key 突然过期大量并发请求同时回源。Agent 里最典型的就是 system prompt 缓存所有请求都读同一个 key一旦过期几千个请求同时打数据库。解决方案是互斥锁重建第一个发现缓存失效的请求去抢分布式锁抢到的负责回源并回填其他请求短暂等待后重试读缓存。这个逻辑用 Redis 的 SET NX EX 就能实现// 尝试获取重建锁 let lock_key format!(lock:{}, cache_key); let acquired redis_conn.set_nx_ex(lock_key, 1, 10)?; if acquired { // 抢到锁回源 let data fetch_from_db().await?; redis_conn.set_ex(cache_key, serialize(data), 300)?; redis_conn.del(lock_key)?; return Ok(data); } else { // 没抢到等一会儿重试 tokio::time::sleep(Duration::from_millis(50)).await; return read_from_cache(cache_key); }注意锁的过期时间要大于回源耗时否则锁提前释放重建逻辑就失效了。我一般设 10s回源超过 10s 说明数据库本身有问题该报警了。4.3 缓存雪崩大批 key 同时过期雪崩是大量 key 在同一时刻过期请求全部涌向数据库。根因通常是批量写入时 TTL 设成了同一个值。解决办法很简单TTL 加随机抖动。基础 TTL 加上 0 到 10% 的随机值比如基础 300s实际设 300 到 330s 之间。这样过期时间就分散开了。let base_ttl 300; let jitter rand::thread_rng().gen_range(0..30); redis_conn.set_ex(key, value, base_ttl jitter)?;这个改动成本极低但效果立竿见影。我上线这个策略后Redis 的 QPS 曲线从原来的尖峰变成了平滑曲线。4.4 缓存治理的监控指标治理不能靠感觉得有数据。我盯的几个核心指标指标含义健康阈值命中率hits / (hits misses) 85%平均 TTL所有 key 的平均剩余生存时间稳定无骤降内存使用率used_memory / maxmemory 75%慢查询数slowlog 长度每分钟 5连接数connected_clients 连接池上限的 80%命中率低于 85% 就要查原因了通常是 key 设计不合理或者 TTL 太短。内存使用率超过 75% 要提前扩容别等 OOM。5. 分布式锁与并发扛压实战5.1 AI Agent 为什么需要分布式锁Agent 的并发场景比普通服务复杂。举几个例子同一个用户同时发两条消息会话历史可能写乱多个实例同时给同一个会话做记忆压缩结果重复计算工具调用有副作用时比如发消息、下单必须保证只执行一次。这些都需要分布式锁。Redis 实现分布式锁的标准姿势是SET key value NX EX secondsvalue 用一个唯一标识比如 UUID释放时用 Lua 脚本校验 value 再删防止误删别人的锁。-- 释放锁的 Lua 脚本 if redis.call(GET, KEYS[1]) ARGV[1] then return redis.call(DEL, KEYS[1]) else return 0 end5.2 Redlock 到底要不要用关于 Redlock 的争议一直没停过。我的实践结论是单 Redis 实例 主从 哨兵的锁对 Agent 场景够用了。Redlock 需要多个独立 Redis 实例运维复杂度高而且它解决的是Redis 主从切换导致锁丢失这个极端场景Agent 场景下锁丢失最多导致一次重复计算业务上能容忍。如果你做的是金融级交易 Agent那另说得上 Redlock 或者干脆用 etcd/Consul 做协调。但绝大多数 Agent 应用单实例锁 合理 TTL 就够了。5.3 连接池配置Lettuce 超时的元凶RedisCommandTimeoutException这个报错我猜很多人都见过尤其是用 Lettuce 的时候。根因通常是连接池配置不当。默认配置下Lettuce 是单连接共享模式高并发时命令排队超过默认超时60s就抛异常。我的配置经验连接池大小max-active设为 CPU 核数 * 2 到 4 倍。8 核机器设 32 差不多。超时时间命令超时设 500ms 到 1s别用默认的 60s。Agent 请求本来就要求低延迟等 60s 还不如直接失败重试。空闲连接检测开启test-while-idle防止拿到已经断开的连接。共享连接 vs 连接池高并发场景用连接池commons-pool2低并发用共享连接更省资源。Rust 侧用deadpool-redis或bb8-redis做连接池配置思路一样。我实测 8 核机器、32 连接、500ms 超时能稳定扛住 8000 QPS 左右。5.4 扛并发的几个实战技巧技巧一Pipeline 批量操作。Agent 加载会话时经常要读多个 key用 Pipeline 一次发出去RTT 从 N 次降到 1 次。实测能省 60% 以上的网络往返时间。技巧二Lua 脚本做原子操作。比如检查限流 计数 设过期这三步用 Lua 脚本一次执行避免竞态。技巧三读写分离。主库写从库读Agent 的读请求远多于写请求读写分离能显著提升吞吐。但要注意主从延迟会话刚写完立刻读可能读不到这种场景强制走主库。技巧四热点 key 打散。如果某个 key 特别热比如全局配置可以复制成 N 份key 加随机后缀读的时候随机选一份。这个技巧能把单 key 的压力分散到多个节点。6. 常见问题与排查技巧实录6.1 问题速查表现象可能原因排查方法解决RedisCommandTimeoutException连接池太小 / 慢命令阻塞看 slowlog、连接数扩连接池、优化慢命令缓存命中率骤降key 设计变更 / TTL 太短对比变更前后的 key 分布回滚变更、调 TTL内存持续增长key 没设 TTL / 大 keyredis-cli --bigkeys补 TTL、拆分大 key主从数据不一致主从延迟 / 网络抖动INFO replication看 offset关键读走主库分布式锁失效锁过期时间太短看业务耗时日志调大 TTL、加续期反序列化失败序列化格式变更看异常堆栈加版本前缀、灰度6.2 几个我踩过的坑坑一大 key 阻塞。有次会话 List 里存了几万条消息一次 LRANGE 直接把 Redis 单线程卡了 2 秒所有请求超时。后来强制 LTRIM 到 50 条问题消失。教训是任何可能无限增长的结构都要有长度控制。坑二序列化格式混用。开发时用 JSON上线改成 MessagePack结果旧数据反序列化全炸。后来加了 key 版本前缀才解决。教训是序列化格式变更必须走版本化。坑三锁没设过期时间。早期用SETNX没加 EX某次服务崩溃后锁没释放后续请求全部阻塞。现在强制用SET NX EX锁必须有 TTL。坑四本地缓存和 Redis 不一致。本地缓存 TTL 设了 10 分钟Redis 更新后本地还是旧数据用户看到过期信息。后来把本地 TTL 降到 60s并且写操作时主动清本地缓存问题缓解。6.3 排查工具推荐redis-cli基础中的基础--bigkeys、--hotkeys、MONITOR都是排查利器。Redis Desktop Manager可视化看 key调试时很方便。redis-cli --latency测延迟判断是不是网络问题。INFO 命令INFO memory、INFO stats、INFO replication定期采集做监控。提示生产环境慎用MONITOR和KEYS这两个命令会阻塞 Redis高并发时直接引发故障。要用就用SCAN系列替代KEYS。7. 我个人的一些经验体会这套 AI Agent Redis 缓存的方案我在两个项目里跑了大半年最大的体会是缓存不是加得越多越好而是要想清楚每个缓存点的失效策略和一致性要求。Agent 场景下会话状态可以容忍短暂不一致但工具调用结果如果涉及副作用就必须严格保证幂等。另外别迷信高性能三个字。Redis 单机确实快但配置不当照样超时。连接池、序列化、大 key、热点 key这四个点任何一个出问题性能都会断崖式下跌。我建议上线前一定要做压测用真实流量模型跑一遍把 P99 延迟和错误率摸清楚。最后分享一个小技巧给每个缓存 key 的 value 里塞一个_cached_at时间戳字段排查问题时能直接看出数据是什么时候缓存的比翻日志快多了。这个习惯帮我定位过好几次数据看起来是旧的的诡异问题。
阅读完成 · 觉得有帮助？
