目标：支持百万 QPS 的后端服务

• QPS = Queries Per Second，每秒请求数
• 百万 QPS = 1,000,000 请求/秒 —— 是一个非常高的并发量（如抖音、淘宝首页、微信红包等场景）
• C 端服务 = 面向终端用户，要求低延迟、高可用、强体验、高稳定性

整体架构设计原则

在开始设计之前，牢记几个核心原则：

分层解耦 —— 不同职责分层处理，便于扩展和维护
水平扩展 —— 所有层都支持横向扩容（无状态优先）
缓存优先 —— 尽可能命中缓存，减少数据库压力
异步解耦 —— 耗时操作异步化，提升响应速度
降级容灾 —— 故障时有降级方案，保障核心链路可用
监控告警 —— 全链路可观测，快速定位问题

分层架构设计（Layered Architecture）

我们将系统按职责分为多个层次，每一层都可以独立扩展和优化：

1
2
3

[客户端] → [CDN] → [接入层] → [业务逻辑层] → [数据访问层] → [数据存储层]
                         ↑
                    [缓存层、消息队列、配置中心等中间件]

客户端层（Client）

• 用户通过 App/Web/H5 访问服务
• 优化点：
• 客户端缓存（如 LocalStorage、图片缓存）
• 请求合并、懒加载、预加载
• 接口降级（如网络差时展示本地缓存数据）
• 埋点监控用户体验（FPS、首屏时间、错误率）

CDN + 静态资源层

• 静态资源（JS/CSS/图片/视频）全部走 CDN
• 作用：
• 减轻源站压力
• 提升用户访问速度（就近节点）
• 支持百万 QPS 的静态请求
• 优化：
• 文件压缩（Gzip/Brotli）
• 文件名哈希 + 强缓存（Cache-Control: max-age=31536000）
• 使用 HTTP/2 或 HTTP/3 提升并发效率

接入层（API Gateway / 负载均衡）

• 负责流量接入、路由、认证、限流、日志、WAF
• 技术选型：
• Nginx / OpenResty（高性能反向代理）
• API 网关：Kong / APISIX / 自研网关
• 核心能力：
• 负载均衡（轮询、一致性哈希、最少连接）
• TLS 终止（HTTPS 卸载）
• IP 限流、用户级限流（如令牌桶）
• 熔断降级（如返回兜底数据）
• 灰度发布、AB 测试路由

💡 示例：10 台 Nginx 机器，每台支撑 10 万 QPS → 总计 100 万 QPS 接入能力

业务逻辑层（微服务集群）

• 无状态服务，部署在 K8s 或容器集群中，可无限横向扩展
• 技术栈：
• Python 框架：FastAPI（高性能异步）或 Go（如 Gin）更佳（Python 在超高并发下可能成为瓶颈）
• 服务注册发现：Consul / Nacos / Eureka
• 配置中心：Apollo / Nacos
• 优化点：
• 异步非阻塞处理（async/await + Uvicorn + Gunicorn）
• 连接池复用（DB、Redis、RPC）
• 本地缓存（如 LRU 缓存热点数据）
• 接口幂等设计（防重复提交）
• 上下文透传（TraceID、用户身份）

💡 单个 Python 服务实例约支撑 5K10K QPS（视业务复杂度），百万 QPS 需 100200 个实例 + 自动扩缩容（HPA）

缓存层（Cache Layer）—— 性能关键！

• 80%~95% 的请求应在缓存层命中，避免打到数据库
• 分层缓存策略：

1

客户端缓存 → CDN缓存 → 本地缓存（进程内） → 分布式缓存（Redis集群）

• Redis 使用策略：
• 集群模式（Redis Cluster）或代理模式（Codis/Twemproxy）
• 热点 Key 探测 + 本地缓存（如 Guava / Caffeine）
• 缓存穿透：布隆过滤器 or 缓存空值
• 缓存击穿：互斥锁（mutex key）或逻辑过期
• 缓存雪崩：随机过期时间 + 多级缓存
• 数据一致性：延迟双删、Binlog 监听（Canal）+ 消息队列更新缓存

