Spring AI生产级改造：Redis持久化会话记忆，ES存储向量索引

搞 Spring AI 项目的同学八成都有过同一个尴尬时刻本地调得好好的对话逻辑、RAG 流程全通一部署到生产隔天用户回来继续聊天机器人完全不记得昨天说了什么。原因就一句话——Spring AI 默认的会话记忆和向量存储都是内存态的进程一重启全部归零。我在一个智能客服项目里踩过这个坑之后索性把整套方案做成了“记忆落 Redis、向量落 ES 的重启不丢”结构对话历史用 Redis 持久化知识库向量索引放 Elasticsearch应用重启、发版、扩容数据都还在。这篇文章把这套改造从头到尾拆开讲包括 Spring AI 的记忆抽象机制、Redis 侧的自定义实现、ES 侧的向量库配置、以及实际生产环境里遇到过的各种坑。如果你是正在用 Spring AI 做 ChatBot、RAG 问答或智能助手并且已经受够了“一重启就失忆”的默认行为这篇内容可以直接照着抄。1. 为什么非改造不可内存态记忆的致命短板1.1 默认实现到底丢在哪Spring AI 刚上手时特别省事很多东西开箱即用。比如会话记忆默认有一个内存实现向量存储也默认有一个基于内存的简单实现。你把对话丢进去、把文档向量写进去测试阶段一切正常。但这些默认实现本质上就是一个进程内的 Map 或者 List生命周期跟着 JVM 走。问题非常直白应用重启数据没了。应用多实例部署每个实例各存各的用户第一次请求打到 A 节点记住的事第二次请求被负载均衡导到 B 节点B 节点完全不知道。实例缩容那一台机器上的全部记忆直接消失。这三条在开发环境无所谓一旦进入生产条条都是事故。我做客服项目时最开始只接了一个简单上下文窗口本地自测连续问五轮没问题结果灰度上去用户反馈“刚才还聊得好好的刷新一下就失忆了”。排查到最后就是内存态存储导致的。1.2 Redis 和 ES 在这次改造里的分工既然要解决“重启不丢”第一步是选存储。对话记忆和向量数据其实是两种完全不同特征的数据不能都丢同一个地方。对话记忆的特点是高频读写、单条数据量小、对延迟极其敏感、而且有过期语义一般不需要永久保存。这种场景 Redis 是天然合适的读写微秒级支持 TTL数据结构灵活运维成本低。向量数据的特点是每条数据是一个几百上千维的浮点数组核心操作不是点查而是相似度搜索而且生产环境里往往还要结合业务字段做过滤。这种场景需要的是专业的向量检索能力。Elasticsearch 从 7.x 开始引入 dense_vector8.x 之后 kNN 检索已经很成熟可以和业务字段做组合过滤还自带分布式扩展能力。两者分工可以这样理解Redis 管“记得住上下文”ES 管“找得到相关知识”。一个是对话的短期记忆一个是知识的长期索引各有各的归属。数据维度默认内存方案升级到 Redis / ES会话历史进程内 MapRedis带 TTL可续期向量索引进程内 ListElasticsearch支持 kNN 过滤多实例共享不支持天然支持重启/发版全丢不丢容量上限受单机内存限制按需横向扩展1.3 改造前必须先确认 Spring AI 版本Spring AI 最近一年 API 变动非常频繁尤其是进入 1.0 稳定版前后很多核心接口都重命名过。我最早是在 0.8.x 的某个里程碑版本上做的第一版实现后来升级到 1.0.x原来的代码几乎要重写一遍。所以看这篇文章之前先确认两件事你的 Spring AI 依赖版本是多少看 pom.xml 或 build.gradle。你当前版本的ChatMemory接口方法签名是什么样。我能给你的最稳妥建议是直接打开本地依赖里的源码看一眼或者到仓库里找到对应 tag 的源码。接口方法名变了不可怕可怕的是你不知道变了还在用旧签名硬写编译都过不去。后面所有代码我都基于 Spring AI 1.0.x 的接口风格给出如果你还在用里程碑版本重点看设计思路而非逐行代码。2. 记忆落 Redis从默认内存到自定义持久化2.1 Spring AI 的记忆抽象与窗口机制Spring AI 把对话记忆拆成了两层抽象ChatMemory负责“存”和“取”原始会话消息是底层存储接口。ChatMemoryService负责“怎么用”比如按 token 窗口裁剪、按消息条数限制、从完整会话里取最近 N 条。你平时在代码里配置的“窗口大小”其实作用在ChatMemoryService这一层而不是存储层。存储层只关心一件事给我一个 conversationId把对应的整段会话消息落盘。这个拆分很重要因为它意味着你不需要动窗口策略只需要替换ChatMemory的底层实现就能把内存存储换成 Redis。窗口裁剪逻辑完全复用 Spring AI 自带的机制。以 1.0.x 为例ChatMemory的核心方法大概长这样根据 conversationId 获取会话。保存整个会话。删除会话。你的任务就是把这几个方法实现成“读写 Redis”然后把实现注册成一个 BeanSpring AI 会自动感知并使用它。2.2 用 Redis 实现 ChatMemory 的完整步骤我的做法是提供一个自定义 Bean内部用 Spring Data Redis 操作字符串类型value 存 JSON。实现思路如下Component public class RedisChatMemory implements ChatMemory { private static final String KEY_PREFIX ai:chat:memory:; private final RedisTemplateString, String redisTemplate; private final ObjectMapper objectMapper; public RedisChatMemory(RedisTemplateString, String redisTemplate, ObjectMapper objectMapper) { this.redisTemplate redisTemplate; this.objectMapper objectMapper; } Override public OptionalConversation getConversation(String conversationId) { String json redisTemplate.opsForValue().get(KEY_PREFIX conversationId); if (json null) { return Optional.empty(); } try { return Optional.of(objectMapper.readValue(json, Conversation.class)); } catch (Exception e) { // 反序列化失败时宁可重新开始会话也不要让接口直接报错 return Optional.empty(); } } Override public void addConversation(Conversation conversation) { try { String json objectMapper.writeValueAsString(conversation); redisTemplate.opsForValue().set(KEY_PREFIX conversation.id(), json, Duration.ofHours(24)); } catch (Exception e) { throw new IllegalStateException(Redis 会话写入失败, e); } } Override public void deleteConversation(String conversationId) { redisTemplate.delete(KEY_PREFIX conversationId); } }代码本身不复杂但有几处细节是实际跑过才会发现的下面单独展开说。2.3 序列化与 TTL两个最容易被忽略的细节第一个坑是序列化。Conversation里包含一个ListMessage而Message是一个接口有 SystemMessage、UserMessage、AssistantMessage、ToolResponseMessage 等具体类型。Jackson 默认序列化接口类型的实现类时只按运行时类型输出字段反序列化时却不知道要还原成哪个子类结果就是 JSON 能写进去读出来直接抱错。我踩过一次之后放弃了直接用 Spring AI 的Conversation做 Redis 存储对象改成自定义结构public class ConversationEntity { private String conversationId; private ListMessageEntity messages; private long lastUpdatedAt; } public class MessageEntity { private MessageType type; private MapString, Object content; private MapString, Object metadata; }写入前做一次转换读取后做一次还原。多一层转换的好处是彻底绕开 Jackson 多态反序列化问题而且这个结构也是你自己定义的将来换存储、加字段都方便。第二个坑是 TTL。会话数据是敏感且有生命周期的不能永久躺在 Redis 里。我建议所有 key 统一设置过期时间比如 24 小时。每次有新的对话消息写入时set 操作会顺带覆盖过期时间等于“活跃即续期”。不活跃的会话自然过期不用额外写清理任务。如果你担心 Redis 里残留太多的 key还可以配一个定时任务扫描ai:chat:memory:*前缀的 key把超过 N 天没更新的删掉。不过一般来说 TTL 已经够用定时任务属于锦上添花。注册完这个 Bean 之后你可以做个简单验证跑一个多轮对话确认 Redis 里出现了ai:chat:memory:xxx的 key然后重启应用再带着同一个 conversationId 继续对话模型应该记得之前的内容。这一步通过记忆落 Redis 的改造就算完成了。3. 向量落 ESElasticsearchVectorStore 生产配置3.1 为什么选 ES 而不是 Redis 向量很多人会问Redis 也能存向量为什么不直接用 Redis 的向量能力我的判断依据是检索场景的复杂度。对话记忆是点查Redis 的 Hash 或 String 足够。但知识库检索往往伴随着业务过滤条件比如“只查当前租户的数据”“只查某个分类下的文档”。Elasticsearch 的 filter 能力非常成熟可以和向量检索组合成一条 DSL在一个请求里完成过滤和排序。另外向量检索的召回质量跟索引结构有关系。ES 的 dense_vector 字段支持 HNSW 算法配置好之后可以保证一定的召回率。Redis 的向量能力不是不强而是它更适合简单的场景一旦过滤条件复杂起来ES 的表达能力和生态优势就体现出来了。我项目里当时还考虑过专门的向量数据库但最后放弃了一个核心原因不想为了一个检索功能单独引入一套新存储。ES 本来就是日志和全文检索的基础设施团队对它已经很熟复用这一套反而省事。3.2 维度、距离算法与自动建索引Spring AI 对 Elasticsearch 有官方集成配置好之后它会自动创建索引、写入向量、执行 kNN 检索。我的配置大致如下spring: ai: vectorstore: elasticsearch: index-name: ai_vector_store dimensions: 1536 distance-type: cosine number-of-shards: 1 number-of-replicas: 0 elasticsearch: uris: http://localhost:9200 username: elastic password: ${ES_PASSWORD}这里面有两个参数必须对齐否则会出问题dimensions必须等于你所用 EmbeddingModel 产出的向量维度。用 OpenAI 的接口通常是 1536用本地部署的嵌入模型可能是 768、1024 或其他值。不匹配的话写入向量时 ES 会直接拒绝。distance-type影响相似度计算方式。常见的选择是 cosine它适合文本语义检索因为只关心方向不关心模长。注意如果你自己手动创建过同名索引那 mapping 里的字段类型必须和 Spring AI 默认生成的保持一致。我遇到过手工建了个索引、字段类型写错结果 Spring AI 启动时检测到索引已存在不会重建写入时却一直失败非常折腾。Spring AI 的 ElasticsearchVectorStore 在启动时如果没有检测到索引会自动创建这个自动建的 mapping 是它的默认结构一般不用手工干预。但如果你对分片数、副本数有要求可以在配置里指定建议测试环境把副本设成 0节省资源生产环境至少 1 个副本。3.3 多租户隔离与元数据过滤实战只把向量写进 ES 是不够的生产级检索几乎都要带业务过滤。Spring AI 的 VectorStore API 支持在添加文档时附带 Metadata并且在检索时通过 filter 表达式过滤。写入侧构造文档时给每个 Document 加上 metadataDocument doc new Document(text, Map.of( tenantId, tenant_001, category, faq )); vectorStore.add(List.of(doc));检索侧通过 filter 表达式限定范围FilterExpressionBuilder b new FilterExpressionBuilder(); FilterExpression filter b.eq(tenantId, tenant_001).build(); SearchRequest request SearchRequest.builder() .query(理赔流程是什么) .topK(5) .filterExpression(filter) .build(); ListDocument results vectorStore.similaritySearch(request);这样就能保证就算整个知识库里有多租户的数据检索时也只返回当前租户的内容避免数据串味。向量落 ES 之后重启丢失问题也就不存在了。文档向量是持久化的应用重启后索引还在检索结果和之前保持一致。这一步做完整个“记忆 知识”两条链路都告别了内存态。4. 生产实战踩坑记录与排查清单4.1 典型问题一版本切换引发序列化异常现象是应用日志里出现 Jackson 反序列化失败指向Message类型无法构造。原因多数不是代码逻辑问题而是 Spring AI 升级后ChatMemory接口和内部数据类型变了。旧版本里存的是 List 新版本里包了一层 Conversation如果你的 Redis 里已经存在旧格式的数据升级后第一次读取就会异常。解法是做好兼容处理。读取时如果反序列化失败不要直接抛错而是返回空会话让对话“重新开始”。同时把 Redis key 加一个带版本号的前缀比如v2:ai:chat:memory:让新旧数据天然隔离。4.2 典型问题二索引 mapping 不一致导致写入失败现象是往 ES 写入向量时抛mapper_parsing_exception提示某个字段类型不对。原因几乎都是索引已经存在但 mapping 与 Spring AI 默认结构不一致。常见于你手工建过索引、或者之前用其他工具写过数据字段类型是 long 但 Spring AI 期望 keyword或者 dense_vector 的维度不一致。解法如果索引里没有不可丢的数据直接删除索引让 Spring AI 重建如果要保留数据就只能手动改 mapping但 dense_vector 的维度一旦创建就改不了只能重建索引重新灌数据。所以我的经验是索引名一定要和环境隔离测试别用生产索引名。4.3 典型问题三会话窗口策略导致 token 超限现象是对话轮数一多调用模型时报超出上下文长度限制。很多人会把maxMessages当成 token 上限其实它只控制消息条数。比如你设置了 20 条但其中某条消息特别长20 条加起来可能已经超过模型的上下文窗口。解法是改用基于 token 计数的窗口策略。Spring AI 提供了对应的TokenCountWindowChatMemoryService它需要注入一个 Token 计数组件并且要和你实际使用的模型配套。不同模型的 tokenizer 不同计数结果也不一样。落地时我建议按模型类型配置各自的 token 上限留出 10%-20% 的余量给回复内容。4.4 快速排查清单症状可能原因处理方向重启后对话失忆未注册 Redis ChatMemory Bean确认自定义 Bean 是否被扫描看 Redis 里有没有 keyRedis 有 key 但读出来是空反序列化失败被吞掉查日志中的 Jackson 异常检查 Message 类型信息ES 写入报 mapper 异常索引 mapping 不一致删除索引重建或改字段类型向量检索结果为空维度不匹配核对 EmbeddingModel 输出维度和 ES 配置多轮对话后报 token 超限窗口策略按条数而非 token换 Token 计数窗口实现多实例下记忆互相覆盖每次会话生成不同 conversationId前端传回稳定 conversationId存到会话上下文这张表我在项目里每次排查问题时都会扫一眼基本覆盖了这套方案里八成以上的故障方向。5. 性能与容量设计改造完成之后还要想的几件事5.1 会话记忆的过期与总量控制Redis 做会话存储之后第一个要面对的问题是“容量规划”。一次多轮对话的 JSON 可能从几百字节到几十 KB 不等如果用户量起来Redis 内存占用会涨得很快。我的做法是写操作时估算 JSON 大小超过阈值比如 50KB就把更早的消息截掉一部分只保留最近的内容。因为对话记忆本质上只是给模型提供上下文太久远的消息留着也是浪费存储。配合 TTL 自动过期Redis 的内存基本能维持在一个稳定水位。5.2 索引生命周期与写入吞吐ES 向量索引的容量和写入吞吐也不能忽视。文档向量化之后每条数据都是几百上千维的浮点数组占空间不小。我建议按业务模块拆分索引不要一个索引装所有数据。定期做索引生命周期管理比如按时间分索引旧索引自动删除或归档。批量写入时控制批次大小一次 100-500 条比较合适太大容易把 ES 写入队列打满。5.3 监控指标这套方案上线后建议至少盯三个指标Redis 的命中率和内存使用率。命中率太低说明 TTL 太短或者 conversationId 传得不稳定。ES 的查询延迟和拒绝率。kNN 查询本身不慢但 filter 条件复杂时要注意性能。应用侧调用模型的 token 消耗。这个能直接反映窗口策略是否合理。我当时就是在监控里发现某个渠道的会话特别长单次请求 token 消耗剧增才去优化了窗口策略。没有监控这些问题都要等用户投诉才会暴露。改造做到这一步Spring AI 项目的生产化基础就算打牢了。记忆在 Redis 里向量在 ES 里应用随便重启、随便扩容数据都还在。你自己在本地改代码验证的时候也可以专门试试跑完一轮对话看一眼 Redis 里的 key 和 ES 索引里的文档数然后 kill 掉进程再启动带着同一个会话去问“我刚才说什么了”看到模型能准确接上话那种感觉比什么单元测试都踏实。