一文整理：并发请求隔离的常见误区与最佳实践
线上系统最危险的时刻，往往不是“并发变高”，而是某个环节开始变慢后，慢请求互相拖死：线程池被占满、连接池被打满、下游依赖超时，最后演变成级联雪崩。
很多同学第一反应是“扩容/加机器”，但在 1–3 年阶段更该补的，是一套可落地的并发请求隔离：把拥塞关在局部，不让它扩散到全站。
这篇我用“全景图 + 落地顺序 + 自查清单”的方式，把限流、排队、熔断、降级、线程池隔离、无状态化串成一条可执行路线，照着做就能明显提升稳定性与抗压能力。
01 为什么“并发高”不致命，“互相拖死”才致命
并发本身不是原罪。可怕的是：当某个依赖变慢（数据库、第三方接口、缓存 miss、磁盘 IO），请求开始堆积，随后引发连锁反应：
- 线程池队列越堆越长 → 请求等待时间暴涨
- 连接池被占满 → 新请求拿不到连接
- 上游重试/客户端重试 → 流量进一步放大
- 最终：原本健康的接口也被拖垮（“全站抖动”）
结论一句话：并发治理的核心不是“扛住所有请求”，而是“控制拥塞传播”。
02 并发隔离到底在隔离什么？（一句话讲清）
并发隔离 = 给不同类型的请求、不同依赖、不同资源池划边界。
让慢的、重的、不稳定的那部分“自己慢/自己失败”，不要把核心链路一起带走。
你可以把隔离理解成：
- 给系统装“隔离舱门”（限流/熔断/超时）
- 给资源划“不同车道”（线程池/连接池/队列分离）
- 给业务定“优先级”（核心链路先活）
03 并发治理 6 件套：从入口到资源层的全景图（重点收藏）
下面这 6 类，从外到内覆盖“入口 → 执行 → 依赖 → 数据 → 业务优先级”。（截图中提到的限流、队列、优雅降级、服务标签/策略、自定义执行器等，我都在这里做了工程化重排。）
3.1 入口隔离：限流（保护系统上限）
你要回答 3 个问题：对谁限？限多少？限了怎么办？
要点清单：
- 限流维度：接口/用户/租户/IP/设备/全站
- 返回策略：直接拒绝（429）/返回降级数据/引导重试（带抖动）
- 保护对象：线程池、DB、第三方依赖（谁最脆弱就先护谁）
常见坑：全局一刀切，把核心用户/核心链路也限掉。
3.2 排队隔离：队列/异步化（削峰填谷）
适用场景：允许延迟的任务（通知、报表、风控、异步计算等）。
要点清单：
- 队列不是“万能蓄水池”，要有：最大长度、超时、丢弃/降级策略
- 消费端要做：幂等、重试退避、死信队列（别把重试变成二次洪峰）
常见坑：只上队列不做“堆积告警”，最终“队列把 DB 压死”。
3.3 执行隔离：线程池/执行器隔离（防止互相抢资源）
当一个服务里同时有“快接口”和“慢接口”，最容易互相拖死。
要点清单：
- 核心接口单独线程池（小而稳），非核心接口另起线程池（可被挤压）
- 配合：队列长度上限 + 任务超时 + 拒绝策略（不要无限排队）
- 自定义执行策略/执行器：把“不同工作负载”拆到不同资源池里
常见坑：线程池越拆越多，参数拍脑袋，压测一来全乱。
3.4 依赖隔离：超时 + 熔断（防止下游把你拖死）
对外部接口、弱依赖、抖动依赖，一定要把“等待”限制住。
要点清单：
- 超时要“分层”：客户端/服务端/下游都要有（别只配一个地方）
- 熔断触发：错误率、超时率、慢调用比例
- 熔断后必须有：降级返回（兜底数据/默认值/缓存结果）
常见坑：只熔断不降级 → 用户体验仍然灾难。
3.5 数据隔离：缓存/DB 保护（别让热点打穿）
热点与缓存 miss 往往是并发事故的导火索。
要点清单：
- 缓存策略：防穿透/防击穿/防雪崩（核心是“保护 DB”）
- DB 保护：慢查询治理、连接池保护、读写分离/限速、关键表优先
常见坑：只做缓存命中率，不做“DB 压力阈值告警”。
3.6 业务隔离：分级服务（核心链路优先活）
并发上来时，“所有功能都可用”几乎不现实，你需要优先级。
要点清单：
- 分级示例：下单/支付 > 详情页 > 推荐 > 埋点/画像
- 必备：降级开关（可灰度）、降级预案、回滚策略
- 目标：核心链路在高压下仍可用（哪怕功能变少）
常见坑：没有预案，事故来了只能“硬扛”。
04 最容易踩的 8 个坑（很多人限流了还是崩）
- 只做入口限流，不做线程池/连接池隔离
- 排队无上限，队列堆积把下游压死
- 超时只配一个地方，链路仍然会“无限等待”
- 熔断后没降级，用户体验直接崩盘
- 线程池参数拍脑袋，没压测没校准
- 重试无退避，失败时把流量放大
- 缓存 miss 没兜底，热点直接打穿 DB
- 没有监控闭环：你根本不知道隔离有没有生效
05 落地顺序：先做哪 3 个最值？（1–3 年后端照着做）
如果你资源有限，建议按这个顺序落地（投入产出比最高）：
第一优先级（立刻能救命）
- 全链路超时（至少：入口/服务内调用/下游依赖）
- 核心接口限流（保护线程池与 DB）
- 弱依赖熔断 + 降级兜底
第二优先级（提升抗压上限）
- 线程池隔离：核心/非核心分池
- 可异步的全部队列化（并补齐堆积告警）
第三优先级（体系化治理）
- 业务分级与开关化降级
- 数据层分仓/保护阈值、热点治理
06 无状态自查：你的服务到底能不能水平扩？
快速自查清单（任意命中一条，就要警惕）：
- 是否把请求态数据放在本地内存/静态变量（重启/扩容就丢）
- 是否依赖本地文件作为状态（多实例一致性难保证）
- 是否把“本地缓存”当唯一来源（多实例数据漂移）
- 是否依赖单机定时任务保证一致性（扩容后重复执行/漏执行）
改造方向：
把状态下沉到 Redis/DB/消息系统，并补齐幂等；服务实例尽量做到“可随时替换”。
07 监控指标清单：怎么判断隔离真的生效？（闭环）
建议至少看这 8 类：
- 流量：QPS、突增速率
- 延迟：P95/P99、超时数
- 错误：5xx、依赖错误率
- 线程池：活跃线程数、队列长度、拒绝次数
- 连接池：占用率、等待时间
- DB：慢查询数、CPU/IO、锁等待
- 缓存：命中率、热点 key、回源量
- 降级/熔断：触发次数、恢复次数、受影响接口
新闻搜索
