Solid Queue（solid_queue）是 Rails 官方思路的后台任务方案：不另搭消息队列服务，直接用应用已有的 SQL 数据库存任务、跑任务。对已经用 Rails Active Job 的团队来说，它最大的吸引力是少一套基础设施——任务状态、重试、定时、优先级都在数据库里，看得见、查得到；代价是队列的吞吐与锁行为从此和数据库配置绑在一起，任务量大了要先调数据库，而不是先加队列节点。
30 秒速读
solid_queue 是 Ruby on Rails Active Job 的数据库队列后端，用 SQL 数据库存储任务，通过 worker、dispatcher 与 scheduler 处理排队、派发和定时任务。据仓库说明，它支持延迟任务、定时任务、优先级、并发控制、暂停队列与批量入队，可用时使用 FOR UPDATE SKIP LOCKED 减少轮询任务时的锁阻塞。支持 MySQL、PostgreSQL 与 SQLite，最低要求 Rails 7.1 与 Ruby 3.2。适合希望减少额外队列基础设施的 Rails 应用；需要独立于 Rails 的队列协议或专用消息系统能力时，要先与其他方案验证对比。
项目信息
| 项目 | 内容 |
|---|---|
| 项目名称 | Solid Queue（solid_queue） |
| 实现语言 | Ruby |
| 运行环境 | Rails 7.1 或更高版本，Ruby 3.2 或更高版本，MySQL、PostgreSQL 或 SQLite |
| 平台 | 多平台 |
| 许可证 | 以仓库 LICENSE 文件为准 |
| 分发方式 | Bundler 安装，bin/rails solid_queue:install 生成配置与结构 |
| 适用场景 | 邮件发送、异步业务操作、延迟与定时任务、批量入队 |
选型对照：数据库队列，还是专用消息队列
结论先行：应用以 Rails Active Job 为任务抽象、团队愿意把队列运维与数据库运维合在一起时，选 solid_queue；任务量极大、需要跨语言消费或独立队列协议时，专用消息系统更合适。
| 维度 | Solid Queue | 专用消息队列（如 Redis 队列服务） | 直接同步执行 |
|---|---|---|---|
| 基础设施 | 无新增，用已有 SQL 数据库 | 需额外部署与维护队列服务 | 无，但阻塞请求 |
| 任务可见性 | 高，任务就是数据库里的行，可查可审 | 需借助管理界面或命令查看 | 无任务记录 |
| 与 Rails 结合 | 深，复用 Active Job 的重试、丢弃与序列化机制 | 需适配层对接 Active Job | 不涉及 |
| 吞吐上限 | 受数据库配置与锁行为制约 | 通常更高，专为高并发设计 | 受请求线程制约 |
| 跨语言消费 | 不适合，面向 Rails Active Job | 多数支持多语言客户端 | 不涉及 |
上手步骤
- 先核对版本：Rails 在 7.1 或更高版本、Ruby 在 3.2 或更高版本，版本不够先升级框架，不要在旧版本上强行安装。
- 决定队列数据库放哪里：与业务库共用一个库最省事，但任务量稍大就建议独立数据库，避免任务轮询拖慢业务查询，这个决定要在安装前定好。
- 用 Bundler 安装后，运行 bin/rails solid_queue:install，生成配置文件、队列数据库结构与 bin/jobs 启动包装器，再按实际任务量调整 worker、dispatcher 与 scheduler 的配置。
- 在开发环境先跑通三类任务：立即执行的邮件发送、延迟执行的任务、定时执行的任务，确认重试、丢弃与错误处理都按 Active Job 的机制工作。
- 配置并发与优先级：按队列设置并发上限，用数值或队列顺序定优先级，验证高优先级任务确实先被消费、暂停队列后任务不再派发。
- 试一次批量入队：用 enqueue_all 批量提交一批任务，观察数据库写入与消费速度，确认批量接口符合预期再用到生产流程。
- 上线前补齐运维流程：失败任务、被非正常终止的任务、定时任务的清理与监控都要有对应的检查办法，不要等任务堆积了才发现没有告警。
核心能力
- 为 Rails Active Job 提供基于数据库的任务入队与处理能力，任务状态直接落在 SQL 数据库里。
- 覆盖延迟任务、定时任务、并发控制、暂停队列、按数值或队列顺序设置优先级等常见任务处理需求。
- 支持 enqueue_all 批量入队与批处理相关能力，批量提交任务时不用逐条循环。
- 可用时使用 FOR UPDATE SKIP LOCKED，减少 worker 轮询任务时的锁等待。
- 提供 worker、dispatcher、scheduler、Puma 插件以及线程或进程模式配置，可按部署场景调整运行形态。
注意事项与边界
- 它离不开 Rails Active Job。需要脱离 Active Job 独立运行的队列场景不适合用它，跨语言、多协议的队列需求要另选方案。
- 吞吐与锁行为跟着数据库走。任务数据与队列处理都依赖 SQL 数据库，数据库配置、锁语义、并发参数会直接影响队列表现，压测要在目标数据库上做，不能拿 SQLite 的开发环境数据推断生产表现。
- FOR UPDATE SKIP LOCKED 不是处处可用。不同数据库与版本对它的支持程度不同，具体锁行为要结合所选数据库确认，换数据库后要重新验证。
- 容量边界不要靠猜。据仓库说明，公开摘要没有给出跨数据库的性能数据、故障恢复目标或容量边界，生产规模适配性要用实际任务负载验证，包括队列顺序、优先级、重试、定时任务与异常终止后的行为。
- 升级要按仓库说明走。既有安装的升级步骤、队列 schema 变更都要先在副本环境验证，升级后重跑失败任务与定时任务的回归检查。
适用人群与不适合谁
适合已经使用 Ruby on Rails 与 Active Job、希望把后台任务状态统一放在 MySQL、PostgreSQL 或 SQLite 中的开发团队，任务以邮件、异步业务操作、延迟与定时任务为主的场景最对口。
不适合的场景：需要独立于 Rails 的队列协议、明确的跨数据库性能指标或专用消息系统能力，或者任务要由非 Rails 服务消费，这些情况下专用消息队列是更稳妥的选择。
获取方式
GitHub 国内访问较慢，如打不开可多刷新几次
关注「软件教程管家」
回复软件名即取即下：网盘下载链接 + 提取码，一步直达，不用再跳转。
本站资源仅供个人学习交流，请勿用于商业用途。软件与资料版权归原作者所有；如有侵权，请通过公众号「软件教程管家」联系我们，我们将在 24 小时内下架处理。查看免责声明 ›
