01 - 什么是高并发

在动手优化之前，先把「高并发」这三个字说清楚。很多人一上来就想「加缓存、上集群」，却说不清自己到底要优化什么。这一章帮你建立量化的认知。

一句话先记住：高并发的本质，是「有限的资源」要应付「大量同时到来的请求」。所有优化，都是在这两端做文章。

1.1 三个核心指标

评价一个系统「快不快、扛不扛得住」，就看三个数：

它们之间有个经典关系（近似）：

QPS  ≈  并发数  /  平均响应时间

举例：平均响应时间 100ms（0.1s），系统能扛住 500 个并发
     QPS ≈ 500 / 0.1 = 5000

结论：想提高 QPS，要么「降低响应时间」，要么「提高能承受的并发数」

这个公式是所有优化的出发点：优化 RT 和 优化并发承载能力，是高并发的两条主线。

1.2 高并发到底难在哪

系统的资源是有限的：CPU 核数、内存大小、数据库连接数、网络带宽……

平时请求少，资源绰绰有余，岁月静好。可一旦请求量暴涨：

        请求：10000/s 涌进来
              │
              ▼
   ┌────────────────────┐
   │   你的服务器          │
   │   CPU 100%           │  ← 算不过来
   │   连接池被占满         │  ← 排不上队
   │   内存被打满          │  ← 存不下
   └────────────────────┘
              │
              ▼
      响应变慢 → 超时 → 雪崩

难点不在「处理一个请求」，而在「同时处理成千上万个请求，还要保证每个都足够快、且系统不崩」。

1.3 优化的两个大方向

面对高并发，所有手段最终都归到这两类：

方向一：提高单机处理能力（把一台机器榨干）

让同一台机器每秒能处理更多请求。手段包括：

• 缓存：不去查慢的数据库了，直接从内存拿 → RT 骤降
• 异步化：把非核心任务丢到后台 → 主流程 RT 骤降
• 池化：复用连接 / 线程 → 省掉创建销毁的开销
• 更好的并发模型：用协程（asyncio）代替线程，单机扛更多连接

方向二：横向扩展（不够就加机器）

一台不够就多台，把请求分摊出去。手段包括：

• 负载均衡：把请求均匀分给多台应用服务器
• 读写分离：读请求分给多个数据库从库
• 分库分表：数据太大，拆到多个库多个表（见系列三）

方向一（垂直）：           方向二（水平）：
让一台更强                 加更多台

  ┌───┐                  ┌───┐ ┌───┐ ┌───┐
  │强 │        vs        │   │ │   │ │   │
  │化 │                  └───┘ └───┘ └───┘
  └───┘                    ↑ 负载均衡分流

实战顺序：先榨干单机（方向一，成本低），再考虑加机器（方向二，成本高但上限高）。别一上来就买服务器。

1.4 一个重要前提：先测量，再优化

不要凭感觉优化。没有数据支撑的优化，往往是在「优化根本不慢的地方」。

正确姿势：

1. 压测 → 找到当前 QPS 上限、慢在哪
2. 定位瓶颈 → 是 CPU？内存？数据库？还是网络？
3. 针对性优化 → 只优化真正的瓶颈
4. 再压测 → 验证有没有变好

有句名言：「过早优化是万恶之源。」 先跑起来、先测量，找到真正的瓶颈再下手。（压测与监控见第 10 章）

本章小结

下一章预告：一个请求从进来到返回，要经过网关、应用、缓存、数据库……到底每一层都可能慢在哪？我们画一张「全链路瓶颈地图」。

下一章 → 02 - 全链路瓶颈地图