【AI系统限流与熔断实战】一次线上崩溃教会我如何用限流熔断保护系统完整可复现方案一、问题场景真实线上事故这篇文章不是“理论”是我真实踩过的坑。系统上线第2周一个很普通的晚上流量突然上涨被某个社区转载然后接口响应从 2s → 10sCPU 直接 100%模型 API 开始返回 429限流最终整个系统不可用最关键的一点是不是高并发压垮的而是“少量异常请求”拖死的日志如下[ERROR] upstream timeout [ERROR] too many requests [WARN] retry failed排查后发现 一个用户脚本 1 秒 30 请求二、问题分析为什么系统一定会崩这个问题的本质不是“流量大”而是架构问题。1️⃣ AI系统的“慢接口”特性普通接口50ms ~ 200msAI接口2s ~ 10s 意味着请求一旦堆积 线程被占满 新请求无法处理2️⃣ 没有限流 任人攻击原始代码defchat(prompt):returnmodel.generate(prompt) 没有限制谁都可以无限请求无法区分正常用户 / 恶意用户3️⃣ 没有熔断 雪崩放大器当模型变慢请求积压超时重试更慢形成“自我放大”三、解决方案生产级设计不是简单加个 if 判断而是要设计完整防护体系入口层限流 ↓ 服务层熔断 ↓ 降级策略兜底 ↓ 模型调用四、实操步骤完整可复现✅ 步骤1实现分布式限流Redis 滑动窗口为什么不用内存 因为你一定是多实例部署限流代码可直接跑importredisimporttime rredis.Redis(hostlocalhost,port6379,db0)defrate_limit(user_id,limit10,window1):nowint(time.time())keyfrl:{user_id}:{now}countr.incr(key)ifcount1:r.expire(key,window)returncountlimit接入接口defchat(user_id,prompt):ifnotrate_limit(user_id):return{code:429,msg:请求过于频繁}returncall_model(prompt)⚠️ 为什么用“时间窗口”而不是简单计数 防止突发流量burst五、熔断机制实现核心为什么必须有熔断 当模型服务异常每个请求都在失败但系统还在不断重试 必须“主动停止调用”实现带状态机importtimeclassCircuitBreaker:def__init__(self,threshold5,timeout10):self.fail_count0self.thresholdthreshold self.timeouttimeout self.last_fail_time0self.stateCLOSEDdefcall(self,func,*args):ifself.stateOPEN:iftime.time()-self.last_fail_timeself.timeout:self.stateHALF_OPENelse:returnself.fallback()try:resultfunc(*args)self.fail_count0self.stateCLOSEDreturnresultexceptExceptionase:self.fail_count1self.last_fail_timetime.time()ifself.fail_countself.threshold:self.stateOPENreturnself.fallback()deffallback(self):return{code:503,msg:服务繁忙请稍后再试}接入调用breakerCircuitBreaker()defcall_model(prompt):returnbreaker.call(model.generate,prompt)六、降级策略很多人忽略如果你只返回错误 用户体验直接崩降级设计deffallback_response():return{msg:当前系统繁忙,tips:建议稍后重试}七、完整调用链关键defchat(user_id,prompt):# 1. 限流ifnotrate_limit(user_id):return请求过多# 2. 熔断保护resultbreaker.call(model.generate,prompt)returnresult八、验证结果压测数据压测环境100并发 / 5分钟优化前指标数值成功率60%平均响应6s错误率高优化后指标数值成功率95%平均响应2.5s错误率可控九、踩坑记录真实经验❌ 坑1限流只做单机 多实例完全失效❌ 坑2熔断没有恢复机制 服务永远不可用❌ 坑3限流粒度错误 全局限流 → 正常用户被误伤十、适合收藏核心总结✔ 三层保护体系限流 → 挡攻击熔断 → 防雪崩降级 → 保体验✔ 推荐实践用户级限流IP级限流Token级限流✔ 避坑清单❌ 不限流❌ 不做熔断❌ 不做降级❌ 不区分用户十一、总结核心认知 AI系统的本质不是“能处理多少请求”而是在极端情况下如何优雅地拒绝请求十二、进阶优化拉开差距Nginx入口限流第一道防线Sentinel企业级多级限流架构限流日志分析十三、下一篇预告 【ELK日志系统实战】如何在3分钟内定位线上问题