Maybe Finance自托管部署中的Redis连接问题解决方案

问题背景

在自托管部署Maybe Finance项目时，用户遇到了两个关键问题：

1. 上传图片时出现错误提示
2. 系统日志显示Redis连接失败

这些问题源于docker-compose配置中缺少Redis服务，而Maybe Finance的后台任务处理系统Sidekiq依赖于Redis服务。

技术分析

1. 原docker-compose配置的不足

原始配置包含了应用服务(app)和PostgreSQL数据库服务(postgres)，但缺少了Redis服务。当应用尝试执行ActiveStorage的文件分析任务时，Sidekiq无法连接到Redis，导致任务队列失败。

2. 错误表现

系统日志显示的关键错误信息：

RedisClient::CannotConnectError (Connection refused - connect(2) for 127.0.0.1:6379)

这表明应用尝试连接本地Redis服务(默认端口6379)但失败了，因为容器环境中并未运行Redis服务。

解决方案

1. 修改docker-compose配置

需要在docker-compose文件中添加Redis服务。以下是推荐的配置方式：

services:
  redis:
    image: redis:latest
    restart: unless-stopped
    ports:
      - "6379:6379"
    volumes:
      - redis-data:/data

2. 应用服务的环境变量调整

同时需要更新app服务的环境变量，确保其连接到正确的Redis服务：

environment:
  REDIS_URL: "redis://redis:6379/0"

3. 完整的docker-compose示例

结合原有配置，完整的docker-compose文件应包含三个主要服务：应用服务、PostgreSQL和Redis服务。

技术原理

1. Maybe Finance的架构依赖

Maybe Finance使用Sidekiq作为后台任务处理器，而Sidekiq依赖于Redis作为其消息队列存储。当应用需要处理耗时操作（如文件上传、分析等）时，会将这些任务放入Redis队列中，由Sidekiq工作进程异步处理。

2. ActiveStorage的工作机制

ActiveStorage是Rails的文件上传组件，在上传文件后通常会触发分析任务（如提取元数据、生成预览等）。这些分析任务默认通过ActiveJob异步执行，而配置中使用了Sidekiq作为ActiveJob的适配器。

最佳实践建议

1. 资源隔离：对于生产环境，建议将Redis数据目录挂载到宿主机，确保数据持久化
2. 性能监控：添加Redis监控工具，如RedisInsight，便于观察队列状态
3. 安全配置：为Redis设置密码保护，特别是在暴露端口的情况下
4. 资源限制：为Redis容器设置适当的内存限制，防止内存溢出

总结

在自托管部署Maybe Finance这类Rails应用时，必须确保所有依赖服务（数据库、Redis等）都正确配置并运行。通过完善docker-compose配置，添加Redis服务并正确设置连接参数，可以解决文件上传和后台任务处理的问题。这种解决方案不仅适用于Maybe Finance，也适用于其他使用类似技术栈的Rails应用的自托管部署场景。