Day10｜一次微信群裂变引发的高并发事故复盘：Nginx、接口性能

1. 前言：离“n+1”最近的一次

今天是第十天写博客。
这次要分享一次让我印象极其深刻的线上事故。现在回头看，虽然已经能自嘲“这是我离 n+1 最近的一次”，但当时的紧张和无助，真的只有亲历者才能体会。

---

2. 事故经过：微信群裂变带来的流量洪峰

事情的起因其实很“偶然”。那天我们的 APP 做了一波微信视频号的引流推广，主持人在视频号里说：“大家可以进 APP 领优惠券啦！”
我一开始还挺淡定，觉得直播间才一千多人，系统肯定扛得住。

但真正让人猝不及防的是——有工程商把这个消息转发到了多个微信群，还说“可以答题了”！
微信群的扩散能力远超预期，短短几分钟内，APP 涌入人数直接飙到 1 万，并发峰值竟然冲到了 6 万！

APP 立刻变得卡顿甚至崩溃，用户反馈如雪片般飞来，所有服务几乎全线告警，包括我负责的优惠券服务也没能幸免。

---

3. 排查过程：逐步定位瓶颈

事故发生后，我第一时间去看 RDS 数据库，发现数据库内存虽然上升，但整体还在可控范围，于是暂时排除了数据库瓶颈。

接着 ssh 上服务器，用 curl 命令测试自己负责的服务是否正常。看到返回 ok 时，心里稍微松了口气。然后又去检查网关服务，同样用 curl 确认活着没问题。那一刻还在庆幸，“n+1大礼包”应该轮不到我了。

但问题到底出在哪？继续排查，用 top 命令查看系统资源占用。终于发现——我们把三台 nginx 都部署在同一台服务器上！
高并发流量全部涌进来，三台 nginx 实例一起疯狂消耗内存和 CPU，直接把这台服务器榨干。CPU、内存全线飙红，服务器直接被拖垮。6 万人同时并发请求，这种压力下，一台服务器根本顶不住。

---

4. 接口性能也是幕后“杀手”

除了超大并发量，另一个核心问题是接口响应慢导致 Nginx 连接无法及时释放。

• 高并发下，如果后端接口能在 1 秒内快速返回，Nginx 能很快释放连接继