一、高并发概述：到底什么是高并发？

说实话，我入行头三年，一直觉得「高并发」是个玄学词。老板说「系统要支持高并发」，我就往服务器上加机器，加完发现该崩还是崩。后来踩的坑多了才明白——高并发不是堆机器，而是让每台机器把活干得又快又稳。

咱们先给个定义：高并发，指的是系统在极短时间内，同时处理大量请求的能力。注意「同时」和「大量」这两个词——不是一天一亿次，而是同一秒内来了一万次。

1.1 高并发的三个衡量指标

我面试时经常问候选人：「你说你们系统支持高并发，拿什么量的？」很多人答不上来。其实业界就三个硬指标：QPS、TPS、并发数。咱们一个一个说清楚。

指标	全称	含义	典型场景
QPS	Queries Per Second	每秒查询数，侧重读请求	搜索引擎、商品详情页
TPS	Transactions Per Second	每秒事务数，侧重写/完整操作	下单、支付、转账
并发数	Concurrency	系统同时承载的连接/请求数	WebSocket连接、在线用户

QPS 是最常见的。比如你刷淘宝首页，每次刷新就是一个 Query。我见过很多团队把 QPS 吹上天，结果一压测发现全是缓存命中——那不算真本事。

TPS 比 QPS 更重。一次下单，要扣库存、生成订单、调用支付、发消息通知……这一串操作才算一个 Transaction。我曾在电商项目里遇到过：QPS 能扛 5 万，TPS 一上 2000 就超时。为什么？因为写操作要锁库存、要保证一致性，瓶颈全在数据库。

并发数 是另一个维度。它不关心你每秒处理多少请求，只关心「同一时刻有多少连接挂在系统上」。典型的例子是 WebSocket 长连接——聊天室 10 万人同时在线，但每人每分钟只说一句话，QPS 可能只有几百，可并发数就是 10 万。

1.2 高并发带来的四大挑战

你想想看，一秒内涌进来一万个请求，系统会出什么问题？我总结为四个字：慢、崩、错、贵。

1. 响应变慢——请求排队，CPU 打满，用户转菊花。
2. 系统崩溃——内存溢出、连接池耗尽、数据库被打死。
3. 数据错误——超卖、重复下单、状态不一致。
4. 成本飙升——机器加了一堆，钱花了不少，性能没上去。

咱们展开聊聊。

挑战一：响应变慢

这是最直观的。平时 10ms 返回的接口，并发一上来变成 2 秒。原因通常是资源争抢：线程池满了、数据库连接池满了、锁竞争激烈。我记得有一次排查线上问题，发现接口慢是因为日志框架在并发下内部加锁——写日志比处理业务还慢。

挑战二：系统崩溃

比慢更可怕的是直接挂掉。最常见的场景：缓存穿透 + 数据库打满。请求绕过缓存直接打到数据库，数据库连接池耗尽，然后所有请求都超时，最终服务宕机。我曾经在凌晨两点被电话叫醒，就是因为这个——那次之后，我养成了给所有缓存接口加布隆过滤器的习惯。

挑战三：数据错误

高并发下，数据一致性是最大的坑。典型的就是超卖：库存 100 件，同时来了 200 个下单请求，不加锁的话，最后卖了 200 件。你以为加个 synchronized 就完了？在分布式环境下，synchronized 只对本机有效——这就是为什么需要分布式锁、乐观锁、Redis 原子操作这些东西。

挑战四：成本飙升

很多团队解决高并发的方式简单粗暴：加机器。但机器不是万能的。我见过一个项目，从 10 台加到 100 台，QPS 只涨了 3 倍——因为瓶颈在数据库，加应用服务器没用。说白了，不加思考的扩容，就是烧钱。

1.3 高并发的知识体系全景图

下面这张图，是我自己梳理的高并发知识体系。整个课程都会围绕这个框架展开。你可以把它当作一张地图——学完一章，回来看看自己走到了哪里。

1.4 一个真实案例：从 500 到 50000 的蜕变

最后分享一个我亲身经历的项目。刚接手时，系统 QPS 只有 500，一到促销就挂。我们做了三件事：

• 第一，加本地缓存 + Redis，把 80% 的读请求挡在数据库外面。
• 第二，把下单流程拆成异步，用消息队列削峰。
• 第三，数据库做读写分离，主库只写，从库只读。

三个月后，QPS 稳定在 5 万，服务器只加了 4 台。你看，高并发不是靠蛮力，是靠理解每一层的瓶颈。接下来的课程，我会带你一层一层拆开这些技术——从连接池到线程模型，从缓存到限流，把每个「为什么」都讲透。