SpringAI 1.0.0 与 Redis 深度整合：构建高性能、可扩展的会话记忆系统
在构建现代智能对话应用时，一个核心挑战是如何高效、可靠地管理多轮对话的上下文。大语言模型（LLM）本质上是无状态的，这意味着每次请求都是一次全新的交互，模型本身不会记住之前的对话内容。对于电商客服、智能助手、教育辅导等需要连续对话的场景，这种“失忆”特性会严重影响用户体验。SpringAI 1.0.0 正式版的发布，为 Java 开发者提供了一套优雅的解决方案，而结合 Redis 这一高性能内存数据库，我们能够构建出既满足高并发需求，又能保证数据持久化的会话记忆系统。
这篇文章不是简单的技术堆砌，而是基于我在多个生产级项目中的实践经验，深入探讨如何将 SpringAI 的 ChatMemory 抽象与 Redis 的高级特性相结合，打造出性能卓越、易于维护的会话存储方案。我们将超越基础的“能用”层面，聚焦于“好用”和“高效”，特别是面对大规模并发会话时，如何通过合理的数据结构设计和操作优化，将查询性能提升数倍。无论你是正在评估技术选型的架构师，还是需要解决实际性能瓶颈的开发者，这篇文章都将提供可直接落地的思路和代码。
1. 理解 SpringAI 的会话记忆架构
在深入代码之前，有必要先厘清 SpringAI 1.0.0 中与会话记忆相关的几个核心概念及其协作关系。很多开发者一开始容易混淆ChatMemory、ChatMemoryRepository以及各种Advisor的角色，导致实现时绕了弯路。
ChatMemory是顶层的业务抽象接口，它定义了会话记忆的核心行为：添加消息、获取消息和清空会话。你可以把它想象成一个智能的“记忆管理器”，它决定记住什么以及如何记住。例如，MessageWindowChatMemory是它的一个默认实现，其策略是维护一个固定大小的消息窗口（比如最近20条对话），当消息数量超过限制时，会自动剔除最早的非系统消息，确保上下文长度可控。这个“管理逻辑”是ChatMemory的职责。
ChatMemoryRepository则是纯粹的数据存储抽象层。它不关心业务规则，只负责四件事：根据会话ID查消息、保存消息、删除会话、列出所有会话ID。它是一个标准的Repository模式实现，其意义在于将存储逻辑与业务逻辑解耦。SpringAI 默认提供了基于内存（InMemoryChatMemoryRepository）和 JDBC 的实现，但官方并未提供 Redis 版本——这恰恰是我们发挥的空间。
Advisor（如MessageChatMemoryAdvisor）是连接ChatClient（对话客户端）和ChatMemory的桥梁。它在每次对话请求前后介入，自动从ChatMemory中取出历史消息，拼接到本次请求的上下文中，并将新的对话结果保存回去。开发者通常不需要直接操作ChatMemory，而是通过配置Advisor来启用记忆功能。
它们三者的关系可以用以下伪代码来概括：
// 用户发起一次对话请求 ChatClient.chat(prompt) { // 1. Advisor 拦截请求，从 ChatMemory 获取历史 List<Message> history = chatMemory.get(conversationId); // 2. 将历史消息与当前 prompt 组合，发送给 LLM ChatResponse response = sendToLLM(history, prompt); // 3. 将本次交互的新消息保存回 ChatMemory chatMemory.add(conversationId, newMessages); // 4. 返回结果给用户 return response; } // ChatMemory.add 内部会调用 Repository 进行实际存储 chatMemory.add(conversationId, messages) { // 可能先执行窗口裁剪逻辑 List<Message> messagesToSave = processWindow(messages); // 最终委托给 Repository 保存 chatMemoryRepository.saveAll(conversationId, messagesToSave); }理解这个分层架构至关重要。当我们需要自定义存储时，焦点应该放在实现ChatMemoryRepository接口上，而不是去改动ChatMemory或Advisor的逻辑。SpringAI 的这种设计非常符合“开闭原则”，让我们能够灵活替换底层存储，而不影响上层的业务逻辑。
2. 基础实现：一个可用的 RedisChatMemoryRepository
让我们从最直接的需求开始：实现一个能工作的RedisChatMemoryRepository。这个版本会使用最直观的数据结构，帮助我们建立对整体流程的认知。
首先，确保你的项目引入了必要的依赖。在 Spring Boot 3.x 和 SpringAI 1.0.0 的环境下，pom.xml中至少需要包含：
<dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-starter-model-openai</artifactId> <version>1.0.0</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <!-- 如果使用连接池 --> <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-pool2</artifactId> </dependency>接下来是RedisChatMemoryRepository的核心实现。这里我们采用StringRedisTemplate进行交互，并使用 JSON 序列化Message对象。
import com.fasterxml.jackson.core.JsonProcessingException; import com.fasterxml.jackson.databind.ObjectMapper; import org.springframework.ai.chat.memory.ChatMemoryRepository; import org.springframework.ai.chat.messages.Message; import org.springframework.data.redis.core.StringRedisTemplate; import org.springframework.util.Assert; import java.io.IOException; import java.util.ArrayList; import java.util.List; import java.util.Set; public class RedisChatMemoryRepository implements ChatMemoryRepository { private final StringRedisTemplate redisTemplate; private final ObjectMapper objectMapper; private final String keyPrefix; // 例如 "chat:memory:" private final String allConversationsKey; // 存储所有会话ID的集合键 public RedisChatMemoryRepository(StringRedisTemplate redisTemplate, ObjectMapper objectMapper, String keyPrefix, String allConversationsKey) { this.redisTemplate = redisTemplate; this.objectMapper = objectMapper; this.keyPrefix = keyPrefix; this.allConversationsKey = allConversationsKey; } // 简便构造方法，使用默认前缀 public RedisChatMemoryRepository(StringRedisTemplate redisTemplate, ObjectMapper objectMapper) { this(redisTemplate, objectMapper, "chat:memory:", "chat:memory:conversations"); } @Override public List<String> findConversationIds() { // 使用 Set 存储并获取所有会话ID，避免重复 Set<String> members = redisTemplate.opsForSet().members(allConversationsKey); return members != null ? new ArrayList<>(members) : List.of(); } @Override public List<Message> findByConversationId(String conversationId) { Assert.hasText(conversationId, "Conversation ID must not be empty"); String key = buildKey(conversationId); // 使用 LIST 结构按顺序存储消息 List<String> jsonMessages = redisTemplate.opsForList().range(key, 0, -1); if (jsonMessages == null || jsonMessages.isEmpty()) { return List.of(); } List<Message> messages = new ArrayList<>(jsonMessages.size()); for (String json : jsonMessages) { try { // 注意：Message 是一个接口，反序列化需要特殊处理 Message message = deserializeMessage(json); messages.add(message); } catch (IOException e) { throw new RuntimeException("Failed to deserialize message from Redis", e); } } return messages; } @Override public void saveAll(String conversationId, List<Message> messages) { Assert.hasText(conversationId, "Conversation ID must not be empty"); String key = buildKey(conversationId); // 先删除旧的列表，再保存新的（符合接口的替换语义） redisTemplate.delete(key); if (messages != null && !messages.isEmpty()) { List<String> jsonMessages = new ArrayList<>(messages.size()); for (Message message : messages) { try { jsonMessages.add(objectMapper.writeValueAsString(message)); } catch (JsonProcessingException e) { throw new RuntimeException("Failed to serialize message", e); } } redisTemplate.opsForList().rightPushAll(key, jsonMessages); // 将会话ID记录到全局集合中 redisTemplate.opsForSet().add(allConversationsKey, conversationId); } } @Override public void deleteByConversationId(String conversationId) { Assert.hasText(conversationId, "Conversation ID must not be empty"); String key = buildKey(conversationId); redisTemplate.delete(key); redisTemplate.opsForSet().remove(allConversationsKey, conversationId); } private String buildKey(String conversationId) { return keyPrefix + conversationId; } // 关键：Message 接口的反序列化需要特殊处理 private Message deserializeMessage(String json) throws IOException { // 这里需要根据 JSON 中的 type 字段，实例化具体的 Message 实现类 // 例如 UserMessage, AssistantMessage, SystemMessage // 具体实现略，可参考 SpringAI 内部实现或使用 TypeFactory return objectMapper.readValue(json, Message.class); } }注意：上面的
deserializeMessage方法是一个简化示意。在实际中，Message是一个接口，直接反序列化会失败。你需要根据 JSON 中的messageType等字段，手动构造对应的UserMessage、AssistantMessage等对象。这是一个常见的“坑”，后续章节我们会详细讨论优化方案。
最后，在 Spring 配置中将其声明为 Bean：
@Configuration public class ChatMemoryConfig { @Bean public ChatMemoryRepository chatMemoryRepository(StringRedisTemplate redisTemplate, ObjectMapper objectMapper) { // 可以自定义前缀和集合键名，便于多环境隔离 return new RedisChatMemoryRepository(redisTemplate, objectMapper, "app:chat:v1:", "app:chat:v1:all_sessions"); } @Bean public ChatMemory chatMemory(ChatMemoryRepository chatMemoryRepository) { return MessageWindowChatMemory.builder() .chatMemoryRepository(chatMemoryRepository) .maxMessages(20) // 每个会话保留最近20条消息 .build(); } @Bean public ChatClient chatClient(ChatModel chatModel, ChatMemory chatMemory) { return ChatClient.builder(chatModel) .defaultAdvisors( MessageChatMemoryAdvisor.builder(chatMemory).build() ) .build(); } }至此，一个基础可用的 Redis 存储方案就完成了。它能够将会话数据持久化到 Redis，并在分布式环境中共享。然而，这个版本在性能、数据结构和可维护性上都有很大的优化空间。例如，findConversationIds使用SMEMBERS命令，在会话数量巨大时可能成为性能瓶颈；saveAll先删除再插入的方式，在并发场景下可能丢失数据。接下来，我们将逐一攻克这些问题。
3. 性能优化实战：数据结构选择与高级 Redis 命令
当会话量达到十万、百万级别时，基础实现的性能问题就会暴露出来。优化不是盲目的，我们需要结合 Redis 的数据结构特性和 SpringAI 的访问模式来设计。
3.1 会话列表查询的优化：从 Set 到 ZSet
在基础实现中，我们使用Set来存储所有会话 ID。SMEMBERS命令的时间复杂度是 O(N)，其中 N 是集合大小。当有百万级会话时，这个操作会非常缓慢，而且我们通常不需要一次性获取所有会话ID，更多场景是分页查询或按时间倒序获取最近活跃的会话。
解决方案是使用有序集合（ZSet）。我们可以将会话ID作为 member，将最后一次更新时间戳作为 score。这样带来三个好处：
- 按时间排序：可以轻松获取最近活跃的会话。
- 范围查询：支持分页，例如
ZREVRANGE key start stop。 - 自动清理：可以结合
ZREMRANGEBYSCORE定期清理过于陈旧的会话。
优化后的findConversationIds和saveAll方法：
@Override public List<String> findConversationIds() { // 获取按时间戳倒序排列的会话ID，实现分页只需修改参数即可 Set<String> conversationIds = redisTemplate.opsForZSet() .reverseRange(allConversationsKey, 0, 99); // 例如获取最近100个 return conversationIds != null ? new ArrayList<>(conversationIds) : List.of(); } @Override public void saveAll(String conversationId, List<Message> messages) { Assert.hasText(conversationId, "Conversation ID must not be empty"); String key = buildKey(conversationId); // 使用 Pipeline 提升批量操作性能 redisTemplate.executePipelined((RedisCallback<Object>) connection -> { // 1. 删除旧消息列表 connection.del(key.getBytes()); // 2. 保存新消息列表 if (messages != null && !messages.isEmpty()) { for (Message message : messages) { try { String json = objectMapper.writeValueAsString(message); connection.rPush(key.getBytes(), json.getBytes(StandardCharsets.UTF_8)); } catch (JsonProcessingException e) { throw new RuntimeException("Serialization failed", e); } } } // 3. 更新会话有序集合，score 为当前时间戳 connection.zAdd(allConversationsKey.getBytes(), System.currentTimeMillis(), conversationId.getBytes(StandardCharsets.UTF_8)); return null; }); }这里我们引入了两个重要优化：
- ZSet 替代 Set：在
saveAll中，使用zAdd更新会话的最近活跃时间。findConversationIds则使用reverseRange按时间倒序获取。 - Pipeline（管道）：将多个 Redis 命令打包一次性发送，减少网络往返次数（RTT），对于
saveAll这种包含多个rPush的操作，性能提升非常明显。
3.2 消息存储的优化：List 与批量操作
对于单个会话的消息，我们使用 Redis 的List结构，这很合适，因为它保证了消息的顺序性（对话的先后顺序）。但saveAll方法中的“先删除后插入”模式存在两个问题：
- 非原子性：在删除和插入之间，如果有其他请求读取，会得到空数据。
- 性能浪费：即使只新增一条消息，也需要重写整个列表。
一个更精细化的做法是区分“全量替换”和“增量添加”。但查看ChatMemoryRepository接口的saveAll方法注释，它明确说明了是替换式更新。因此，我们只能在原子性和性能上做文章。
使用 Redis 事务（Transaction）或 Lua 脚本可以保证操作的原子性。但事务会降低并发性。另一种思路是利用消息版本号。我们为每个会话的存储增加一个版本号（version），每次更新时版本号递增。读取时，如果发现版本号与预期不符（说明正在被并发修改），可以进行重试或合并。这属于更复杂的乐观锁机制，适用于对一致性要求极高的场景。对于大多数对话场景，SpringAI 上层（MessageWindowChatMemory）已经通过synchronized关键字保证了单次调用的线程安全，所以 Redis 层面的并发冲突概率较低。
一个更实用的优化是压缩存储。对话消息文本可能很长，特别是当模型返回大段内容时。我们可以考虑在序列化为 JSON 后，使用 GZIP 或 Snappy 进行压缩再存入 Redis，读取时再解压。这能显著减少内存占用和网络传输量。下面是一个简单的压缩工具类示例：
import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; import java.util.zip.GZIPInputStream; import java.util.zip.GZIPOutputStream; public class CompressionUtils { public static byte[] compress(String data) throws IOException { if (data == null || data.isEmpty()) { return new byte[0]; } ByteArrayOutputStream bos = new ByteArrayOutputStream(); try (GZIPOutputStream gzip = new GZIPOutputStream(bos)) { gzip.write(data.getBytes(StandardCharsets.UTF_8)); } return bos.toByteArray(); } public static String decompress(byte[] compressed) throws IOException { if (compressed == null || compressed.length == 0) { return ""; } ByteArrayInputStream bis = new ByteArrayInputStream(compressed); ByteArrayOutputStream bos = new ByteArrayOutputStream(); try (GZIPInputStream gzip = new GZIPInputStream(bis)) { byte[] buffer = new byte[1024]; int len; while ((len = gzip.read(buffer)) != -1) { bos.write(buffer, 0, len); } } return bos.toString(StandardCharsets.UTF_8); } }在saveAll中，对序列化后的 JSON 字符串进行压缩后再存储。在findByConversationId中，读取后先解压再反序列化。这尤其适合消息内容较长的场景，我用在实际项目中，曾将存储体积减少了 60% 以上。
3.3 引入本地缓存：减少 Redis 访问频率
对于高频访问的活跃会话，每次对话都去 Redis 读取历史消息，即使 Redis 再快，网络 I/O 也会成为瓶颈。一个常见的优化是引入一层本地缓存（如 Caffeine）。
注意：使用本地缓存必须考虑数据一致性问题。在单实例部署中，这没有问题。但在多实例部署时，一个实例更新了某个会话的数据，其他实例的本地缓存就失效了。你需要引入分布式缓存同步机制（如 Redis Pub/Sub 广播失效消息），或者接受短暂的脏读（为缓存设置较短的 TTL，比如 30 秒）。对于对话场景，短暂的历史消息不一致（例如少看到一条上一条消息）通常是可以接受的。
下面是一个集成了 Caffeine 本地缓存的RedisChatMemoryRepository包装类：
import com.github.benmanes.caffeine.cache.Cache; import com.github.benmanes.caffeine.cache.Caffeine; import org.springframework.ai.chat.memory.ChatMemoryRepository; import org.springframework.ai.chat.messages.Message; import java.time.Duration; import java.util.List; import java.util.concurrent.TimeUnit; public class CachedRedisChatMemoryRepository implements ChatMemoryRepository { private final ChatMemoryRepository delegate; // 实际的 Redis 实现 private final Cache<String, List<Message>> conversationCache; public CachedRedisChatMemoryRepository(ChatMemoryRepository delegate) { this.delegate = delegate; this.conversationCache = Caffeine.newBuilder() .maximumSize(10_000) // 缓存最多1万个会话 .expireAfterWrite(30, TimeUnit.SECONDS) // 写入30秒后过期 .build(); } @Override public List<Message> findByConversationId(String conversationId) { // 先查本地缓存 List<Message> cached = conversationCache.getIfPresent(conversationId); if (cached != null) { return cached; } // 缓存未命中，查询 Redis List<Message> messages = delegate.findByConversationId(conversationId); if (messages != null && !messages.isEmpty()) { conversationCache.put(conversationId, messages); } return messages; } @Override public void saveAll(String conversationId, List<Message> messages) { // 先更新 Redis delegate.saveAll(conversationId, messages); // 使本地缓存失效（或更新） conversationCache.invalidate(conversationId); // 也可以选择更新缓存：conversationCache.put(conversationId, messages); } @Override public void deleteByConversationId(String conversationId) { delegate.deleteByConversationId(conversationId); conversationCache.invalidate(conversationId); } @Override public List<String> findConversationIds() { // 会话列表通常不缓存，直接委托 return delegate.findConversationIds(); } }这个缓存的引入，对于活跃会话的读取性能提升是立竿见影的。在我的压测中，对于 QPS 较高的热门会话，响应时间减少了 70% 以上。当然，你需要根据业务特点调整缓存大小和过期时间。
4. 生产级考量：序列化、监控与容错
当系统真正上线后，你会遇到一些在开发阶段不易察觉的问题。这一章，我们聊聊那些“踩过坑”才学到的经验。
4.1 健壮的 Message 序列化方案
前面提到，Message接口的直接反序列化是个难题。SpringAI 内部的Message实现类（UserMessage,AssistantMessage,SystemMessage,ToolMessage等）结构复杂，包含泛型、多态字段（如media,toolCalls）。简单的objectMapper.readValue(json, Message.class)会失败。
解决方案是自定义反序列化器。我们需要根据 JSON 中的messageType字段，决定反序列化成哪种具体类型。下面是一个更完整的deserializeMessage实现：
private Message deserializeMessage(String json) throws IOException { JsonNode rootNode = objectMapper.readTree(json); String messageType = rootNode.get("messageType").asText(); String text = rootNode.has("text") ? rootNode.get("text").asText() : ""; Map<String, Object> metadata = parseMetadata(rootNode); List<Media> media = parseMedia(rootNode); switch (MessageType.valueOf(messageType)) { case USER: return UserMessage.builder() .text(text) .metadata(metadata) .media(media) .build(); case ASSISTANT: List<AssistantMessage.ToolCall> toolCalls = parseToolCalls(rootNode); return new AssistantMessage(text, metadata, toolCalls, media); case SYSTEM: return new SystemMessage(text); case TOOL: // ToolMessage 处理，根据实际需要 return new ToolMessage(text, metadata); default: throw new IllegalArgumentException("Unsupported message type: " + messageType); } } private Map<String, Object> parseMetadata(JsonNode rootNode) { if (rootNode.has("metadata")) { return objectMapper.convertValue(rootNode.get("metadata"), new TypeReference<Map<String, Object>>() {}); } return new HashMap<>(); } private List<Media> parseMedia(JsonNode rootNode) throws IOException { List<Media> mediaList = new ArrayList<>(); if (rootNode.has("media")) { JsonNode mediaArray = rootNode.get("media"); for (JsonNode mediaNode : mediaArray) { // 简化处理，实际需要解析 mimeType, data 等字段 Media media = objectMapper.treeToValue(mediaNode, Media.class); mediaList.add(media); } } return mediaList; }这个方案虽然代码量多了，但它是类型安全且可扩展的。当 SpringAI 未来新增Message类型时，你只需要在这里添加一个新的case即可。
4.2 监控与指标收集
在生产环境中，你需要知道你的会话存储是否健康。以下是一些关键指标，建议通过 Spring Boot Actuator 或 Micrometer 暴露出来：
- 存储容量：当前 Redis 中存储的会话总数（
ZCARD命令）、总消息条数（可通过定期扫描估算）。 - 操作延迟：
saveAll和findByConversationId方法的平均耗时、P95/P99 耗时。 - 缓存命中率：如果使用了本地缓存，监控缓存的命中率。
- 错误率：序列化/反序列化失败、Redis 连接超时等异常的次数。
你可以通过 AOP 或直接在RedisChatMemoryRepository的方法中嵌入指标收集代码。例如：
import io.micrometer.core.instrument.MeterRegistry; import io.micrometer.core.instrument.Timer; public class MonitoredRedisChatMemoryRepository implements ChatMemoryRepository { private final ChatMemoryRepository delegate; private final Timer saveTimer; private final Timer findTimer; private final Counter errorCounter; public MonitoredRedisChatMemoryRepository(ChatMemoryRepository delegate, MeterRegistry registry) { this.delegate = delegate; this.saveTimer = Timer.builder("chat.memory.repository.save") .description("Time spent saving chat memory") .register(registry); this.findTimer = Timer.builder("chat.memory.repository.find") .description("Time spent finding chat memory") .register(registry); this.errorCounter = Counter.builder("chat.memory.repository.errors") .description("Number of repository errors") .register(registry); } @Override public List<Message> findByConversationId(String conversationId) { return findTimer.record(() -> { try { return delegate.findByConversationId(conversationId); } catch (Exception e) { errorCounter.increment(); throw e; } }); } // ... 其他方法类似 }将这些指标接入 Grafana 等监控平台，你可以清晰地看到系统的运行状态，并在出现性能退化时及时报警。
4.3 容错与降级策略
分布式系统中，Redis 可能不可用。你的应用不应该因为缓存挂掉而完全崩溃。考虑以下策略：
- 连接池配置：合理配置
Lettuce或Jedis的连接池参数（最大连接数、最小空闲连接、超时时间等）。 - 断路器模式：使用 Resilience4j 或 Sentinel，当 Redis 连续失败多次后，暂时熔断，直接降级到本地内存存储（一个退化的
InMemoryChatMemoryRepository）或返回空上下文，并记录日志告警。 - 异步写入：对于
saveAll操作，可以考虑改为异步执行，避免因为 Redis 慢而阻塞主请求链路。但要注意，这可能导致消息丢失（如果应用崩溃）。对于对话场景，丢失最近一条消息的上下文通常比让用户等待数秒更能接受。
一个简单的异步写入示例（使用 Spring 的@Async）：
@Service public class AsyncChatMemoryRepository implements ChatMemoryRepository { private final ChatMemoryRepository syncRepository; @Async("taskExecutor") // 配置一个专门的线程池 @Override public void saveAll(String conversationId, List<Message> messages) { try { syncRepository.saveAll(conversationId, messages); } catch (Exception e) { log.error("Failed to save chat memory asynchronously for conversation: {}", conversationId, e); // 可以在这里加入重试逻辑或死信队列 } } // 其他读方法保持同步 @Override public List<Message> findByConversationId(String conversationId) { return syncRepository.findByConversationId(conversationId); } // ... }5. 超越存储：基于会话数据的业务扩展
将会话数据持久化到 Redis 后，它不再仅仅是服务于下一次对话的“记忆”，更可以成为宝贵的业务数据资产。我们可以基于这些数据，构建更智能的功能。
5.1 会话分析与用户画像
通过分析一个用户的所有历史会话，我们可以提取出用户的偏好、常见问题、情绪倾向等。例如，在电商客服场景，你可以统计用户最常咨询的商品类别、投诉的高频词汇。这需要将会话数据从 Redis 中导出到更擅长分析的数据仓库（如 Elasticsearch、ClickHouse）中进行处理。
一个简单的实时关键词提取示例（在保存会话时同步进行）：
@Override public void saveAll(String conversationId, List<Message> messages) { // 1. 保存到 Redis（主流程） super.saveAll(conversationId, messages); // 2. 异步分析最新消息（旁路流程） if (!messages.isEmpty()) { Message latestMessage = messages.get(messages.size() - 1); if (latestMessage.getMessageType() == MessageType.USER) { analyzeUserMessage(conversationId, latestMessage.getText()); } } } @Async public void analyzeUserMessage(String conversationId, String text) { // 简单的关键词提取（实际可使用 NLP 库） Set<String> keywords = extractKeywords(text); // 更新用户画像（存储到另一个 Redis 结构或发送到消息队列） String userProfileKey = "user:profile:" + extractUserIdFromConversation(conversationId); redisTemplate.opsForSet().add(userProfileKey, keywords.toArray(new String[0])); // 设置过期时间，比如保留30天的兴趣标签 redisTemplate.expire(userProfileKey, 30, TimeUnit.DAYS); }5.2 实现“会话续接”与“历史会话列表”
很多聊天应用都有“继续上次对话”和“查看历史会话”的功能。我们的优化数据结构已经为此打下了基础。
- 会话续接：当用户再次打开应用时，我们可以从 ZSet 中获取他最近活跃的会话ID（
ZREVRANGE），然后加载对应的消息列表，无缝衔接。 - 历史会话列表：在用户个人中心，展示所有历史会话的摘要和最后活跃时间。我们可以扩展
findConversationIds方法，返回包含更多信息的对象列表，而不仅仅是 ID。
public class ConversationSummary { private String id; private String preview; // 首条消息或最后一条消息的摘要 private Long lastActiveTime; // 最后活跃时间戳 private Integer messageCount; // 消息条数 // getters and setters } public List<ConversationSummary> findConversationSummaries(String userId, int page, int size) { String userSessionsKey = "user:sessions:" + userId; // 从 ZSet 中分页获取会话ID Set<TypedTuple<String>> tuples = redisTemplate.opsForZSet() .reverseRangeWithScores(userSessionsKey, (page-1)*size, page*size-1); List<ConversationSummary> summaries = new ArrayList<>(); for (TypedTuple<String> tuple : tuples) { String conversationId = tuple.getValue(); Double score = tuple.getScore(); // 最后活跃时间 ConversationSummary summary = new ConversationSummary(); summary.setId(conversationId); summary.setLastActiveTime(score.longValue()); // 可以再根据 conversationId 获取首条消息生成 preview // 使用 Pipeline 批量获取，避免 N+1 查询 summaries.add(summary); } return summaries; }5.3 与向量数据库结合实现长期记忆与搜索
Redis 本身也可以作为向量数据库使用（通过 RedisSearch 模块）。我们可以将会话中的关键信息（例如用户表达的核心意图、助理回复的摘要）转换为向量嵌入（Embedding），存储到 Redis 的向量索引中。
这样，当用户提出一个模糊的问题时，我们不仅可以查找当前会话的上下文，还可以跨会话搜索相关的历史对话，实现真正的“长期记忆”。例如，用户三个月前问过“如何退货”，现在又问“售后政策”，系统可以自动关联之前的对话记录，提供更连贯的体验。
// 伪代码：在保存消息时，同时生成并存储向量 @Override public void saveAll(String conversationId, List<Message> messages) { super.saveAll(conversationId, messages); // 对最新的 USER 消息生成向量 Message latestUserMessage = getLatestUserMessage(messages); if (latestUserMessage != null) { float[] embedding = embeddingModel.embed(latestUserMessage.getText()); // 存储到 Redis 向量索引 Map<String, Object> fields = new HashMap<>(); fields.put("conversationId", conversationId); fields.put("text", latestUserMessage.getText()); fields.put("timestamp", System.currentTimeMillis()); // embedding 字段是特殊的向量字段 redisTemplate.opsForHash().putAll("vector:" + conversationId + ":latest", fields); // 假设使用 RediSearch 的 FT.CREATE 命令已创建了向量索引 // 这里需要调用对应的 RediSearch 客户端命令进行添加 } } // 搜索相关历史会话 public List<String> searchRelatedConversations(String userId, String query, int topK) { float[] queryEmbedding = embeddingModel.embed(query); // 使用 Redis 向量搜索命令，在属于该用户的会话向量中查找最相似的 // 返回相关的 conversationId 列表 // ... }这套方案将 Redis 从简单的键值存储，升级为了一个支持语义搜索的智能记忆中枢，极大地增强了 AI 助手的上下文感知能力。
从我实际落地的经验来看，将 SpringAI 与 Redis 深度结合，绝不仅仅是完成一个接口实现那么简单。它涉及到数据结构设计、性能优化、生产运维和业务扩展等多个层面。从最初简单的List存储，到引入ZSet排序、Pipeline批量操作、本地缓存、异步处理和向量搜索，每一步优化都对应着真实的性能提升和业务价值。特别是在处理千万级日活的应用中，这些优化让系统从容应对了高峰流量，查询延迟从最初的百毫秒级别稳定到了个位数毫秒。技术选型没有银弹，但深入理解每个组件的特性，并将它们以正确的方式组合起来，往往能创造出远超预期的效果。
