企业官网建设流程全解析

前几天我们在改造一个 AI 问答服务时，发现大部分请求都压在模型网关的 API 上，一个用户反复问同一个问题，系统就反复去调用大模型，响应慢、费用高。当时我把最传统的那套 Redis 缓存方案搬过来做了一层“语义缓存”，又把 Redis Stack 的向量检索能力接进 RAG 链路，整个服务的成本降了接近一半。所以当我看到“Redis 已正式接入 AI”这个趋势时，感触特别深——Redis 早就不是那个只用来做 Session 和热点数据的缓存中间件了，它正在成为 AI 应用落地时最顺手、最便宜、也最关键的一块基础设施。这篇文章就基于我实际改造项目的一些经验，把 Redis 和 AI 的结合点、操作细节、以及踩过的坑一次说清楚，适合正在做 AI 应用开发、或者想把现有 Redis 能力复用到 AI 场景的工程师参考。

1. Redis 在 AI 应用里的角色定位

1.1 为什么 AI 应用离不开 Redis

先聊一个最朴素的问题：AI 服务到底缺 Redis 什么？

一个典型的大模型问答链路，用户请求进来之后要过权限校验、上下文组装、Prompt 构建，然后才真正调模型接口。模型接口的延迟通常在几百毫秒到几秒，QPS 上限又严格卡着配额，成本还按 Token 计费。这种情况下，如果没有一层“缓存”挡在前面，业务根本跑不起量。但 AI 场景的缓存和传统的 Redis 缓存有个本质区别：用户不会一字不差地问同一个问题，今天问“怎么做红烧肉”，明天问“红烧肉怎么做”，传统的 key-value 精确匹配根本命中不了，这就需要把语义信息引进来。Redis 在这个位置刚好接得住，它既有内存级的低延迟性能，又能通过向量扩展做相似度检索，还能用 TTL 和淘汰策略控制内存水位，天然适合做这一层数据底座。

除了缓存，AI 应用的数据形态也比传统业务复杂得多。模型服务的 Prompt 历史、用户的会话状态、Agent 的执行上下文、文档切块后的向量数据、异步任务的消息队列，这些数据对延迟、持久化、排序、淘汰都有要求。如果把它们全部塞进关系型数据库，读写压力一大就扛不住；如果什么都上重型中间件，中小团队又养不起。Redis 的多数据类型正好可以一张底牌打多种牌：String 缓存结果片段、Hash 存用户画像、List 做任务队列、ZSet 做热点统计和滑动窗口、Stream 做事件流，再加上 Redis Stack 的向量索引，一条链路全打通。

1.2 说 Redis“正式接入 AI”的两层含义

标题里说的“正式接入 AI”，我理解有两层含义，一层在生态层面，一层在工具层面。

生态层面，Redis 官方这两年明显在向 AI 基础设施方向靠拢，Redis Stack 内置的 RediSearch 支持向量索引和 KNN 检索，官方文档专门给出了 RAG 场景的参考架构，各种 AI Agent 框架也把 Redis 列入默认的 memory 和 message broker 选项。行业内讨论 AI 应用架构时，Redis 已经从“可选组件”变成了“默认组件”。工具层面，Redis 的数据写入和查询能力在大模型时代被重新挖掘，比如用嵌入式向量构建语义缓存、用 Redis 做 Agent 的记忆层、用 Lua 脚本保证分布式锁和限流的原子性，这些用法让 Redis 在 AI 链路中承担了以前由好几种中间件分摊的职责。

说句实话，很多团队在规划 AI 项目时第一反应是“要不要上专门的向量数据库”，第二反应是“要不要上消息队列”。这两个问题我在本文后面会讲到：如果你的数据量在千万级以下、对向量检索精度要求没那么苛刻，用 Redis 就够了；如果你的消息量没到每秒上万条，用 Redis 的 Stream 或 List 也能顶住。先把链路跑起来，比一开始就上一堆重型组件重要得多——这是我在多次项目里被现实教育出来的结论。

