SpringBoot集成Lettuce连接Redis：从基础配置到生产级优化实战

1. 项目概述与核心价值

最近在几个新项目里，我又一次用到了SpringBoot集成Redis这套经典组合。不过这次，我没有选择大家更熟悉的Jedis，而是全面转向了Lettuce。原因很简单，在微服务架构和高并发场景下，Lettuce带来的性能提升和资源管理优势，是实实在在能感受到的。很多朋友可能还停留在“SpringBoot + Redis = Jedis”的认知里，或者虽然知道Lettuce，但对其核心特性和最佳实践了解不深。今天，我就以一个实际项目为背景，从头到尾拆解一遍SpringBoot集成Lettuce连接Redis的完整流程、核心配置、高级用法以及那些容易踩坑的细节。无论你是刚开始接触，还是想优化现有的集成方案，这篇文章都能给你提供一份可以直接“抄作业”的实操指南。

简单来说，Lettuce是一个高性能、线程安全的Redis客户端，它基于Netty构建，支持响应式编程，并且提供了连接池和异步操作等高级特性。在SpringBoot 2.x版本之后，它已经取代Jedis成为Spring Data Redis默认的底层客户端。这意味着，即使你在pom.xml里没有显式声明，只要引入了spring-boot-starter-data-redis，用的就是Lettuce。但“默认”不等于“最优”，不经过合理配置，你可能无法发挥其全部潜力，甚至遇到连接泄漏、性能瓶颈等问题。接下来，我们就从环境搭建开始，一步步深入。

2. 环境准备与项目初始化

2.1 依赖引入与版本选择

首先，创建一个标准的SpringBoot项目。在pom.xml中，核心依赖其实只需要一个：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency>

这个starter会自动引入spring-data-redis和lettuce-core。这里有一个关键点：务必关注Lettuce的版本。SpringBoot的父POM会管理一个默认版本，但有时为了修复特定Bug或使用新特性，我们需要手动升级。你可以通过mvn dependency:tree命令查看实际引入的版本。例如，在SpringBoot 2.7.x中，默认的Lettuce版本可能是6.1.x。如果遇到连接超时或集群拓扑刷新问题，可以考虑升级到6.2.x或更高版本。

<!-- 可选：显式指定Lettuce版本 --> <properties> <lettuce.version>6.2.4.RELEASE</lettuce.version> </properties> <dependency> <groupId>io.lettuce</groupId> <artifactId>lettuce-core</artifactId> <version>${lettuce.version}</version> </dependency>

为什么选择Lettuce而不是Jedis？这是最常被问到的问题。Jedis是直连模式，每个线程操作需要从连接池获取物理连接，多线程环境下存在竞争。而Lettuce的连接是基于Netty的事件驱动模型，一个连接（StatefulRedisConnection）可以在多个线程间共享，通过异步方式处理所有请求，减少了物理连接数量，在高并发下资源利用率和吞吐量显著更高。简单类比，Jedis像是一个需要频繁借还的“公共自行车”，而Lettuce则像是一个高效的“共享巴士线路”。

2.2 基础配置文件解析

接下来是application.yml（或application.properties）的配置。基础的单机Redis配置大家都很熟悉：

spring: redis: host: 127.0.0.1 port: 6379 password: yourpassword # 如果没有密码，可以省略或留空 database: 0 # 默认使用0号数据库 lettuce: pool: max-active: 8 # 连接池最大连接数（使用负值表示没有限制） max-idle: 8 # 连接池中的最大空闲连接 min-idle: 0 # 连接池中的最小空闲连接 max-wait: -1ms # 连接池最大阻塞等待时间（使用负值表示无限等待） shutdown-timeout: 100ms # 关闭超时时间

