这是《Spring AI 实战》系列第 3 篇。第 1 篇讲了为什么用 Spring AI、Portable API 怎么屏蔽模型差异第 2 篇落地了「能聊天、有性格、记得住」的三件套ChatClient Prompt ChatMemory。这一篇解决三件套里最容易被忽略、却最要命的一环ChatMemory 怎么从「demo 玩具」变成「生产级持久化」。开局InMemoryChatMemory 能玩不能上线第 2 篇里我们用的记忆是内存版最小写法就一行BeanpublicChatMemorychatMemory(){returnnewInMemoryChatMemory();}它能跑通多轮对话但有三个致命伤任何一个都足以让你在生产环境翻车重启即丢进程一重启所有对话记忆清零用户第二天来聊AI 完全不认识他。内存无限堆积InMemoryChatMemory不淘汰、不落盘会话越多内存越涨最终 OOM。多实例不同步加了节点做负载均衡A 实例记的对话 B 实例不知道用户请求在实例间漂移记忆时有时无。金鱼脑的聊天机器人上线即事故。要解决这个问题核心动作只有两步引依赖 写 yml。下面两套方案都来自 Spring AI Alibaba 官方扩展代码量趋近于零。方案一MySQLAlibaba JDBC Starter适合团队已经有 MySQL的场景零额外基础设施。第一步引依赖dependencygroupIdcom.alibaba.cloud.ai/groupIdartifactIdspring-ai-alibaba-starter-memory-jdbc/artifactIdversion1.0.0.3/version/dependency第二步写配置spring:ai:chat:memory:repository:jdbc:mysql:jdbc-url:jdbc:mysql://localhost:3306/memory_db?useSSLfalseserverTimezoneAsia/Shanghaiusername:rootpassword:${MYSQL_PASSWORD}driver-class-name:com.mysql.cj.jdbc.Driverenabled:true# 默认 false必须显式打开enabled一开框架在MysqlChatMemoryRepository初始化时自动检查表是否存在——不存在就给你建好。DDL、索引、字段设计全包了你连建表 SQL 都不用写。如果你的数据库是 PostgreSQL、Oracle、SQL Server把mysql换成postgres、oracle、sqlserver即可配置结构完全一致。第三步写代码ChatConfig—— 全局缓存和 Advisor一次构建ConfigurationpublicclassChatConfig{BeanpublicMessageWindowChatMemorychatMemory(MysqlChatMemoryRepositoryrepository){returnMessageWindowChatMemory.builder().chatMemoryRepository(repository).maxMessages(50).build();}BeanpublicChatClientchatClient(ChatClient.Builderbuilder,MessageWindowChatMemorychatMemory){returnbuilder.defaultAdvisors(MessageChatMemoryAdvisor.builder(chatMemory).build()).build();}}ChatController—— 每次请求只传对话 IDRestControllerpublicclassChatController{privatefinalChatClientchatClient;publicChatController(ChatClientchatClient){this.chatClientchatClient;}GetMapping(/chat)publicStringchat(RequestParamStringprompt,RequestParamStringconversationId){returnchatClient.prompt(prompt).advisors(a-a.param(MessageChatMemoryAdvisor.CONVERSATION_ID,conversationId)).call().content();}}conversationId区分不同用户/会话每人一段独立的记忆空间。ChatClient 和 Advisor 启动时建好请求链路零开销。方案二RedisAlibaba Redis Starter适合团队已经有 Redis、且要更高读写性能的场景。第一步引依赖Redis 需要两个包——自动装配 实现dependencygroupIdcom.alibaba.cloud.ai/groupIdartifactIdspring-ai-alibaba-autoconfigure-memory/artifactIdversion1.0.0.3/version/dependencydependencygroupIdcom.alibaba.cloud.ai/groupIdartifactIdspring-ai-alibaba-starter-memory-redis/artifactIdversion1.0.0.3/version/dependency第二步写配置单机最简spring:ai:memory:redis:mode:standalonehost:localhostport:6379password:${REDIS_PASSWORD}想换客户端一行client-type:jedis# 默认 lettuce可选 jedis / redisson集群模式spring:ai:memory:redis:mode:clustercluster:nodes:10.0.0.1:6379,10.0.0.2:6379,10.0.0.3:6379第三步写代码ChatConfig—— 和 MySQL 方案只差一个注入的 Repository 类型ConfigurationpublicclassChatConfig{BeanpublicMessageWindowChatMemorychatMemory(BaseRedisChatMemoryRepositoryrepository){returnMessageWindowChatMemory.builder().chatMemoryRepository(repository).maxMessages(50).build();}BeanpublicChatClientchatClient(ChatClient.Builderbuilder,MessageWindowChatMemorychatMemory){returnbuilder.defaultAdvisors(MessageChatMemoryAdvisor.builder(chatMemory).build()).build();}}ChatController —— 和 MySQL 方案完全一样一行不动RestControllerpublicclassChatController{privatefinalChatClientchatClient;publicChatController(ChatClientchatClient){this.chatClientchatClient;}GetMapping(/chat)publicStringchat(RequestParamStringprompt,RequestParamStringconversationId){returnchatClient.prompt(prompt).advisors(a-a.param(MessageChatMemoryAdvisor.CONVERSATION_ID,conversationId)).call().content();}}从 MySQL 切到 Redis改动的代码只有一行—— 把MysqlChatMemoryRepository换成BaseRedisChatMemoryRepository。Controller 零改动业务逻辑零改动。这就是抽象层带来的红利。为什么要避开手写方案如果纯手写你需要实现ChatMemoryStore接口写 60 行、Jackson 多态序列化配置、定时清理任务、建表 SQL。两个存储方案加起来小 200 行。Alibaba 方案呢两段配置 两段 Config 不到 30 行。而且多出来的不光是代码量维度手写Alibaba JDBCAlibaba Redis建表手动 SQL自动建不需要序列化Jackson 多态配置框架内置框架内置过期清理手写定时任务框架内置框架内置 TTL多客户端无-Lettuce/Jedis/Redisson 切着玩集群手写共享库就行配置写几个 IP切存储改代码量重写改一行改一行选 MySQL 还是 Redis维度MySQLRedis额外运维零已有 MySQL需要 Redis性能毫秒级够用微秒级多实例共享MySQL 即可天然支持依赖量1 个包2 个包一句话团队已经有 Redis 就上 Redis没有就用 MySQL。聊天记忆不值得你专门引入一套 Redis 基础设施。几个容易踩的点enabled: true必须显式打开JDBC 和 Redis 的 Starter 默认enabledfalse不写这一行框架不会初始化 Repository启动不报错但记忆根本没持久化——排查起来很隐蔽。配置项是jdbc-url不是url和 Spring 传统的spring.datasource.url命名不同照抄老习惯会连不上库。client-type别乱填Redis 默认lettuce可选jedis/redisson填了不存在的值启动直接失败。maxMessages要设不设这个窗口记忆照样无限增长虽然落盘了但单会话消息越来越多token 成本和控制台都吃不消。conversationId必须每次传忘了传所有用户共享同一段记忆聊天内容串台。小结Spring AI Alibaba 把记忆持久化做成了「引依赖 写 yml」的体力活把常用存储封成 Starter、把记忆做成可配置的 Bean、让存储切换不影响业务代码。你不需要关心 JSON 序列化、表结构、过期策略、客户端的底层差异——闭着眼睛配 yml写两段 Config聊天机器人就带上生产级持久化记忆了。如果这篇对你有帮助点个关注 我会持续更新 Spring AI 实战系列从聊天、RAG 到原理篇篇带完整代码关注不迷路。博主10 年 Java 全栈开发优质创作者。专注 Spring 源码、架构设计与 Spring AI 实战。前文回顾Spring AI 实战1Java 开发者如何优雅接入大模型附完整代码Spring AI 实战2ChatClientPrompt记忆三件套手把手搭 AI 对话附代码