2. 给大模型缓存加速：语义缓存与防击穿实战

2.1 精确缓存不够用了，语义缓存才是答案

传统缓存的思路很简单：请求参数拼一个 key，查 Redis，有就返回，没有就穿透到下游。但这个模式放到大模型场景里命中率极低。用户问“Redis 怎么安装”和“redis 如何安装”，在精确匹配视角下是两个完全不同的 key，在语义视角下是同一个问题，应该共用同一个答案。这就是语义缓存的切入点。

我目前的实现方案是：用户提问进来之后，先用 Embedding 模型把问题转成一个向量，然后用 RediSearch 的向量索引做 KNN 检索，检出来的结果如果相似度超过阈值，直接把对应缓存内容返回；如果没有超过阈值，才调用大模型，拿到结果后把答案和问题向量一起写入 Redis。这里最关键的是相似度阈值的调参，阈值设太高缓存命中率上不来，设太低会把语义不相关的用户问题错误命中，返回一个文不对题的答案。按我的经验，用 OpenAI 的 text-embedding-3-small 做向量，余弦相似度阈值设在 0.92 到 0.95 之间比较稳妥；阈值过低造成的错误命中，比没命中更伤体验。这个阈值不是拍脑袋定的，要拿真实用户问题做一批离线样本测召回率和误判率，再落到线上观察。Embedding 模型可以单独部署一个本地服务，单机扛住公司的日常检索量问题不大，不必一开始就上分布式推理服务。

写入缓存的 TTL 也要想清楚。大模型生成的答案很多时候带有时间属性，比如“最近的技术趋势”这类问题，答案过一个月就过时了。我一般给语义缓存设置三个档位：通用知识类 TTL 设 7 天，类目知识类设 24 小时，涉及实时数据的设 30 分钟。这样既保证大部分问题可以命中缓存，又不至于让用户长期拿到过时内容。另一个细节是缓存内容的来源标识，最好在写库的时候顺带记一条“generated_at”字段，方便后续手动清理和模型升级后批量失效。

2.2 用 Redis 数据类型解决 AI 场景的具体问题

Redis 的几种数据类型在 AI 场景里各有各的用处，这里列几个我实际用过的组合，可以直接抄作业。

• String：存短文本、模型返回的片段、鉴权 Token、简单计数。比如把大模型生成的摘要结果直接写成 String，key 里带上用户 ID 或会话 ID。
• Hash：存结构化数据，比如用户的会话画像、偏好标签、模型调用统计。一个用户一个 key，field 对应不同维度，改一个维度不影响别的。
• List：做任务队列。比如把批量文档解析任务塞进 List，Worker 从左边取任务，处理完把结果写到另一个 key，天然就是生产者-消费者模型。
• ZSet：做热点排序和限流计数。每个成员是用户问题的 ID，score 是提问时间戳，通过 ZREMRANGEBYSCORE 删除过期记录，再用 ZCARD 统计窗口内请求数，滑动窗口限流就这么实现。
• Stream：做事件流。Agent 跑任务时的状态变更、模型调用的日志事件，都可以写 Stream，消费组各自维护消费位点。

如果团队里还有人对 Redis 数据类型不熟，我建议用这样一句话理解：String 是变量，Hash 是对象，List 是队列，ZSet 是排行榜加时间线，Stream 是消息队列。把这几种数据结构用熟，AI 应用的很多通用模块都能用 Redis 自己搭出来，不必引入额外组件。

2.3 分布式锁：别让一千个请求同时打到模型网关

缓存穿透是传统缓存的老问题，但在 AI 场景里问题会被放大：因为模型网关的 QPS 配额比数据库珍贵得多，一旦缓存 key 失效或者不存在，几十个并发请求同时穿透到模型接口，配额瞬间被打爆，然后就是限流、重试、毛刺，整个服务雪崩。解决办法是加分布式锁，让同一时刻只有一个请求去调大模型，其他请求等锁释放后直接读缓存。

