-
我给接口加了限流、限定每分钟最多 600 次以为稳了,大促时下游服务还是被瞬间打爆雪崩,我反复确认限流配置数字没错、监控里平均 QPS 也没超百思不得其解,最后才发现是我用的固定窗口计数器在每分钟切换那一瞬间放进了两倍流量的深度复盘
我的服务前面挡着一层限流:统计每分钟进来多少请求、超过 600 个就拒绝、下一分钟清零重数,我对它很放心。可大促当晚下游连接池瞬间被占满、超时、连锁雪崩,而限流明明开着。我盯监控,每分钟请求量几乎都贴着 600 的线没哪分钟超过,拒绝计数也在涨说明它确实在拦,可下游就是被打爆了。我怀疑下游容量缩水、怀疑配置被改大,都没有。直到把被打爆那一刻精确到秒的请求时间戳拉出来按秒画图才倒吸凉气:某一分钟最后…- 0
- 0
-
我给接口加了"每分钟最多 100 次"的限流,结果它还是在某个瞬间被 200 次请求打穿了,我对着固定窗口限流的临界问题排查了大半天的复盘
给核心接口加限流保护,用了最直观的固定时间窗口算法——每分钟一个计数器超100就拒绝,以为每分钟最多100稳了。可一次流量高峰系统还是被打出问题,查监控发现诡异现象:某时间点附近一小段时间内接口竟处理了近200次,远超每分钟100。对着限流代码反复看计数器没错阈值也是100怎么放进200个?排查大半天才理解固定窗口限流隐蔽的临界问题(边界突刺):在两个窗口交界处可放进近2倍请求——某分钟后30秒来…- 0
- 0
-
限流算法完全指南:从一次"限了每分钟一万却涌进两万"看懂固定窗口、滑动窗口、漏桶与令牌桶
2021 年我做一个对外开放的 API 谁都能调所以得防着被刷不能让某个调用方一秒钟打几千个请求把我的服务和数据库拖垮怎么挡住这种过量调用这件事我没多想就有了方案数个数第一版我做得很顺手我做了一个计数器每分钟开头清零每来一个请求就加一一旦这一分钟的计数超过设定的上限后面的请求就全部拒绝本地一测真不错我心里很笃定限流不就是数个数嘛数到上限就拒绝可等这个 API 真正上线面对真实世界里花样百出的调用方…- 2
- 0
-
限流算法完全指南:从一次"固定窗口在临界点放进双倍流量、服务被打挂"看懂四种限流
2023 年我做一个对外开放的 API 服务。为了不被人滥用产品要求给每个用户限流每分钟最多 100 次请求超了就拒绝。第一版我做得很直接用一个计数器记下这一分钟这个用户调了多少次到 100 就拒绝等下一分钟计数器清零重新开始数。本地一测很完美一分钟内连发 100 次正常第 101 次准确地被拒掉。我心里很踏实限流不就是数个数嘛。可上线之后服务还是三番五次地被某些用户打到过载监控上的请求曲线时不时…- 0
- 0
-
接口限流完全指南:从一次"活动一开服务就被瞬时流量冲垮"看懂限流算法
2021 年我维护一个电商下单服务,平时流量平稳,我从没为它能扛多少操过心。直到运营搞了一场大促,海报一推送出去,大量用户在同一分钟涌进来抢购,我盯着监控看着请求量像火箭一样窜起来,然后服务就崩了。不是变慢是直接崩:接口大面积超时,数据库连接被瞬间占满,实例被一个个判定不健康踢出负载均衡,被踢掉的实例那份流量又分摊到剩下的实例上,一场标准的雪崩。我第一反应是加机器,可扩容要时间等新实例起来高峰早过…- 0
- 0
-
限流算法完全指南:从一次"促销把数据库打挂"看懂固定窗口、滑动窗口、令牌桶
2022 年我负责一个商品详情接口,平时扛得很轻松。直到一次运营促销,流量几十倍涌入,响应时间从几十毫秒飙到几秒,大面积超时,整个服务雪崩——不只是这个接口,同服务里别的功能全挂了。问题不是流量本身,是我的服务对"一瞬间涌进多少请求"毫无防备。我加了个固定窗口计数器每秒限 1000,本地完美,下一次促销系统还是被打出问题。我一直以为限流就是数个数够了就拒绝,真相是限流是一整套关…- 0
- 0
令牌桶
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×