GoodJob 和 Sidekiq 选哪个？Rails 后台任务框架对比
GoodJob 用 PostgreSQL 保证事务安全，Sidekiq 用 Redis 换取极致吞吐。本文从事务安全性、崩溃恢复、延迟、部署模型、并发与监控等维度深度对比两大 Rails 后台任务框架。
已经在用 PostgreSQL、任务量中等（每秒数百以内）、追求基础设施精简选 GoodJob；超高吞吐（每秒数千以上）、已有 Redis 运维能力、需要成熟商业支持选 Sidekiq。两者的分水岭不是功能列表，而是"数据库事务保证 vs 内存队列速度"的架构取舍。
底层机制决定一切
GoodJob 把任务存在 PostgreSQL 表里，用 advisory lock 实现多 worker 安全认领，用 LISTEN/NOTIFY 实现毫秒级即时派发。Sidekiq 把任务推进 Redis 的 List 结构（Pro 版有增强的可靠队列机制），靠 BRPOP 阻塞拉取。一个吃数据库的事务红利，一个吃内存的吞吐红利，后续所有差异都由此展开。
事务安全性
这是 GoodJob 的杀手锏：任务入队可以和业务数据写入放在同一个数据库事务里。
ActiveRecord::Base.transaction do
order.save!
OrderEmailJob.perform_later(order.id) # 同事务，要么都成要么都滚
end
Sidekiq 推 Redis 不参与数据库事务，极端情况下会出现"订单回滚了但邮件任务已发出"的幽灵任务。社区有各种 after_commit 技巧缓解，但做不到 GoodJob 这种原生保证。
崩溃恢复与可靠性
- GoodJob：worker 崩溃 → 数据库连接断开 → advisory lock 自动释放 → 任务被重新认领。语义简单且必然正确。
- Sidekiq：基本版 worker 崩溃时正在处理的任务可能丢失（Redis 弹出即删除）；Pro 版的 super_fetch 提供了"崩溃恢复"能力，把任务先放私有队列、确认完成才删除。要花钱买可靠性，这是它的商业模式。
两者都要求任务幂等，但 GoodJob 的恢复语义开箱即用。
延迟与吞吐
Sidekiq 赢在极端性能：Redis 内存操作 + 多线程拉取，吞吐与拾取延迟取决于 Worker 并发、任务逻辑及 Redis 负载。GoodJob 靠 LISTEN/NOTIFY 也能做到近实时派发，但高并发下 PostgreSQL 的行锁和表膨胀会成为瓶颈，容量应以任务时长、数据库负载和实测结果确定。对发邮件、跑报表、同步数据这类业务，两者体验无差别；做实时流式处理才需要 Sidekiq 的吞吐上限。
部署与资源占用
GoodJob 可以内嵌在 Web 进程里跑（小规模部署零额外成本），也可以独立进程；不引入新中间件意味着省掉 Redis 的高可用、监控、备份一整套运维。Sidekiq 必须带 Redis，容器化部署至少是 web + worker + redis 三个角色，资源账单和心智负担都更重。
队列管理、过滤与监控
两者的 Web UI 都支持队列查看、失败重试、任务搜索。GoodJob 的仪表盘原生免费且信息更"关系型"（SQL 式过滤、执行历史完整可查）；Sidekiq 免费版 UI 功能基础，批量操作、增强指标在 Pro/Enterprise。优先级方面，Sidekiq 的队列加权策略成熟，GoodJob 的线程池分配简单直观。
迁移与共存
两者都实现了 ActiveJob 接口，业务代码基本不用改。渐进迁移路径：新任务类指定 GoodJob 适配器，存量任务继续 Sidekiq，观察稳定后整体切换并下线 Redis。
常见问题（FAQ）
Q：不用 ActiveJob、直接用 Sidekiq Worker 的项目能迁吗？
可以但要改代码：把 Sidekiq::Worker 换成 ApplicationJob，参数序列化方式也有细微差别（ActiveJob 支持 GlobalID）。趁迁移统一成 ActiveJob 规范，长期是收益。
Q：GoodJob 任务表膨胀怎么办？
开启自动清理配置（config.good_job.cleanup_interval），保留期按业务需要设 7~30 天；历史执行数据有审计价值的话，清理前归档到数仓。
Q：已有 Redis（做缓存）还需要 GoodJob 吗？
有 Redis 不代表要用它当队列。决策点仍然是：是否需要每秒数千级的吞吐？需要则 Sidekiq，否则 GoodJob 的事务安全和少一套故障域更有价值。
参考文档
本文依据公开文档整理，示例需按项目依赖版本验证；不将文档中的性能描述视为本项目实测结果。
