当前位置：首页 > news >正文

【SpringAI篇04】：从内存到MySQL，构建可重启的智能对话系统

news 2026/8/15 6:29:45

1. 为什么需要从内存存储升级到数据库持久化

刚开始接触SpringAI开发时，很多开发者都会选择默认的内存存储方案。这种方案简单直接，不需要额外配置数据库，特别适合快速原型开发。但当你真正要把应用部署到生产环境时，就会发现内存存储存在几个致命缺陷。

最明显的问题就是数据易失性。内存中的数据在应用重启后会全部丢失，这意味着用户每次重新打开聊天界面，之前的对话记录都会消失。想象一下，你正在和客服机器人讨论产品问题，突然系统需要更新重启，回来后发现之前的对话全没了，这种体验有多糟糕。

另一个问题是内存限制。MessageWindowChatMemory默认会限制保存的消息数量（比如只保留最近的20条），超出限制的旧消息会被自动丢弃。在实际业务场景中，用户可能需要查阅几天前的对话记录，这种限制显然无法满足需求。

我去年开发过一个电商客服系统，最初用的就是内存存储。结果上线第一天就收到大量投诉——用户反映每次刷新页面聊天记录就没了。更糟的是，当并发用户数增加到500以上时，服务器内存直接爆满。那次教训让我深刻认识到：生产级应用必须使用数据库持久化。

2. 内存存储与数据库持久化的技术对比

2.1 内存存储的工作原理

SpringAI默认的InMemoryChatMemoryRepository底层使用ConcurrentHashMap存储数据。这种实现有三大特点：

读写速度快：直接操作内存，没有磁盘I/O开销
线程安全：使用并发集合保证多线程环境下的数据安全
临时存储：数据生命周期与JVM进程绑定

// 伪代码展示内存存储实现原理 public class InMemoryChatMemoryRepository implements ChatMemoryRepository { private final ConcurrentHashMap<String, List<Message>> storage = new ConcurrentHashMap<>(); @Override public void save(String conversationId, Message message) { storage.computeIfAbsent(conversationId, k -> new ArrayList<>()).add(message); } }

2.2 数据库持久化的优势

相比之下，基于MySQL的JdbcChatMemoryRepository带来了质的提升：

数据持久化：服务器重启不影响对话记录
存储容量大：不受JVM内存限制
历史追溯：可以查询任意时间点的对话
集群支持：多实例应用可以共享对话记录

通过实测对比，两种方案的关键指标差异如下：

对比维度	内存存储方案	MySQL持久化方案
数据持久性	进程退出即丢失	永久保存
存储容量	受JVM堆内存限制	仅受磁盘空间限制
读写性能	微秒级响应	毫秒级响应
集群支持	单实例有效	多实例共享
历史查询	仅能访问当前会话	支持全量历史检索

3. 实现MySQL持久化的完整步骤

3.1 环境准备与依赖配置

首先需要在项目中添加必要的依赖。除了基础的Spring Boot Starter和MySQL驱动外，关键是要引入spring-ai-starter-model-chat-memory-repository-jdbc：

<dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-starter-model-chat-memory-repository-jdbc</artifactId> </dependency>

这里有个容易踩的坑：版本兼容性问题。建议使用SpringAI的BOM管理依赖版本，避免出现奇怪的类冲突。我在项目中是这样配置的：

<dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-bom</artifactId> <version>1.0.0</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>

3.2 数据库表设计与初始化

SpringAI要求特定的表结构来存储对话记录。建议创建一个schema-mysql.sql文件放在resources目录下：

CREATE TABLE IF NOT EXISTS SPRING_AI_CHAT_MEMORY ( conversation_id VARCHAR(36) NOT NULL, content TEXT NOT NULL, type VARCHAR(10) NOT NULL, `timestamp` TIMESTAMP NOT NULL, CONSTRAINT TYPE_CHECK CHECK (type IN ('USER', 'ASSISTANT', 'SYSTEM', 'TOOL')) );

这个表设计有几个关键点：

conversation_id使用UUID格式，确保全局唯一
content字段使用TEXT类型，支持长文本存储
type字段通过CHECK约束保证数据一致性

在application.yml中配置自动初始化：

