你不是金鱼——Spring AI 聊天记忆从“重启即失忆”到 MySQL 持久化的生产级改造实录

你不是金鱼——Spring AI 聊天记忆从“重启即失忆”到 MySQL 持久化的生产级改造实录一、问题不是“记不住”，而是系统根本没有记忆层很多团队第一次做 AI 对话应用时，都会产生一个错觉：模型这么聪明，应该能“记住”我刚刚说过的话现实是：大语言模型是无状态的每次调用都是一次全新的推理所谓“记忆”，本质上是应用层把历史消息重新拼进 Prompt这意味着，一旦你的聊天历史只存在 JVM 内存里，服务重启、Pod 漂移、实例扩缩容、节点故障，都会让用户的上下文瞬间消失。这不是体验问题，而是架构问题。在真实生产环境里，聊天记忆至少要同时满足四件事：重启不丢多实例共享多租户隔离成本和延迟可控如果做不到这四点，所谓“AI 客服”“AI 助手”“AI Copilot”都只是单机 Demo。二、先厘清一个常被混淆的概念：Memory 不是 HistorySpring AI 官方文档对这件事的定义非常重要：Chat Memory：提供给模型参与当前推理的上下文记忆Chat History：完整对话流水，用于审计、回放、分析、合规、训练这两个概念在工程上绝不能混为一谈。如果你把完整历史全部塞给模型，会遇到三个问题：Token 成本持续上涨响应延迟不断变大无关历史污染当前意图，回答质量反而下降所以一个成熟系统通常是“双轨存储”：一条轨道给模型用：短期记忆，窗口化、可裁剪、面向推理一条轨道给业务用：完整历史，可审计、可检索、可归档这也是为什么 Spring AI 把记忆抽象做成了两层：策略层和存储层。三、Spring AI 聊天记忆到底是怎么工作的Spring AI 的聊天记忆可以拆成三个核心角色：┌─────────────────────────────────────────────────────────┐ │ ChatClient + Advisor Chain │ │ 负责把“记忆”在请求前注入，在响应后写回 │ └─────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────┐ │ ChatMemory │ │ 负责决定“哪些消息应该保留给模型” │ │ 内置实现：MessageWindowChatMemory │ └─────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────┐ │ ChatMemoryRepository │ │ 负责决定“消息存在哪里” │ │ InMemory / JDBC / Cassandra / Neo4j / Mongo 等 │ └─────────────────────────────────────────────────────────┘1.ChatMemory是策略，不是数据库ChatMemory的职责不是持久化，而是控制记忆边界。默认实现MessageWindowChatMemory维护一个滑动窗口，默认保留最近 20 条消息，同时保留系统消息。这层解决的是：当前会话应该带多少上下文给模型老消息什么时候被驱逐如何避免上下文无限膨胀2.ChatMemoryRepository是存储抽象ChatMemoryRepository只做一件事：存和取。官方 API 的方法很简单：public interface ChatMemoryRepository { ListString findConversationIds(); ListMessage findByConversationId(String conversationId); void saveAll(String conversationId, ListMessage messages); void deleteByConversationId(String conversationId); }这里有一个很容易被忽略、但对高并发架构非常关键的点：saveAll(...)的语义是“替换当前会话的记忆窗口”它不是逐条 append这意味着在默认模式下，窗口越大，每次写入放大越明显。假设窗口保留 40 条消息，那么一轮对话结束后，Repository 很可能要把这 40 条的当前视图整体保存一次。工程上这会带来两个直接结论：记忆窗口不是越大越好“短期记忆”和“完整归档”最好拆开设计3. Advisor 才是“自动注入记忆”的关键在ChatClient里，真正把记忆串起来的是 Advisor。以MessageChatMemoryAdvisor为例，它在一轮对话里做两件事：请求发给模型之前，根据conversationId取出历史消息并拼入 Prompt模型响应回来之后，把本轮消息更新回ChatMemory可以把它理解成一个“记忆拦截器链”：四、为什么默认InMemoryChatMemoryRepository一定会在生产翻车Spring AI 默认会自动装配：InMemoryChatMemoryRepositoryMessageWindowChatMemory它非常适合本地开发，但不适合生产，原因不是“性能差”，而是“边界错了”。1. 生命周期绑定 JVM内存记忆和进程同生共死：应用重启即丢失滚动发布即丢失OOM 重启即丢失2. 无法跨实例共享在 Kubernetes 或 ECS 多副本部署下：用户第一次命中 Pod A第二次命中 Pod B两个实例各自持有不同内存结果就是“机器人像失忆了一样前后矛盾”。3. 无法治理和审计你看不到：某个租户最近占了多少记忆数据哪些会话增长异常某个回答为什么会引用那段历史所以内存实现的本质定位只有一个：本地验证不是试运行，不是灰度，也不是生产。五、生产选型：为什么第一站通常应该是 MySQL很多人会问，聊天记忆是不是应该直接上 Redis？答案是：未必。先看三种典型选型：方案优点缺点适合场景InMemory零成本、零配置重启丢失、无法共享本地开发JDBC + MySQL强一致、易审计、易运维、SQL 能力强写放大明显、热点会话压力集中大多数生产系统Redis 自定义 Repository低延迟、天然 TTL、横向扩展好审计弱、历史检索弱、持久化语义需要额外设计高频短会话、超高并发场景对大多数企业应用，MySQL 是最稳妥的第一站，原因有四个：团队熟悉，运维成熟强一致语义清晰容易做租户隔离、索引、归档、备份便于和历史表、工