一、高并发架构概述
1.1 什么是高并发
高并发，说白了就是系统在极短时间内要处理海量请求。
我经常跟团队里的小伙伴说：别把高并发想得太玄乎。你想想看，双十一零点那一刻，几亿人同时点下单按钮，这就是典型的高并发场景。再比如微博热搜爆了，瞬间几千万人刷新页面，这也是。
我个人习惯把高并发拆成两个维度来理解：
- 并发量：同一时刻有多少请求打过来
- 处理能力：系统能不能扛得住，还能正常响应
举个例子。你开了一家奶茶店，平时一分钟来3个客人，你一个人忙得过来。但突然来了100个客人，你就得加人手、加设备、优化流程。高并发架构，就是给系统「加人手、加设备、优化流程」的过程。
核心观点：高并发不是单纯地堆机器，而是让系统在高压下依然稳定、快速、不丢数据。
1.2 高并发的衡量指标
聊高并发，绕不开三个核心指标。我在面试架构师时，必问这三个概念。
QPS（每秒查询数）
QPS 全称 Queries Per Second，指系统每秒能处理的查询请求数量。
我遇到过不少刚入行的同学，把 QPS 和并发数搞混。其实很简单：
- QPS：每秒能处理多少个请求
- 并发数：同一时刻系统中有多少个请求正在处理
举个例子。一个系统同时有100个请求在处理（并发数=100），每个请求耗时50ms。那 QPS 就是 100 / 0.05 = 2000。嗯，这里要注意，并发数和 QPS 之间有个公式：
QPS = 并发数 / 平均响应时间（秒）TPS（每秒事务数）
TPS 全称 Transactions Per Second。它和 QPS 的区别在哪？
我个人习惯这样区分：
- QPS 侧重查询，比如一次页面加载、一次搜索
- TPS 侧重事务，比如一次下单（包含扣库存、生成订单、支付等多个步骤）
说白了，一个事务可能包含多个查询。比如你在电商平台下单，后台可能要查库存、查用户信息、写订单表、扣减库存……这一整套才算一个事务。
避坑指南：我曾经在压测时只看 QPS，结果上线后数据库直接被打挂了。后来才发现，TPS 才是衡量写操作压力的关键指标。读多写少的场景看 QPS，写操作频繁的场景一定要盯 TPS。
响应时间
响应时间就是用户发出请求到收到完整响应的时间。
我一般把响应时间拆成三段：
- 网络传输时间：数据在网络上跑的时间
- 排队等待时间：请求在队列里等着被处理的时间
- 服务处理时间：服务器真正干活的时间
你想想看，为什么有时候系统负载不高，但响应却很慢？大概率是排队等待时间太长了。就像你去银行办业务，柜员明明闲着，但叫号系统卡住了，你只能干等。
| 指标 | 含义 | 典型场景 |
|---|---|---|
| QPS | 每秒查询数 | 搜索引擎、内容列表页 |
| TPS | 每秒事务数 | 下单、支付、转账 |
| 响应时间 | 请求到响应的总耗时 | 所有在线系统 |
1.3 高并发带来的挑战
高并发不是请客吃饭。我做了十几年架构，踩过的坑能写一本书。这里挑几个最典型的说说。
挑战一：系统崩溃
这是最直接的。流量突然暴涨，服务器扛不住，直接宕机。
我记得有一次，某电商平台搞秒杀活动，预估流量是平时的10倍，结果实际来了30倍。数据库连接池瞬间被打满，紧接着应用服务器也挂了，最后整个站点都打不开。那次事故直接导致几千万的损失。
注意：系统崩溃往往不是瞬间发生的。它会经历一个过程：响应变慢 → 请求堆积 → 资源耗尽 → 雪崩。如果你能在这个链条的早期介入，很多事故是可以避免的。
挑战二：数据不一致
高并发下，数据一致性问题特别容易暴露。
举个例子。两个人同时买最后一张机票。在低并发场景下，A先下单，库存扣减，B再下单，发现没库存了，一切正常。但在高并发下，A和B几乎同时发起请求，两个请求都读到库存为1，都执行了扣减操作。结果呢？一张票卖给了两个人。
我曾经在项目中遇到过类似的超卖问题。排查到最后，发现是缓存和数据库之间的数据同步没做好。嗯，这里要提醒大家：高并发下的数据一致性，一定要从架构层面去保证，不能指望代码层面打补丁。
挑战三：响应变慢
系统没崩，但慢得像蜗牛。用户等得不耐烦，直接关页面走人。
响应变慢的原因很多：
- 数据库查询没加索引，全表扫描
- 缓存命中率低，大量请求穿透到数据库
- 线程池配置不合理，任务排队时间过长
- 网络带宽被打满，数据包丢包重传
我个人的排查习惯是：先看响应时间的分布。如果99%的请求都在100ms以内，但1%的请求要5秒，那大概率是慢查询或者垃圾回收（GC）导致的。如果整体都慢，那就要看系统资源是不是已经到瓶颈了。
挑战四：资源竞争
高并发下，多个请求同时争抢同一份资源，比如数据库连接、文件锁、内存空间。
你想想看，一个线程池只有100个线程，结果来了1000个请求。那900个请求只能排队等着。如果每个请求处理时间又长，那排队时间就会指数级增长。
我曾经优化过一个系统，它的数据库连接池只有20个，但业务高峰期有200个并发请求。结果呢？大部分请求都在等数据库连接，CPU利用率不到10%，但响应时间却超过10秒。说白了，资源没用好，全浪费在排队上了。
总结一下：高并发带来的四大挑战——系统崩溃、数据不一致、响应变慢、资源竞争。每一个挑战背后，都有对应的架构设计策略。后面的章节，我会逐一展开讲。
1.4 我的几点建议
课程刚开始，我想先分享几个做高并发架构的心得：
- 不要过早优化。先保证功能正确，再考虑性能。我见过太多项目，架构设计得花里胡哨，结果业务逻辑全是bug。
- 压测是必须的。不上压测，你永远不知道系统的真实水位在哪里。我曾经吃过这个亏，后来每个项目上线前，至少做三轮压测。
- 监控要到位。没有监控，高并发系统就像蒙着眼睛开车。QPS、响应时间、错误率、资源利用率，这些指标必须实时可见。
- 做好降级预案。高并发下，系统不可能永远100%可用。关键是要想清楚：当压力超过阈值时，哪些功能可以降级，哪些必须保住。
好了，第一章就到这里。下一章我会讲高并发架构的核心设计原则，包括无状态设计、缓存策略、异步处理这些实战内容。咱们下节课见。