无需登录 数据私有 本地保存

API速率限制模拟器 - 滑动窗口与令牌桶

后端 开发工具 API 模拟 算法 速率限制
66
0
0
0

⚡ API 速率限制模拟器

对比 滑动窗口 与 令牌桶 两种限流算法 · 相同请求流，不同表现

窗口时间跨度
窗口内允许的上限
令牌生成速度
最大令牌存储量
滑动窗口 就绪
0 / 100 当前窗口请求数
总请求
0
通过
0
拒绝
0
令牌桶 就绪
100 / 100 当前令牌数
总请求
0
通过
0
拒绝
0
请求日志 （最近50条）
# 时间 滑动窗口 令牌桶 备注
等待请求...
常见问题与知识点
滑动窗口算法如何工作？
滑动窗口维护一个时间窗口（如60秒），只统计窗口内的请求数量。当新请求到达时，先移除窗口外的旧请求记录，再检查当前计数是否超过阈值。窗口随时间不断"滑动"，过期请求自动失效。这种算法严格限制窗口内的请求密度，但对突发流量容忍度较低。
令牌桶算法如何工作？
令牌桶以固定速率生成令牌存入桶中（最多不超过桶容量）。每个请求需要消耗1个令牌才能通过。如果桶中有足够令牌，请求立即通过；否则被拒绝。这种算法允许短期突发流量（桶中积蓄的令牌可一次性消耗），同时长期平均速率受令牌生成速率限制。
滑动窗口 vs 令牌桶：核心区别是什么？
滑动窗口：严格限制任意时间窗口内的请求总数，适合需要精确控制的场景。突发流量容易被拒绝。
令牌桶：允许一定程度的突发（桶容量作为缓冲），对短期流量尖峰更友好。长期平均速率依然可控。
简单理解：滑动窗口是"刚性"限制，令牌桶是"弹性"限制。
什么是突发流量？为什么令牌桶能更好地处理？
突发流量指短时间内大量请求集中到达。令牌桶可以在流量低谷时积蓄令牌（最多到桶容量），在突发时一次性消耗这些令牌，从而平滑处理尖峰。滑动窗口没有"积蓄"机制，窗口内的请求计数一旦达到上限就会拒绝后续请求，即使之前流量很低。
如何选择合适的限流算法？
• API网关/反向代理：滑动窗口更直观，便于用户理解配额
• 微服务内部限流：令牌桶更灵活，允许服务处理短期波动
• 需要精确QPS控制：令牌桶配合合适容量可实现精确限速
• 需要简单透明：固定窗口或滑动窗口更易解释
桶容量和令牌速率如何配合调优？
桶容量决定了最大突发大小。例如速率10个/秒、容量100个，意味着可瞬间处理100个请求（消耗所有令牌），之后每秒恢复10个。一般建议容量 = 速率 × 预期最大突发秒数。容量过小则退化为严格限速，过大则可能失去限流意义。
🔧 相关工具