若依照系统分隔版删除Redis数据库
文章目录
1 移除Redis相关配置项
2 屏蔽ruoyi-framework模块中的RedisConfig类
3 在ruoyi-common模块的core/redis目录下创建MyCache类
4 重构RedisCache工具类
5 更新ruoyi-common模块下utils/DictUtils工具类
6 暂时禁用基于Redis的限流逻辑
7 重启应用完成切换
1 移除Redis相关配置项
在开始代码层面的改造之前，首要任务是清理应用配置文件中的Redis连接参数。这一步骤至关重要，因为如果配置文件中仍然保留着Redis的主机地址、端口、密码或集群节点信息，Spring Boot在启动时可能会尝试建立连接，导致启动报错或产生不必要的网络开销。因此，我们需要在application.yml或application.properties文件中，找到所有以spring.redis或spring.data.redis开头的配置项，并将其全部删除或注释掉。这样做不仅能让系统摆脱对Redis服务的依赖，还能确保后续引入的本地缓存机制能够独立运行，不受外部中间件状态的影响。
2 屏蔽ruoyi-framework模块中的RedisConfig类
进入ruoyi-framework模块，定位到RedisConfig类。这里不建议直接删除该类，而是采用注释的方式暂时禁用。具体操作是，将类上的@Configuration、@EnableCaching以及方法上的@Bean注解全部注释掉。这种处理方式具有极高的灵活性，因为如果未来项目架构调整，需要重新引入Redis作为分布式缓存或消息队列，只需将这些注解取消注释即可快速恢复功能，无需重新编写配置代码。通过这种方式，我们保留了代码结构的完整性，同时切断了当前运行时对Redis客户端Bean的依赖，为后续替换缓存实现铺平道路。
3 在ruoyi-common模块的core/redis目录下创建MyCache类
为了替代原有的Redis缓存实现，我们需要在ruoyi-common模块的core/redis包路径下新建一个名为MyCache的类。这个类需要实现Spring Cache抽象层提供的Cache接口。Cache接口定义了一系列标准的方法，如get、put、evict等，通过实现这些方法，我们可以自定义缓存的底层存储逻辑。在此场景中，我们可以选择使用Java原生的ConcurrentHashMap或者引入Caffeine等高性能本地缓存库作为底层支撑。这种设计允许开发者根据业务需求自由扩展功能，例如增加缓存过期策略、命中率统计或数据序列化逻辑，从而构建一个既符合Spring标准又具备高度可定制性的本地缓存组件。
新建MyCache
4 重构RedisCache工具类
接下来，我们需要修改RedisCache工具类，使其不再直接操作Redis客户端，而是通过Spring Cache抽象层调用我们刚刚创建的MyCache实现。在修改过程中，原有的基于RedisTemplate的代码逻辑应当保留但注释掉，而不是直接删除。这样做是为了保持代码的历史追溯性，一旦未来需要切回Redis，开发者可以快速对比新旧逻辑，减少调试成本。新的实现逻辑将依赖于注入的CacheManager或特定的Cache对象，通过标准的get、put、delete方法来完成数据的读写操作。这种解耦设计使得RedisCache类从一个具体的Redis操作工具，转变为一个通用的缓存访问门面，极大地提升了代码的可维护性和扩展性。
5 更新ruoyi-common模块下utils/DictUtils工具类
字典工具类DictUtils在RuoYi框架中扮演着重要角色，它负责加载和缓存系统字典数据。由于底层缓存机制已经从Redis切换为本地缓存，我们需要调整DictUtils中的相关逻辑。主要改动在于获取字典数据时，不再直接调用Redis的get方法，而是通过RedisCache工具类（此时已指向本地缓存实现）来读取数据。同时，需要注意本地缓存的数据一致性策略，虽然本地缓存性能极高，但在多实例部署场景下，不同节点间的字典数据可能存在短暂的不一致。因此，在修改代码时，应确保字典数据的更新操作能够正确触发缓存的失效或刷新机制，以保证业务逻辑的正确性。
内容如下：
6 暂时禁用基于Redis的限流逻辑
RuoYi框架中通常包含基于Redis实现的接口限流功能，这依赖于Redis的原子性操作（如INCR和EXPIRE）来统计请求次数。当移除Redis依赖后，原有的限流逻辑将无法正常工作，因为本地内存无法跨进程共享计数状态。为了避免系统启动报错或运行时异常，我们需要找到限流相关的注解（如@RateLimiter）及其对应的AOP切面逻辑，将其暂时注释掉。这里同样采用注释而非删除的策略，是为了保留代码结构。如果未来引入Redis或替换为其他分布式限流方案（如令牌桶算法的分布式实现），只需取消注释并调整底层实现即可。在当前阶段，禁用限流功能虽然降低了系统的防刷能力，但保证了核心业务流程的畅通无阻。
7 重启应用完成切换
完成上述所有代码和配置的修改后，最后一步是重启应用程序。重启过程是验证所有改动是否生效的关键环节。在启动日志中，我们需要重点关注是否有与Redis连接相关的异常信息，确保系统不再尝试连接Redis服务器。同时，观察应用启动速度，由于去除了外部中间件依赖，启动时间可能会有所缩短。启动成功后，建议进行简单的功能测试，例如访问字典接口或执行涉及缓存读写的业务操作，以确认本地缓存机制工作正常，数据读写符合预期。如果一切正常，则标志着从Redis到本地缓存的迁移工作圆满完成，系统现在可以在无Redis环境下稳定运行。