Spring Data Redis与Spring Boot 3.5.0版本兼容性问题解析

在使用Spring Boot 3.5.0版本时，开发者可能会遇到一个与Redis缓存相关的运行时异常。当配置了Redis缓存的TTL（Time To Live）参数后，系统会抛出java.lang.NoSuchMethodError异常，提示找不到redis.clients.jedis.params.SetParams.px(long)方法。

问题现象

该问题主要出现在以下两种配置场景中：

1. 通过application.properties/yml文件配置：

spring.cache.redis.time-to-live=1500s

2. 通过Java代码配置RedisCacheManager：

@Bean
RedisCacheManager cacheManager(RedisConnectionFactory redisConnectionFactory) {
    RedisCacheConfiguration cacheConfig = RedisCacheConfiguration.defaultCacheConfig()
        .entryTtl(Duration.ofSeconds(1500))
        .disableCachingNullValues();
    return RedisCacheManager.builder(redisConnectionFactory)
        .cacheDefaults(cacheConfig)
        .build();
}

问题根源

这个问题的本质是Spring Boot 3.5.0版本中引入的依赖冲突。具体来说，是Jedis客户端库的版本不兼容问题。在Spring Boot 3.5.0中，默认引入的Jedis版本可能较低，而Spring Data Redis在实现TTL功能时需要调用Jedis 6.0.0及以上版本中新增的API方法。

解决方案

目前有两种可行的解决方案：

1. 显式指定Jedis版本：在项目的pom.xml文件中强制指定Jedis的版本为6.0.0或更高版本：

<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>6.0.0</version>
</dependency>

2. 等待Spring Boot官方修复：Spring Boot团队已经意识到这个问题，并计划在3.5.1版本中修复这个兼容性问题。届时开发者可以直接升级Spring Boot版本而无需手动指定Jedis版本。

技术背景

这个问题的出现反映了Java生态系统中依赖管理的重要性。当底层库（这里是Jedis）的API发生变化时，上层框架（Spring Data Redis）如果依赖了新API，而项目实际引入的库版本不匹配，就会导致运行时错误。

NoSuchMethodError是典型的二进制兼容性问题，它发生在编译时使用的类版本与运行时加载的类版本不一致的情况下。在这个具体案例中，Spring Data Redis编译时可能使用了Jedis 6.0.0+的API，但运行时加载的是较低版本的Jedis类。

最佳实践建议

1. 在项目中使用依赖管理工具（如Maven的dependencyManagement或Gradle的platform）统一管理依赖版本
2. 定期检查项目中的依赖冲突，可以使用mvn dependency:tree或Gradle的依赖分析工具
3. 关注框架的发布说明，特别是涉及底层依赖升级的变更
4. 考虑使用Spring Boot的BOM（Bill of Materials）来管理相关依赖版本

总结

这个问题的出现提醒我们，在升级Spring Boot等大型框架时，需要特别注意其传递依赖的变化。对于生产环境，建议在升级前充分测试，或者等待第一个维护版本（如这里的3.5.1）发布后再进行升级，以获得更稳定的依赖关系。