-
我给接口加了限流、限定每分钟最多 600 次以为稳了,大促时下游服务还是被瞬间打爆雪崩,我反复确认限流配置数字没错、监控里平均 QPS 也没超百思不得其解,最后才发现是我用的固定窗口计数器在每分钟切换那一瞬间放进了两倍流量的深度复盘
我的服务前面挡着一层限流:统计每分钟进来多少请求、超过 600 个就拒绝、下一分钟清零重数,我对它很放心。可大促当晚下游连接池瞬间被占满、超时、连锁雪崩,而限流明明开着。我盯监控,每分钟请求量几乎都贴着 600 的线没哪分钟超过,拒绝计数也在涨说明它确实在拦,可下游就是被打爆了。我怀疑下游容量缩水、怀疑配置被改大,都没有。直到把被打爆那一刻精确到秒的请求时间戳拉出来按秒画图才倒吸凉气:某一分钟最后…- 0
- 0
-
限流算法完全指南:从一次"促销把数据库打挂"看懂固定窗口、滑动窗口、令牌桶
2022 年我负责一个商品详情接口,平时扛得很轻松。直到一次运营促销,流量几十倍涌入,响应时间从几十毫秒飙到几秒,大面积超时,整个服务雪崩——不只是这个接口,同服务里别的功能全挂了。问题不是流量本身,是我的服务对"一瞬间涌进多少请求"毫无防备。我加了个固定窗口计数器每秒限 1000,本地完美,下一次促销系统还是被打出问题。我一直以为限流就是数个数够了就拒绝,真相是限流是一整套关…- 0
- 0
滑动窗口
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×