记一次由 jedis 引发的离谱选学问题-编程知识

背景

我的应用中，使用 jedis 作为连接 redis 的客户端，一直在用的好好的，后来有一个新的组件，也需要使用 redis，但是组件是内部封装的，我只能提供一个 StringReidsTempalte，所以我基于应用本身构造的 factory，又重新构建了一个新的 template。

使用版本

springboot: 3.0.6
jedis: 4.3.2
redis 安装版本： 7.0.11
jdk： 17

现状

当时的现状就是这样的：

有一个统一的factory 构造器，构造一个 factory，并将这个 factory 交由 spring 管理。

应用内部统一使用的缓存客户端，由自定义构造一个 RedisTemplate，而新的组件，使用 factory 构造一个新的 StringRedisTemplate。

表象

我在本地启动的时候，没有任何问题，正常和 redis 交互。

部署到服务器启动的时候，会在实际和 redis 交互的底层逻辑处，报出异常。

报错位置1：

org.springframework.data.redis.connection.jedis.JedisStringCommands#set(byte[], byte[], org.springframework.data.redis.core.types.Expiration, org.springframework.data.redis.connection.RedisStringCommands.SetOption)

在这个地址执行的时候，invoke 方法没问题，执行到 from 的时候，debug 执行，会报上面构建的 SetParams 这个类找不到。（只有 debug 会报，正常执行该堆栈打印不出）

通过解包，找到实际服务器的 jar 包中的 lib，发现对应的jar 包是有的，也存在这个类。

后面我就不管这个，果然就继续执行了，这个地方并无卡点。

执行到 getOrElse 的时候，就会报另外一个异常，也就是服务器会打印出来的异常，Unknown redis exception.

堆栈信息中，大概得处理逻辑就是从cgLib 中获取客户端的时候，会有一些地方有卡点，不过太过深入，没有继续追，肯定不是底层逻辑的 bug，只能是我的客户端构造的有问题。

于是我就开始仔细看我构造出来的客户端，和我正常的客户端比较。

然而这个也没有什么异常的情况。

我的自己构建的客户端连接池，正常使用，用了很久了，一直没问题，实际到底层的时候，都是在一个地方使用的，应该是没啥问题。

通过网上找关于 jedis 客户端的使用 demo，几乎和我的没差别，只是调优参数不一样。

jedis 报错：Unknown redis exception 的几种常见问题

Redis 服务未启动或者未连接：在程序连接 Redis 时，如果 Redis 服务未启动或者程序无法连接到 Redis，就会出现这个异常。确保 Redis 服务已启动，且连接信息配置正确。
Redis 服务故障：Redis 服务本身发生故障导致连接断开，也会引起这个异常。这时可以检查 Redis 服务是否正常，以及网络连接是否正常。
Redis 客户端版本问题：Spring Data Redis 依赖于 lettuce 和 Jedis 客户端来访问 Redis。如果使用了不兼容的客户端版本，就会出现这个异常。确保 Spring Data Redis、lettuce 和 Jedis 的版本匹配。
Redis 操作出错：使用 Redis 进行操作时，可能会遇到一些错误情况，如 key 不存在，操作类型不匹配等。这时检查 Redis 的操作是否合规，可以帮助解决这个异常。

针对这些可能产生该异常的情况，可以分别进行如下处理：

确认 Redis 服务已启动，并检查网络连接和连接信息是否正确。
检查 Redis 服务是否正常，以及网络连接是否正常。
选择适合的 Spring Data Redis、lettuce 和 Jedis 版本，确保版本匹配。
确认 Redis 的操作是否合规，以及检查 Redis key 是否存在。

解决问题

最终发现，根本无法下手，因为我本地是好的，java 版本都没问题。

最终尝试使用 lettuce。

问题解决，正常使用。

如果有各位大佬知道具体原因，欢迎交流！不胜感激！

拓展

lettuce 和 jedis比较

spring boot 本身默认使用的就是 lettuce，所以个人觉得直接使用 lettuce 会更好一些。

lettuce 是 jedis 的后起之秀，相较于 jedis 来说，lettuce 有如下优点

线程安全（jedis 线程非安全）
基于 Netty 框架的事件驱动通信，可以异步（jedis 为同步阻塞 IO，不支持异步）
基于异步+线程安全，所以更适合分布式缓存。
- ps：我的应用就是分布式的，考虑到有可能是线程安全导致的问题，所以尝试使用 lettuce，结果就解决问题了。（只是猜测可能是线程安全问题导致，并没有实际验证，虽然解决，可能只是误打误撞）

相较于 jedis，lettuce 的缺点也有

jedis 提供了更为全面的 reidis 操作特性的 api。
jedis 的 api 基本和 redis 的指令一一对应，使用简单，更容易理解。而 lettuce 的api 更抽象一些，学习成本会更高一些。

lettuce 使用

和 jedis 相比，lettuce 使用更简单，因为 lettuce 并不需要配置连接池，因为 lettuce 单链接的性能就很好，线程池数量太低，会导致性能降低，太高和单链接性能差异不大，但是资源消耗更多。

所以简单配置即可。

spring boot 3之后，也移除了直接配置连接池的入口。只需要简单配置 redis 的链接方式即可。

    @Bean("lettuceConnectionFactory")public RedisConnectionFactory lettuceConnectionFactory(CacheConfiguration configuration) {logger.info("开始构建 redis factory...{}", JedisConnectionFactory.class.getName());
//        GenericObjectPoolConfig<RedisProperties.Lettuce> poolConfig = getLettucePoolConfig();
//
//        LettuceClientConfiguration clientConfig = LettuceClientConfiguration.builder()
//                .build();RedisStandaloneConfiguration redisConfig = getRedisConfiguration(configuration);
//        LettuceConnectionFactory factory = new LettuceConnectionFactory(redisConfig, clientConfig);LettuceConnectionFactory factory = new LettuceConnectionFactory(redisConfig);factory.afterPropertiesSet();return factory;}

注意：lettuce 的 factory 创建完成之后，一定要调用afterPropertiesSet方法，否则在实际使用的时候就会报错。