Analyzes system flow, identifi…

# 秒杀502问题分析与修复方案

一、先定位：是连接池耗尽还是Redis锁超时？

502的本质：网关(Nginx)收到上游应用无响应/连接被拒，说明应用层已“堵死”。两者都可能引发，需按顺序排查。

1. 排查数据库连接池

• 活动期间抓取应用日志与Druid/HikariCP监控指标：active connections是否达到maxPoolSize、是否有大量线程阻塞在getConnection并抛出Connection is not available类异常
• 观察MySQL端：show processlist看是否存在大量活跃连接、慢SQL
• 典型特征：线程栈dump显示大量线程WAITING在获取连接处

2. 排查Redis锁超时

• 检查分布式锁（Redisson等）的tryLock等待时间设置；若未设等待上限或锁未正确释放（如业务超长持有），请求会排队堆积
• 监控Redis：slowlog、连接数、是否存在大Key或网络抖动
• 典型特征：日志出现lock acquire timeout、线程栈卡在锁获取处

3. 快速区分方法

• 压测时用jstack抓线程栈：卡在连接池获取 → DB问题；卡在Redis锁/Lua脚本调用 → 锁问题
• 两者也可能是连锁反应：锁竞争堆积 → 线程占满 → Tomcat线程池耗尽 → Nginx报502

二、修复方案

短期（止血）

• 数据库连接池：maxPoolSize设置在合理区间（一般10~30/实例），开启leakDetectionThreshold排查连接泄漏
• Redis锁：tryLock设置有限等待时间（如百毫秒级），获取失败快速返回“稍后重试”；确保锁有过期时间+看门狗续期
• Tomcat线程池与Nginx超时参数对齐，避免网关提前断开

中期（架构优化）

• 削峰：请求先进MQ异步下单，接口只做快速校验+入队，前端按钮防抖、验证码错峰
• 库存预扣减：库存放Redis用Lua脚本原子扣减，扣减成功才落库，DB只处理已过滤后的少量订单
• 锁粒度细化到商品/库存维度，或用无锁方案（Lua+异步落库+最终一致性对账）

兜底

• 限流（网关层Sentinel/Nginx limit_req）+ 熔断降级，超出容量直接返回友好提示
• 上线前全链路压测，明确系统容量水位

结论：3000 QPS下订单直连DB大概率是连接池瓶颈为主因，Redis锁配置不当会放大问题；根治靠“Redis预扣库存+MQ异步落库”，而非单纯调参数。