你不是金鱼——Spring AI 聊天记忆从“重启即失忆”到 MySQL 持久化的生产级改造实录
你不是金鱼——Spring AI 聊天记忆从“重启即失忆”到 MySQL 持久化的生产级改造实录
一、问题不是“记不住”，而是系统根本没有记忆层
很多团队第一次做 AI 对话应用时，都会产生一个错觉：
- 模型这么聪明，应该能“记住”我刚刚说过的话
现实是：
- 大语言模型是无状态的
- 每次调用都是一次全新的推理
- 所谓“记忆”，本质上是应用层把历史消息重新拼进 Prompt
这意味着，一旦你的聊天历史只存在 JVM 内存里，服务重启、Pod 漂移、实例扩缩容、节点故障，都会让用户的上下文瞬间消失。
这不是体验问题，而是架构问题。
在真实生产环境里，聊天记忆至少要同时满足四件事：
- 重启不丢
- 多实例共享
- 多租户隔离
- 成本和延迟可控
如果做不到这四点，所谓“AI 客服”“AI 助手”“AI Copilot”都只是单机 Demo。
二、先厘清一个常被混淆的概念：Memory 不是 History
Spring 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 { List<String> findConversationIds(); List<Message> findByConversationId(String conversationId); void saveAll(String conversationId, List<Message> 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 是最稳妥的第一站，原因有四个：
- 团队熟悉，运维成熟
- 强一致语义清晰
- 容易做租户隔离、索引、归档、备份
- 便于和历史表、工