设计百万 QPS / 百万 TPS 系统的方法论：从“数字”走向“可落地架构”
“百万级”不是一个架构风格，而是一组可量化指标（吞吐、延迟、可用性、成本）在真实约束下的平衡结果。设计时最容易犯的错是：只盯QPS/TPS，忽略了它背后真正的瓶颈——带宽、包处理（PPS）、连接、CPU 指令预算、IOPS、fsync、锁争用、尾延迟、故障域。
1) 先定义清楚：QPS vs TPS（为什么 TPS 通常更难）
QPS（Queries Per Second）
多数情况下指请求数/秒，常见是读多写少、可缓存、可降级。
关键矛盾：入口承载 + 缓存命中率 + 尾延迟控制。
TPS（Transactions Per Second）
“事务”可能意味着：一次业务交易（含多次读写、校验、落库、提交）或数据库提交次数/秒。
难点来自“事务”的三件事：
一致性（并发冲突、幂等、顺序）
持久性（WAL/日志、fsync、复制确认）
原子性（跨表/跨服务的原子操作）
直观结论：百万 QPS 可以靠缓存把绝大多数请求“挡在源站外”；百万 TPS 代表大量“必须落盘/必须一致”的写入，更接近系统极限。
2) 设计百万级系统的总原则：分层 + 横向扩展 + 明确故障域
一个可落地的高吞吐架构通常长这样（从外到内）：
GSLB/DNS（多Region入口选择，可选） ↓ 边缘/Anycast/CDN/WAF（拦截、缓存、抗DDoS） ↓ L4 LB（高吞吐转发、连接分摊） ↓ L7 Gateway（鉴权、路由、限流、灰度、观测采样） ↓ 无状态服务层（可水平扩展） ↓ 缓存层（多级：本地 + 分布式） ↓ 写入层（日志/队列/流） ↓ 存储层（分片、复制、读写路径分离）核心思想：
入口层解决“流量进得来”
缓存层解决“后端别被打穿”
写入层解决“写扩展与一致性成本”
存储层解决“持久化与恢复”
3) 容量设计的正确姿势：先把 QPS/TPS 转成硬指标
你最终要落地的是这些指标，而不是“QPS”本身：
网络/连接
平均请求/响应大小 → 推导Gbps/Tbps
包大小与协议 → 推导PPS/Mpps
短连接 vs 长连接（HTTP/2/3）→ 推导连接数、握手 TPS
计算预算（每请求的 CPU 指令）
百万 QPS 意味着：每请求的 CPU 预算可能只有几十到几百微秒（取决于核数与并发模型）
大量 JSON 解析、加解密、日志、正则路由，都可能成为热点
存储预算（TPS 的关键）
每事务写入字节数（含索引/WAL）→写吞吐
每事务是否 fsync/复制确认 →持久性成本
热点键/热点行并发 →锁与冲突
结论：“百万”先做口径统一：请求大小、连接模型、事务定义、持久性等级、SLO（p99 延迟），否则所有“方案”都是玄学。
4) 百万 QPS 的典型架构打法（读多写少/可缓存场景）
4.1 关键指标：命中率与尾延迟
百万 QPS 成败往往取决于：
边缘/CDN 命中率（能否把 80%~99% 请求挡在源站外）
缓存层命中率（Redis/本地缓存的二次挡板）
防止缓存击穿/雪崩（尾延迟杀手）
4.2 必备机制清单
多级缓存：Local cache（Caffeine）+ Redis Cluster + CDN
热点 Key 治理：热点拆分、请求合并（singleflight）、预热
缓存策略：Cache-Aside + 逻辑过期 + 异步刷新
限流与降级：令牌桶/漏桶、按租户/接口/用户分维度限流
隔离（Bulkhead）：线程池/连接池隔离，防止级联故障
重试风暴治理：重试预算、指数退避、熔断、超时上收敛
4.3 网关与服务层的工程细节（决定你能不能真到百万）
长连接（Keep-Alive / HTTP2 多路复用）优先
避免“同步阻塞 + 大线程池”无限放大尾延迟
日志与追踪：采样，不要全量同步写磁盘
序列化：减少 JSON 大对象（字段裁剪、二进制协议视情况）
5) 百万 TPS 的典型架构打法（写多/强一致/可恢复场景）
百万 TPS 的核心矛盾不是“接入”，而是：写放大 + 持久化 + 并发冲突。
5.1 一个务实的写入链路：先“可持久”，再“可查询”
推荐把写入路径拆成两段：
写入入口（Ingest）：只做校验、幂等、限流、快速返回
持久日志（Commit Log）：Kafka/Pulsar/自研日志，按分区顺序追加
异步物化（Materialize）：消费者更新缓存/数据库/搜索索引
读模型（CQRS）：用物化视图服务查询
这套的关键收益：
TPS 的“硬承载”落在顺序追加写（最适合扩展）
业务一致性靠分区键顺序+幂等+补偿/Saga，而不是分布式事务
5.2 TPS 系统必备的“事务工程学”
幂等：Idempotency-Key、去重表、幂等写入语义（Exactly-once 不要迷信，靠工程实现）
Outbox/Inbox：事务内写 outbox，异步投递，保证“落库与发消息一致”
Saga/补偿：不要上 2PC（除非你真的愿意为一致性付巨大代价）
分区键设计：保证同一业务实体（订单/账户）落到同一分区以获得顺序与低冲突
批处理与组提交：批量写、合并 fsync、减少随机 IO
写放大控制：索引克制、日志结构存储（LSM）更友好（但读放大要用缓存对冲）
5.3 存储选型的现实边界
“百万 TPS 直写单库”一般不成立，常见落地是：
分片（Sharding）：按业务主键分片，写扩展是线性的
复制策略：异步复制提升吞吐；强一致复制提升可靠性但吞吐下降
一致性等级：明确每条写需要的 durability（本地落盘即可？需要多数派确认？）
这就是 TPS 更难的本质：你要明确“写到底要多可靠、多一致”，否则无法设计。
6) 让系统“扛得住”的最后一公里：SLO、过载与演练
百万级系统最终拼的是失效模式管理：
SLO 驱动设计：p50/p95/p99 延迟目标明确
过载保护：优雅拒绝（快速失败）、排队上限、背压（Backpressure）
降级预案：返回缓存、返回近似值、只读模式、延迟写
压测方法：阶梯加压 + 长稳压 + 混沌注入（网络抖动/节点故障）
观测体系：RED/USE 指标 + Trace 采样 + 日志结构化与采样
7) 两套“参考架构”对照（建议你用来写方案/画图）
A) 百万 QPS（读多）
CDN/边缘缓存（优先）
L4/L7 网关集群
多级缓存（本地 + Redis）
DB 只承接“缓存未命中”的少量请求
强化：热点治理、击穿/雪崩、限流降级
B) 百万 TPS（写多）
Ingest 层快速校验 + 幂等
Commit Log（分区追加写）承接 TPS
异步消费者物化到多种读模型（缓存/OLTP/ES）
Saga/补偿保证跨服务一致性
强化：分区键、组提交、写放大控制、重放与恢复
一个直接的落地建议（架构师视角）
如果你目标是“业务百万级”，优先把系统设计成：
读：尽可能缓存化；写：尽可能日志化（追加写）。把“强一致事务”限制在最小边界（单分片/单聚合根），其余用最终一致 + 可补偿。