如何选择适合项目的「限流 / 熔断 / 降级」方案

如何选择适合项目的「限流 / 熔断 / 降级」方案

一、先分清 3 个核心概念（避免选错）

1. 限流：防刷、防打爆、控制 QPS
2. 熔断：依赖服务超时 / 报错太多，直接断开，防止雪崩（比如大模型接口超时、向量库卡顿）
3. 降级：服务不行时，返回兜底文案、走简化逻辑

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
• 多轮对话、长耗时接口

强制搭配规则

1. 必须要有熔断 → 选 Resilience4j
2. 必须要有接口限流 → 单机用 Resilience4j 自带限流，集群加 Redisson
3. 大文件 / 分片上传 → 搭配 Bucket4j 做单独限流
4. 禁止只用纯限流框架（Guava/Redisson/Lua），没有熔断会雪崩

---

五、最简选型口诀

1. 单体 AI 项目 → 直接：Resilience4j
2. 集群多节点 → Resilience4j + Redisson
3. 高并发上传 → Bucket4j
4. 小项目简单防刷 → Guava
5. 不要复杂框架 → Redis+Lua
6. 阿里生态要控制台 → Sentinel

---

六、给你固定不变的长期技术栈（直接长期用）

plaintext

熔断降级：Resilience4j（永久标配）
单机限流：Resilience4j 内置限流
分布式限流：Redisson
高并发特殊接口：Bucket4j

这套组合：

• 无厂商绑定
• 性能拉满
• 维护活跃
• 适配单体 / 微服务 / AI 业务全覆盖