Rails 8 新特性全解析：Solid Queue / Cache / Cable，抛弃 Redis 方案实战
——当 Rails 决定替你砍掉整个 Redis 依赖，这不是噱头，是一场架构范式的革命。
一、为什么 Rails 8 要"干掉" Redis？
先说一句得罪人的话：Redis 很强，但 95% 的应用根本用不到它的极限性能，却要为它付出全部的运维代价。
你要维护 Redis server，要配置 persistence，要监控内存，要搭建 HA 高可用集群，还要理解两套完全不同的数据存储语义。对小团队来说，这不是技术选型，这是技术负担。
David Heinemeier Hansson 在 Rails World 上的那句话至今振聋发聩：
"Rails 8 的想法是摆脱趋势跟踪，拒绝一些行业中流行的想法——比如不敢碰 Linux 服务器，或者非要给自己的应用塞一个 Redis。"
于是，Rails 8 带来了三把刀：Solid Queue、Solid Cache、Solid Cable——全部基于数据库驱动，全部零额外依赖。Redis？可以退场了。
二、Solid Queue：用 PostgreSQL 取代 Sidekiq + Redis
2.1 核心原理：FOR UPDATE SKIP LOCKED
Solid Queue 的技术内核极其优雅。它利用 PostgreSQL 9.5 引入的 FOR UPDATE SKIP LOCKED 语句，让多个 Worker 在竞争同一批 Job 时互不阻塞——完美模拟了 Redis 那种高速、原子性的任务锁定行为，而无需任何外部服务。
数据只存三张表：
表格
表名 用途
solid_queue_jobs 所有 Job 的元数据
solid_queue_scheduled_executions 排程中的 Job
solid_queue_ready_executions 可立即执行的 Job
配合 PostgreSQL 的 MVCC 机制，大量 insert/delete 被 autovacuum 自动消化，你甚至不需要调优。
2.2 实战：从零搭建
新建 Rails 8 项目（自动集成）：
bash
rails new myapp
# Solid Queue 已是默认后端，无需任何配置
已有项目升级：
ruby
# Gemfile
gem 'solid_queue'
bash
bin/rails generate solid_queue:install
bin/rails db:migrate
核心配置 config/queue.yml：
yaml
production:
dispatchers: 2
workers:
- queues: [critical]
concurrency: 10
- queues: [default, mailers]
concurrency: 5
scheduler:
dynamic_tasks_enabled: true # 运行时动态增删定时任务
启动：
bash
bin/jobs start # Fork 模式（默认，最佳性能）
bin/jobs start --mode async # Async 模式，单进程多线程，省资源
bin/jobs start --skip-recurring # 开发环境跳过定时任务
2.3 杀手级功能：动态任务调度
这是 Sidekiq Enterprise 才有的付费功能，Solid Queue 免费送：
ruby
# 运行时添加定时任务
SolidQueue::RecurringTask.create(
job_class: "DailyReportJob",
cron_expression: "0 0 * * *",
queue_name: "reports"
)
# 运行时移除
task = SolidQueue::RecurringTask.find_by(job_class: "DailyReportJob")
task.destroy
2.4 对比 Sidekiq + Redis：一张表看清差距
表格
维度 Sidekiq + Redis Solid Queue
吞吐模型 多线程（但 Redis 是单点瓶颈） 数据库原生 MVCC
内存占用（200 QPS） ~1GB（12 Worker） ~320MB（4 Worker）
月账单（AWS t3.medium） ~$84 ~$42
监控 UI ✅ 自带 Web UI ✅ Mission Control（免费替代 Sidekiq Dashboard）
故障转移 Redis 主从切换有窗口期 实测 12 秒内完成，37 个任务零丢失自动续跑
并发控制 ❌ 付费功能 ✅ 免费内建
外部依赖 必须 Redis 无需任何额外服务
但请注意： Solid Queue 要求 Redis 配置为单节点或主从模式（不支持 Redis Cluster），因为它的原子操作依赖 Lua 脚本在单个 Redis 实例上执行。如果你已在用 Redis Cluster，要么拆出专用实例，要么接受部分高级功能降级。
三、Solid Cable：用数据库取代 Redis 做 WebSocket
Action Cable 终于不再被 Redis 绑架了。
Solid Cable 的工作方式： 消息存入数据库表，通过轮询机制检查更新。虽然是轮询，但在大多数场景下性能与 Redis 相当，且不受 PostgreSQL 适配器 8KB 消息负载限制。
yaml
# config/cable.yml
production:
polling_interval: 0.1
message_retention: 1.hour
autotrim: true
兼容 MySQL、SQLite、PostgreSQL。如果你的应用本来就不需要 Redis，Solid Cable 让你彻底摆脱对它的依赖。
四、Solid Cache：磁盘缓存取代内存缓存
Redis 和 Memcached 的替代品来了。Solid Cache 利用磁盘存储，提供：
更大的数据集（不受内存限制）
加密支持
保留策略（Retention Policy）
更低的成本（磁盘比内存便宜一个数量级）
对于缓存 HTML 片段、API 响应这类场景，Solid Cache 是降维打击。
五、AI 后台任务实战：Solid Queue + 优先级队列 + 智能重试
当你的 Rails 应用接入 AI（GPT、Embedding 等），传统的作业管理思维会彻底失效。AI 任务慢、贵、受限、易失败，必须用专门的模式来治理。
5.1 优先级队列设计
ruby
# app/jobs/ai_chat_job.rb
class AiChatJob < ApplicationJob
queue_as :ai_realtime # 实时交互，毫秒级响应
def perform(conversation_id, message)
# 调用 AI 聊天 API
end
end
# app/jobs/batch_embedding_job.rb
class BatchEmbeddingJob < ApplicationJob
queue_as :embeddings # 批量向量化，可延迟一整夜
def perform(document_ids)
# 批量生成向量
end
end
5.2 分级调度配置
yaml
# config/solid_queue.yml
production:
dispatchers:
- polling_interval: 1
batch_size: 500
workers:
- queues: [ai_realtime]
threads: 3
polling_interval: 0.1 # 0.1秒检查一次，极快响应
- queues: [critical, default]
threads: 3
polling_interval: 0.5
- queues: [ai_batch, embeddings]
threads: 2
polling_interval: 2 # 2秒检查一次，节省数据库压力
关键认知： polling_interval 是最容易被忽视但最致命的参数。每个 Worker 线程都按这个间隔查询数据库，间隔越短、队列越多，数据库压力越大。务必根据实际负载调优。
5.3 智能重试：指数退避 + 抖动
AI 任务最常见的失败原因是速率限制（HTTP 429）和超时。固定间隔重试等于对已受限的 API 发起 DDoS 攻击。
ruby
# app/jobs/concerns/ai_base_job.rb
module AiBaseJob
extend ActiveSupport::Concern
included do
# 速率限制：重试5次，多项式退避 + 抖动
retry_on Faraday::TooManyRequestsError,
wait: :polynomially_longer,
attempts: 5
# 网络超时：重试3次，多项式退避
retry_on Faraday::TimeoutError,
wait: :polynomially_longer,
attempts: 3
# AI 通用错误：固定等待10秒，最多3次
retry_on OpenAI::Error,
wait: 10.seconds,
attempts: 3
# 记录不存在直接丢弃，不重试
discard_on ActiveRecord::RecordNotFound
end
end
六、Rails 8 部署革命：Kamal 2
别忘了，Rails 8 还带来了 Kamal 2——一行命令完成生产部署：
bash
kamal setup # 两分钟内配置好生产服务器
kamal deploy # 零停机部署
内置 Thruster 代理，不再需要 Nginx
Kamal Proxy 取代 Traefik，支持 Let's Encrypt 自动 SSL
集成 1Password / Bitwarden 管理密码
Docker 容器开箱即互联网就绪
七、灵魂拷问：你真的需要 Redis 吗？
表格
场景 推荐方案
日均 < 100 万 Job，PostgreSQL 够用 Solid Queue，零额外依赖
日均 > 1000 万 Job，极致吞吐需求 Sidekiq + Redis，依然是王者
不需要 Redis 做其他事 Solid Cable + Solid Cache，全栈数据库驱动
小型项目 / 独立开发者 SQLite 后端，Rails 8 官方支持，部署成本趋近于零
结语
Rails 8 的"三大 Solid"不是要挑战 Redis 的性能极限——它是在问你一个更务实的问题：你真的需要 Redis 吗？
对 99% 的应用来说，把整套基础设施收敛到 PostgreSQL，是 2026 年最合理的架构选择。能用数据库解决的事情，就不要再引入一个新服务。这不仅是技术简化，更是思维简化。
正如那篇引爆社区的文章所说：
"开发者太常在堆功能，而不是解决问题。Redis 是强，但大多数时候我们根本用不到它的极限，而却要为它付上运维成本、部署复杂度与系统风险。"
把 Redis 留给真正需要它的 1%，其余的——交给 Solid Queue 就够了。
