-
限流算法完全指南:从一次"固定窗口在临界点放进双倍流量、服务被打挂"看懂四种限流
2023 年我做一个对外开放的 API 服务。为了不被人滥用产品要求给每个用户限流每分钟最多 100 次请求超了就拒绝。第一版我做得很直接用一个计数器记下这一分钟这个用户调了多少次到 100 就拒绝等下一分钟计数器清零重新开始数。本地一测很完美一分钟内连发 100 次正常第 101 次准确地被拒掉。我心里很踏实限流不就是数个数嘛。可上线之后服务还是三番五次地被某些用户打到过载监控上的请求曲线时不时…- 0
- 0
-
接口限流完全指南:从一次"活动一开服务就被瞬时流量冲垮"看懂限流算法
2021 年我维护一个电商下单服务,平时流量平稳,我从没为它能扛多少操过心。直到运营搞了一场大促,海报一推送出去,大量用户在同一分钟涌进来抢购,我盯着监控看着请求量像火箭一样窜起来,然后服务就崩了。不是变慢是直接崩:接口大面积超时,数据库连接被瞬间占满,实例被一个个判定不健康踢出负载均衡,被踢掉的实例那份流量又分摊到剩下的实例上,一场标准的雪崩。我第一反应是加机器,可扩容要时间等新实例起来高峰早过…- 0
- 0
-
限流算法完全指南:从一次"促销把数据库打挂"看懂固定窗口、滑动窗口、令牌桶
2022 年我负责一个商品详情接口,平时扛得很轻松。直到一次运营促销,流量几十倍涌入,响应时间从几十毫秒飙到几秒,大面积超时,整个服务雪崩——不只是这个接口,同服务里别的功能全挂了。问题不是流量本身,是我的服务对"一瞬间涌进多少请求"毫无防备。我加了个固定窗口计数器每秒限 1000,本地完美,下一次促销系统还是被打出问题。我一直以为限流就是数个数够了就拒绝,真相是限流是一整套关…- 0
- 0
令牌桶
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×