Spring Boot限流降级核心是“入口控流+故障兜底”，推荐Sentinel（集成简单、可视化配置、支持持久化）、自定义注解+Redis（粒度细、响应快）、Guava RateLimiter（单机平滑限流）；降级需业务强绑定，分级兜底并真实验证。
Spring Boot 项目实现接口限流降级，核心是“入口控流 + 故障兜底”。不需要大动架构，加依赖、配规则、写简单逻辑，就能在高并发或下游异常时守住服务底线。
用 Sentinel 快速集成限流与熔断
这是目前最推荐的方式，尤其适合中大型 Spring Boot 应用。它把限流、熔断、降级、监控打包成轻量组件，无需额外部署中间件，控制台可视化配置，规则还能持久化到 Nacos。
- 引入 starter：
spring-cloud-starter-alibaba-sentinel（注意版本兼容 Spring Boot 和 Spring Cloud） - 配置 Dashboard 地址：
spring.cloud.sentinel.transport.dashboard=localhost:8080 - 启动 Sentinel 控制台（
sentinel-dashboard-1.8.6.jar或更高），访问http://localhost:8080，默认账号密码为 sentinel/sentinel - 接口打上
@SentinelResource(value = "orderCreate", fallback = "fallbackOrder")注解，其中fallback方法返回兜底数据（如空订单、缓存结果或友好提示） - 在控制台动态配置 QPS 限流规则（比如 /order/create 每秒最多 100 次），或错误率熔断规则（5 秒内失败率超 50%，触发 30 秒熔断）
用注解 + AOP + Redis 手动实现精准限流
适合对第三方依赖敏感、或只需要按 IP/用户/接口维度做简单频控的场景。不依赖外部组件，逻辑清晰，便于审计和定制。
- 定义
@RateLimit(max = 5, timeWindow = 60)自定义注解，支持按 URI+IP 或登录用户 ID 组合生成 Redis key - 用
@Aspect切入被注解的方法，在执行前读取 Redis 中当前 key 的计数器（如rate:ip:/api/user/info:192.168.1.100） - 使用
INCR+EXPIRE原子操作：首次调用设过期时间（如 60 秒），后续递增；若计数 > max，直接抛出RuntimeException并由全局异常处理器返回 429 - 优势是粒度细、响应快、无额外线程开销；缺点是不带熔断能力，需配合 Hystrix 或自定义降级逻辑补充
用 Guava RateLimiter 做单机平滑限流
适用于内部服务、低 QPS 接口或压测阶段快速验证，不依赖 Redis 或远程组件，纯内存实现，基于令牌桶算法，请求可排队等待而非硬拒绝。
- 引入
guava依赖，声明@Bean创建RateLimiter.create(10.0)（每秒 10 个令牌） - 在 Controller 或 Service 中调用
rateLimiter.tryAcquire()：返回 true 则放行，false 则返回限流响应 - 也可用
acquire()阻塞等待令牌，适合对延迟不敏感但要求不丢请求的场景（如后台任务触发） - 注意：它是单机限流，集群多实例下无法协同，不能替代分布式限流方案
降级策略要和业务强绑定
限流只是“挡”，降级才是“托”。没有兜底逻辑的限流，用户体验就是“报错”；有降级的限流，才是“稳住”。
- Feign 调用下游失败时，启用
fallbackFactory返回缓存数据或默认值（如商品详情查不到，展示历史快照） - 数据库慢查询触发熔断后，降级方法可查 Redis 缓存、本地 Map 或返回空列表，避免级联雪崩
- 前端接口降级建议分级：一级降级（返回缓存）、二级降级（返回静态页）、三级降级（返回维护提示），通过配置中心动态开关
- 所有降级逻辑必须经过真实异常路径测试，避免“写了降级却没走”的线上事故
