限流、降级与熔断机制：原理、算法（令牌桶/漏桶）、实战场景
本章节聚焦三大核心保护机制：限流（控制请求速率）、降级（牺牲非核心保核心）、熔断（自动切断故障链路）。面试官常从原理区别、算法选型、分布式实现、动态配置四个维度深挖。掌握回答框架和追问路径，是冲击高阶岗位的关键。
面试问答卡片
问题1：请解释限流、降级和熔断的区别与联系
面试官考察点：是否理解三者边界；能否用系统化视角说明协同关系；是否有实战场景认知。
回答框架：
- 定义：限流控制流量速率；降级是关闭非核心功能；熔断是自动切断故障调用链路。
- 触发条件：限流：QPS/并发超阈值；降级：资源不足、异常比例低；熔断：错误率持续升高。
- 恢复机制：限流通过令牌桶或滑动窗口自然恢复；降级手动/自动恢复；熔断需半开探测探明服务恢复。
- 协同关系：限流是第一道防线，降级是主动收缩，熔断是被动快速止损，三者结合形成多层保护。
示例回答：限流、降级、熔断都是保护分布式系统可用性的手段。限流通过令牌桶控制入口流量；降级在压力大时主动关闭非核心服务，保证核心业务；熔断类似断路器，当调用下游错误率超过阈值时断开链路，减少级联故障。恢复时，限流随时间补充令牌，降级需人工或自动恢复，熔断通过半开探测判断服务状态。三者按防御面分层配合，共同提升系统容错能力。
可能追问：
- 实际项目中如何同时配置限流与熔断？优先级如何？
- 降级策略中如何保证核心业务不受影响？
- 熔断后如何快速恢复调用链路？半开状态需要多长时间？
问题2：令牌桶和漏桶算法的原理及适用场景
面试官考察点：对经典限流算法的理解深度；是否关注算法细节（如突发处理、桶大小、更新策略）；能否结合网关特性选型。
回答框架：
- 漏桶：固定速率出水（执行），可以缓冲突发进水，但输出平滑。适用：数据库写入、消息队列消费等需要严格平滑的场景。
- 令牌桶：定时生成令牌，有令牌才放行，允许一定突发（桶内积累令牌）。适用：API网关、高并发读请求，允许短时突发。
- 对比：漏桶不关心突发，令牌桶控制平均速率且允许突发。实现上令牌桶需定时补充令牌，漏桶需定时漏出。
- 网关选择：大部分网关（如Sentinel、Guava）采用令牌桶，因为支持突发且性能好。漏桶用在需要削峰填谷的场景。
示例回答：令牌桶算法以固定速率向桶中添加令牌，请求需获取令牌才能通过，允许桶内积累令牌形成突发。漏桶算法则是固定速率从队列中取出请求执行，入队可快但出队恒定。在API网关中，令牌桶更常用，例如Sentinel默认采用令牌桶+滑动窗口，支持QPS限流和并发控制，允许短时突增流量；而漏桶适合消费有严格速率限制的场景，如写入数据库。选型时还需考虑预热、动态调整桶大小等能力。
可能追问：
- 令牌桶的“突发”是否会压垮下游？如何设置桶大小？
- 如何实现分布式令牌桶？Redis Lua脚本如何保证原子性？
- 令牌桶的补充速率是定时任务还是每次请求时计算？
问题3：在API网关中如何实现平滑限流并避免误伤正常流量？
面试官考察点：工程实践能力；是否考虑“梯度限流”“动态阈值”“用户感知”等高级话题；能否从业务角度设计限流策略。
回答框架：
- 平滑策略：采用令牌桶算法，配合“预热”使限流阈值逐步升高，避免冷启动时瞬间压垮。
- 多维限流：按API、用户、IP等维度独立统计，不同等级用户设置不同阈值。
- 动态调优：实时监控实际QPS和错误率，配置中心下发阈值，支持灰度生效。
- 兜底机制：限流时返回友好提示（如Retry-After头），结合降级策略让用户使用降级功能。
示例回答：实现平滑限流需用令牌桶预热功能，让限流阈值从低到高逐渐恢复。结合多维限流（按用户ID、API路径）不同等级分配不同配额。配合实时监控，当正常流量突增但错误率不高时，自动上调阈值；当错误率升高时下调。同时提供配置中心动态调整限流参数，避免硬编码。最后限流返回429 + 重试等待时间，并在客户端实现指数退避重试，减少对正常流量的误伤。
可能追问：
- 如何区分正常突增和恶意攻击？可结合行为分析和速率增量判断。
- 限流阈值是根据历史数据还是人工预设？如何动态计算？
- 如果在Kubernetes环境下部署，如何基于CPU/mem自适应限流？
项目案例：高并发秒杀场景下的网关限流熔断设计
| 项目名称 | 基于Kong+Sentinel的秒杀网关限流熔断系统 |
|---|---|
| 业务背景 | 电商平台大促秒杀，瞬间流量达正常峰值10倍，需保护后端订单、库存等服务 |
| 规模指标 | QPS峰值 200万，网关节点 50个，下游服务 30+，降级比例控制在5%以内 |
| 技术栈 | Kong (API网关) + Sentinel (限流熔断) + Redis (分布式计数器) + Nacos (动态配置) + Prometheus (监控) |
| 核心难点 |
|
| 面试高频追问 |
|
| 可迁移回答话术 | “我们采用Sentinel定义降级规则，当错误率超过20%时开启熔断，窗口时长30秒。同时通过Nacos配置中心下发限流阈值，运行时根据监控数据自动调整，避免了人工配置滞后。对于分布式令牌桶，我们使用Redis Lua脚本保证原子性，一个P99延迟下Lua脚本耗时<1ms，满足性能要求。” |
大厂模拟面试
面试官提问：如何设计一个支持动态配置的限流策略？请从架构、算法、实现细节三个方面说明。
候选人回答（通用）：先简单说了令牌桶，然后提到可以用配置中心下发参数，但是具体怎么刷新、怎么保证原子性没说清楚。
普通答案：使用配置中心存放QPS阈值，定时轮询更新本地限流器，关闭旧限流器创建新的。缺点：切换瞬间可能丢失请求或导致限流不准。
优秀答案：采用Sentinel的“热点参数限流”机制，将限流规则抽象为FlowRule，通过Nacos监听规则变化，sentinel内部使用CAS原子更新限流器。同时定义每个资源独立的限流器，避免全局锁。切换时采用双Buffer模式，新规则立即生效，旧规则等待存量请求处理完再释放。
专家答案：我参考了Sentinel的滑动窗口+令牌桶实现。动态配置方面，使用配置中心推送FlowRule到每个网关节点，节点内维护一个ConcurrentHashMap
面试官追问：如果配置中心推送延迟，导致部分节点限流阈值不一致，如何处理？
- 候选人的补充：引入一个协调者（如Redis）保存全局版本号，节点定时检测版本号，不一致则重新拉取。同时允许节点短时间不一致，因为限流本身是局部保护，整体错误率会在监控层面发现。