这里要强调一个很多人踩过的坑：用 SETNX 加锁很容易，但释放锁时一定要保证原子性。最朴素的错误写法是“先 GET 锁的值，判断是自己的就 DELETE”，问题在于 GET 和 DELETE 之间锁可能已经过期被别的线程拿到，你再 DELETE 就把别人的锁删了。正确的做法是用 Lua 脚本一次性完成“比对并删除”：

if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end

加锁时除了 SET key value NX EX，value 一定要用随机串（比如 UUID），这个随机串就是锁的持有者身份。锁的过期时间也大有讲究，模型调用时长不稳定，我见过一次调用耗时超过锁过期时间，锁提前失效，两个请求同时进模型接口的情况。设得过长又会在进程崩溃时拖累恢复时间。更好的做法是用 Redisson 这类客户端，开启看门狗自动续期，每隔一段时间检查锁是否仍持有，持有就续期。这个机制我自己验证过，进程崩溃后锁会逐渐自然过期，不会死锁，省了很多事。

2.4 限流保护大模型 API 配额

模型网关一般都有每分钟请求数限制和 Token 消耗限制，超了直接给你 429。为了防止某个用户刷爆配额，需要在 Redis 里做限流。我推荐用滑动窗口而不是固定窗口：固定窗口在窗口切换瞬间容易放两倍流量，滑动窗口更平滑。

滑动窗口用 ZSet 实现很优雅。每个用户一个 key，score 存时间戳，member 存请求 ID。请求进来时先用 ZREMRANGEBYSCORE 删掉窗口之外的旧记录，然后 ZCARD 统计当前窗口内请求数，超过阈值就拒绝请求。整个过程要放到 Lua 脚本里保证原子性，否则并发下会统计不准。脚本大概长这样：

local key = KEYS[1] local window = tonumber(ARGV[1]) local limit = tonumber(ARGV[2]) local now = tonumber(ARGV[3]) local member = ARGV[4] redis.call('ZREMRANGEBYSCORE', key, 0, now - window) local count = redis.call('ZCARD', key) if count < limit then redis.call('ZADD', key, now, member) redis.call('EXPIRE', key, window) return 1 end return 0

除了按用户维度限流，还可以按接口维度、按 IP 维度各自建 key。这里有个小细节：member 用随机串而不是时间戳，否则同一毫秒内两个请求的 member 相同，ZADD 会去重，导致计数偏小。另外别忘了给 key 设置过期时间，否则每个用户都会在 Redis 里留下一个持续膨胀的 ZSet，内存迟早被吃光。

3. 向量检索与 AI 记忆：Redis Stack 实战

3.1 用 Redis Stack 搭一个 RAG 检索链路

RAG 是目前企业落地大模型最主流的方案，原理不复杂：把私有知识库的文档切块、Embedding、存进向量库，用户提问时把问题也转成向量，从向量库中检索最相关的文档片段，再把这些片段拼进 Prompt 交给大模型生成答案。传统方案是引入独立的向量数据库，但如果只是几百万量级的向量，用 Redis Stack 完全够用，还能省去一套中间件的运维成本。

我用的就是 Redis Stack 里的 RediSearch 模块。建索引时这样建：

FT.CREATE idx_docs ON HASH PREFIX 1 doc: SCHEMA content TEXT embedding VECTOR HNSW 6 TYPE FLOAT32 DIM 1024 DISTANCE_METRIC COSINE

注意 DIM 必须和 Embedding 模型的输出维度一致，如果用的是 text-embedding-3-small，维度是 1536，就要设成 1536。查询时用 KNN 子句：

FT.SEARCH idx_docs "*=>[KNN 5 @embedding $vec AS score]" PARAMS 2 vec "向量二进制内容" SORTBY score ASC DIALECT 2