spring: ai: chat: memory: repository: jdbc: initialize-schema: always schema: classpath:schema-mysql.sql

4. 核心代码实现与配置

4.1 数据源配置详解

MySQL连接配置是第一个容易出错的地方。以下是经过生产验证的推荐配置：

spring: datasource: url: jdbc:mysql://localhost:3306/spring_ai_chat?useSSL=false&useUnicode=true&characterEncoding=UTF-8 username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver hikari: maximum-pool-size: 10 connection-timeout: 30000

特别提醒：一定要设置characterEncoding=UTF-8，否则中文对话内容会出现乱码。我曾经因为漏掉这个参数，花了三天时间排查中文存储问题。

4.2 ChatMemory的Bean配置

配置类的实现非常简洁，但内涵丰富：

@Configuration @RequiredArgsConstructor public class ChatConfig { private final JdbcChatMemoryRepository repository; @Bean public ChatMemory chatMemory() { return MessageWindowChatMemory.builder() .chatMemoryRepository(repository) .maxMessages(50) .build(); } }

这里有几个实践经验值得分享：

maxMessages建议设置为50-100，既保证上下文完整又不会加载过多历史
对于高并发场景，可以添加@EnableCaching提升性能
考虑实现自定义的ChatMemoryRepository接口来扩展功能

5. 效果验证与性能优化

5.1 基础功能测试

启动应用后，可以通过简单三步验证功能：

发起新对话："你好，我想咨询产品问题"
重启应用服务器
继续对话："我昨天问的那个产品..."

如果系统能正确回忆之前的对话内容，说明持久化成功。我建议使用Postman或curl脚本自动化这个测试流程。

5.2 高并发场景下的优化

当用户量增长时，原始实现可能遇到性能瓶颈。通过JMeter测试，我们发现两个优化点：

批量插入优化：默认实现是单条插入，可以重写save方法改用批量插入
缓存层添加：使用Caffeine缓存热点对话

优化后的Repository实现示例：

public class OptimizedChatMemoryRepository implements ChatMemoryRepository { private final JdbcTemplate jdbcTemplate; private final Cache<String, List<Message>> cache; @Override @Transactional public void save(String conversationId, Message message) { // 批量插入逻辑 jdbcTemplate.batchUpdate( "INSERT INTO SPRING_AI_CHAT_MEMORY VALUES (?,?,?,?)", new BatchPreparedStatementSetter() { // 实现省略 }); // 更新缓存 cache.put(conversationId, loadMessages(conversationId)); } }

6. 生产环境最佳实践

6.1 数据清理策略

对话数据会随时间不断增长，需要制定清理策略。我推荐两种方案：

定时任务清理：保留最近N天的数据

@Scheduled(cron = "0 0 3 * * ?") // 每天凌晨3点执行 public void cleanupOldConversations() { jdbcTemplate.update( "DELETE FROM SPRING_AI_CHAT_MEMORY WHERE timestamp < ?", LocalDateTime.now().minusDays(30)); }

归档策略：将旧数据迁移到历史表

6.2 监控与告警

通过Spring Actuator添加健康检查：

management: endpoint: health: show-details: always endpoints: web: exposure: include: health,metrics

关键监控指标包括：

对话记录增长速率
数据库查询延迟
存储空间使用率

7. 扩展应用场景

7.1 多模态对话存储

除了文本消息，现代对话系统还需要处理图片、文件等多媒体。可以通过扩展表结构实现：

ALTER TABLE SPRING_AI_CHAT_MEMORY ADD COLUMN media_type VARCHAR(20), ADD COLUMN media_url VARCHAR(255);

7.2 跨会话分析

持久化后的数据可以用于业务分析，比如：

-- 统计最常被提及的产品 SELECT COUNT(*) as count, REGEXP_SUBSTR(content, '产品[：:](\\w+)') as product FROM SPRING_AI_CHAT_MEMORY WHERE type = 'USER' GROUP BY product ORDER BY count DESC;

在实际项目中，这类分析帮助我们发现了很多用户痛点。比如通过分析发现"退货流程"是被提及最多的问题，我们随后优化了相关流程，客户满意度提升了35%。

查看全文

http://www.cnnetsun.cn/news/1578408.html