后端架构可靠性幂等限流熔断
AI 应用后端第一课：幂等、限流、超时与熔断怎么一起工作
Agent 系统的后端稳定性不是“加机器”能解决的：重试会放大流量、工具调用有副作用、模型推理成本高且不可控。本文给出一套可落地的稳定性基线：幂等键保证写操作可去重，分层限流保护多租户，超时预算控制端到端 p95，熔断与降级防止级联故障，并提供工程 checklist。
2026年3月4日
Synthly 团队
预计阅读 16 分钟
📷 Photo by panumas nikhomkhai via Pexels
为什么这是“第一课”：Agent 的失败会被重试放大
传统后端的稳定性问题通常来自：流量突增、慢查询、依赖挂了。
Agent 系统多了一个放大器：重试与重跑。
- 模型输出错 → 你可能重跑
- 工具超时/429 → 你会重试
- 队列重复投递 → 你会再执行
- 用户不耐烦 → 连点 + 刷新
如果你没有稳定性基线，系统会在压力下出现：
- 重复写入（副作用倍增）
- 成本失控（token、工具调用）
- 级联故障（下游被打挂）
这篇文章给一套“可直接落地”的组合拳：幂等 + 限流 + 超时预算 + 熔断/降级。
一、幂等：让写操作“重复触发也只做一次”
1）幂等不是“防重复请求”，而是“防重复副作用”
你需要优先保护的是这些动作：
- 发邮件/发短信
- 创建工单/订单
- 写入数据库状态
- 扣费/支付
这些动作一旦重复执行，很难回滚。
2）幂等键（Idempotency Key）的最小规则
- 写操作必须带
idempotencyKey - 幂等键必须与“业务意图”绑定，而不是与“请求”绑定
推荐形态：
tenantId:userId:action:resourceId:version
例如：
t1:u9:send_email:thread123:v3
3）幂等存储：你需要记住“我做过了”
常见实现：
- Redis：低延迟，适合短期幂等（分钟~小时）
- Postgres：可靠持久，适合需要审计的幂等
关键字段建议：
- key
- status（in_progress/succeeded/failed）
- result摘要（回执 id）
- createdAt/updatedAt
注意：如果你只在成功后记录，超时重试仍可能重复执行。建议先写 in_progress 再执行。
二、限流：把系统保护做成“分层”
1）三层限流（Agent 场景推荐）
- 入口限流（用户/租户）
- 防刷、防滥用
- 策略：令牌桶/漏桶
- 推理资源限流（模型）
- 控制 GPU/并发推理、token 成本
- 策略：并发上限 + 排队 + 降级模型
- 工具/下游限流
- 保护外部 API、数据库、第三方服务
- 策略：按 toolKey 限流 + 熔断
2）拒绝策略不是“直接 429”
Agent 产品更适合做“用户可理解”的拒绝：
- 入口限流：提示稍后重试
- 推理限流：排队并给出预计等待
- 工具限流：降级为草稿/只读模式/延后执行
拒绝如果不可解释，会触发用户连点与刷新，反而更糟。
三、超时：用预算管理端到端 p95
1）超时是预算，不是一个数字
把端到端超时拆成阶段预算：
- 模型推理：例如 15s
- 检索/RAG：例如 5s
- 工具调用：例如 10s（可多次）
- 合并与校验：例如 2s
总预算例如 30s。
2）重试必须“吃预算”
每次重试都会消耗预算，所以你要同时控制：
- 单工具最大重试次数
- 单工具最大累计耗时
- 任务端到端最大耗时
一个简单规则：
- 任务级
deadline优先级最高 - 工具级超时不能把任务级 deadline 吃光
3）超时后的产物策略
超时不等于“什么都不给”。更好的体验是：
- 返回部分产物（草稿/已检索到的片段）
- 明确说明下一步（继续后台执行/需要用户确认/稍后重试）
四、熔断：停止把失败传播到更多系统
1）熔断触发条件
常见触发器：
- 连续失败率超过阈值
- p95/p99 延迟飙升
- 429/5xx 占比升高
熔断的对象通常是：
- 某个外部工具（例如
gmail.send） - 某个下游服务（例如向量检索）
2）熔断后必须有降级路径
熔断不是“直接失败”，它应该触发降级：
- 写操作降级：改为生成草稿 + 等待人工确认
- 检索降级：只用缓存/只用最近结果
- 模型降级：小模型先回答 + 明确不确定性
五、把四件事串起来：一条“可恢复”的执行链
一个典型的安全执行顺序：
- 入口限流（按租户/用户）
- 创建任务记录（分配 deadline）
- 写操作前生成幂等键（写入 in_progress）
- 调用工具（带工具级限流/超时）
- 记录回执（succeeded + result摘要）
- 失败按错误类型决定：重试/降级/熔断/停止
这套顺序能把“重试放大器”变成“可控路径”。
六、上线 Checklist（后端稳定性基线）
- 幂等：所有写工具调用都有
idempotencyKey+ 结果记录 - 限流：入口/模型/工具三层限流 + 不同拒绝策略
- 超时：端到端 deadline + 阶段预算 + 重试吃预算
- 熔断：按工具/下游粒度熔断 + 自动恢复
- 降级：每个关键工具都有降级路径（草稿/只读/延后）
- 指标：失败率、重试次数、p95/p99、429 占比、幂等冲突数
常见问题
我已经有 API 网关限流了，还需要工具限流吗？
需要。网关保护的是你的入口，工具限流保护的是你的依赖。很多事故不是入口爆了，而是某个外部 API 被并发打挂引发级联。
幂等键应该由前端还是后端生成？
建议后端生成并管理（更可信、更一致）。前端可以传一个 clientRequestId 用于关联，但不要依赖它作为唯一幂等键。