这里最容易出问题的点是向量的传入格式：RediSearch 存的是向量二进制，用 redis-cli 手动测试特别容易弄错格式，我建议直接用客户端 SDK 封装好的方法，避免手拼命令。另外一个坑是 PREFIX 1 doc: 这个前缀，要求你写入文档时每个向量所在 Hash 的 key 必须以 doc: 开头，前缀不一致索引查不到。

单机 Redis 处理百万级向量的 KNN 检索，延迟大概在十几毫秒到几十毫秒，相比动辄上百毫秒的模型调用，这个开销完全可接受。真要跑到千万级向量再考虑迁移到专用向量库，这个迁移时机我建议用数据量、吞吐量和召回率三个指标决定，数据量涨到单机内存装不下时再折腾，前期用 Redis 快速验证产品价值，比一开始就铺重资产划算得多。

3.2 AI Agent 的记忆如何用 Redis 管起来

AI Agent 应用（比如智能客服、自动化助手）和普通问答一个很大的区别在于它有“记忆”。用户昨天聊到一半的需求，今天继续聊，Agent 要能接上。这个记忆分两层：短期记忆是会话级上下文，长期记忆是用户偏好和行为沉淀。我之前试过把短期记忆直接塞进模型上下文的 Token 里，结果上下文越长费用越高、响应越慢，后来改成用 Redis 管理和裁剪。

短期记忆我用 Hash 存：key 是 sessionId，field 是这个消息的 ID，value 是消息内容。每次新消息进来往 Hash 里追加一条，同时用 ZSet 记录消息顺序，到一定条数后从 ZSet 里取最老的记录删掉，保证上下文窗口可控。长期记忆用 String 或 Hash 存用户画像，比如用户最关心的话题、历史沟通的偏好、常用语言，这些信息在每次对话开始时拉取并拼进系统 Prompt，效果比模型自己去“回忆”好得多。

这里有个很值得推荐的设计：把记忆按语义建索引。用户 A 三周前问过“数据迁移方案”，今天又问“数据库迁移会不会丢数据”，如果靠关键词匹配很难找到关联，但用向量检索一下 Redis 里存的过往对话摘要，就能把三周前那轮上下文捞出来作为参考。这就是把 Redis 的普通存储能力和向量能力叠加起来用，效果相当好。

3.3 序列化问题：为什么你存进去的中文全是乱码

这是我在项目里被坑得最深的一次。Java 项目用 Spring Data Redis 默认的序列化器，存一个对象进去，Redis 里看到的是类似\xac\xed\x00\x05t...的乱码串，用可视化工具查看时中文完全不可读，排查问题时一脸懵。后来才弄清楚，Spring Data Redis 默认用的是 JdkSerializationRedisSerializer，序列化出来的根本不是文本。

解决方案有三种：第一，配置 Jackson2JsonRedisSerializer 或 GenericJackson2JsonRedisSerializer，把对象转成 JSON 后存储，人类可读、跨语言性好；第二，用 StringRedisSerializer 手动序列化，自己控制格式，适合数据结构简单的场景；第三，追求极致性能就上 Protobuf 或 MessagePack 这种二进制序列化方案，体积小、速度更快，但调试不方便。我的建议是开发阶段用 JSON 序列化，方便排查问题，性能瓶颈真的出现了再切二进制序列化。另外特别注意一点：如果 Redis 里已经有旧序列化方式写入的数据，切换序列化器后 key 对不上，读不到旧数据，这时候要做好数据迁移或者缓存预热，别等到上线了才发现缓存全部失效，把数据库和模型网关压垮。

还有一个细节，JSON 序列化时对象如果带有类型信息，反序列化会有安全风险，建议配置允许的包路径白名单，或者干脆别用带多态类型的序列化框架，保持数据模型扁平化。

4. 部署与配置：从零搭一套 Redis+AI 环境

4.1 Docker 安装与主从架构

和 AI 项目集成时，我强烈推荐直接用 Docker 部署 Redis Stack，镜像自带 RediSearch、RedisJSON 模块，少操很多心。最基础的一条命令：

