Day12｜高并发下的真实考验：微服务、IO链路与我的“妥协之路”

1. 前言：以为万无一失，现实却啪啪打脸

今天是写博客的第12天。
本以为上次直播事故后，经过一轮Nginx扩容、前端静态资源上CDN，系统终于能扛住大流量了。谁知道，这次又被现实狠狠上了一课……

---

2. 事故重现：高并发下的链路失控

事情发生在昨晚直播期间。我们的答题页面有个“提交答案领券”的按钮，用户答完题点击就能领取优惠券。这个流程在测试环境、甚至小范围试点时都一点问题没有。然而在直播引流、高并发场景下，各种问题集中爆发：

2.1 防抖缺失，重复提交

前端和后端都没做防抖，用户连续点击“提交”按钮，每点一次就插入一条答题记录。短时间内，数据库竟然多了大量重复数据，直接导致后续业务混乱。

2.2 券生成与业务链路过长

原先的业务流程是这样的：

1. 答题模块给出分数
2. 前端拿到分数，再请求优惠券模块
3. 优惠券服务内部判断分数能领多少钱的券，并返回券ID
4. 前端根据券ID跳转到详情页

乍一看很合理，但在高并发下漏洞百出：

• 券表和归集表数据不一致，统计口径对不上
• 券生成校验链路复杂，响应时间变长
• 前端页面一直转圈圈，用户体验极差
• 网络IO太多，链路太长导致脏数据频发

2.3 系统资源被榨干

• Redis连接数爆满，直接报超时异常
• MySQL CPU利用率高达180%，持续2分钟才恢复
• 峰值过后，系统才慢慢降温，但脏数据已经产生

---

3. 技术复盘：设计失误与经验教训

3.1 链路越长，风险越大

之前因为两个人分别开发答题和领券模块，所以分成了两个微服务。每个请求都要经过前端、网关、Nginx、两个后端服务，多次网络IO。
在高并发下，每多一次网络跳转，都是一次性能和稳定性的损耗。

3.2 一致性与性能的两难

• 想用分布式事务（feign+事务）保证一致性？接口超时更严重。
• 想提前批量生成优惠券再update？依然会有数据一致性风险。
• 最终只能在一致性和性能之间反复权衡。

3.3 防抖和幂等必不可少

高并发场景下，防抖/幂等不是“可选项”，而是必须项。不然各种重复提交、数据脏写分分钟让你怀疑人生。

---

4. 折中的解决方案：为需求妥协，为稳定让步

最后，我们做了如下调整：

1. 基础设施升配

   • Redis最大连接数从6调到500
   • MySQL线程数提升
   • 整体服务升配

2. 链路收敛，业务合并

   • 优惠券模块迁移到答题项目里，所有操作在同一个服务内完成
   • 前端只需发一次“提交答案”请求，后端内部串行处理所有逻辑
   • 极大减少了网络IO和链路长度

3. 压力测试与优化

   • 在生产环境模拟高并发流量进行压测
   • 针对链路瓶颈做专项优化

4. 防抖与幂等实现

   • 前后端都加了防抖机制
   • 后端接口增加幂等校验，避免重复写入

这样做的效果：

• Nginx和网关压力显著降低
• 网络IO次数减少
• 用户体感响应速度提升明显
• 数据一致性问题得到缓解

但也有新的思考：

“把两个微服务合成一个工程，这还叫微服务吗？”

确实不那么“优雅”了，但在当前业务压力和团队能力下，这样的折中，是最务实的选择。

---

5. 成长感悟：纸上谈兵到实战落地

这次事故让我明白，高并发场景下的技术挑战远比想象中复杂。很多架构理念只有真正在生产环境踩过坑、掉过坑，才能真正理解其背后的取舍。

开发的尽头，其实就是不断做折中，不断为业务稳定性、性能和开发效率寻找平衡点。