一、高并发概述：到底什么是高并发？
先问个问题：你心里对「高并发」的定义是什么？
很多人一上来就说「QPS 十万、百万」，其实这有点片面。我个人的理解是——高并发不是数字游戏，而是系统在单位时间内能稳定处理大量请求的能力。说白了，就是你的服务扛不扛得住。
我记得刚入行那会儿，带我的老大哥跟我说过一句话，我一直记到现在：「高并发不是测出来的，是设计出来的。」当时不太懂，后来踩了坑才明白。
1.1 高并发的本质
高并发，本质上是一个资源竞争的问题。
你想想看，同一时刻，成千上万个请求涌进来。CPU 要抢、内存要抢、数据库连接要抢、网络带宽也要抢。谁抢到了，谁就先被处理。抢不到的，要么排队等，要么直接超时。
所以，高并发优化的核心思路就两条：
- 减少资源竞争——比如用无锁设计、用读写分离
- 提升资源利用率——比如用连接池、用异步非阻塞
核心观点：高并发优化的本质，是在有限资源下，通过合理的架构设计和代码实现，让系统吞吐量最大化、响应时间最小化。
1.2 高并发的衡量指标
聊高并发，离不开三个核心指标：QPS、TPS、RT。这三个指标，我建议你刻在脑子里。
| 指标 | 全称 | 含义 | 我的经验 |
|---|---|---|---|
| QPS | Queries Per Second | 每秒查询数，衡量读请求的吞吐量 | 最常用的指标，但容易被缓存命中率「骗」 |
| TPS | Transactions Per Second | 每秒事务数，衡量写请求或完整业务链路的吞吐量 | 支付、下单场景必看，比 QPS 更真实 |
| RT | Response Time | 响应时间，从发请求到收到响应的总耗时 | 用户感知最直接的指标，没有之一 |
这里有个坑，我必须要说——别只看平均值。
我曾经接手过一个项目，RT 平均值只有 50ms，看起来挺漂亮。结果一查 TP99（99% 的请求都在这个时间内完成），好家伙，直接飙到 2 秒。为什么？因为有少量慢请求把平均值拉低了，但实际用户体验已经崩了。
避坑指南：衡量 RT 时，一定要关注 TP90、TP99、TP999 这些分位值。平均值会骗人，分位值不会。
1.3 三个指标之间的关系
QPS、TPS、RT 不是孤立的。它们之间有一个经典的公式：
系统吞吐量（QPS/TPS） ≈ 并发线程数 / 平均响应时间（RT）这个公式怎么理解？我举个例子：
- 假设你的服务有 100 个线程同时处理请求
- 每个请求平均耗时 200ms
- 那么你的 QPS ≈ 100 / 0.2 = 500
你看，想提升 QPS，要么增加线程数，要么降低 RT。但线程数不是无限加的——线程多了，上下文切换的成本就上来了，RT 反而会变长。这就是高并发优化里最常见的跷跷板效应。
小技巧：我个人习惯在做性能压测时，先固定线程数，观察 RT 的变化；再固定 RT 目标，调整线程数。这样能快速找到系统的「甜蜜点」。
1.4 高并发带来的挑战
高并发不是请客吃饭。流量一上来，各种问题就冒出来了。我列几个最常见的：
1.4.1 资源耗尽
数据库连接池被打满、线程池队列溢出、内存 OOM……这些我都遇到过。最惨的一次，线上数据库连接数飙到 2000+，直接把库给拖死了。
1.4.2 缓存雪崩与穿透
缓存失效的瞬间，大量请求直接打到数据库。我见过一个案例，缓存 key 同时过期，数据库瞬间被打到 CPU 100%，服务直接挂了半小时。
1.4.3 服务雪崩
一个服务挂了，依赖它的服务也跟着挂，像多米诺骨牌一样。我记得有一次，订单服务超时，导致支付服务线程池被占满，然后整个交易链路都瘫痪了。
1.4.4 数据一致性问题
高并发下，并发写操作很容易导致数据不一致。比如库存超卖、重复下单。我曾经在电商项目里，就因为并发扣库存没加锁，一夜之间多卖了 500 件商品——嗯，那个月的绩效就别提了。
1.5 高并发知识体系总览
下面这张图，是我自己梳理的高并发优化知识体系。你可以把它当成整个课程的地图：
1.6 我的几点建议
课程刚开始，我想先给你打打预防针：
- 别迷信「银弹」——没有一种技术能解决所有高并发问题。缓存、消息队列、读写分离……每个工具都有它的适用场景。
- 先度量，再优化——我见过太多人上来就改代码，结果改了半天，瓶颈根本不在那儿。先搞清楚瓶颈在哪，再动手。
- 高并发是系统工程——从架构到代码，从数据到运维，每个环节都可能成为瓶颈。这也是为什么我把知识体系画成四个方向——你得有全局视野。
好了，第一章就到这里。记住这三个指标：QPS、TPS、RT。后面的每一章，都会围绕它们展开。