docker run -d --name redis-stack -p 6379:6379 -p 8001:8001 redis/redis-stack:latest

端口 6379 是 Redis 端口，8001 是 RedisInsight 的默认端口，不需要可视化界面的话可以不映射。如果项目里只是用纯 Redis 而不是向量检索，用redis:7-alpine这种轻量镜像就够了，说实话用 Redis Stack 镜像启动稍微慢一点，内存占用也高一些，但功能全。

主从架构是生产环境的基本操作。用 Docker Compose 部署时在从节点的配置里加一行：

replicaof redis-master 6379

或者在 redis.conf 里写replicaof 127.0.0.1 6379。主从部署时有一个细节经常被忽略：从节点默认是只读模式，如果你的缓存治理脚本或者 AI 任务队列脚本误连到从节点写入，会直接报错。要明确区分连接配置。另外，主从复制会在主节点数据量大时产生全量 RDB 传输，同步期间主节点会 fork 子进程占内存，务必给主节点留出足够内存余量，否则直接 OOM。

4.2 Windows 下的安装与常用配置

开发环境是 Windows 的同行也别慌，Redis 在 Windows 下的安装不算麻烦。最简单的方式是去 Redis 官网或 GitHub 下载 Windows 版本的 zip 包，解压后直接运行：

redis-server.exe redis.windows.conf

注意 Windows 版本没有 Linux 上的后台 daemon 化概念，窗口不能关，关了 Redis 就停了。另一种方式是用 WSL 装 Linux 版 Redis，跟生产环境完全一致，我更推荐这种，可以最大程度避免 Windows 版本和 Linux 版本在指令、配置上的细微差异。配置文件里有几个参数建议从一开始就调好：maxmemory设置内存上限防止占满机器内存，maxmemory-policy allkeys-lru指定内存淘汰策略，appendonly yes开启 AOF 持久化防止重启丢数据。

Windows 上我遇到过坑是端口被占用。默认 6379 可能被别的服务占用，启动时报Could not create server TCP listening socket *:6379: bind: No error，用netstat -ano | findstr 6379找一下什么进程占的端口，改配置文件的port或者杀掉占用进程都可以。还有一点，Windows 版本 Redis 对 Redis Stack 模块的支持不全，想做向量检索建议还是用 Linux 环境或者 Docker，别在 Windows 原生环境上死磕。

4.3 可视化工具怎么选

连 Redis 的工具现在选择挺多，我实际用过比较顺手的两个：Another Redis Desktop Manager 和 Redis Insight。

Another Redis Desktop Manager（简称 ARDM）是社区用户很熟悉的 Redis Desktop Manager 的延续版，界面直观，连接配置简单，还能直接浏览 Hash、ZSet、Stream 这些复杂数据类型，看 key 的过期时间和内存占用都很方便。Redis Insight 是官方推出的可视化工具，对 Redis Stack 的支持最好，可以在界面上直接执行向量查询、查看索引结构、监控慢日志，还带有命令行终端。我现在的习惯是：日常开发调试用 ARDM，因为启动快、内存占用低；排查向量索引和慢查询问题时切 Redis Insight。两者的对比我整理成下面这个表：

4.4 生产环境必调的配置和安全项

生产环境的 Redis+AI 服务，有一些配置项是必调的，漏一个都可能出事故。

先看安全。默认没有密码而且监听所有网卡，这在生产环境里等于裸奔。至少要做三件事：配置requirepass设置强密码；bind只绑定内网地址；rename-command禁用或重命名FLUSHALL、KEYS、EVAL这类危险命令。之前我们有一次 Redis 被入侵者执行了 FLUSHALL，整个缓存一天的数据全没了，就是没做这三件事的教训。

