服务雪崩是资源耗尽引发的级联失效，需通过紧急限流、手动熔断、降级响应立即止损；结合线程堆栈、日志时间戳、连接数等指标定位首爆点；再分层验证网关、缓存、数据库健康度；恢复后须分级设超时、业务线程池隔离、加固缓存策略并加入主动健康探测。
高并发下服务雪崩不是单点故障，而是资源耗尽引发的级联失效。处理核心不是“修某个接口”，而是快速切断故障传播链、释放阻塞资源、定位根本瓶颈。
一、立即止损：切断雪崩链路
雪崩发生时，首要目标是阻止恶化，而非深挖根因：
- 紧急限流：在网关（如 Nginx 或 Spring Cloud Gateway）层对异常路径（如 /api/order）启用硬限流，例如每秒 50 请求，防止下游持续被压垮；
- 手动熔断：通过配置中心（如 Apollo、Nacos）或运维脚本，临时关闭非核心依赖（如积分服务、通知服务），减少线程占用和远程调用；
- 降级静态响应：对可接受弱一致性的接口（如商品详情页的推荐模块），直接返回缓存兜底数据或空结果，避免穿透调用。
二、快速定位首爆点与阻塞源
不靠猜，靠指标交叉验证：
-
查线程堆栈：用
jstack [PID] > dump.txt抓取当前线程快照，重点搜索WAITING或BLOCKED状态，看是否大量线程卡在数据库连接获取（getConnection）、Redis 响应等待或下游 HTTP 调用上； -
比对时间戳：同步查看 Nginx
error.log中首次出现upstream timed out的时间，和应用日志中第一条TimeoutException或Connection refused的时间是否吻合——吻合点即为雪崩起点； -
确认资源瓶颈：执行
ss -tnp | grep :8080 | wc -l查当前 ESTABLISHED 连接数，对比max_connections和worker_connections × worker_processes，若接近上限，说明连接池或 Nginx 连接资源已耗尽。
三、分层验证依赖健康度
排除“假雪崩”——很多看似后端崩溃，实为反代或中间件配置失当：
-
绕过网关直连：用
curl -w "%{http_code} %{time_total}\n" http://[后端IP]:8080/health批量测试各实例，确认是否真不可用，还是 Nginx 重试机制放大了问题； -
检查缓存层：登录 Redis，运行
INFO stats查rejected_connections和expired_keys是否突增；运行KEYS *（仅开发环境）或SCAN辅助判断是否存在大量 Key 同时过期（缓存雪崩典型特征）； -
验证数据库：执行
SHOW PROCESSLIST，看是否有大量Waiting for table metadata lock或长时间Sleep连接；查慢查询日志，确认是否因某条 SQL 拖垮整个连接池。
四、恢复后必须补上的防线
雪崩平息后，只重启服务远远不够，需加固薄弱环节：
-
超时必须分级设置：HTTP 调用超时 ≤ 数据库查询超时 ≤ 缓存操作超时，且全部显式声明（不能依赖框架默认值），例如 Feign 客户端设
readTimeout=2000，Druid 连接池设connectionProperties=druid.stat.mergeSql=true;druid.stat.slowSqlMillis=1000； -
线程池按业务隔离：不要共用 Tomcat 公共线程池，为不同依赖（如支付、库存、风控）分配独立线程池，并设合理队列长度与拒绝策略（建议使用
CallerRunsPolicy避免丢请求）； - 缓存策略加固：热点 Key 加随机过期时间（±2–5 分钟），空值也缓存（防穿透），关键数据加本地缓存（Caffeine）作二级保护；
-
加入主动健康探测：在服务启动后，定时调用下游
/health，连续失败 N 次自动触发熔断，而不是等第一次请求失败才反应。
