百万请求怎么网络承载？

本文目录导读：

1. 第一阶段：网络基础设施与接入层（第1-3层）
2. 第二阶段：四层与七层负载均衡（第4-7层）
3. 第三阶段：应用层与无状态设计
4. 第四阶段：缓存与数据层
5. 总结：一个典型的百万 QPS 架构图

这是一个非常经典且硬核的架构问题，首先要明确一个核心概念：“百万请求” 通常指的是 QPS（每秒查询率，Queries Per Second） 达到 100 万，而不是指一天之内总共 100 万次请求（后者平均 QPS 仅为 11.5，普通单机即可承载）。

如果目标是 单日 100 万次请求，那么平均 QPS 仅为 11.5，任何现代的单台服务器都可以轻松处理，技术挑战的核心在于 100万 QPS（每秒百万请求） 的网络承载和系统架构。

要实现这个级别的网络承载，需要从 网络基础设施、DNS/负载均衡、应用架构 和 缓存/存储 四个层面进行深度设计,以下是核心的实现路径和关键点：

第一阶段：网络基础设施与接入层（第1-3层）

这是处理百万请求的第一道门槛，主要解决两个问题：带宽和并发连接数。

1. 带宽计算与保障

   • 假设每次请求的平均响应大小为 1KB（一个简单的 JSON 响应），100万 QPS 意味着出口带宽需求约为：100万 * 1KB * 8 = 8Gbps。
   • 如果包含图片、视频或 HTML 页面（响应可能为 10KB - 100KB），带宽需求会飙升至 80 Gbps - 800 Gbps。
   • 解决方案：必须使用多线 BGP（边界网关协议）机房，接入至少 10Gbps 或 100Gbps 的物理带宽；或者使用多机房、多运营商链路进行分流。

2. 网络设备与架构

   • 交换机：使用三层交换机，配置巨型帧,提升内网传输效率。
   • 防火墙/LB（负载均衡器）：单台硬件防火墙或软件负载均衡器（如 LVS、Nginx）难以处理百万并发 TCP 连接。
   • 方案：采用 “接入层 — 负载均衡层 — 应用层” 的串联架构。
     • 硬件负载均衡器（F5 / Citrix ADC）：用于处理 SSL 卸载。
     • LVS（Linux 虚拟服务器，四层负载均衡）：四层转发，性能极高,可作为接入层入口。
     • DNS 轮询 / Anycast：通过 DNS 将流量分散到不同区域的数据中心。

第二阶段：四层与七层负载均衡（第4-7层）

单台 Nginx 或 LVS 无法处理百万 QPS,需要集群化。

1. 四层负载均衡（LVS + Keepalived）

   • 功能：直接转发 TCP 包，不解析 HTTP 内容,性能极高。
   • 方案：通过 DR（直接路由，Direct Routing）模式或 TUN（IP隧道，IP Tunneling）模式，以集群形式部署，一台 LVS 可以轻松处理几十万并发连接，对于百万 QPS，通常需要 2-4 组 LVS 集群，每组处理 25-50万 QPS。
   • 高可用：LVS 本身需要主备，通过 Keepalived 实现 VIP（虚拟 IP，Virtual IP）漂移。

2. 七层负载均衡（Nginx / OpenResty）

   • 功能：解析 HTTP 协议，进行 URL 路由、Rewrite、限流、WAF（Web 应用防火墙）等。
   • 瓶颈：单台 Nginx 即使优化到极致，QPS 通常也在 5-10万。
   • 方案：在 LVS 后面部署 Nginx 集群（规模需约 20-40 台），每台 Nginx 约处理 2.5-5万 QPS。
   • 优化技巧：
     • 开启 sendfile、tcp_nopush。
     • 调整 worker_connections 和 worker_processes 为 CPU 核心数。
     • 使用 HTTP/2 或 连接池 复用连接,减少握手开销。
     • 使用 OpenResty（Lua 脚本） 在 Nginx 层直接做缓存或限流。

第三阶段：应用层与无状态设计

这是承受压力的核心，应用服务器（如 Java、Go、Python）必须做到 无状态。

1. 应用集群化与扩容

   • 水平扩展：应用服务器（如 Tomcat、Spring Boot、Go Gin）必须是“无状态”的，Session 信息存入 Redis 或 分布式 Cache 中，这样,可以简单通过增加服务器数量来线性扩展处理能力。
   • 规模估算：假设单台 8核 16GB 的 Go/Java 应用可处理 1000-2000 QPS（经过良好优化），那么处理 100万 QPS 需要 500-1000 台 这样的应用服务器。

