文章讲述了Rails 8移除了对Redis的依赖，转而采用基于关系型数据库的新方案SolidQueue、SolidCache和SolidCable来处理任务队列、缓存和实时消息。作者虽然认可Redis的性能优势，但也指出这些新方案简化了技术栈，证明了传统关系型数据库同样能胜任这些任务。这体现了"无聊技术"的价值——简单可靠的方案有时比专用解决方案更可取。

标题：告别Redis，拥抱SolidQueue：Rails 8的轻量级队列解决方案

核心内容：

1. 技术栈革新

• Rails 8移除了对Redis的依赖，推出基于关系型数据库的新组件：
  • SolidQueue（任务队列）
  • SolidCache（缓存）
  • SolidCable（实时消息传输）
• 大多数应用可完全弃用Redis

2. Redis的隐性成本

• 运维负担：需部署/监控服务器、配置持久化策略、内存管理
• 系统复杂度：网络连接、客户端认证、高可用集群维护
• 故障排查：需同时调试Redis和关系型数据库两套系统

3. SolidQueue技术原理

• 利用PostgreSQL 9.5的SKIP LOCKED特性解决锁竞争问题
• 三表协作机制：
  • solidqueuejobs（存储任务元数据）
  • solidqueuescheduledexecutions（定时任务）
  • solidqueuereadyexecutions（待执行任务）
• 多进程协同工作，各司其职

4. 特色功能

• 内置定时任务系统（通过recurring.yml配置）
• 免费提供任务并发控制功能
• 可视化监控工具Mission Control Jobs

5. 迁移指南

• 五步迁移法：更换适配器→安装组件→转换配置→更新Procfile→清理旧依赖
• 现有ActiveJob任务无需修改即可兼容

6. 适用场景建议

• 适用场景：吞吐量<100任务/秒，延迟容忍>100ms
• 仍需Redis的场景：高频交易、复杂发布订阅、原子计数器等

7. 性能表现

• 基准测试：37signals日均处理2000万任务（约230任务/秒）
• 对比数据： | 指标 | Redis+Sidekiq | SolidQueue | |-----------|-------------|----------| | 吞吐量 | 数千/秒 | 200-300/秒 | | 监控 | 独立面板 | 集成面板 | | 故障模式 | 6+种 | 2种 |

8. 开发者价值

• 简化基础设施
• 降低运维负担
• 统一技术栈（使用现有SQL技能）

文章通过技术对比和实际案例，论证了对于大多数Rails应用，采用SolidQueue能有效降低系统复杂度，建议开发者评估实际需求后考虑迁移。

以下是评论内容的总结：

1. Redis与SolidQueue的可靠性对比

   • 支持Redis的观点认为其经过长期实战检验，而SolidQueue的可靠性尚待验证
     • "Redis has been battle-tested for so long that switching always feels risky" (reen_signalhq)
     • "在高峰时段（约5k job/分钟）遇到严重问题...切换至Redis+BullMQ后再无回头" (ashniu123)
   • 支持SolidQueue的观点认为对多数应用已足够
     • "Oban的基准测试显示单节点每分钟可处理百万级任务，99.99999%应用用不到" (victorbjorklund)
     • "当系统可以简化时总是好消息...很多Rails应用并没有高负载" (antirez)

2. 技术选型考量

   • 性能方面：
     • "处理大JSON负载时，Redis明显优于Postgres/SQLite" (rajaravivarma_r)
     • "数据库队列允许系统状态快照，便于开发环境复现" (speleding)
   • 运维复杂度：
     • "Redis需要额外维护：持久化策略、HA集群等" (EugeneOZ提出质疑)
     • "Postgres队列在业务增长后可能需要独立数据库服务器" (skywhopper)

3. 实际应用体验

   • 正面反馈：
     • "开发环境中SolidQueue零压力，考虑放弃切换到Redis" (jjgreen)
     • "与现有应用集成的文档不足是初期挑战" (madethemcry)
   • 局限性：
     • "Basecamp主要关注MySQL兼容性，可能影响Postgres优化" (jacob-s-son)
     • "SQLite在10个左右worker时就会遇到瓶颈" (rajaravivarma_r)

4. 架构哲学争议

   • 简化派：
     • "用现有RDBMS替代Redis可以降低系统复杂度" (skywhopper)
     • "新应用开发应该优先关注产品构建而非基础设施" (steviee)
   • 专用工具派：
     • "Redis和SQL本质是不同的概念" (ckbkr10)
     • "高频交易等场景仍需亚毫秒级延迟" (KolmogorovComp)

5. 云成本考量：

   • "Railway按使用量计费模式使多数据库方案变得可行" (madethemcry)
   • "Redis在云环境中常作为隐藏成本存在" (madethemcry)

总结：评论呈现了数据库队列(特别是SolidQueue)与Redis队列的持续争论，核心分歧在于"简化架构"与"性能需求"之间的权衡，多数观点认为对于中低负载应用，数据库队列是可行选择。