容量估算与服务器选型清单

本篇定位

回答一个最实际的问题：这个业务该买几台机器、每台买多大配置？ 从日 PV 出发，一步步算出峰值 QPS，再按各层单机的"经验承载能力"倒推机器数量，最后给出日 PV 1 万 / 10 万 / 100 万 / 1000 万 / 1 亿五档的完整配置清单。所有数字都是业界经验起点，必须用压测校验，不能照抄上线。配套：架构设计方法论、高可用与容灾。

一、先把这些概念算清楚

小白类比：估算饭馆要多少座位，得先知道每天来多少人（PV）、最忙那一小时挤进来多少人（峰值 QPS）、同时坐下来点菜的有几桌（并发）。服务器同理。

指标	含义	怎么估
PV（页面浏览量）	一天页面被打开多少次	业务方给 / 拍脑袋起步
UV（独立访客）	一天多少个不同的人来	通常 UV ≈ PV 的 1/3 ~ 1/10
QPS	每秒查询数（读为主）	峰值 QPS = 日 PV ÷ 86400 × 峰值系数
TPS	每秒事务数（写为主）	一般远小于 QPS，读写比常见 5:1 ~ 10:1
并发在线数	同时正在操作的用户数	≈ 日活 × 同时在线比例（常见 5%~10%）
数据量	一年产生多少数据	单条记录大小 × 日增量 × 天数
带宽	网络出口要多大	峰值 QPS × 单请求响应字节

1.1 峰值 QPS 换算公式

一天的访问从不均匀——大部分集中在白天高峰的 2~4 小时。业界常用简化：

平均 QPS = 日 PV ÷ 86400
峰值 QPS ≈ 平均 QPS × 峰值系数（经验 50~100）

峰值系数取 50 的含义：全天约 5% 的流量挤在 1 小时内（≈3600 秒），即 日PV×5%÷3600 ≈ 日PV÷72000。大促/突发场景要再乘 2~3 倍。

日 PV	平均 QPS	峰值 QPS（×50）	大促峰值（×2）
1 万	0.1	~6	~12
10 万	1.2	~60	~120
100 万	11.6	~580	~1200
1000 万	116	~5800	~1.2 万
1 亿	1157	~5.8 万	~12 万

二、各层单机承载经验值

⚠️ 这些是"起点经验值"，业务逻辑复杂度影响极大：一个空接口和一个要 JOIN 三张表的接口，QPS 差 10 倍。上线前务必压测。

2.1 接入 / Web 层

组件	单机经验承载	说明
Nginx 静态 Web	3 万~5 万 QPS	纯静态小文件，瓶颈主要是连接数和带宽
Nginx 反向代理/网关	1 万~3 万 QPS	转发+日志+限流，比纯静态低
LVS / DPVS（四层）	10 万+ QPS	内核态转发，性能极高，做大流量入口

2.2 应用层（业务代码）

技术栈	单机经验承载（简单接口）	复杂业务接口
Java / Spring Boot（4C8G）	800~1500 QPS	300~500 QPS
Go（4C8G）	3000~8000 QPS	1000~2000 QPS
Node.js（4C8G）	1000~2000 QPS	看异步化程度

CPU 核数与 QPS 经验关系：Java 业务接口大致 1 核 ≈ 200~400 QPS（压到 70% 利用率）；Nginx 静态 1 核 ≈ 5000~10000 QPS。应用层加 CPU 基本线性，但要同步加内存（线程栈、GC）。

2.3 数据层

组件	单机经验承载	容量建议
MySQL（主库）	写 TPS 500~2000；读 QPS 2000~5000	单表建议 < 2000 万行 / < 50GB；超过就分库分表
MySQL（从库）	读 QPS 3000~8000	读多写少就多加从库做读写分离
Redis（单实例）	8 万~12 万 QPS	单实例内存建议 < 10GB（大了 fork 会阻塞）；数据量大上 Cluster
Kafka（单 broker）	写入 5 万~10 万条/秒	吞吐靠分区数和 broker 数水平扩展

2.4 内存 / 连接 / 磁盘 / 带宽经验

维度	经验规则
JVM 内存	-Xmx 设为物理内存的 50%~70%，留给堆外、Metaspace、OS page cache；不要把 16G 全给堆
连接数	每个 TCP 连接约占 4KB 内核缓冲；Nginx worker_connections 调大到数万；应用连接池（DB）大小别盲目开大，MySQL max_connections 通常 500~2000 封顶
磁盘 IOPS	机械盘 ~100~200 IOPS；SATA SSD ~1万；NVMe SSD ~5万~10万。数据库、Redis 持久化、Kafka 落盘必须 SSD/NVMe
磁盘容量	按数据量 ×3 年增长预留，日志盘和数据盘分开；MySQL 留 binlog + 备份空间
带宽	带宽(Mbps) = 峰值QPS × 单请求平均响应字节 × 8 ÷ 1024 ÷ 1024；静态资源走 CDN，源站带宽只回源