这里重点看lettuce.pool配置。虽然Lettuce本身基于共享连接，性能优异，但SpringBoot默认还是为其包装了一个通用的连接池（实际上是commons-pool2）。在绝大多数生产环境中，我建议保留并合理配置连接池。为什么？因为连接池可以管理连接的创建和销毁，避免频繁建立TCP连接的开销，同时能防止因网络闪断导致连接失效后，业务线程获取到不可用的连接。max-active不宜设置过大，通常8-16对于大多数应用足够了，设置过大会增加Redis服务器端的负载和内存消耗。max-wait设置为-1（无限等待）在生产环境有风险，可能造成线程饥饿，建议设置为一个合理的值，如5000ms，并做好获取连接失败的异常处理。

3. 核心配置类与连接工厂定制

仅仅依靠默认配置，往往不能满足生产需求。我们需要通过@Configuration类来深度定制RedisConnectionFactory和RedisTemplate。

3.1 自定义Redis连接工厂配置

创建一个配置类，例如RedisConfig：

@Configuration public class RedisConfig { @Bean public RedisConnectionFactory redisConnectionFactory(RedisProperties properties) { RedisStandaloneConfiguration config = new RedisStandaloneConfiguration(); config.setHostName(properties.getHost()); config.setPort(properties.getPort()); config.setPassword(RedisPassword.of(properties.getPassword())); config.setDatabase(properties.getDatabase()); // 构建Lettuce连接工厂 LettuceClientConfiguration clientConfig = LettuceClientConfiguration.builder() .commandTimeout(Duration.ofSeconds(2)) // 命令超时时间 .shutdownTimeout(Duration.ofMillis(100)) // 关闭超时 .clientOptions(ClientOptions.builder() .autoReconnect(true) // 自动重连 .disconnectedBehavior(ClientOptions.DisconnectedBehavior.REJECT_COMMANDS) // 断开时拒绝新命令 .build()) .build(); return new LettuceConnectionFactory(config, clientConfig); } }

在这个配置中，有几个关键点：

1. commandTimeout：这是最重要的参数之一。它定义了Redis客户端等待服务器响应的最长时间。设置过短，在Redis负载高或网络波动时容易超时；设置过长，可能导致故障线程被长时间挂起。根据业务容忍度和Redis集群性能，通常设置在1-5秒。
2. autoReconnect：必须设置为true。这样在网络临时中断恢复后，Lettuce会自动尝试重建连接，对业务无感知。
3. disconnectedBehavior：我推荐设置为REJECT_COMMANDS。这意味着当连接断开时，新的命令会立即收到异常，而不是进入一个等待队列。这符合“快速失败”的原则，让上层业务能及时感知故障并采取降级策略，避免请求堆积。

3.2 定制RedisTemplate：解决序列化痛点

SpringBoot默认提供的RedisTemplate的键值序列化器是JdkSerializationRedisSerializer。这会导致两个严重问题：一是序列化后的键值可读性极差，在Redis客户端里看到的是乱码；二是不同JVM环境或类加载器可能导致反序列化失败。因此，定制RedisTemplate是必须的。

@Configuration public class RedisConfig { // ... 上面的 redisConnectionFactory Bean ... @Bean public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory connectionFactory) { RedisTemplate<String, Object> template = new RedisTemplate<>(); template.setConnectionFactory(connectionFactory); // 使用StringRedisSerializer来序列化和反序列化redis的key值 StringRedisSerializer stringSerializer = new StringRedisSerializer(); template.setKeySerializer(stringSerializer); template.setHashKeySerializer(stringSerializer); // 使用GenericJackson2JsonRedisSerializer来序列化和反序列化redis的value值 GenericJackson2JsonRedisSerializer jsonSerializer = new GenericJackson2JsonRedisSerializer(); template.setValueSerializer(jsonSerializer); template.setHashValueSerializer(jsonSerializer); template.afterPropertiesSet(); return template; } }

序列化器选择解析：

• Key序列化器 (StringRedisSerializer)：将String转换为byte[]，存储到Redis里是人类可读的字符串。这是最通用的选择，因为Redis的Key通常是字符串标识符。
• Value序列化器 (GenericJackson2JsonRedisSerializer)：使用Jackson库将对象序列化为JSON字符串存储。优点是可读性好，不同语言（如Python、Node.js）也能读取；并且会在JSON中存入对象的类名信息（@class），反序列化时能还原成正确的Java类型。缺点是相比专门的二进制序列化（如Kryo），体积稍大，速度稍慢。但对于绝大多数业务场景，JSON的通用性和可调试性优势更大。

注意：如果你确定Value只存储简单的String类型，也可以使用StringRedisSerializer。但为了灵活性，我通常统一使用JSON序列化器。

4. 基础与高级操作案例实战

配置好了，我们来实战操作。Spring Data Redis提供了两种主要的操作方式：RedisTemplate和StringRedisTemplate（后者是前者的特化，键值都使用String序列化器）。我们使用自定义的RedisTemplate。

4.1 注入与基础数据类型操作

首先在Service中注入定制的RedisTemplate：

@Service public class RedisService { @Autowired private RedisTemplate<String, Object> redisTemplate; // 获取实际操作对象，针对不同数据结构 private ValueOperations<String, Object> valueOps() { return redisTemplate.opsForValue(); } private HashOperations<String, String, Object> hashOps() { return redisTemplate.opsForHash(); } private ListOperations<String, Object> listOps() { return redisTemplate.opsForList(); } // ... 类似地获取 SetOperations, ZSetOperations }

字符串（String）操作示例：

public void stringOperations() { // 设置值，10秒后过期 valueOps().set("user:1001:name", "张三", Duration.ofSeconds(10)); // 仅当key不存在时设置（实现分布式锁的基础） Boolean success = valueOps().setIfAbsent("lock:order", "locked", Duration.ofSeconds(30)); // 获取值 String name = (String) valueOps().get("user:1001:name"); // 原子递增 Long newCount = valueOps().increment("article:1001:view"); }

哈希（Hash）操作示例（适合存储对象）：

public void hashOperations() { Map<String, Object> userMap = new HashMap<>(); userMap.put("name", "李四"); userMap.put("age", 28); userMap.put("city", "北京"); // 存储整个Map hashOps().putAll("user:1002", userMap); // 获取单个字段 String city = (String) hashOps().get("user:1002", "city"); // 增量修改某个字段 hashOps().increment("user:1002", "age", 1L); }

4.2 发布订阅（Pub/Sub）模式

Lettuce天然支持异步和响应式编程，这让实现发布订阅模式非常简洁。首先，定义一个消息监听器：

@Component public class RedisMessageListener implements MessageListener { @Override public void onMessage(Message message, byte[] pattern) { String channel = new String(message.getChannel()); String body = new String(message.getBody()); System.out.println("收到频道 [" + channel + "] 的消息: " + body); // 这里进行具体的业务处理 } }

然后，在配置类中注册这个监听器到容器：

@Configuration public class RedisConfig { @Bean public RedisMessageListenerContainer messageListenerContainer(RedisConnectionFactory connectionFactory, RedisMessageListener listener) { RedisMessageListenerContainer container = new RedisMessageListenerContainer(); container.setConnectionFactory(connectionFactory); // 订阅频道 “news” Topic topic = new ChannelTopic("news"); container.addMessageListener(listener, topic); // 也可以订阅模式匹配的频道，如 “log.*” // Topic patternTopic = new PatternTopic("log.*"); // container.addMessageListener(listener, patternTopic); return container; } }

发布消息就很简单了：

@Service public class NewsService { @Autowired private RedisTemplate<String, Object> redisTemplate; public void publishNews(String news) { redisTemplate.convertAndSend("news", news); } }

实操心得：Pub/Sub模式是解耦系统的好工具，比如用于系统间通知、配置刷新、缓存失效广播等。但要注意，它是非持久化的。如果订阅者不在线，消息就丢失了。对于要求消息必达的场景，应该考虑更成熟的消息队列，如RabbitMQ或Kafka。

4.3 管道（Pipelining）与事务（Transaction）

管道（Pipelining）用于批量执行多个命令，减少网络往返（RTT）时间，显著提升批量操作的性能。Lettuce通过RedisTemplate的executePipelined方法支持。

public List<Object> pipelineExample() { // 执行管道操作 List<Object> results = redisTemplate.executePipelined(new SessionCallback<Object>() { @Override public Object execute(RedisOperations operations) throws DataAccessException { ValueOperations ops = operations.opsForValue(); for (int i = 0; i < 100; i++) { ops.set("pipeline:key:" + i, "value" + i); } // 注意：管道内命令的返回值在管道执行完毕后统一返回 return null; } }); // results 包含了所有 set 命令的返回结果（通常是 "OK"） return results; }

事务（Transaction）通过MULTI和EXEC命令保证一系列操作的原子性。在Spring中，可以通过SessionCallback配合multi()和exec()来使用。

public void transactionExample() { List<Object> txResults = redisTemplate.execute(new SessionCallback<List<Object>>() { @Override public List<Object> execute(RedisOperations operations) throws DataAccessException { operations.multi(); // 开启事务 operations.opsForValue().set("tx:key1", "value1"); operations.opsForValue().increment("tx:counter"); operations.opsForSet().add("tx:set", "member"); return operations.exec(); // 执行事务，返回结果列表 } }); // txResults 包含三个命令的执行结果 }

重要区别：Redis的事务不是关系型数据库的ACID事务。它不支持回滚（Rollback）。如果在exec()之前有命令语法错误，整个事务会被丢弃；如果在exec()时运行时出错（比如对字符串进行incr），只有出错的命令会失败，其他命令依然会执行。所以，Redis事务更准确的叫法是“命令打包执行”。

5. 生产级进阶配置与优化

当项目从开发环境走向生产环境，尤其是面对集群、哨兵模式或者需要更精细的资源控制时，基础配置就不够用了。

5.1 连接Redis集群与哨兵模式

Redis集群模式配置：

spring: redis: cluster: nodes: 192.168.1.101:7001,192.168.1.102:7002,192.168.1.103:7003 max-redirects: 3 # 最大重定向次数 password: cluster-password lettuce: pool: max-active: 16 max-idle: 8 min-idle: 4

在代码配置类中，需要使用RedisClusterConfiguration：

@Bean public RedisConnectionFactory lettuceConnectionFactory(RedisProperties properties) { RedisClusterConfiguration clusterConfig = new RedisClusterConfiguration(); // 解析配置文件中的节点列表 String[] nodes = StringUtils.commaDelimitedListToStringArray(properties.getCluster().getNodes()); for (String node : nodes) { String[] hostPort = StringUtils.split(node, ":"); clusterConfig.addClusterNode(new RedisNode(hostPort[0].trim(), Integer.parseInt(hostPort[1].trim()))); } clusterConfig.setMaxRedirects(properties.getCluster().getMaxRedirects()); clusterConfig.setPassword(RedisPassword.of(properties.getPassword())); LettuceClientConfiguration clientConfig = LettuceClientConfiguration.builder() .readFrom(ReadFrom.REPLICA_PREFERRED) // 优先从副本读取，提升读性能 .commandTimeout(Duration.ofSeconds(3)) .build(); return new LettuceConnectionFactory(clusterConfig, clientConfig); }

关键配置ReadFrom.REPLICA_PREFERRED：这指示Lettuce优先从副本节点读取数据，从而分摊主节点的读压力，提升整体吞吐量。其他策略还有MASTER（只从主节点读）、REPLICA（只从副本读）、MASTER_PREFERRED（优先主节点）等。

Redis哨兵模式配置：

spring: redis: sentinel: master: mymaster # 主节点名称 nodes: 192.168.1.201:26379,192.168.1.202:26379,192.168.1.203:26379 password: sentinel-password

对应的Java配置使用RedisSentinelConfiguration。

5.2 连接池深度调优与监控

虽然Lettuce连接开销小，但生产环境仍建议使用连接池。除了max-active等基础参数，还有一些隐藏参数需要关注。我们可以通过自定义GenericObjectPoolConfig来精细控制：

@Bean public LettuceConnectionFactory redisConnectionFactory(RedisProperties properties) { // ... 省略 RedisStandaloneConfiguration 或集群/哨兵配置 ... GenericObjectPoolConfig<Object> poolConfig = new GenericObjectPoolConfig<>(); poolConfig.setMaxTotal(properties.getLettuce().getPool().getMaxActive()); poolConfig.setMaxIdle(properties.getLettuce().getPool().getMaxIdle()); poolConfig.setMinIdle(properties.getLettuce().getPool().getMinIdle()); poolConfig.setMaxWait(properties.getLettuce().getPool().getMaxWait()); // 重要：开启空闲连接逐出和测试 poolConfig.setTestWhileIdle(true); // 空闲时是否测试连接有效性 poolConfig.setTimeBetweenEvictionRuns(Duration.ofSeconds(30)); // 逐出扫描间隔 poolConfig.setMinEvictableIdleTime(Duration.ofSeconds(60)); // 连接最小空闲时间，低于此值不被逐出 LettucePoolingClientConfiguration clientConfig = LettucePoolingClientConfiguration.builder() .poolConfig(poolConfig) .commandTimeout(Duration.ofSeconds(2)) .shutdownTimeout(Duration.ofMillis(200)) .build(); return new LettuceConnectionFactory(standaloneConfig, clientConfig); }

监控连接池状态：可以将连接池注册到Spring Boot Actuator或通过JMX进行监控，关注numActive（活跃连接数）、numIdle（空闲连接数）、numWaiters（等待连接的线程数）等指标。如果numWaiters持续大于0，说明max-active可能设置偏小。

5.3 超时与重试策略配置

网络是不稳定的，完善的超时和重试策略是系统韧性的保障。在LettuceClientConfiguration中可以进行全局配置：

LettuceClientConfiguration clientConfig = LettuceClientConfiguration.builder() .commandTimeout(Duration.ofSeconds(2)) // 单命令超时 .shutdownTimeout(Duration.ofMillis(500)) // 关闭客户端超时 .clientOptions(ClientOptions.builder() .socketOptions(SocketOptions.builder() .connectTimeout(Duration.ofSeconds(1)) // 连接建立超时 .keepAlive(true) // 开启TCP keepalive .build()) .timeoutOptions(TimeoutOptions.enabled(Duration.ofSeconds(5))) // 启用命令超时 .autoReconnect(true) // 自动重连 .cancelCommandsOnReconnectFailure(true) // 重连失败时取消挂起命令 .disconnectedBehavior(ClientOptions.DisconnectedBehavior.REJECT_COMMANDS) .build()) .clientResources(ClientResources.builder() .ioThreadPoolSize(4) // I/O线程数，通常设置为CPU核心数 .computationThreadPoolSize(4) // 计算线程数 .build()) .build();

• connectTimeout：建立TCP连接的超时时间，不宜过长。
• TimeoutOptions.enabled：启用Lettuce内置的命令超时控制，比单纯依赖commandTimeout更精细。
• ClientResources：用于配置Lettuce底层的Netty线程池。在Web容器（如Tomcat）中，如果I/O线程数设置过多，可能会与容器线程竞争。通常保持默认或设置为CPU核心数即可。

6. 常见问题排查与性能优化实战

在实际使用中，一定会遇到各种问题。这里我总结几个最典型的案例和排查思路。

6.1 连接超时与连接泄漏排查

问题现象：应用运行一段时间后，出现RedisCommandTimeoutException，或者监控发现Redis连接数持续增长不释放。

排查步骤：

1. 检查连接池配置：确认max-active是否设置过小。通过redisTemplate.getConnectionFactory().getConnection().info(“stats”)可以查看Redis服务端的连接数。如果客户端连接数远大于max-active，说明存在连接泄漏。
2. 检查命令超时时间：commandTimeout是否设置过短？在Redis执行slowlog get命令，查看是否有慢查询阻塞了后续命令。
3. 检查连接泄漏：这是Lettuce集成中最常见的问题之一。确保每次从连接池获取RedisConnection后，必须在finally块中关闭。但更常见的是RedisTemplate在序列化/反序列化异常时没有正确关闭连接。一个有效的排查方法是，在测试环境，将连接池的removeAbandonedTimeout（如果使用commons-pool2）设置一个较短时间（如30秒），并开启logAbandoned，观察日志中是否有连接泄露的警告。
4. 使用连接池监控：通过JMX或Actuator的/actuator/metrics/redis.pool.*端点，监控连接池的活跃、空闲、等待数量变化趋势。

优化建议：为所有Redis操作添加统一的异常处理，确保连接被安全释放。考虑使用@Transactional注解时，注意其边界，避免一个事务内包含过多的Redis操作或耗时操作，导致连接占用时间过长。

6.2 序列化导致的存储异常

问题现象：存入Redis的对象取出来时类型转换错误（ClassCastException），或者使用redis-cli看到的value是乱码。

原因与解决：

1. 序列化器不一致：这是最根本的原因。确保写入和读取使用的是同一个RedisTemplate实例，且其序列化配置完全相同。在微服务架构中，如果多个服务共用Redis，需要约定统一的序列化协议（如都使用JSON）。
2. 类路径变化：使用GenericJackson2JsonRedisSerializer时，JSON中存储了类全限定名。如果存储后，类的包名修改了，反序列化就会失败。对于这种场景，可以考虑自定义ObjectMapper，配置@JsonTypeInfo使用更稳定的类型标识，或者直接使用StringRedisSerializer存储手动序列化的JSON字符串。
3. 乱码问题：如果redis-cli中看到\xac\xed\x00\x05t\x00\x05value这类乱码，说明使用了默认的JDK序列化器。按照本文第3.2节的方法，将其替换为StringRedisSerializer或GenericJackson2JsonRedisSerializer即可。

6.3 集群环境下的拓扑刷新与路由

问题现象：在Redis集群模式下，进行扩容（增加分片）或缩容后，客户端出现MOVED或ASK错误，或者部分请求失败。

原理与配置：Redis集群数据分布在不同的槽（slot）上。当集群拓扑变化（主从切换、节点增减）时，客户端需要更新本地的槽位-节点映射关系。Lettuce会自动处理MOVED重定向，并可以定期刷新集群拓扑。

LettuceClientConfiguration clientConfig = LettuceClientConfiguration.builder() .commandTimeout(Duration.ofSeconds(3)) .clientOptions(ClientOptions.builder() .autoReconnect(true) .disconnectedBehavior(ClientOptions.DisconnectedBehavior.REJECT_COMMANDS) .topologyRefreshOptions( // 拓扑刷新配置 TopologyRefreshOptions.builder() .enablePeriodicRefresh(Duration.ofMinutes(10)) // 定期刷新 .enableAllAdaptiveRefreshTriggers() // 自适应刷新（收到MOVED/ASK错误时） .build()) .build()) .build();

• enablePeriodicRefresh：即使没有错误，也定期（如10分钟）从集群拉取最新拓扑，适合稳定的集群。
• enableAllAdaptiveRefreshTriggers：在收到MOVED或ASK重定向错误时，立即触发拓扑刷新。这在集群变更期间非常有用。

实操心得：在生产环境，建议同时开启定期刷新和自适应刷新。拓扑刷新的过程会阻塞所有命令直到完成，因此刷新间隔不宜过短。在集群执行CLUSTER FAILOVER或RESHARD操作前，最好能通过运维手段通知应用，或确保客户端配置了合理的重试和超时机制。

6.4 性能瓶颈分析与优化建议

如果发现Redis操作变慢，可以按以下顺序排查：

1. Redis服务器本身：通过redis-cli执行INFO commandstats查看命令耗时统计。执行SLOWLOG GET 10查看最近慢查询。检查服务器CPU、内存、网络带宽。
2. 客户端网络：使用ping或redis-benchmark测试客户端到Redis服务器的网络延迟。
3. Lettuce客户端配置：
   • 连接池不足：增加max-active，但需同步观察Redis服务端连接数。
   • 线程池竞争：检查ClientResources的ioThreadPoolSize是否过小。对于并发量极高的应用，可以适当调大，但不要超过CPU核心数太多。
   • 序列化开销：对于存储大对象（超过10KB），GenericJackson2JsonRedisSerializer的序列化/反序列化可能成为瓶颈。可以考虑使用更高效的序列化工具，如Kryo或Protostuff，但需要自己实现RedisSerializer接口，并牺牲可读性。
4. 业务代码层面：
   • 避免大Key：单个String类型的Value不应超过10KB，Hash、List等集合元素的平均大小也应控制。大Key会阻塞Redis，影响稳定性。
   • 使用管道：对于批量写入或读取，务必使用executePipelined。
   • 避免频繁连接：确保操作复用同一个RedisTemplate和底层的连接池。

7. 测试策略与集成验证

为了保证集成的可靠性，必须编写完善的测试。

7.1 单元测试：使用嵌入式Redis

对于开发环境和CI/CD流水线，可以使用嵌入式Redis服务器，避免依赖外部环境。

<dependency> <groupId>it.ozimov</groupId> <artifactId>embedded-redis</artifactId> <version>0.7.3</version> <scope>test</scope> </dependency>

@SpringBootTest @ActiveProfiles("test") public class RedisServiceTest { @Autowired private RedisService redisService; @Test void testSetAndGet() { redisService.set("testKey", "testValue"); String value = redisService.get("testKey"); assertEquals("testValue", value); } }

在src/test/resources/application-test.yml中配置嵌入式Redis的端口。

7.2 集成测试：针对真实环境

单元测试通过后，还需要在类生产环境（Staging）进行集成测试，重点验证：

• 集群模式下的读写：数据是否正确地分布在不同的分片？
• 故障转移：手动触发主节点故障，观察客户端能否自动切换到新主节点，业务是否受影响（应有短暂超时）。
• 网络分区：模拟网络抖动，验证autoReconnect和重试机制是否生效。
• 性能压测：使用JMeter或自定义脚本，模拟高并发场景，观察响应时间、错误率和连接池指标。

7.3 健康检查与就绪探针

在K8s等容器化环境中，需要为应用添加健康检查。Spring Boot Actuator提供了Redis健康指示器。

management: endpoint: health: show-details: always health: redis: enabled: true

访问/actuator/health可以查看Redis连接状态。在K8s的readinessProbe中配置此端点，可以确保只有当Redis连接正常时，流量才会被导入Pod。

集成Lettuce连接Redis是一个从“能用”到“好用”再到“稳定高效”的持续优化过程。从最开始的基础配置、序列化器选择，到生产环境下的连接池调优、超时重试策略、集群拓扑刷新，每一个环节都需要根据实际业务场景和运维环境进行仔细考量。我个人的经验是，前期多花时间在配置和测试上，制定好规范（如Key命名规范、序列化协议），远比后期出了问题再救火要划算得多。最后，再分享一个小技巧：对于复杂的Redis操作，可以考虑将其封装在独立的Service中，并在内部做好异常处理、日志记录和指标上报（如使用Micrometer），这样业务代码会更清晰，也更容易进行统一的监控和治理。