再看内存和持久化。maxmemory一定要设，否则 Redis 会把服务器内存吃干。maxmemory-policy的选择要看场景：缓存层用allkeys-lru或allkeys-lfu；如果 Redis 里存了主从复制等必须保留的数据，用volatile-lru只淘汰有过期时间的 key。持久化方面，纯缓存对持久化要求不高，用 RDB 快照就够了；但如果 Redis 在项目里还承担了 AI 任务队列或 Agent 状态的存储，必须开 AOF，并且把appendfsync设成everysec，平衡性能和数据安全。

采样参数maxmemory-samples决定 LRU 淘汰的近似精度，默认 5，能调到 10 淘汰更精准但 CPU 消耗稍高，我一般设 10。Redis 7 之后默认用redis.conf里的io-threads可以开启多线程 IO，但注意文档说得很清楚，这是 IO 线程不是命令执行线程，别指望它能解决所有性能问题，而且只有在网络吞吐量成为瓶颈时才需要开启。

5. 常见问题与排查技巧实录

5.1 缓存穿透、击穿、雪崩的根治方案

这三兄弟是缓存系统绕不开的问题，在 AI 场景下危害被放大了，因为下游从“数据库查询”变成了“模型 API 调用”，每一层穿透都是真金白银和用户体验损失。

• 缓存穿透：查询根本不存在的数据。比如用户问一个知识库里完全没有内容的话题，每次都直接穿透到模型网关，模型还一本正经地答“我不知道”。解决方式：缓存空结果，给一个短 TTL（比如 5 分钟），同时用布隆过滤器前置拦截，先判断 key 是否存在，不存在直接返回，不进模型。
• 缓存击穿：热点 key 失效瞬间，大量请求涌进。解决方式：分布式锁 + 一个请求去加载，其他请求等待；推荐再加“逻辑过期”方案，缓存里存的过期时间比实际 TTL 短，异步线程刷新缓存，用户永远拿的是“新数据”，不会因为缓存过期产生集中穿透。
• 缓存雪崩：大量 key 同时过期，或者 Redis 本身挂了。解决方式：TTL 加随机值，不要把一批 key 的过期时间设成一个整点；Redis 做主从加哨兵或者集群，提高可用性；在应用层做多级缓存，本地缓存扛第一波，Redis 扛第二波。

我处理这类问题时一个心得是：先看监控图确认是哪一个“兄弟”在作怪，再针对性下手。穿透的特点是 QPS 高但实际数据不存在，击穿的特点是集中在某个 key，雪崩的特点是整体延迟抬升。对着现象用药，别所有问题都上一套方案，浪费资源还不好维护。

5.2 缓存与数据库的一致性：双删策略

AI 应用中，模型返回的数据有时需要回写业务库，业务库更新了以后缓存怎么同步，这是个经典难题。我目前用的方案是延迟双删：更新数据库之前删一次缓存，更新数据库之后等几百毫秒再删一次缓存。第一次删除是让失效数据尽快不下发，第二次删除是处理掉并发读写中间产生的脏缓存。

这个“等几百毫秒”的时间怎么定？要评估数据库主从同步和读请求完成的最坏时间，一般 500 毫秒到 1 秒比较稳妥。不能太短，否则第一个线程还没写完数据库，第二个线程已经把旧数据回填了缓存；也不能太长，否则这段时间内缓存一直缺失，后端压力全落在数据库上。

延迟双删不是百分百可靠，但对大多数业务够用。更彻底的做法是配合消息队列异步更新缓存，写数据库后发一条消息，消费端串行更新缓存，这个方案的维护成本高一些，但一致性更强。根据我的经验，AI 场景里大部分数据对一致性的容忍度没有想象中那么低，模型生成的答案本身带有概率性和时效性，缓存稍微旧一点问题不大，先保证可用性和成本可控，再去抠一致性。

5.3 大 key 问题：Redis 延迟突刺的元凶

