Solid Queue 推 Fiber 模式省线程
推荐指数 55.0 NO. 016 · 2026.08.02
发布2026/08/01Score78Comments33
为什么值得看
Solid Queue 1.6.0 新增基于 Async 的 fiber 工作模式，单线程内可调度 100+ fiber 处理 I/O 密集型任务。对频繁调用 LLM API 的 Rails 应用来说，这意味着用更少内存跑更多并发 job，告别线程池资源吃紧的痛点。
编辑判断
Ruby 社区做后台 job 长期面临一个尴尬：Sidekiq 快但依赖 Redis 且多进程吃内存，Delayed Job 省资源但性能差。Solid Queue 作为 Rails 7.1+ 默认的 Active Job 后端，用数据库表存 job 本就是为了降低基础设施门槛，但线程池模型在高并发 I/O 场景下依然撑不住。
Fiber + Async 的方案其实是把 Ruby 3 的 Ractor 生态成熟前的过渡路径走通了——不用改业务代码，换个配置就能切。对比 Python 的 Celery 用 gevent/eventlet 做协程调度，Ruby 这边之前缺乏生产级方案，现在补上了关键一块。
如果你的 Rails 应用每天有几万到几十万 LLM API 调用，且还在用 Sidekiq + 大内存实例硬撑，迁移到 Solid Queue fiber 模式可能是性价比最高的优化。注意先确认所有 gem 都兼容 fiber isolation，特别是数据库连接池和 HTTP 客户端的配置。
社区反馈
意见分歧 31 条评论
核心争论：Fiber 模式是否真比线程池高效，以及数据库连接管理是否成为新瓶颈
This is a nice update. Is it possible to either have multiple ractors dispatching jobs with fibres or to set up multiple queues with different strategies? E.g. one for IO bound and one for CPU bound? With Sidekiq I’ve had luck having workers running on Truffleruby but generally don’t use it for my m
You can, and Carmine (who coded this update) wrote exactly about this on this blog post: https://paolino.me/solid-queue-doesnt-need-a-thread-per-job/ From his article: One backend, two modes Fiber mode isn’t universally better. CPU-bound jobs get nothing from it, and blocking lib
So fibers are a lot like threads but they're more scoped to a task that can be paused and resumed, that's kinda cool