Erupt框架中Redis会话配置导致的启动问题分析

问题背景

在使用Erupt框架1.12.19版本时，开发者遇到了项目启动卡住的问题。经过排查发现，当项目中引入erupt-job模块并启用Redis会话功能时，会导致应用无法正常启动。这个问题在1.12.10版本中不存在，但在1.12.15及更高版本中出现。

问题现象

开发者最初观察到以下现象：

1. 项目从老版本升级到1.12.19后无法启动
2. 移除erupt-job模块及相关JobHandler类后可以正常启动
3. 清空数据库表数据后问题依旧存在
4. 删除job相关表和.erupt文件夹后问题仍然存在

根本原因

经过深入排查，发现问题实际上与Redis客户端库的选择有关，而非erupt-job模块本身。具体表现为：

1. 当使用Jedis作为Redis客户端时（通过排除Lettuce并显式引入Jedis依赖），且配置erupt.redis-session=true时，应用启动会卡住
2. 当使用默认的Lettuce客户端或关闭Redis会话功能(erupt.redis-session=false)时，应用可以正常启动

解决方案

对于遇到类似问题的开发者，可以采取以下解决方案之一：

1. 使用默认Redis客户端配置： 保持Spring Boot默认的Redis客户端配置，即不排除Lettuce：

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

2. 关闭Redis会话功能： 在配置文件中设置：

   erupt:
     redis-session: false
   

3. 检查Redis客户端兼容性： 如果必须使用Jedis，需要确保版本兼容性，并测试与Erupt框架的集成情况。

技术建议

1. 版本升级注意事项： 从1.12.10升级到更高版本时，需要注意Redis相关配置的变化，特别是当项目中使用非默认Redis客户端时。

2. 依赖管理： 在Spring Boot项目中修改默认依赖时（如替换Redis客户端），需要全面测试框架各功能的兼容性。

3. 问题排查方法： 当遇到启动卡住问题时，可以：

   • 检查日志输出
   • 尝试简化配置
   • 使用依赖排除法定位问题模块
   • 对比不同版本的行为差异

总结

这个问题揭示了框架升级和第三方依赖管理中的常见陷阱。虽然表面现象指向erupt-job模块，但实际原因是Redis客户端选择与框架功能的兼容性问题。开发者在进行技术栈调整时，应当充分测试各功能模块的兼容性，特别是当修改Spring Boot默认配置时。