📚 课程目录第1章课程导入与全景认知

1. 课程导入与全景认知

我记得那是几年前的一个双十一晚上。凌晨刚过，流量瞬间暴涨，监控大屏上的数字像坐过山车一样往上窜。突然，报警声响了——订单服务超时，紧接着是连锁反应，整个交易链路都瘫了。那天晚上我们团队忙到天亮，才把系统救回来。

事后复盘时，大家讨论最多的一个词就是「高并发」。说白了，高并发不是什么神秘的概念。它就是系统在极短时间内，要处理大量同时涌进来的请求。你想想看，平时每秒几百个请求的系统，突然要扛几万甚至几十万，这中间的差距，就是我们要解决的问题。

高并发的本质：不是单纯地堆机器，而是在有限资源下，让系统能稳定、快速地处理海量请求。

做高并发设计，首先得知道怎么衡量它。我习惯用三个核心指标来判断系统的并发能力：QPS、TPS 和 RT。这三个指标就像汽车的仪表盘，缺一不可。

这三个指标之间有个微妙的关系。QPS 和 TPS 越高，RT 往往会跟着涨。为什么会这样？因为资源是有限的，请求多了，排队时间自然就长了。我在项目中遇到过一种情况：QPS 从 1000 涨到 2000，RT 从 10ms 飙到了 200ms。表面上看吞吐量上去了，实际上用户体验已经崩了。

我的建议：不要只看 QPS/TPS 的峰值，要关注 RT 的 p99（99% 请求的响应时间）。p99 能真实反映系统在压力下的表现。

高并发不是请客吃饭。它带来的挑战，我总结为四大类：

资源瓶颈：CPU、内存、网络带宽、数据库连接，哪个先扛不住，哪个就是瓶颈。我曾经见过一个系统，数据库连接池被占满，所有请求都在等连接释放，最后整个服务假死。
数据一致性：并发高了，数据竞争就来了。库存超卖、订单重复、账户扣款对不上，这些都是血泪教训。我记得有一次，因为并发扣款没做好，一个用户买了 1 件商品，结果系统扣了他 3 次钱。
系统稳定性：流量一上来，各种隐藏的 bug 全冒出来了。内存泄漏、线程死锁、缓存穿透，平时不显眼的问题，在高并发下会被无限放大。
运维复杂度：系统规模大了，部署、监控、扩容、故障恢复，每个环节都变得复杂。你想想看，几百台机器同时跑，一台出问题怎么快速定位？

避坑指南：我曾经犯过一个错误——只关注了单机的性能优化，忽略了整体架构的扩展性。结果流量翻倍时，单机优化得再好也扛不住。记住，高并发设计要从架构层面入手，不能只盯着代码细节。

说了这么多挑战，那高并发系统到底该怎么设计？我画了一张图，把核心逻辑串起来。你看完就明白了。

这张图展示了一个典型的高并发系统架构。从用户请求进来，到最终数据落地，每一层都在解决特定的问题。流量分发层负责把请求均匀地打到后端；缓存层扛住大部分读请求；业务层保持无状态，方便水平扩展；异步层用消息队列削峰填谷；数据层通过分库分表来突破单库瓶颈。

嗯，这里要注意一点：不是所有系统都需要每一层。我见过不少团队，一上来就上全套，结果复杂度把自己搞死了。高并发设计的原则是「按需引入」，先解决最痛的点，再逐步优化。

做高并发这些年，我踩过不少坑，也见过别人踩坑。这里列几个常见的误区：

误区一：高并发就是加机器。加机器确实能提升吞吐量，但如果代码有锁竞争、有状态依赖，加再多机器也没用。我曾经见过一个系统，加了 10 台机器，QPS 只涨了 20%，因为瓶颈在数据库。
误区二：缓存能解决一切。缓存确实快，但缓存穿透、缓存雪崩、缓存一致性，哪个处理不好都是灾难。我记得有一次，缓存过期时间设置不合理，导致大量请求直接打到数据库，数据库瞬间被打挂。
误区三：异步就万事大吉。异步能削峰，但会引入消息丢失、重复消费、顺序问题。你想想看，用户下单成功了，结果异步扣款失败了，这账怎么算？

核心观点：高并发设计没有银弹。每个方案都有 trade-off，你要做的是根据业务场景，找到最适合的平衡点。

这一章我们聊了高并发的定义、衡量指标和核心挑战。说白了，高并发就是一场资源与需求的博弈。QPS、TPS、RT 这三个指标，是你判断系统健康状况的「三驾马车」。而资源瓶颈、数据一致性、系统稳定性、运维复杂度，是你在设计高并发系统时必须面对的四大挑战。

接下来的章节，我会带你深入每个环节，从架构设计到代码实现，从缓存策略到数据库优化，一步步把高并发系统拆开揉碎了讲清楚。嗯，准备好了吗？我们开始吧。