如何选择适合项目的「限流 / 熔断 / 降级」方案
如何选择适合项目的「限流 / 熔断 / 降级」方案
一、先分清 3 个核心概念（避免选错）
- 限流：防刷、防打爆、控制 QPS
- 熔断：依赖服务超时 / 报错太多，直接断开，防止雪崩（比如大模型接口超时、向量库卡顿）
- 降级：服务不行时，返回兜底文案、走简化逻辑
AI 项目特点：大模型响应慢、外部 API 不稳定、文件上传耗资源 →熔断 + 限流必须同时要有
二、主流方案 核心能力速览
表格
| 方案 | 限流 | 熔断降级 | 分布式集群 | 性能 | 运维成本 | 适用场景 |
|---|---|---|---|---|---|---|
| Resilience4j | ✅ | ✅ 强 | 需配合 Redis | 极高 | 低 | 单体 / 微服务通用、AI 项目首选 |
| Sentinel | ✅ | ✅ | ✅ | 高 | 中（控制台） | 阿里生态、需要可视化规则 |
| Redisson | ✅ | ❌ | ✅ | 高 | 低 | 只做分布式限流 |
| Bucket4j | ✅ | ❌ | 支持 Redis | 极高 | 极低 | 高并发纯限流、大文件上传 |
| Guava RateLimiter | ✅ | ❌ | ❌ | 极高 | 0 | 小项目、临时简单防刷 |
| Redis+Lua | ✅ | ❌ | ✅ | 高 | 极低 | 无框架、轻量自研 |
| Hystrix | ✅ | ✅ | ✅ | 低 | 高 | 老旧项目，彻底淘汰 |
三、按「项目类型」直接选型（抄作业）
1. 单体项目（你当前 RAG 项目）
✅最终推荐：Resilience4j
- 自带：限流 + 熔断 + 降级 + 超时控制
- 无中间件强依赖、轻量、Spring 官方维护
- 完美适配 AI 大模型慢接口、文档上传、向量库异常
- 不需要控制台、配置简单、注解即用
你的项目直接用这套：Resilience4j 全覆盖，完全替代 Sentinel
2. 集群 / 多实例部署（后续扩容）
✅ 组合方案：
- 熔断降级：Resilience4j（本地熔断，防单实例雪崩）
- 分布式限流：Redisson（全局统一 QPS、多节点流量统一管控）
原因：
- Resilience4j 没有原生分布式限流
- Redisson 只有限流、没有熔断
- 两者互补，企业微服务标准搭配
3. 高并发场景（大文件上传、高频问答）
✅Bucket4j
- 纯令牌桶实现，性能天花板
- 支持精细化限流、流量整形
- 适合：分片上传、批量文档解析、高频 AI 问答
4. 小型项目、内部工具、极简架构
✅Guava RateLimiter
- 零配置、几行代码搞定
- 只做简单 QPS 限制，够用、无复杂度
- 缺点：单机、不能集群
5. 极简技术栈、不想引入任何中间件框架
✅Redis + Lua 原生限流
- 无第三方组件、轻量自研
- 适合小团队、技术栈极简主义
6. 阿里生态、需要可视化动态规则
✅Sentinel
- 可视化控制台、动态改限流 / 熔断规则
- 适合中台、复杂微服务
- 缺点：阿里生态绑定、过重
四、AI RAG 项目 专属选型原则（重点）
你的业务：
- 依赖外部大模型 API（不稳定、超时多）
- 文档解析、向量化 耗 CPU/IO
- 多轮对话、长耗时接口
强制搭配规则
- 必须要有熔断→ 选 Resilience4j
- 必须要有接口限流→ 单机用 Resilience4j 自带限流，集群加 Redisson
- 大文件 / 分片上传→ 搭配 Bucket4j 做单独限流
- 禁止只用纯限流框架（Guava/Redisson/Lua），没有熔断会雪崩
五、最简选型口诀
- 单体 AI 项目→ 直接：Resilience4j
- 集群多节点→ Resilience4j + Redisson
- 高并发上传→ Bucket4j
- 小项目简单防刷→ Guava
- 不要复杂框架→ Redis+Lua
- 阿里生态要控制台→ Sentinel
六、给你固定不变的长期技术栈（直接长期用）
plaintext
熔断降级：Resilience4j（永久标配） 单机限流：Resilience4j 内置限流 分布式限流：Redisson 高并发特殊接口：Bucket4j这套组合：
- 无厂商绑定
- 性能拉满
- 维护活跃
- 适配单体 / 微服务 / AI 业务全覆盖