Redis 是单线程执行命令的，如果某个 key 的 value 特别大，操作它的时候会阻塞其他所有命令，表现为整体延迟突然抖动。AI 场景里最容易出现大 key 的地方是：把整个文档内容直接塞进一个 String、把一个用户的全部会话记录都塞进一个 Hash、把一批向量二进制一起存进去。我见过最夸张的一次，一个 Hash 里存了 40 万条会话消息，HGETALL 命令执行了 3 秒钟，那 3 秒内整个 Redis 的所有请求都堵住了。

排查大 key 用redis-cli --bigkeys就行，它会扫描整个实例并输出最大的几个 key。处理方式分两类：能拆就拆，把大 Hash 拆成多个小 key，或者把大文档拆成多段分别存；拆不掉的做压缩，比如向量数据用二进制序列化压缩后再存。另外一定要给大 key 的读取设置超时时间，避免单个慢命令耗尽连接池。

这里有一个我自己的原则：单个 key 的 value 超过 10KB 就要警惕，超过 100KB 必须拆分或者压缩。尤其在做向量存储时，一篇文章的向量可能就有几十万个浮点数，如果整篇塞进一个 key，查询和写入都会非常痛苦。按文档块切分，一块一个 key，索引前缀统一，查询时用 KNN 一次只取前几块，这才是正确姿势。

5.4 连接池与连接数问题

AI 应用经常是突发流量，每个请求都要从连接池拿一个 Redis 连接。连接池配小了，高峰期大量线程阻塞在获取连接上，整体延迟变高；配大了，Redis 单机默认的最大连接数是 10000，超过之后报ERR max number of clients reached。我建议一开始就把连接池的max-total和max-idle参数根据预估 QPS 算好，并且加好连接获取超时，宁可短暂报错也不能无限等待。Jedis 和 Lettuce 的默认配置不同，Spring Boot 3 默认 Lettuce，它在并发场景下连接复用做得更好，但遇到大响应时也可能有背压问题，需要配套调timeout参数。

排查连接问题时重点看两个指标：活跃连接数和等待获取连接线程数。如果是连接不够，现象是获取连接超时；如果是连接泄漏，现象是活跃连接数持续上涨、空闲连接不释放，一般能从代码 audit 里找到没归还的连接。我曾经在项目里排查过一个诡异问题：Redis 连接数缓慢增长直到拒绝新连接，最后发现是一个 AI 异步任务里捕获异常后没有归还连接，这种代码 review 很难看出来，一定要靠监控图定位。

5.5 缓存治理的日常工作清单

Redis 接入 AI 之后规模上涨很快，我见过不少团队线上 Redis 乱成一锅粥，key 命名随便起、过期时间乱设、数据无人清理。这里列一份我整理的缓存治理日常清单：

• key 命名按业务线划分，比如ai:qabot:{userId}:{sessionId}:{seq}，方便按前缀批量清理和排查。
• 所有 key 必须设计 TTL，不允许出现永不过期的业务缓存。如果内存允许长期保留的数据，单独建一个“常驻区”，通过配置明确管理。
• 每周跑一次--bigkeys和内存分析，确认没有大 key 和无主流 key。
• 在指标监控面板里关注缓存命中率，命中率低于 80% 时要分析是缓存空间不够、TLL 设置不合理还是新上线功能没做缓存。
• 模型升级、词向量模型变更之后，要及时清理旧的语义缓存和向量索引，否则新旧向量混在一起语义检索效果会很奇怪。

这些事不需要一次做完，但一定要形成固定的巡检节奏。把 Redis 当成 AI 链路中的“责任田”来管理，才不至于等到出了问题再临时抱佛脚。

最后分享一个我自己的经验：做 Redis + AI 的接入，不要一开始就追求架构的“高大上”，先把语义缓存和向量检索这两件事用 Redis 跑通，把成本指标和命中率监控建立起来，再根据数据决定要不要引入更重的组件。我见过太多团队第一版就上了专用向量库加消息队列，结果链路长了、排查难了，实际效果未必比 Redis 方案好多少。工具永远是为业务服务的，把 Redis 这块地基吃透，AI 应用的地基就稳了一大半。