一、高并发概述：什么是高并发、衡量指标与核心挑战
说起高并发，很多刚入行的同学第一反应就是「很多请求同时打过来」。这个理解没错，但太粗糙了。我做了十几年后端，见过太多系统在流量高峰时「崩」得莫名其妙。说白了，高并发不是简单的「人多」，而是一种系统在极短时间内处理海量请求的能力。
举个例子。双十一零点，几亿用户同时点「结算」。你的系统能不能扛住？扛住了，响应时间会不会从 50ms 变成 5s？这就是高并发要解决的问题。
1.1 高并发的三个核心衡量指标
我面试时经常问候选人：「你怎么衡量一个系统的高并发能力？」很多人张口就是 QPS。其实不够。你得看三个维度。
| 指标 | 全称 | 含义 | 我常用的关注点 |
|---|---|---|---|
| QPS | Queries Per Second | 每秒查询数，衡量系统吞吐能力 | 读多写少的场景，比如商品详情页 |
| TPS | Transactions Per Second | 每秒事务数，衡量完整业务处理能力 | 下单、支付这类写操作，一个事务可能包含多次查询 |
| RT | Response Time | 响应时间，从发请求到收到响应的耗时 | 我习惯看 TP99，而不是平均值 |
你可能会问：「这三个指标怎么配合着看？」嗯，我举个例子。假设你的系统 QPS 到了 10000，但 RT 从 50ms 飙到了 2s。这说明什么？系统已经过载了，请求在排队。这时候只看 QPS 是没意义的——用户感知到的就是「卡死了」。
1.2 高并发带来的四大挑战
我在项目中踩过不少坑。每次流量上来，问题就暴露了。总结下来，高并发主要带来四个方面的挑战。
挑战一：资源竞争与锁冲突
这是最直接的。多个线程同时写同一个数据，不加锁就乱套，加了锁又变串行。我曾经维护过一个库存系统，高峰期 Redis 的分布式锁争抢导致大量超时，最后不得不改成乐观锁 + 重试机制。
- 数据库行锁：热点行更新，比如秒杀库存，行锁竞争能把 CPU 打满
- 分布式锁：Redis 锁、ZooKeeper 锁，锁的粒度越粗，性能越差
- 内存锁：synchronized、ReentrantLock，锁的范围要尽量小
挑战二：系统过载与雪崩
流量超过系统承载上限时，不会慢慢变慢，而是直接崩溃。更可怕的是雪崩——一个服务挂了，依赖它的服务也跟着挂，像多米诺骨牌一样。
挑战三：数据一致性问题
高并发下，保证数据一致性变得极其困难。尤其是分布式系统，CAP 定理摆在那里——你不可能同时满足一致性、可用性和分区容错性。
- 库存超卖：两个请求同时读到库存为 1，都扣减成功，结果库存变成 -1
- 重复下单：用户手抖点了两次提交，幂等性没做好，生成了两笔订单
- 缓存与数据库不一致：先删缓存再更新 DB，中间有并发读，读到旧数据
挑战四：资源瓶颈与成本
高并发意味着高资源消耗。CPU、内存、网络带宽、磁盘 IO，任何一个成为瓶颈，系统都跑不快。而且，资源不是无限的——加机器能解决问题，但成本也上去了。
我见过一个团队，为了抗住双十一流量，直接买了 3 倍的服务器。结果流量过去后，资源闲置了半年。说白了，高并发优化的本质，是用最少的资源，扛住最大的流量。
1.3 高并发知识体系总览
下面这张图是我自己梳理的高并发优化知识体系。你可以把它当作整个课程的地图。后面每一章，都会围绕其中一个方向展开。
1.4 一个真实案例：从 500 QPS 到 5000 QPS
我几年前接手过一个订单查询服务。刚接手时，单机 QPS 只有 500，RT 平均 200ms。用户反馈「查个订单要转半天」。
我做了什么？
- 加缓存：热点订单数据放到 Redis，读请求直接走缓存，QPS 到了 1500
- 优化 SQL：加了联合索引，把全表扫描改成索引覆盖，RT 降到 50ms
- 异步化：非核心字段用异步线程加载，主流程只返回必要数据
- 限流：接入 Sentinel，设置 QPS 阈值 5000，超过的请求直接返回「稍后再试」
最终单机 QPS 稳定在 5000，RT 控制在 80ms 以内。你看，没有用什么黑科技，就是把这四个方向挨个优化了一遍。
1.5 本章小结
高并发不是玄学。它有三个明确的衡量指标：QPS、TPS、RT。它带来四个核心挑战：资源竞争、系统雪崩、数据一致、资源成本。而优化的方向，就是围绕架构、缓存、并发控制、存储这四个层面展开。
后面的章节，我会逐一深入每个方向。你想想看，如果现在你的系统突然流量翻 10 倍，你能扛住吗？