💡 Redis 单节点约支撑 10 万 QPS，百万 QPS 需 10+节点集群 + 读写分离 + 分片

数据访问层（DAO / ORM / 数据库中间件）

• 业务层不直接访问 DB，通过 DAO 或 ORM（如 SQLAlchemy）或数据库中间件（如 ShardingSphere）
• 优化：
• SQL 优化、索引覆盖、慢查询监控
• 连接池（如 DBUtils、SQLAlchemy Pool）
• 读写分离（主库写，从库读）
• 分库分表（水平拆分用户 ID、订单 ID 等）

数据存储层（Database）

▶ 关系型数据库（MySQL / PostgreSQL）

• 读写分离：1 主 N 从，从库承担读流量
• 分库分表：
  • 按用户 ID 哈希分 128 库，每库 32 表 → 支持海量数据
  • 中间件：ShardingSphere、Vitess、MyCat
• 优化：
  • 主从同步延迟监控（Seconds_Behind_Master）
  • 半同步复制 or 无损复制（增强数据一致性）
  • 归档历史数据（冷热分离）

💡 单 MySQL 实例支撑约 1K~5K QPS（复杂查询更低），百万 QPS 需数百从库 + 分库分表

▶ NoSQL（Redis / MongoDB / ES）

• Redis：缓存 + 热点数据（前面已讲）
• MongoDB：文档型，适合灵活结构（如用户画像、日志）
• ES：搜索、聚合分析（如商品搜索、行为日志分析）

异步与消息队列层（削峰填谷、解耦）

• 非核心链路异步化，如：
  • 用户行为埋点 → Kafka → Flink 实时计算
  • 发送通知 → MQ → Worker 异步消费
  • 订单创建后扣库存 → 异步最终一致性
• 技术选型：
• Kafka：高吞吐、顺序性、持久化（适合日志、事件流）
• RabbitMQ：低延迟、复杂路由（适合任务队列）
• 保障：
• 消息幂等消费（唯一 ID + 去重表）
• 死信队列 + 人工干预
• 消费积压监控 + 自动扩容消费者

服务拆分（微服务化）—— 解决复杂度与扩展性

• 单体架构无法支撑百万 QPS，必须按业务域拆分服务：

1
2
3
4
5

用户服务（User） → 认证、资料、权限
商品服务（Item） → 商品详情、库存、价格
订单服务（Order） → 下单、支付、状态机
推荐服务（Rec） → 千人千面、算法召回
活动服务（Promo） → 秒杀、优惠券、抽奖

• 拆分原则：
• 单一职责、高内聚低耦合
• 独立部署、独立数据库（避免分布式事务）
• 通过 RPC（gRPC / Dubbo）或 HTTP API 通信
• 治理能力：
• 服务注册发现、熔断限流（Sentinel / Hystrix）
• 链路追踪（SkyWalking / Jaeger）
• 配置管理、日志集中收集（ELK / Loki）

监控 & 运维 & 自动化

• 没有监控的系统 = 裸奔
• 必备能力：
• 全链路监控（请求量、延迟、错误率）
• 日志收集（ELK / Loki + Grafana）
• 告警（Prometheus + AlertManager + 企业微信/钉钉）
• 自动扩缩容（K8s HPA 根据 CPU/内存/自定义指标）
• 压测常态化（定期全链路压测，如使用 JMeter/Locust + 影子库）

关键技术选型参考（Python 生态为主）

注意：纯 Python 在百万 QPS 场景下可能成为瓶颈，可考虑：

• 核心服务用 Go / Rust 重写
• Python 服务做 BFF（Backend For Frontend）层，聚合下游 Go 服务
• 使用 Cython / PyPy 加速关键路径

总结：百万 QPS 架构设计 checklist