Ruby on Rails Scalability: MVP to Millions of Users

Rails 能撑到百万级甚至更高流量；真正先崩的通常是数据库、任务队列和缺缓存，不是框架本身。Shopify BFCM 2025 应用服务器峰值超过 1.17 亿次请求/分钟，靠分片等架构手段留在 Rails。

常见误判 → 实际原因

• 「扛不住流量」→ 多半是 N+1

• 「数据库挂」→ 全打主库、没缓存

• 「高峰变慢」→ 请求里同步调第三方

• 「服务器打满」→ 单机、没水平扩展

• 「该上微服务了」→ 往往是缺索引 / 胖模型

瓶颈顺序与对应招

1. N+1 → includes / preload，用 Bullet

2. 连接池耗尽 → 算清连接；必要时 PgBouncer

3. 后台队列堆积 → Solid Queue / Sidekiq，按优先级拆队列

4. 单机顶满 → 无状态进程 + 负载均衡

5. 多机后缓存/会话乱 → Solid Cache / Redis

数据库进阶（别跳步） 先查索引与执行计划 → 再读副本 → 再分区 → 最后才分片。

真正硬伤： 单进程吞吐低于 Go/JVM，多花机器、少花工程时间。YJIT 能缩小差距。极低延迟、十万级 WebSocket、重 CPU 更适合拆独立服务，不必整站重写。

动手前先看： 各接口 p95、最慢 SQL 的 EXPLAIN ANALYZE、所有 Puma/Job 的总连接数。