Day13｜高并发极限压测与全链路瓶颈排查：凌晨3点的“打流”实录

1. 前言：压力测试，永远比你想象的残酷

今天是写博客的第13天。
连续几天都在和高并发死磕。以为上次被冲崩后，Nginx扩容到3台、RDS升级、Redis调优，一切都能顺利应对。结果现实再次给我上了一课——系统还是在80个并发量时崩溃，距离我们承诺的160还差一大截。这一夜，我和同事们几乎“打流”到凌晨三点，终于把问题逐一揪了出来。

---

2. 问题重现：80并发就白屏，哪里出了问题？

2.1 Nginx扩容无效

我们把Nginx从1台扩到3台，本以为能抗住更大流量。可生产环境模拟打流后，前端依然在80个并发时白屏，后端接口集体挂起。
所有微服务都宕机，这显然是“公共服务”出问题了。

2.2 RDS性能怀疑

第一反应是RDS数据库瓶颈，因为阿里云监控显示偶尔有RDS CPU拉满的情况。
于是我们果断升级RDS，把核数翻倍、内存加倍。但结果让人失望——问题依旧，80并发依然崩溃，CPU间歇性飙高但很快恢复。

2.3 高并发下的请求分布分析

冷静下来后，我们统计了一下单用户链路：
一次完整流程要走20个请求，其中16个查库、4个写库。
于是我们尝试只打“读”流量，看看RDS极限是多少。结果依然是80左右的并发顶不住，这说明——RDS不是唯一瓶颈！

---

3. 进一步排查：Redis与网关

3.1 Redis最大连接数坑

接着我们把排查目标转向Redis。
阿里云Redis支持2万QPS，但监控显示峰值才4万多QPS，远没到Redis极限。但接口里却频繁报Redis超时。

深入排查后发现，校验系统最大连接数只设置了6个！
在万级并发下，6个连接完全不够用。我们把最大连接数调到500，QPS略有提升，但整体并发能力还是没明显变化。

3.2 网关与鉴权服务成新瓶颈

继续分析链路，发现所有请求都要经过网关和鉴权服务。查