1. 高并发系统概述：什么是高并发、高并发的衡量指标、高并发带来的挑战

大家好，我是你们的老朋友。今天咱们正式开课，聊聊高并发。

说实话，我做了十几年后端，见过太多系统在流量洪峰面前瞬间崩塌的场景。有一次凌晨三点，我还在线上紧急扩容，那滋味，真不好受。所以，理解高并发，是每个后端工程师的必修课。

1.1 什么是高并发？

高并发，说白了就是系统在同一时刻要处理大量请求。

你想想看，双十一零点，几亿人同时点下单按钮。或者微博上某个明星突然爆出大瓜，粉丝们疯狂刷新。这些场景，就是典型的高并发。

但要注意，高并发不是简单的「人多」。它有三个核心特征：

• 短时间内大量请求涌入——不是慢慢来，是一窝蜂
• 系统资源争抢激烈——CPU、内存、数据库连接，大家都在抢
• 响应时间要求苛刻——用户可没耐心等，几秒没反应就跑了

我个人习惯把高并发系统比作一个繁忙的十字路口。车多、速度快、还不能出事故。怎么设计红绿灯、怎么规划车道，就是我们要解决的问题。

1.2 高并发的衡量指标

光说「高」不行，得量化。业内常用的指标有三个：QPS、TPS、RT。

1.2.1 QPS（Queries Per Second）

每秒查询数。它衡量的是系统一秒内能处理多少个请求。

举个例子，你的首页接口QPS是1000，意味着每秒有1000个用户同时访问首页。我在项目中遇到过，QPS从500涨到2000，数据库连接池直接被打满，那叫一个惨。

QPS的估算公式很简单：

QPS = 总请求数 / 总耗时（秒）

比如，1小时内处理了360万请求，那平均QPS就是：

3600000 / 3600 = 1000 QPS

1.2.2 TPS（Transactions Per Second）

每秒事务数。它和QPS很像，但更强调「事务」的完整性。

一个事务可能包含多个请求。比如下单操作，需要扣库存、生成订单、更新用户余额。这一整套才算一个事务。

我建议你记住这个区别：

指标	含义	典型场景
QPS	每秒查询数	读操作、查询接口
TPS	每秒事务数	写操作、下单、支付

1.2.3 RT（Response Time）

响应时间。从用户发出请求到收到完整响应，这中间的时间。

RT通常看两个值：

• 平均RT——所有请求的平均耗时
• TP99——99%的请求都在这个时间内完成

为什么TP99比平均值更重要？

嗯，这里要注意。平均值容易被极端值拉低。比如100个请求，99个1ms，1个10s，平均RT才100ms，看起来不错。但那个10s的用户早就骂娘了。

TP99能真实反映大多数用户的体验。我一般会盯着TP99看，超过500ms就要报警了。

1.3 高并发带来的挑战

高并发不是请客吃饭。它带来的挑战，我掰着手指头数给你听。

1.3.1 性能瓶颈

这是最直接的。请求一多，系统哪里都慢。

• CPU打满——计算密集型任务扛不住
• 内存溢出——缓存、对象创建太多
• 磁盘IO卡死——日志写得太频繁
• 网络带宽占满——数据包太多，网卡扛不住

我曾经遇到过一个案例，业务高峰期，日志框架没控制好，每秒写几百MB日志，直接把磁盘IO打满了。业务请求反而被阻塞。你说冤不冤？

1.3.2 数据一致性问题

高并发下，数据很容易乱。

比如两个人同时抢最后一个库存。两个请求都读到库存为1，都去扣减。如果没有锁机制，库存就变成-1了。

这就是经典的「超卖」问题。我建议你记住：并发越高，数据一致性越难保证。

1.3.3 系统可用性下降

高并发下，系统更容易出故障。

• 雪崩效应——一个服务挂了，拖垮整个链路
• 死锁——多个线程互相等待，谁也动不了
• 资源耗尽——线程池、连接池全部占满

你想想看，一个电商大促，如果商品服务挂了，订单服务、支付服务、物流服务全跟着遭殃。这就是典型的雪崩。

1.3.4 运维复杂度飙升

系统规模一大，运维就头疼。

• 监控难——几十个服务，几百个指标，看不过来
• 排查难——一个慢请求，到底是哪个环节的问题？
• 扩容难——加机器不是万能的，有些瓶颈在代码层面

我记得有一次线上故障，排查了整整一个通宵。最后发现是Redis的一个key没设置过期时间，内存越积越多，最终导致缓存雪崩。从那以后，我养成了给每个缓存key设置TTL的习惯。

1.4 总结

好了，这一章的内容就这些。我们来捋一捋：

• 高并发就是大量请求同时涌入，系统要扛得住
• QPS看查询量，TPS看事务量，RT看响应速度
• 挑战来自性能、一致性、可用性、运维四个方面

下一章，我会带你深入分析高并发系统的设计原则。说白了，就是怎么从架构层面把这些挑战一一化解。

咱们下节课见。