限流降级不是简单加注解，而是需结合业务、瓶颈与容错目标，分层设计、动态适配、可观测可调优：限流守入口水位，常用令牌桶（平滑+突发）、漏桶（匀速）、滑动窗口（精准统计）；降级主动舍非核心保主干，强调可配、可测、可逆；熔断则自动隔离故障依赖防雪崩，依赖状态机与接口粒度配置；落地须闭环于监控、压测与混沌演练。
高并发系统中限流降级不是“加个注解就完事”，而是要结合业务场景、系统瓶颈和容错目标，分层设计、动态适配、可观测可调优。
限流：守住系统入口水位线
限流核心是控制单位时间内的请求数量，防止突发流量压垮下游（DB、缓存、第三方接口）或耗尽线程池。常用策略有三种，选型要看精度、性能和一致性要求：
- 令牌桶（Token Bucket）：适合平滑放行+短时突发，如 API 网关层限流。Guava RateLimiter 是典型实现，单机可用；分布式场景需配合 Redis + Lua（原子扣减 token）或 Redis-Cell 模块。
- 漏桶（Leaky Bucket）：强调匀速处理，适合对响应延迟敏感的后台任务（如日志上报、异步通知），但无法应对合理突发，Java 中可用 ScheduledThreadPool + 队列模拟，生产环境较少单独使用。
- 滑动窗口（Sliding Window）：比固定窗口更精准，避免临界突刺问题。Sentinel 的 QPS 限流默认采用滑动时间窗（基于时间分片的数组+当前时间戳定位），适合统计类限流；也可用 Redis ZSet 实现带时间戳的请求记录，内存开销略高但跨节点一致。
降级：主动放弃非核心，保障主干链路
降级不是“服务挂了才降”，而是预设规则，在依赖超时、错误率飙升或系统负载过高时，自动切换为轻量逻辑（如返回缓存旧数据、兜底文案、空结果或简化计算）。关键在“可配、可测、可逆”：
- 用 Sentinel 或 Hystrix（虽已停更但仍有存量系统）定义 fallback 方法，但避免在 fallback 里再调远程服务——否则可能引发级联降级。
- 降级开关建议外置：存于 Apollo/Nacos 配置中心，支持运行时秒级生效；同时提供 HTTP 接口手动触发（如 /api/degrade/enable?resource=orderPay），便于应急。
- 对缓存降级，注意 stale-while-revalidate 模式：先返回过期缓存，异步刷新；避免大量请求穿透到 DB。
熔断：自动隔离故障依赖，防止雪崩
熔断是降级的前置保护机制，基于失败率/慢调用比例等指标自动“断开”不健康的下游，给其恢复时间。Sentinel 的熔断器状态机（Closed → Open → Half-Open）是工业级实践：
- 配置三项核心参数：统计时长（如 60s）、失败阈值（如错误率 ≥ 50%）、熔断持续时间（如 10s）。注意时长不宜过短（频繁抖动），也不宜过长（影响用户体验）。
- Half-Open 状态下只放行有限请求数（Sentinel 默认 1 个），成功则关闭熔断，失败则重置计时器——这比简单定时恢复更健壮。
- 避免对所有 RPC 调用统一熔断，应按接口粒度（如 user-service/getUserInfo）独立配置，不同依赖恢复能力差异大。
落地要点：别只靠框架，得闭环
再好的组件，脱离监控、压测和演练就是纸老虎：
- 所有限流/降级/熔断事件必须打日志（含资源名、触发原因、当前阈值），并接入 ELK 或 Prometheus + Grafana，设置告警（如“1 分钟内触发降级超 100 次”）。
- 定期做混沌工程：用 ChaosBlade 注入延迟、异常或 CPU 飙升，验证降级是否生效、日志是否完整、告警是否及时。
- 上线前务必压测：用 JMeter 或 wrk 模拟峰值流量，观察线程池堆积、Redis 连接数、DB 执行时间等指标，反向校验限流阈值是否合理（比如 DB 连接池满时，限流是否已在更上层拦截）。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
