第十四天：高并发场景下的系统故障复盘与性能调优

这里是我的第十四天博客，也是一次特殊的总结。过去两天没有更新，因为我们经历了一场“硬仗”，对高并发场景下的系统做了深度排查和性能调优。这次复盘不仅是对技术问题的梳理，更是对团队协作、系统设计和个人成长的一次全面反思。三次压力测试都完美通过了，但并发量只有30，远低于预期，这个现象让我困惑了许久。经过链路分析，终于找到了原因：微服务间feign-client连接数太保守，导致请求堆积，表面上看并发很高，实际却被“卡脖子”了。调整参数后，请求流畅分发，并发量也变得平稳。这是一次宝贵的性能调优经验，也是一次真实的问题分析和事后复盘。

今天这篇博客，我会从故障发生、排查过程、团队应对、技术优化、经验总结和未来展望几个维度，完整复盘整个流程。希望能给正在做高并发架构的小伙伴们一些启发，也欢迎大家留言交流。

---

一、背景介绍：为什么要做高并发测试？

我们项目是一个直播+答题+领券活动系统，用户在App中参与答题，答完题后可以领取优惠券。活动期间，主播会在直播间引导用户进入App参与答题抢券。由于业务模式决定了瞬时流量极大，后端系统需要承受高并发压力。

以往我们的测试环境流量有限，生产环境也没有遇到过极端并发。但随着业务规模扩大，直播活动成为常态，我们必须提前验证系统在高并发下的表现，确保关键链路不会成为瓶颈。

这次压力测试的目标很明确：

• 验证系统在百人、千人级别并发下的稳定性
• 找出各环节的性能瓶颈
• 优化链路设计，提升整体体验
• 为后续更大规模活动做技术储备

---

二、第一次压力测试：前端卡顿的“假象”

1. 测试场景与预期

第一次压力测试是在上周二晚上进行。我们团队信心满满——直播间有1000个用户在线观看，预估并发不过百来号人。毕竟以往的数据也没超过这个量级。

19点45分，主播一声令下：“大家快去App答题领券！”瞬间流量涌入，我们全员待命，准备迎接挑战。

2. 故障现象

结果出乎意料：App首页出现严重卡顿，甚至白屏，页面资源加载