同一套压测场景，滑动窗口和令牌桶在突发流量下的延迟分布差了一个数量级
同一套压测条件下，令牌桶 P99 延迟仅 23ms，滑动窗口却飙到 310ms。核心差异在于滑动窗口的刚性时间边界导致请求周期性积压，而令牌桶的连续令牌发放避免了“一刀切”延迟。压测数据、根因分析和 Lua 脚本实现均证实，突发流量场景下令牌桶的延迟分布远优于滑动窗口。
标签: #滑动窗口
共 3 篇文章
线上缓存雪崩了三次，我们靠自动识别热点 Key 和动态分散才把这事摁住
面对频繁的热点 Key 引发的缓存雪崩，团队构建了一套自动化解决方案。通过客户端采样与 Flink 基线偏离度算法，能在 20 余秒内自动识别热点。识别后，系统会动态计算副本数并分散读请求，同时利用 Keyspace 通知异步同步数据，保证最终一致性。此外，还加入了客户端限流、分片熔断和本地缓存三重兜底，实现了对业务透明的热点防护。
客户端多模型并发：用滑动窗口 + 令牌桶扛住速率限制
多模型并发调用 API 时，单纯用 sleep 无法解决限流问题。文章提出三层速率控制方案：先区分并发上限（用信号量）和速率上限（用令牌桶），再用滑动窗口防止突发流量。核心是令牌桶控制平均速率，滑动窗口限制瞬时并发，两者组合才能稳定扛住 API 限流。针对多模型、TPM 限制和 429 响应，分别给出独立限流器、加权令牌桶和自适应降速的实现方法。