一、高并发概述：什么是高并发、高并发衡量指标与挑战

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

说实话，我刚开始做.NET开发那会儿，对“高并发”这三个字是又敬又怕。总觉得那是大厂才配聊的话题，咱们小项目哪用得上？直到有一次，我负责的一个活动页面，上线当天直接被用户冲垮了……嗯，那场面，至今难忘。从那以后，我才真正开始认真研究：到底什么是高并发？

1.1 什么是高并发？

高并发，说白了就是：同一时间，有大量用户同时访问你的系统。

你想想看，平时一个网站可能就几十个人在线，服务器轻轻松松。但双十一零点那一刻，几千万人同时点“结算”，这就是高并发。

我个人习惯把高并发理解成“瞬间流量洪峰”。它不是平均流量，而是峰值流量。比如一个系统平均QPS只有100，但某秒突然冲到10000，这才是要命的。

1.2 高并发的衡量指标

聊高并发，不能光凭感觉。咱们得用数据说话。我常用的三个核心指标：QPS、TPS、RT。

指标	全称	含义	我的经验
QPS	Queries Per Second	每秒查询数	最常用，衡量读接口能力
TPS	Transactions Per Second	每秒事务数	侧重写操作，比如下单、支付
RT	Response Time	响应时间	用户感知最直接，越短越好

QPS（每秒查询数）

这个指标我几乎天天看。它表示系统每秒能处理多少个请求。比如一个接口QPS是1000，意味着1秒内能响应1000次调用。

我在项目中遇到过一个问题：某个查询接口QPS上不去，一压测就卡死。后来发现是数据库连接池太小，才10个。调大到100后，QPS直接翻了5倍。你看，有时候问题就这么简单。

TPS（每秒事务数）

TPS和QPS有点像，但更强调“事务”的完整性。一个事务可能包含多个请求。比如下单：先查库存、再扣库存、生成订单、扣减余额……这一整套才算一个事务。

我记得有一次做秒杀系统，TPS死活上不去。排查后发现，每次事务都要写5张表，锁冲突严重。后来改成异步写，TPS从200飙到了2000。嗯，这里要注意：TPS优化往往要从减少锁粒度入手。

RT（响应时间）

RT是用户最直接的感受。你想想看，点一个按钮，等3秒才出结果，你什么心情？

我一般把RT分为三个等级：

• 100ms以内：用户无感知，完美
• 200ms-500ms：可以接受，但能优化就优化
• 1秒以上：必须优化，用户可能流失

1.3 高并发带来的挑战

高并发不是请客吃饭。流量一上来，各种问题就暴露了。我总结了几大挑战：

挑战一：系统崩溃

这是最直接的。流量超过系统承载上限，服务器直接挂掉。我曾经见过一个电商网站，活动刚开始10秒，所有服务器CPU飙到100%，然后……全挂了。

为什么会这样？说白了就是资源不够。CPU、内存、带宽、数据库连接，任何一个成为瓶颈，都可能引发雪崩。

挑战二：数据不一致

高并发下，数据一致性问题特别头疼。比如库存扣减：两个人同时下单，都读到库存还剩1件，都扣成了0，但实际只卖出了1件，库存却变成了-1。

我在项目中遇到过类似问题。当时用了乐观锁，但并发太高时，CAS重试次数太多，性能反而下降。后来改成Redis分布式锁，才解决了。

挑战三：响应变慢

流量一大，每个请求的处理时间都会变长。因为资源被争抢了。比如数据库连接池满了，新请求就得排队等。这一等，RT就从100ms变成了2秒。

你想想看，用户等2秒，可能就关页面了。所以高并发下，保证RT稳定，比保证QPS更重要。

挑战四：雪崩效应

这是最可怕的。一个服务挂了，导致依赖它的服务也挂了，然后像多米诺骨牌一样，整个系统全挂。

我记得有一次，一个缓存服务挂了，所有请求直接打到数据库。数据库扛不住也挂了，然后所有依赖数据库的服务全挂。最后整个系统瘫痪了半小时。

从那以后，我养成了一个习惯：所有依赖都要做降级和熔断。不能因为一个服务挂了，就拖垮整个系统。

1.4 小结

好了，这一章咱们聊了高并发的核心概念。总结一下：

• 高并发就是瞬间大量请求涌入
• QPS、TPS、RT是三个核心衡量指标
• 系统崩溃、数据不一致、响应变慢、雪崩效应是四大挑战

下一章，我会带大家深入聊聊高并发系统的设计原则。比如怎么拆分服务、怎么设计缓存、怎么保证数据一致性。这些都是我踩过坑后总结出来的实战经验，咱们下期见。