线上系统的危险时刻不在高并发本身，而在于"慢请求互相拖死"导致的级联雪崩。本文的核心目标是帮助你建立"可落地的并发请求隔离"体系，将拥塞限制在局部。
问题根源：慢请求如何引发雪崩
当某个依赖变慢时，请求开始堆积，引发连锁反应：线程池队列变长、连接池被占满、重试放大流量。
核心结论：并发治理的核心不是扛住所有请求，而是控制拥塞传播。
并发隔离即"给不同类型请求、不同依赖、不同资源池划边界"，使问题区域自我失败而不拖累核心链路。
六层隔离体系
第一层：入口隔离（限流）
- 限流维度：接口 / 用户 / 租户 / IP / 设备 / 全站
- 返回策略：拒绝 / 降级 / 重试
- 常见坑：全局一刀切影响核心用户
第二层：排队隔离（异步化）
- 适用场景：允许延迟的任务
- 关键要素：队列有上限、超时、丢弃策略
- 常见坑：堆积告警缺失导致队列压死DB
第三层：执行隔离（线程池分离）
- 核心接口单独线程池，非核心另起
- 配合要素：队列长度上限、任务超时、拒绝策略
- 常见坑：参数拍脑袋，压测后全乱
第四层：依赖隔离（超时 + 熔断）
- 超时分层：客户端 / 服务端 / 下游都要配
- 熔断触发：错误率、超时率、慢调用比例
- 常见坑：只熔断不降级导致体验灾难
第五层：数据隔离（缓存 / DB 保护）
- 缓存策略：防穿透 / 防击穿 / 防雪崩
- DB 保护：慢查询治理、连接池保护、读写分离
- 常见坑：只关注缓存命中率，不做 DB 压力告警
第六层：业务隔离（分级服务）
- 优先级示例：下单/支付 > 详情页 > 推荐 > 埋点
- 必备：降级开关、预案、回滚策略
8 个常见陷阱
- 仅做入口限流，忽视线程池 / 连接池隔离
- 队列无上限导致下游压力
- 超时只配一处仍无限等待
- 熔断缺少降级方案
- 线程池参数未经压测
- 重试无退避放大失败流量
- 缓存 miss 无兜底打穿 DB
- 缺乏监控闭环验证效果
落地优先级建议
第一优先级（立刻做）
- 全链路超时
- 核心接口限流
- 弱依赖熔断 + 降级
第二优先级（近期做）
- 线程池隔离
- 可异步任务队列化 + 堆积告警
第三优先级（规划做）
- 业务分级
- 数据层分仓
- 热点治理
无状态化自查清单
需要避免的本地状态依赖：
- 本地内存状态
- 本地文件依赖
- 单机缓存唯一性
- 单机定时任务
改造方向：将状态下沉到 Redis / DB / 消息系统。
监控指标清单
高并发场景下需要持续观测的 8 类关键指标：
| 指标类型 | 关注点 |
|---|---|
| 流量 | QPS / RPS |
| 延迟 | P95 / P99 响应时间 |
| 错误率 | 4xx / 5xx 比例 |
| 线程池状态 | 活跃线程数 / 队列深度 |
| 连接池占用 | 使用率 / 等待数 |
| DB 表现 | 慢查询数 / 连接数 |
| 缓存命中率 | Miss 率趋势 |
| 降级/熔断触发频率 | 触发次数 / 持续时长 |
总结
并发请求隔离不是一次性工程，而是一套需要持续运营的治理体系。从全链路超时和核心接口限流入手，逐步构建多层隔离防线，配合完善的监控闭环，才能真正做到"拥塞止于局部，核心链路无忧"。