# Redis到SolidQueue迁移的工程权衡：队列持久化、内存管理与性能基准 > 深入分析从Redis迁移到SolidQueue的技术决策，聚焦队列持久化策略、内存管理差异、故障恢复机制与性能基准测试实现。 ## 元数据 - 路径: /posts/2026/01/14/redis-solidqueue-migration-comparison/ - 发布时间: 2026-01-14T18:02:04+08:00 - 分类: [systems](/categories/systems/) - 站点: https://blog.hotdry.top ## 正文 在Rails 8的发布中，一个显著的变化是Redis从标准技术栈中被移除。取而代之的是SolidQueue、SolidCache和SolidCable这一套基于关系数据库的解决方案。这一转变引发了开发者社区的广泛讨论：我们真的需要Redis吗？还是说，像PostgreSQL这样的"无聊技术"已经足够胜任队列处理的任务？ ## Redis的真实成本：超越月度账单 Redis作为内存键值存储，在过去十年中一直是Rails应用队列处理的首选。它的速度快、功能强大且稳定可靠。然而，Matt Kelly在SimpleThread的文章中指出，Redis的成本远不止月度托管费用。 **运维复杂度**是Redis的主要隐性成本。要使用Redis，你必须： - 部署、版本管理、补丁更新和监控Redis服务器软件 - 配置持久化策略：选择RDB快照、AOF日志，还是两者兼用？ - 设置和监控内存限制，建立驱逐策略 此外，还有基础设施和互操作性的持续负担： - 维护Rails与Redis之间的网络连接，包括防火墙规则 - Redis客户端认证 - 构建和维护高可用Redis集群 - 跨部署编排Sidekiq进程的生命周期 当作业出现问题时，你需要在Redis和RDBMS这两个语义完全不同的数据存储之间切换上下文，使用不同的查询语言和工具进行调试。更不用说需要维护两套独立的备份策略。 ## SolidQueue的架构革新：基于PostgreSQL SKIP LOCKED Redis与PostgreSQL是两种截然不同的数据存储。Redis在很多方面被当作内存使用：原子性、易失性和极快的速度。那么SolidQueue是如何用PostgreSQL替代Redis的呢？ 关键在于PostgreSQL 9.5引入的`FOR UPDATE SKIP LOCKED`子句。`FOR UPDATE`创建排他行锁，而`SKIP LOCKED`进一步跳过当前已被锁定的行。这一机制使得基于数据库的作业队列即使在规模较大时也能保持可行性。 当工作进程需要作业时，执行以下查询： ```sql SELECT * FROM solid_queue_ready_executions WHERE queue_name = 'default' ORDER BY priority DESC, job_id ASC LIMIT 1 FOR UPDATE SKIP LOCKED ``` 空闲的工作进程总是能获取到下一个可用作业。这一数据库优化解决了早期数据库队列实现中的根本问题：**锁争用**。工作进程永远不会等待另一个进程，也永远不会被阻塞。多个工作进程可以同时查询，PostgreSQL保证每个进程都能获取到唯一的作业。 SolidQueue的架构围绕三个核心表构建： 1. `solid_queue_jobs`：存储所有作业的元数据，如作业名称、Ruby类以及记录作业开始和完成时间的时间戳 2. `solid_queue_scheduled_executions`：等待预定时间的调度作业 3. `solid_queue_ready_executions`：准备立即运行的作业队列 作业表可能会快速且稳定地更新（有大量的插入和删除操作），但PostgreSQL的MVCC设计通过其内置的自动清理进程可以很好地处理这种情况，无需特殊调优。 ## 性能对比：何时选择Redis，何时选择SolidQueue 性能是迁移决策中的关键考量因素。根据实际测试和社区经验，我们可以得出以下指导原则： **选择SolidQueue的场景：** - 处理速度低于100作业/秒 - 作业延迟容忍度大于100毫秒 - 希望简化基础设施栈 - 预算有限，无法承担Sidekiq企业版费用 **仍需要Redis的场景：** - 持续处理数千作业/秒（不是峰值，而是持续负载） - 作业延迟低于1毫秒对业务至关重要（如实时竞价、高频交易） - 需要复杂的pub/sub模式跨多个服务 - 需要密集的速率限制或计数器，受益于Redis的原子操作 作为参考，37signals每天处理2000万个作业，大约每秒230个作业，全部在PostgreSQL上运行，无需Redis。这个规模已经覆盖了绝大多数Rails应用的需求。 ## 并发限制：从付费功能到免费特性 如果你在普通规模下使用Rails，可能不知道Sidekiq也将并发限制作为付费功能提供在Sidekiq企业版中。如果你考虑使用Sidekiq，仅并发限制这一功能就值得购买企业版。 但SolidQueue免费提供了这一功能，而且更多！只需在任何作业中添加`limits_concurrency`： ```ruby class ProcessUserOnboardingJob < ApplicationJob limits_concurrency to: 1, key: ->(user) { user.id }, duration: 15.minutes def perform(user) # 复杂的入职工作流程 end end ``` `limits_concurrency to: 1`确保每个用户在任何时候只有一个`ProcessUserOnboardingJob`作业运行。 `duration`参数也很重要，它定义了SolidQueue保证并发限制的时间长度。如果作业崩溃，信号量最终会过期，防止因崩溃的工作进程从未释放锁而导致的死锁。 实现使用两个表：`solid_queue_semaphores`跟踪并发限制，`solid_queue_blocked_executions`保存等待信号量释放的作业。当作业完成时，它释放信号量并触发调度器解除下一个等待作业的阻塞。这种设计优雅、数据库原生，且无需外部协调。 ## 迁移实施指南：从Sidekiq到SolidQueue 迁移过程相对简单，但需要遵循正确的步骤： ### 步骤1：更改Rails队列适配器 ```ruby # config/environments/production.rb config.active_job.queue_adapter = :solid_queue ``` ### 步骤2：安装SolidQueue ```bash $ bundle add solid_queue $ rails solid_queue:install $ rails db:migrate ``` ### 步骤3：替换sidekiq-cron调度 将`config/sidekiq.yml`中的cron调度转换为`config/recurring.yml`。配置结构类似，但需要更新键名并将经典cron字符串转换为Fugit的首选自然语言格式。 ### 步骤4：更新Procfile ```yaml web: bundle exec puma -C config/puma.rb jobs: bundle exec rake solid_queue:start ``` ### 步骤5：清理旧栈 Redis和Sidekiq现在已过时。可以从Gemfile中删除相应的gem，运行Bundler从Gemfile.lock中移除依赖。 ## 监控与管理：Mission Control Jobs Sidekiq的免费版Web用户界面尚可，Sidekiq Pro（949美元/年）和Sidekiq企业版（起价1699美元/年）提供增强的仪表板。 **Mission Control Jobs**是免费、开源的，专门为Rails 8的SolidQueue生态系统设计： ```ruby # config/routes.rb mount MissionControl::Jobs::Engine, at: "/jobs" ``` 通过这一行代码，你现在拥有： - 所有队列的"实时"作业状态 - 失败作业检查，包含完整堆栈跟踪 - 重试和丢弃控制，支持批量操作 - 调度作业时间线可视化 - 定期作业管理 - 队列特定指标和吞吐量图表 更好的是，Mission Control可以检查你的数据库模式。当你检查失败作业时，可以看到其作业参数（就像Sidekiq一样），但你也可以使用大家都喜欢的查询语言SQL查询作业数据： ```sql SELECT j.queue_name, COUNT(*) as failed_count FROM solid_queue_failed_executions fe JOIN solid_queue_jobs j ON j.id = fe.job_id WHERE fe.created_at > NOW() - INTERVAL '1 hour' GROUP BY j.queue_name; ``` ## 常见陷阱与解决方案 ### 单数据库设置（替代方案） SolidQueue建议使用单独的数据库连接，但如果你愿意，可以在一个数据库中运行所有内容。 1. 将`db/queue_schema.rb`的内容复制到常规迁移中 2. 删除`db/queue_schema.rb` 3. 从环境配置中移除`config.solid_queue.connects_to` 4. 运行`rails db:migrate` 这对于较小的应用程序来说效果很好，但代价是操作灵活性。Rails团队推荐使用单独的连接方法。 ### 轮询间隔 调度作业的默认轮询间隔为1秒，就绪作业为0.2秒。如果你从Sidekiq迁移过来，感觉作业"变慢"了，请检查你的期望。根据经验，SolidQueue的默认值对大多数应用程序都适用。对于后台作业来说，亚秒级延迟通常并不重要。 ### ActionCable和Turbo Streams 如果你使用ActionCable（或任何依赖它的东西，如Turbo Streams），你还需要使用自己的数据库连接配置SolidCable。 ## 可扩展性分析 你可能会问那个永恒的问题："它能扩展吗？" 答案是肯定的，它能扩展。但更好的问题是："它是否足够满足我的扩展需求？" 根据Nate Berkopec 2015年的文章《将Ruby应用扩展到1000 RPM》，可以使用以下公式： **所需应用实例数 = 请求速率（请求/秒）× 平均响应时间（秒）** 让我们为一个典型应用进行计算。假设你的应用每分钟收到100个请求，平均响应时间为200毫秒。这大约是每秒1.67个请求。乘以0.2秒，得到0.083个应用实例所需。你需要一个应用实例的8%来处理负载。 ## 工程决策框架 在决定是否从Redis迁移到SolidQueue时，建议使用以下决策框架： 1. **吞吐量评估**：测量当前和预期的作业处理速率 2. **延迟要求分析**：确定业务对作业延迟的容忍度 3. **运维复杂度对比**：评估当前Redis运维负担与简化栈的收益 4. **成本效益分析**：计算Redis托管成本与开发维护时间 5. **风险缓解计划**：制定回滚策略和监控方案 ## 结论 Redis和Sidekiq是经过精心设计的优秀工具，Rails应用在过去十多年中从这一组合中获益匪浅。但对于大多数Rails应用来说，Redis和Sidekiq解决了一个你并不存在的问题，代价却是你无法承受的。 SolidQueue提供了一个简化基础设施、减轻运维负担的机会，让你能够专注于构建产品，而不是维护技术栈。正如Matt Kelly所指出的，除非你每天处理数百万个作业，否则PostgreSQL很可能已经足够满足你的需求。 迁移决策不应基于技术潮流，而应基于实际需求、运维复杂度和成本效益的理性分析。对于95%的Rails应用来说，SolidQueue不仅足够好，而且可能是更好的选择。 **资料来源**： - SimpleThread文章《I Love You, Redis, But I'm Leaving You for SolidQueue》 - Hacker News关于SolidQueue性能的讨论 ## 同分类近期文章 ### [好奇号火星车遍历可视化引擎：Web 端地形渲染与坐标映射实战](/posts/2026/04/09/curiosity-rover-traverse-visualization/) - 日期: 2026-04-09T02:50:12+08:00 - 分类: [systems](/categories/systems/) - 摘要: 基于好奇号2012年至今的原始Telemetry数据，解析交互式火星地形遍历可视化引擎的坐标转换、地形加载与交互控制技术实现。 ### [卡尔曼滤波器雷达状态估计：预测与更新的数学详解](/posts/2026/04/09/kalman-filter-radar-state-estimation/) - 日期: 2026-04-09T02:25:29+08:00 - 分类: [systems](/categories/systems/) - 摘要: 通过一维雷达跟踪飞机的实例，详细剖析卡尔曼滤波器的状态预测与测量更新数学过程，掌握传感器融合中的最优估计方法。 ### [数字存算一体架构加速NFA评估：1.27 fJ_B_transition 的硬件设计解析](/posts/2026/04/09/digital-cim-architecture-nfa-evaluation/) - 日期: 2026-04-09T02:02:48+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析GLVLSI 2025论文中的数字存算一体架构如何以1.27 fJ/B/transition的超低能耗加速非确定有限状态机评估，并给出工程落地的关键参数与监控要点。 ### [Darwin内核移植Wii硬件：PowerPC架构适配与驱动开发实战](/posts/2026/04/09/darwin-wii-kernel-porting/) - 日期: 2026-04-09T00:50:44+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析将macOS Darwin内核移植到Nintendo Wii的技术挑战，涵盖PowerPC 750CL适配、自定义引导加载器编写及IOKit驱动兼容性实现。 ### [Go-Bt 极简行为树库设计解析：节点组合、状态机与游戏 AI 工程实践](/posts/2026/04/09/go-bt-behavior-trees-minimalist-design/) - 日期: 2026-04-09T00:03:02+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析 go-bt 库的四大核心设计原则，探讨行为树与状态机在游戏 AI 中的工程化选择。