高并发限流降级需基于系统承载力、脆弱点和用户容忍度做科学取舍：先用qps×rt测算真实并发，压测确定各环节阈值；分网关、服务、资源三层限流；按业务优先级实施可配置降级；熔断与限流协同，区分429限流与下游5xx/超时触发熔断。
高并发下的限流降级策略，不是堆组件、也不是调个参数就完事，核心是围绕“系统能扛多少、哪里最脆弱、用户能接受什么损失”做有依据的取舍。设计得当，系统在流量翻倍时仍可平稳运行；设计失当，可能把正常请求拦在外面，或让降级变成全线崩溃。
先摸清底数：用QPS×RT算出真实并发压力
很多团队一上来就配RateLimiter限1000 QPS，却没算过自己服务的真实承载能力。关键公式必须用：并发数 = QPS × 平均RT（秒）。比如下单接口目标5000 QPS、平均耗时150ms，那系统同一时刻要处理750个活跃请求。这个数字决定了线程池大小、连接池上限、甚至是否需要前置排队。压测不是可选项——必须测出数据库写入TPS、Redis吞吐拐点、下游接口超时率突增阈值，再反推各环节限流值。
分层限流：网关、服务、资源三道闸门
单点限流容易失效，要像修水坝一样层层设防：
- 网关层：用Nginx limit_req 或 Spring Cloud Gateway 做全局QPS/IP级限制，拦截恶意刷量和爬虫，避免脏流量进内网
- 服务层：用Guava RateLimiter（Bursty模式）或Sentinel对核心接口限流，例如商品详情页读QPS限8000，下单接口限2000，超限时快速返回兜底数据（如缓存中的旧价格、默认库存文案）
- 资源层：数据库连接池maxActive设为实际压测值+20%，线程池coreSize按CPU核数×2配置，避免因资源耗尽引发雪崩
降级要有明确优先级和开关机制
降级不是“把非核心功能关掉”，而是按业务影响排序，保留主干链路：
- 支付场景中，“订单创建”必须可用，“物流轨迹查询”可降级为静态提示
- 内容平台中，“首页Feed流”必须可用，“评论点赞”可降级为禁用按钮+灰度文案
- 所有降级开关必须接入配置中心（如Apollo/Nacos），支持毫秒级生效，人工开关+自动触发双通道——比如下游接口错误率＞50%持续30秒，自动触发降级；大促前夜运维手动开启“用户中心”只读降级
熔断与限流协同，避免误伤健康服务
限流管“我能不能接”，熔断管“我该不该调”。两者配合才能防雪崩：
- 对下游依赖（如用户中心、风控服务）单独配置熔断规则：10秒内失败5次即熔断，熔断期2分钟，期间所有调用直接返回预设降级结果，不发网络请求
- 熔断恢复需半开状态：熔断期满后放行少量请求试探，成功则关闭熔断，失败则重置计时器
- 注意别把限流错误当成熔断信号——限流返回的是429，而下游超时/5xx才是熔断依据
