百万 QPS每秒百万次请求是互联网基础设施的顶级量级只有少数头部公司如 Google、Meta、阿里、腾讯核心链路在特定场景下能达到。对大多数团队来说更现实的目标是先设计可水平扩展的架构再按流量阶梯逐步演进。本文挑重点讲清楚原理、分层和落地路径。1. 百万 QPS 意味着什么在动手之前必须做容量建模指标估算100 万 QPS每秒 100 万次 HTTP 请求按平均 1KB 响应出站带宽约 8 Gbps仅响应体按 10ms 平均延迟任意时刻约 1 万个并发连接 在处理中单机极限普通 Web 服务器约 1–5 万 QPS静态/缓存命中场景结论不可能靠单机扛百万 QPS必须依赖 CDN 边缘缓存 多层负载均衡 大规模水平扩展 异步解耦。2. 整体架构百万 QPS 的核心思路是 「让请求尽量死在离用户最近的地方」每一层都有明确职责且都可独立扩容。3. CDN 与边缘计算第一道防线3.1 静态资源HTML、CSS、JS、图片、视频走 CDN命中率可达 95%若 100 万 QPS 中有 80 万是静态资源CDN 吸收后源站只剩 20 万 QPS3.2 动态内容边缘化Edge Side Includes (ESI)、边缘 SSRCloudflare Workers、AWS LambdaEdge 在边缘做鉴权、A/B、限流把「读多写少」的 API 做成 边缘缓存短 TTL 缓存键设计3.3 关键实践合理设置Cache-Control、ETag、Vary按地域部署 PoP减少回源源站保护CDN 回源限流、源站 IP 白名单4. 负载均衡两层结构4.1 四层 LBL4基于 IP 端口转发性能极高常用LVSDR/NAT 模式、F5、云厂商 NLB单台 LVS 可达 百万级连接QPS 取决于包大小多 LB 用 ECMP / Anycast / DNS 轮询 做横向扩展4.2 七层 LBL7基于 HTTP 路由、TLS 终止、限流、灰度常用Nginx、Envoy、HAProxy、云 ALB单实例约 5–10 万 QPS视配置而定需要 几十到上百实例4.3 选型建议DNS(GSLB) → Anycast VIP → L4 LB 集群 → L7 LB 集群 → 应用 PodTLS 在 L7 或专用 SSL 卸载层终止硬件或 Envoy长连接场景注意 连接数 而非只看 QPS5. 应用层无状态 水平扩展5.1 无状态设计Session 外置到 Redis 集群文件上传走 对象存储S3/OSS任意实例可随时扩缩容5.2 容器化与编排Kubernetes HPA按 CPU/QPS/自定义指标扩缩单集群可管理数千 Pod超大规模用 多集群 联邦服务网格Istio/Linkerd做流量治理但高 QPS 场景要评估 sidecar 开销5.3 语言与运行时场景推荐高 QPS 读接口Go、Rust、C复杂业务Java虚拟线程/GraalVM、Go计算密集独立 Worker 池连接池、对象池减少 GC 压力零拷贝、io_uringLinux优化 I/O避免同步阻塞调用链路过长5.4 容量估算示例假设单个 Go 实例稳态 2 万 QPS源站需扛 20 万 QPS → 约 10 台加 50% 冗余 → 15 台多可用区部署单区故障仍可用6. 缓存多层缓存体系缓存是扛高并发最核心的手段。6.1 浏览器缓存max-age、immutable减少重复请求6.2 CDN 缓存见上文吸收绝大部分流量6.3 应用本地缓存Caffeine、ristretto 等进程内缓存适合热点配置、字典数据延迟 微秒级注意多实例一致性短 TTL 发布时失效6.4 分布式缓存Redis单 Redis 约 10–20 万 QPSGET集群模式百万 QPS 读 → Redis Cluster 数十节点或 多级缓存本地 Redis热点 Key本地缓存 随机过期 防雪崩互斥锁/单飞singleflight 防击穿6.5 数据库查询缓存缓存穿透布隆过滤器缓存雪崩过期时间加随机抖动缓存与 DB 一致性延迟双删、订阅 binlog 失效缓存6.6 典型读路径请求 → 本地缓存命中? → Redis 命中? → DB最后手段目标打到 DB 的 QPS 控制在 数百数千。7. 数据库读写分离 分片DB 是典型瓶颈百万 QPS 下必须 少写多读、异步写、分片存储。7.1 读写分离主库写多个只读副本读注意主从延迟读己之写用 主库读 或 会话一致性7.2 分库分表水平分片按 user_id、order_id 等 hash中间件ShardingSphere、Vitess、CitusPG跨分片查询尽量避免或走 ES/OLAP 做分析7.3 数据库选型类型场景MySQL/PostgreSQL事务型核心业务TiDB/CockroachDB分布式 SQL自动分片Cassandra/ScyllaDB超高写入、宽表DynamoDB云原生 KV自动扩展7.4 连接池应用与 DB 之间用 PgBouncer、ProxySQL避免「每个 Pod 一个连接」导致连接数爆炸8. 异步化与消息队列同步链路越长能扛的 QPS 越低。8.1 写操作异步化用户下单 → API 快速返回「已受理」→ 消息队列 → 订单/库存/支付 Worker队列Kafka、Pulsar、RocketMQKafka 单集群可达 百万级消息/秒分区扩展8.2 削峰填谷秒杀、抢购请求先入队Worker 按 DB 能力消费配合 令牌桶/漏桶限流8.3 CQRS写模型与读模型分离写走 OLTP读走 Redis / ES / 物化视图最终一致性可接受时读性能可提升一个数量级9. 限流、熔断、降级高并发下保护系统比服务所有请求更重要。9.1 多级限流全局限流网关→ 服务级限流 → 接口级限流 → 用户级限流算法令牌桶、滑动窗口实现Envoy rate limit、Sentinel、自研 Redis Lua9.2 熔断下游故障时快速失败避免级联雪崩Hystrix / resilience4j / Envoy outlier detection9.3 降级非核心功能关闭推荐、评论返回兜底数据缓存快照、默认值静态化热点页面10. 网络与基础设施10.1 带宽百万 QPS × 1KB ≈ 8 Tbps 级别 的峰值带宽需求含请求响应实际靠 CDN 边缘消化源站带宽需求小得多10.2 多地域部署Active-Active 多活用户就近接入数据多活冲突用 CRDT、最后写入胜出、或业务层规避10.3 专线与 Anycast骨干网 Anycast 将流量导向最近数据中心跨地域数据同步延迟要纳入设计11. 可观测性没有监控等于盲飞百万 QPS 下1% 错误 每秒 1 万次失败。11.1 三大支柱MetricsPrometheus Thanos/MimirRED/USE 方法LogsELK/Loki采样 结构化TracesJaeger/Tempo分布式追踪找慢点11.2 关键指标QPS、P99 延迟、错误率、饱和度缓存命中率、队列积压、DB 连接池使用率告警按 SLO 设定如 99.9% 请求 200ms11.3 全链路压测生产级压测流量录制回放、影子流量逐步加压找到第一个瓶颈点12. 安全高并发下的 DDoS 防护CDN WAF 吸收恶意流量验证码、人机校验在边缘完成SYN Cookie、连接限速13. 演进路径不要一步到位大多数系统不需要第一天就百万 QPS。建议分阶段阶段QPS 量级典型架构1 1 万单机/小集群 MySQL Redis21–10 万多实例 读写分离 CDN310–50 万分库分表 消息队列 多级缓存450–100 万多地域 边缘计算 专用基础设施每一步用 压测验证瓶颈再针对性优化避免过度设计。14. 常见误区堆机器不堆架构无状态、缓存、异步没做好加机器收益递减忽视热点少数 Key 打爆 Redis 单分片需本地缓存 热点探测同步链路过长一个请求串 10 个微服务P99 必然爆炸过度微服务化百万 QPS 下服务间 RPC 开销可观合并热点路径没有压测上线后才发现 DB 连接池、某个 JSON 序列化是瓶颈15. 总结支撑百万 QPS 的本质是边缘消化CDN 边缘计算挡住绝大部分流量水平扩展每一层无状态、可独立扩容缓存为王多级缓存让 DB 几乎不被读流量打穿异步解耦写操作走队列读走缓存限流降级宁可拒绝不可雪崩可观测 压测用数据驱动扩容和优化没有银弹只有 分层、分片、缓存、异步 的组合拳。根据业务类型读多/写多、一致性要求调整权重按流量阶段演进比一开始就追求「百万 QPS 架构」更务实。
浅谈如何搭建一个支持百万 QPS 的网站
百万 QPS每秒百万次请求是互联网基础设施的顶级量级只有少数头部公司如 Google、Meta、阿里、腾讯核心链路在特定场景下能达到。对大多数团队来说更现实的目标是先设计可水平扩展的架构再按流量阶梯逐步演进。本文挑重点讲清楚原理、分层和落地路径。1. 百万 QPS 意味着什么在动手之前必须做容量建模指标估算100 万 QPS每秒 100 万次 HTTP 请求按平均 1KB 响应出站带宽约 8 Gbps仅响应体按 10ms 平均延迟任意时刻约 1 万个并发连接 在处理中单机极限普通 Web 服务器约 1–5 万 QPS静态/缓存命中场景结论不可能靠单机扛百万 QPS必须依赖 CDN 边缘缓存 多层负载均衡 大规模水平扩展 异步解耦。2. 整体架构百万 QPS 的核心思路是 「让请求尽量死在离用户最近的地方」每一层都有明确职责且都可独立扩容。3. CDN 与边缘计算第一道防线3.1 静态资源HTML、CSS、JS、图片、视频走 CDN命中率可达 95%若 100 万 QPS 中有 80 万是静态资源CDN 吸收后源站只剩 20 万 QPS3.2 动态内容边缘化Edge Side Includes (ESI)、边缘 SSRCloudflare Workers、AWS LambdaEdge 在边缘做鉴权、A/B、限流把「读多写少」的 API 做成 边缘缓存短 TTL 缓存键设计3.3 关键实践合理设置Cache-Control、ETag、Vary按地域部署 PoP减少回源源站保护CDN 回源限流、源站 IP 白名单4. 负载均衡两层结构4.1 四层 LBL4基于 IP 端口转发性能极高常用LVSDR/NAT 模式、F5、云厂商 NLB单台 LVS 可达 百万级连接QPS 取决于包大小多 LB 用 ECMP / Anycast / DNS 轮询 做横向扩展4.2 七层 LBL7基于 HTTP 路由、TLS 终止、限流、灰度常用Nginx、Envoy、HAProxy、云 ALB单实例约 5–10 万 QPS视配置而定需要 几十到上百实例4.3 选型建议DNS(GSLB) → Anycast VIP → L4 LB 集群 → L7 LB 集群 → 应用 PodTLS 在 L7 或专用 SSL 卸载层终止硬件或 Envoy长连接场景注意 连接数 而非只看 QPS5. 应用层无状态 水平扩展5.1 无状态设计Session 外置到 Redis 集群文件上传走 对象存储S3/OSS任意实例可随时扩缩容5.2 容器化与编排Kubernetes HPA按 CPU/QPS/自定义指标扩缩单集群可管理数千 Pod超大规模用 多集群 联邦服务网格Istio/Linkerd做流量治理但高 QPS 场景要评估 sidecar 开销5.3 语言与运行时场景推荐高 QPS 读接口Go、Rust、C复杂业务Java虚拟线程/GraalVM、Go计算密集独立 Worker 池连接池、对象池减少 GC 压力零拷贝、io_uringLinux优化 I/O避免同步阻塞调用链路过长5.4 容量估算示例假设单个 Go 实例稳态 2 万 QPS源站需扛 20 万 QPS → 约 10 台加 50% 冗余 → 15 台多可用区部署单区故障仍可用6. 缓存多层缓存体系缓存是扛高并发最核心的手段。6.1 浏览器缓存max-age、immutable减少重复请求6.2 CDN 缓存见上文吸收绝大部分流量6.3 应用本地缓存Caffeine、ristretto 等进程内缓存适合热点配置、字典数据延迟 微秒级注意多实例一致性短 TTL 发布时失效6.4 分布式缓存Redis单 Redis 约 10–20 万 QPSGET集群模式百万 QPS 读 → Redis Cluster 数十节点或 多级缓存本地 Redis热点 Key本地缓存 随机过期 防雪崩互斥锁/单飞singleflight 防击穿6.5 数据库查询缓存缓存穿透布隆过滤器缓存雪崩过期时间加随机抖动缓存与 DB 一致性延迟双删、订阅 binlog 失效缓存6.6 典型读路径请求 → 本地缓存命中? → Redis 命中? → DB最后手段目标打到 DB 的 QPS 控制在 数百数千。7. 数据库读写分离 分片DB 是典型瓶颈百万 QPS 下必须 少写多读、异步写、分片存储。7.1 读写分离主库写多个只读副本读注意主从延迟读己之写用 主库读 或 会话一致性7.2 分库分表水平分片按 user_id、order_id 等 hash中间件ShardingSphere、Vitess、CitusPG跨分片查询尽量避免或走 ES/OLAP 做分析7.3 数据库选型类型场景MySQL/PostgreSQL事务型核心业务TiDB/CockroachDB分布式 SQL自动分片Cassandra/ScyllaDB超高写入、宽表DynamoDB云原生 KV自动扩展7.4 连接池应用与 DB 之间用 PgBouncer、ProxySQL避免「每个 Pod 一个连接」导致连接数爆炸8. 异步化与消息队列同步链路越长能扛的 QPS 越低。8.1 写操作异步化用户下单 → API 快速返回「已受理」→ 消息队列 → 订单/库存/支付 Worker队列Kafka、Pulsar、RocketMQKafka 单集群可达 百万级消息/秒分区扩展8.2 削峰填谷秒杀、抢购请求先入队Worker 按 DB 能力消费配合 令牌桶/漏桶限流8.3 CQRS写模型与读模型分离写走 OLTP读走 Redis / ES / 物化视图最终一致性可接受时读性能可提升一个数量级9. 限流、熔断、降级高并发下保护系统比服务所有请求更重要。9.1 多级限流全局限流网关→ 服务级限流 → 接口级限流 → 用户级限流算法令牌桶、滑动窗口实现Envoy rate limit、Sentinel、自研 Redis Lua9.2 熔断下游故障时快速失败避免级联雪崩Hystrix / resilience4j / Envoy outlier detection9.3 降级非核心功能关闭推荐、评论返回兜底数据缓存快照、默认值静态化热点页面10. 网络与基础设施10.1 带宽百万 QPS × 1KB ≈ 8 Tbps 级别 的峰值带宽需求含请求响应实际靠 CDN 边缘消化源站带宽需求小得多10.2 多地域部署Active-Active 多活用户就近接入数据多活冲突用 CRDT、最后写入胜出、或业务层规避10.3 专线与 Anycast骨干网 Anycast 将流量导向最近数据中心跨地域数据同步延迟要纳入设计11. 可观测性没有监控等于盲飞百万 QPS 下1% 错误 每秒 1 万次失败。11.1 三大支柱MetricsPrometheus Thanos/MimirRED/USE 方法LogsELK/Loki采样 结构化TracesJaeger/Tempo分布式追踪找慢点11.2 关键指标QPS、P99 延迟、错误率、饱和度缓存命中率、队列积压、DB 连接池使用率告警按 SLO 设定如 99.9% 请求 200ms11.3 全链路压测生产级压测流量录制回放、影子流量逐步加压找到第一个瓶颈点12. 安全高并发下的 DDoS 防护CDN WAF 吸收恶意流量验证码、人机校验在边缘完成SYN Cookie、连接限速13. 演进路径不要一步到位大多数系统不需要第一天就百万 QPS。建议分阶段阶段QPS 量级典型架构1 1 万单机/小集群 MySQL Redis21–10 万多实例 读写分离 CDN310–50 万分库分表 消息队列 多级缓存450–100 万多地域 边缘计算 专用基础设施每一步用 压测验证瓶颈再针对性优化避免过度设计。14. 常见误区堆机器不堆架构无状态、缓存、异步没做好加机器收益递减忽视热点少数 Key 打爆 Redis 单分片需本地缓存 热点探测同步链路过长一个请求串 10 个微服务P99 必然爆炸过度微服务化百万 QPS 下服务间 RPC 开销可观合并热点路径没有压测上线后才发现 DB 连接池、某个 JSON 序列化是瓶颈15. 总结支撑百万 QPS 的本质是边缘消化CDN 边缘计算挡住绝大部分流量水平扩展每一层无状态、可独立扩容缓存为王多级缓存让 DB 几乎不被读流量打穿异步解耦写操作走队列读走缓存限流降级宁可拒绝不可雪崩可观测 压测用数据驱动扩容和优化没有银弹只有 分层、分片、缓存、异步 的组合拳。根据业务类型读多/写多、一致性要求调整权重按流量阶段演进比一开始就追求「百万 QPS 架构」更务实。