2. 微服务与异步化

   • 拆分服务：将一个大单体应用拆分为多个微服务（订单、用户、商品、支付），每个服务独立部署，负载均衡到自己的集群中,避免单点故障。
   • 消息队列：对于非实时请求（如日志、消息推送、订单处理），使用 Kafka / RabbitMQ / RocketMQ 进行削峰填谷，请求先进入队列，后端 Worker 慢慢消费，这可以将峰值 QPS 降低到可控水平。

3. 熔断、限流与降级

   • 限流：在网关层（如 Nginx/OpenResty）配置单 IP、单用户、或全局限流器（如令牌桶算法）,防止突发流量冲垮系统。
   • 熔断：使用 Hystrix / Sentinel 等库，当依赖的第三方服务或数据库响应变慢时，主动熔断，快速失败,避免级联崩溃。
   • 降级：在压力过大时，关闭非核心功能（如个性化推荐、动画效果、搜索引擎的次要索引）,保证核心交易流程可用。

第四阶段：缓存与数据层

数据库（尤其是关系型数据库）是百万 QPS 架构中最大的瓶颈。

1. 多层次缓存架构

   • 浏览器缓存：设置合理的 Cache-Control 和 Expires 头,让静态资源直接在客户端缓存。
   • CDN：将图片、CSS、JS 等静态资源全量分发到 CDN 节点，CDN 可拦截 80% 以上的流量，是承载百万 QPS 的基石，动态内容也可通过 CDN 边缘计算（如 Cloudflare Workers）加速。
   • 本地缓存：在应用服务器内存中缓存热点数据（如商品详情、用户信息），使用 Guava Cache、Caffeine 或 Go 的 sync.Map，命中率可达 90% 以上,极大减少对下游的请求。
   • 分布式缓存：对于无法本地缓存的大规模数据，使用 Redis Cluster 或 Memcached，百万 QPS 通常需要几十甚至上百个 Redis 分片节点。

2. 数据库读写分离与分库分表

   • 读写分离：主库负责写操作，多个从库负责读操作，可以支撑较高的读 QPS。
   • 分库分表：当单表数据量过大或 QPS 过高时，必须分库分表，将用户、订单数据按 ID 哈希或取模分布在不同的数据库集群中。
   • NoSQL 兜底：对于非结构化或高并发的数据（如日志、社交动态），使用 Elasticsearch、Cassandra、MongoDB。

一个典型的百万 QPS 架构图

[客户端/用户] 
    ↕ (HTTP/HTTPS)
[CDN 加速节点] (静态资源缓存，大幅降低源站压力)
    ↕ 
[全局 DNS 负载均衡 / Anycast] (引流到不同数据中心)
    ↓
[数据中心 1]
    ↕
[硬件负载均衡器 / F5] (SSL 卸载，基础防护)
    ↕
[LVS 四层负载均衡集群 (2组)] (无状态 TCP/包转发，高吞吐)
    ↕
[Nginx / OpenResty 七层负载均衡集群 (20-40台)] (限流、路由、缓存)
    ↓
[微服务网关 (Kong / Zuul)] (认证、限流、日志)
    ↓
[微服务集群 (数百台)]  ←→ [Redis Cluster / 本地缓存] (热点数据)
    ↓                    ↓
[消息队列 (Kafka)] ←→ [数据库集群 (MySQL分库分表 + 读写分离)]

核心要点：

1. 分层分流：从 GSLB（全局服务器负载均衡，Global Server Load Balancing）到 CDN，再到 LVS、Nginx、应用、缓存、数据库,层层过滤和分流。
2. 无状态：应用服务器不存任何本地状态，统一通过 Redis/数据库读取。
3. 最终一致性：在高并发下，放弃强一致性的完美追求，采用最终一致性（如 MQ + 补偿）。
4. 压测与监控：在任何优化之前，使用压测工具（如 wrk、Locust）模拟百万 QPS，找出瓶颈，建立完善的监控系统（Prometheus + Grafana），监控每台机器的 CPU、内存、IO、连接数。

实现百万 QPS 并非单一技术的堆砌，而是一个系统性的工程，涉及网络、系统、应用和数据的深度优化，这需要一个小型技术团队数周甚至数月的时间,对现有系统进行彻底重构。

标签： 网络负载