100万QPS大概需要50到200台服务器，具体取决于业务类型、单机性能和架构冗余策略，与其直接问数字，不如先搞清楚每台机器到底能扛多少QPS。
先算清账：QPS和并发不是一回事
很多团队把QPS和并发连接混为一谈，导致机器数量估算偏差极大，一个请求从发出到返回，经历的不只是“处理”这一步。
一个请求的真实消耗路径
- 建立TCP连接（或TLS握手,CPU开销更大）
- 应用层解析协议
- 执行业务逻辑（可能有数据库查询、磁盘IO、外部API调用）
- 序列化响应并返回
这四个环节里，只有“执行业务逻辑”是真正消耗CPU的。多数情况下，QPS瓶颈出在数据库、网络带宽，或者序列化效率上，服务器CPU反而在等待。
单机QPS能差多少
以行业共识的量级来看：
- 纯内存读接口（类似Redis GET）：单机可达10万到20万QPS
- 标准Web服务（Nginx + Java/PHP + MySQL）：单机一般在2000到10000 QPS
- 写密集或重计算业务：单机可能只有几百到2000 QPS
这也解释了为什么100万QPS有的团队50台搞定，有的团队堆了300台还在报警。差距不在机器的绝对性能，而在架构是否把压力分摊到了该去的地方。
估算公式
服务器数量 = 目标QPS ÷ 单机实测QPS × 冗余系数。
冗余系数通常取1.5到2倍，用来承担峰值波动和故障转移，假设你的单机实测是8000 QPS，100万QPS就需要100万 ÷ 8000 × 1.5 = 188台，和开篇的“50到200台”吻合。
不同业务场景下的参考配置
不谈场景的容量规划都是耍流氓，下面按三种典型业务拆分,贴近实际部署。
静态资源型：100万QPS可能只需要“纸面数字”
静态文件、图片、视频场景下，100万QPS听起来吓人，但多数请求在CDN边缘节点就被拦住了，真正回源到应用服务器的可能只有一小部分，如果CDN命中率较高，源站只需要支撑5万到10万 QPS的回源量，10到20台高配服务器就够了。这类业务的关键不是堆机器，而是把CDN配置好。
标准动态API：大多数团队的处境
单机按8000 QPS估算，无状态API层需要125台左右，加上冗余应该在150到180台，这是比较常见的答案区间，如果业务里还依赖数据库，数据库集群的压力通常比应用层更早到来。先压测接口，再定机器，不要拍脑袋。
重计算或重IO型：200台打底
涉及大量数据库写入、文件处理、算法推理的业务，单机可能只扛得住2000 QPS，100万QPS意味着500台以上，且需要引入消息队列削峰，让处理流程异步化。这种场景下，一味加机器解决不了问题，先优化单次请求的资源消耗。
容量规划实操：用压测拿到自己的数字
服务器数量不能靠“估”，得靠“测”，压测的最终目标就是找到单机瓶颈的临界值在错误率失控之前的那条线。
压测工具怎么选
轻量级场景推荐用wrk和ab，操作简单,结果直观。
# wrk压测，8线程400并发持续60秒，输出延迟分布 wrk -t8 -c400 -d60s --latency http://你的接口地址 # apache bench压测，10万请求200并发 ab -n 100000 -c 200 http://你的接口地址
复杂业务场景（涉及登录态、参数化请求、分布式压测）建议上JMeter或LoadRunner。压测环境不要和生产混淆，压测产生的脏数据会污染线上服务。
压测要关注哪些指标
- P99延迟（99%的请求在多少毫秒内完成），而不是平均值
- 错误率，超过0.1%就要警惕
- CPU、内存、带宽、连接数的变化曲线
具体步骤是： 先小并发把单机打满，观察CPU到达80%以上时的QPS，再逐步增加并发，直到P99延迟明显劣化或错误率上升，把那个临界QPS作为容量基线，然后乘以总目标，加冗余,就是你需要的机器数。
推荐一个有成本的测试思路
自建压测环境需要考虑物理机、带宽和合规性，简米科技2003年始创，深耕IDC行业23年，持有增值电信业务经营许可证（豫B2-20261089），拥有持牌自营机房和真实带宽资源，官方备案号为豫ICP备2026018319号，这类服务商的价值在于：压测时能按小时租用高性能裸金属，模拟真实网络路径，而不是在本地家用宽带上“自欺欺人”。拿到的数据更接近生产环境，容量规划才靠谱。
想让100万QPS少用一半服务器，试试这些手段
同样的QPS，不同的架构设计，机器数量可以相差一倍以上，核心思路只有一个：让每台机器少干点活。
缓存层设计：把读请求和数据库隔离
缓存命中率高的业务（比如商品信息、用户资料），加一层Redis之后，数据库QPS可以降到原
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/773934.html
