模型服务如何做限流、熔断、超时和降级？
在模型服务部署中，系统稳定性是生死线。一个推理服务如果扛不住突发流量，轻则响应缓慢，重则直接崩溃。这道题考的就是你怎么给服务装上"安全气囊"——通过限流、熔断、超时、降级这四层保护，让系统在极端情况下也能保住核心功能、不彻底宕机。
板块1：限流的核心是"控流量"
限流，就是给服务入口装个闸门，按固定速率放行请求。超过的部分要么排队，要么直接拒绝。
为什么不用"直接拒绝"这么简单的方式？ 因为突发流量可能是正常的业务增长，一刀切太粗暴。限流的精髓是：让服务按自己能承受的节奏干活，既不累死自己，也不饿死用户。
主流限流算法有四种：
固定窗口最简单，统计固定时间窗口内的请求数，超了就拒。但它有个致命问题——窗口边界会产生3倍流量冲击。比如限流100/秒，在第1秒末尾和第2秒开头集中来200个请求，都能混进去。
滑动窗口解决了边界问题，它把时间切成多个小格子，动态统计最近N秒的请求量。Redis的限流命令就用这个思路。但实现稍复杂，适合对精度要求高的场景。
漏桶算法像漏斗，不管请求多猛，出水速度恒定。好处是流量绝对平滑，缺点是突发请求得排队等，适合对稳定性要求极高的场景。
令牌桶是现在的主流选择。它按固定速度往桶里放令牌，请求来了就消耗令牌，没令牌就拒掉。关键是：桶有容量，可以攒着，所以允许适度突发。Guava的RateLimiter就是令牌桶实现。
单机限流用Guava RateLimiter就行，代码简单，性能够用。但如果你有多台机器共享限流额度，就必须用Redis做令牌桶的共享存储——每台机器从Redis原子操作获取令牌，拿到才放行。
实战配置建议：先压测测出服务能稳定承载的QPS，限流值设到80%-90%，留点余量应对正常波动。
板块2：熔断器是服务的"保险丝"
限流是防外敌，熔断是防内鬼。当下游依赖出现问题时，继续调用只会白白消耗资源，还可能拖垮自己。熔断器就是及时"断臂求生"的机制。
熔断器的核心是三种状态：
Closed状态是正常状态，所有请求正常通过。熔断器会统计失败请求数和总请求数，当失败比例超过阈值（比如50%），就切换到Open状态。
Open状态下，所有请求直接失败，快速返回错误。就像保险丝烧断，电路不通了。这个状态有个超时时间（一般几十秒），用来给下游恢复的时间。
Half-Open状态是探测阶段。超时结束后，熔断器放一个请求过去试试水。如果成功，说明下游恢复了，切回Closed；如果还是失败，说明还没好，继续Open。
类比一下：熔断器就像保险丝，电流过大烧断了，等一会儿再合上试试，还跳就继续等着。Hystrix和Sentinel都实现了这套机制，配置参数主要是：失败阈值（失败比例达到多少触发）、熔断超时（Open状态持续多久）、请求量阈值（统计基数，太少不触发）。
板块3：降级与超时是最后的防线
降级是主动放弃一些功能，保住核心链路。双十一时商品详情页不显示评价、不加载广告图，这就是降级——牺牲非核心体验，换取系统不崩。
模型服务场景的降级策略：
- 主模型响应慢，切到轻量级小模型
- 非核心推理结果返回默认值
- 关闭批量请求优化，先保证单请求响应
超时是兜底机制。请求发出去了，但等太久没响应，就直接放弃。超时设置太短容易误杀，太长等于没设。
建议配置：接口超时 = 正常响应时间 × 2 + 缓冲（比如P99是200ms，超时设400-500ms）。模型推理超时要单独设，因为模型推理本身耗时波动大。
超时和降级怎么配合？请求进来，先检查是否超时，没超就执行，执行完了再检查是否需要降级返回。核心原则是：不等死、不白等。
板块4：实际落地的工程经验
光知道原理不够，面试更想听你讲落地。
第一，限流-熔断-降级-超时是串联关系，不是选择关系。 限流在最外层拦截突发流量，熔断处理下游故障，降级牺牲非核心功能，超时防止吊死。三层配合才能形成完整保护，就像汽车的安全带+气囊+ABS，缺一不可。
第二，配置必须外部化。 不要把阈值写死在代码里，要放配置中心。流量高峰来了，你需要调参数，但不能发版。Sentinel支持运行时动态调整限流规则，很实用。
第三，重试必须有上限和指数退避。 重试是双刃剑——可以提高成功率，也会放大流量。没有上限的重试会导致重试风暴，下游本来快恢复了，被大量重试请求再次打挂。建议：最多重试2-3次，间隔用指数退避（1s、2s、4s），还要加随机抖动避免惊群。
第四，分布式限流要解决令牌桶的共享问题。 单机RateLimiter各用各的，流量会叠加超限。用Redis实现：SETNX原子获取令牌，Lua脚本保证原子性，key带时间戳做滑动窗口。
第五，监控是这一切的前提。 限流熔断降级了，你得知道。QPS、失败率、响应时间、P99这些指标要实时监控，触发阈值时要有告警。建议用Prometheus+Grafana，配置好告警规则。
面试怎么答
基础版（约150字）：
限流用令牌桶算法，单机用Guava RateLimiter，分布式用Redis原子操作实现共享。熔断器有三种状态：Closed正常放行，失败比例超阈值后Open熔断，经过超时进入Half-Open探测，下游恢复就回到Closed。降级是"丢卒保车"，关闭非核心功能保住主链路。超时配置按P99响应时间的2倍左右设置，防止单次请求拖垮整体。这四层保护要配合使用，限流在最外层拦截流量，熔断处理下游故障，降级牺牲非核心，超时兜底，三者串联形成完整保护链。
加分版（增加以下任意几点）：
- 提到熔断器要配置请求量阈值，失败次数太少不触发，避免误判
- 分布式限流用Redis+Lua脚本保证原子性
- 重试必须加指数退避和上限，避免重试风暴
- Sentinel可以动态调整限流规则，不需要发版
- 强调监控告警是前提，触发熔断降级必须能感知到
一句话总结
模型服务的高可用靠限流控流量、熔断防内鬼、降级丢卒保车、超时不吊死，四层串联配合，加上监控告警和外部化配置，才能在极端流量下保住核心链路不崩溃。