带宽例子：峰值 5000 QPS，接口平均响应 10KB，则出网 ≈ 5000 × 10KB × 8 ≈ 400 Mbps，按 500M 带宽买。静态图片走 CDN 后源站带宽可降一个数量级。

三、五档规模配置清单

下表按"峰值 QPS ÷ 单机经验承载"向上取整，并加 N+1 冗余（挂一台不影响）和 3 年增长预留（约 ×1.5~2）。假设：读写比 5:1、业务为中等复杂度 Web 后端、Linux 云服务器。

3.1 日 PV 1 万（初创 / 内部系统）

层	数量	单台配置	说明
Nginx 接入	1~2 台	2C4G	可与应用混部
应用服务	2 台	2C4G	主备/双活
MySQL	1 主 1 从	4C8G / 100G SSD	必做主从备份
Redis	1 台	2C4G（可混部）	数据少可先不用
MQ	0	—	量小先不上，用同步
合计	~4 台		可先 2 台起步

3.2 日 PV 10 万（小型创业产品）

层	数量	单台配置	说明
Nginx 接入	2 台	2C4G（Keepalived VIP）	见 LVS+Keepalived
应用服务	2~3 台	4C8G	无状态，前面 Nginx 轮询
MySQL	1 主 1 从	8C32G / 500G SSD	读写分离雏形
Redis	3 台（哨兵）	4C8G	或 1 主 1 从 + 1 哨兵
MQ	0~3 台	4C8G	有异步需求再上 Kafka
合计	7~9 台

3.3 日 PV 100 万（成长期业务）

层	数量	单台配置	说明
LVS + Nginx 接入	2~3 台	4C8G	四层+七层分层
应用服务	4~6 台	8C16G	按 ~500 QPS/台，580 峰值需 ~2 台，留冗余
MySQL	1 主 2 从	16C64G / 1T SSD	读写分离，考虑垂直拆分
Redis	3~5 台	8C32G	哨兵或小 Cluster
Kafka	3 台	8C32G / 1T SSD	削峰、异步解耦
合计	~15~18 台

3.4 日 PV 1000 万（中型平台）

层	数量	单台配置	说明
LVS/DPVS + Nginx 网关	4 台	8C16G	接入层集群
应用服务	12~20 台	16C32G	微服务拆分后按服务独立扩
MySQL	6~8 台	32C128G / 2T NVMe	分库分表 + 多主从，见 MySQL 进阶
Redis Cluster	6~9 台	16C64G	分片集群
Kafka	5~7 台	16C64G / 2T NVMe	多分区多副本
合计	~35~50 台

3.5 日 PV 1 亿（大型 / 头部业务）

层	数量	单台配置	说明
DPVS + 网关集群	8~12 台	16C32G	接入层多机房
应用服务	40~80 台	16C32G	按微服务分别扩缩
MySQL	20~30 台	32C128G / 4T NVMe	分库分表、多集群、异地
Redis Cluster	15~20 台	32C128G	大集群+多副本
Kafka	10~15 台	32C128G / 4T NVMe	高吞吐多机房
对象存储/CDN	云服务	—	图片视频全走 OSS+CDN
合计	~100~160 台		应考虑容器化弹性伸缩

1000 万 PV 以上强烈建议容器化：参考 K8s 架构与集群，用 HPA 自动伸缩代替固定买机器。

四、3 年增长预留与压测校验

事项	做法
增长预留	按业务年增长率（常见 50%~100%）算 3 年后容量，机器数量再乘 1.3~1.5；数据库按 3 年数据量规划分库分表时机
余量 Headroom	日常 CPU 水位控制在 60%~70%，留 20%~30% 应对突发和单台宕机接管
压测校验	上表只是"估"，必须压测：单台应用压到 CPU 70% 时的真实 QPS、MySQL 慢查询拐点、Redis 大 key 延迟、MQ 积压
压测后修正	若实测单机 QPS 只有经验值一半，就把机器数 ×2；这比拍脑袋可靠得多
观测兜底	上线后用 Prometheus 看实际水位，持续修正：见容量规划与灾备、SLO

五、延伸阅读

• 方法论与三板斧：架构设计方法论
• 高可用与容灾：高可用与容灾模式
• 数据库选型与高可用：MySQL 进阶与高可用
• 缓存：Redis；消息队列：Kafka
• 容器弹性伸缩：K8s 架构与集群