这几个限流算法，怎么就总是记了又忘呢？😓
- 内容介绍
- 文章标签
- 相关推荐
家人们谁懂啊！明明上周刚跟组里后端小哥一起啃完Sentinel源码里的限流模块,这周坐地铁时突然被运营问"你们系统咋防刷呀",我居然张口就来"嗯...就是那个...漏桶加饼干?"😵 我裂开了。 💫 饼干是什么鬼?哦不对!是令牌桶!天呐,这几个破限流算法怎么就跟闹着玩似的,记一次忘一次,每次想用的时候脑子跟浆糊一样——今天干脆把它们扒开揉碎了骂一遍,顺便求求自己长点记性行不?!
先从那个"傻到冒泡"的固定窗口说起吧...
记得去年刚入行时,导师扔给我一段代码:"这个接口要限每秒100次请求,自己看着改".我屁颠颠查资料,发现"固定窗口"是最简单的:定个时间窗,里面超过100次就拒接.当时觉得"这不跟小区门口门禁卡刷次数一样吗?"so easy!后来啊第一次测就炸锅: 设定阈值1秒100次,测试同学在第0.99秒疯狂点了99下,紧接着第1.01秒又点了99下——单看每个窗口期都没超,但合起来这两波请求挤在2毫秒里!直接把数据库查崩了!导师扶着我的肩膀叹气:"你这叫'给坏人留后门'知道吗?"我当时脸烫得能煎蛋...💦，站在你的角度想...
哦对!这个破算法最大的坑就是临界值问题!就像两根筷子中间夹花生,看着各管各的,实则一不留神就串在一起爆掉.后来问资深开发才知道,解 我emo了。 决办法要么加滑动窗口要么加Redis分布式计数...但Redis那延迟咋整?忘了忘了,反正当时改到凌晨三点才搞定,现在想想还想骂街.
| 那些年用过/听说过的限流组件&坑爹瞬间👀 | ||
|---|---|---|
| Sentinel | 核心算法: | 滑动窗口 - 坑:调规则时没注意"统计时长",一次设成分钟级差点把日活干到零... |
| Guava RateLimiter | 核心算法: | 令牌桶 - 坑:预热模式搞不懂,冷启动时流量突增直接GG; - "为什么每秒生成5个令牌还不够?"主要原因是老子设成QPS=5而不是每秒加5个啊傻X! |
然后是那个"看似聪明实则磨叽"的滑动窗口...
本来以为滑动窗口能解决固定窗口的临界问题,后来啊入坑更深!啥叫滑动窗口?简单说就是把大时间窗切成N个小格子,每次请求过来只算当前格子+前面几个格子的值有没有超阈值.听起来很完美对吧?，探探路。
但麻烦来了:切几格合适?!切太少等于白切,切太多性能又跟不上!上次项目里切了8格,后来啊测试说"压测时还是会偶发超流",找运维查日志才发现——原来格子切换时有毫秒级延迟!那点儿延迟堆起来刚好让第8格和第1格的数据没算进去...😡，纯正。
还有更崩溃的:有些框架默认格子数居然不能改?只能硬着头皮用? leader说"能用就行",但谁知道下次流量峰值会不会刚好卡在格子缝里啊喂!
再说说那个"闷声憋坏事儿"の漏桶算法...
如果说固定窗口是傻,那漏桶就是闷骚.记得第一次听这个词儿还以为是"漏水的 bucket"?不对不对—它是指不管外面流量多大,pou 说句可能得罪人的话... r进来之后都以固定速率慢慢流出去.比如说桶容量10个/秒流出速度—哪怕外面一秒钟砸进来100个请求,也得一个个按每秒1个排着队走.
听起来很温柔对吧?适合那种"细水长流"的场景?但特么谁家里会一直细水长流啊?!双十二零点秒杀时几万请求涌过来—漏桶装不下直接全丢?那用户不得骂到客服爆线?!而且最恶心의是:有些系统为了 "稳定",硬生生把漏桶装成限速阀—后来啊正常用户点击两次都要等半秒...投诉率直接飙升5%!🙃
哦对!还有人跟我说漏桶适合做接口防抖?狗屁!防抖要の是快速响应+拦截高频点击—漏桶装一下等半天,用户早他妈关页面了你才反应过来!，让我们一起...
再说说是那个"看似全能却总踩坑"の令牌 bucket...
共勉。 好了好了终于轮到最常用の令牌桶啦!这个应该没人不知道吧?:按固定速率往桶里塞token,请求来了先拿token—有token就走,没token要么等要么拒.完美解决突发流量对吧?主要原因是只要桶里存够token,就算一秒钟砸进来25个请求也能处理5+20=25个!
但麻烦也接踵而至: - * token生成速率怎么设?设快了不起作用; - * bucket容量多大合适?设大瞭浪费内存; - 要不要预热?冷启动时系统刚起来,token一下全发完会不会被冲垮?，大胆一点...
不忍卒读。 上个月项目上线前一天晚上改参数改到疯掉:Sprint Boot整合Guava RateLimiter时,"setRate"到底要不要带单位?为什么老子写のQPS=5跑起来像QPS=0.5一样慢?!后来翻源码才发现—默认单位居然他妈不是秒而是分钟?!当场想摔键盘!
摸个底。 昨天买奶茶排队看到店员举着牌子:"每人限购两杯!"突然想到—这不就是最原始の限流吗?!但奶茶店不限流会怎样?队伍排到马路上而已;系统不限流会怎样?服务器宕机+扣工资+背锅+领导约谈+女朋友安慰..."所以本质上我们跟奶茶店店员干の活儿一样?"一边码字一边傻笑出声被邻座小姐姐瞪瞭一眼...🤣
唠唠叨叨半天到底想说啥呢?...
最后说一句。 其实就是想骂一句:这些破算法怎么就学不会啊喂?!每次以为记住瞭转头就忘—什么「固定窗ロの临界值」「滑動窗ロの格子數」「漏捅の匀速流出」「令牌捅の產速與容量」…绕來繞去腦子裡亂糟糟嘅.
但誰讓咱們吃這碗飯呢﹖總不能每次遇到流量問題都大眼瞪小眼吧﹖算了算了﹐先把這篇東西存手機裡﹐下次再忘嘅時候﹐好歹能翻出來啐一口﹕ "娱乐這次總算記住瞭吧﹗"
家人们谁懂啊！明明上周刚跟组里后端小哥一起啃完Sentinel源码里的限流模块,这周坐地铁时突然被运营问"你们系统咋防刷呀",我居然张口就来"嗯...就是那个...漏桶加饼干?"😵 我裂开了。 💫 饼干是什么鬼?哦不对!是令牌桶!天呐,这几个破限流算法怎么就跟闹着玩似的,记一次忘一次,每次想用的时候脑子跟浆糊一样——今天干脆把它们扒开揉碎了骂一遍,顺便求求自己长点记性行不?!
先从那个"傻到冒泡"的固定窗口说起吧...
记得去年刚入行时,导师扔给我一段代码:"这个接口要限每秒100次请求,自己看着改".我屁颠颠查资料,发现"固定窗口"是最简单的:定个时间窗,里面超过100次就拒接.当时觉得"这不跟小区门口门禁卡刷次数一样吗?"so easy!后来啊第一次测就炸锅: 设定阈值1秒100次,测试同学在第0.99秒疯狂点了99下,紧接着第1.01秒又点了99下——单看每个窗口期都没超,但合起来这两波请求挤在2毫秒里!直接把数据库查崩了!导师扶着我的肩膀叹气:"你这叫'给坏人留后门'知道吗?"我当时脸烫得能煎蛋...💦，站在你的角度想...
哦对!这个破算法最大的坑就是临界值问题!就像两根筷子中间夹花生,看着各管各的,实则一不留神就串在一起爆掉.后来问资深开发才知道,解 我emo了。 决办法要么加滑动窗口要么加Redis分布式计数...但Redis那延迟咋整?忘了忘了,反正当时改到凌晨三点才搞定,现在想想还想骂街.
| 那些年用过/听说过的限流组件&坑爹瞬间👀 | ||
|---|---|---|
| Sentinel | 核心算法: | 滑动窗口 - 坑:调规则时没注意"统计时长",一次设成分钟级差点把日活干到零... |
| Guava RateLimiter | 核心算法: | 令牌桶 - 坑:预热模式搞不懂,冷启动时流量突增直接GG; - "为什么每秒生成5个令牌还不够?"主要原因是老子设成QPS=5而不是每秒加5个啊傻X! |
然后是那个"看似聪明实则磨叽"的滑动窗口...
本来以为滑动窗口能解决固定窗口的临界问题,后来啊入坑更深!啥叫滑动窗口?简单说就是把大时间窗切成N个小格子,每次请求过来只算当前格子+前面几个格子的值有没有超阈值.听起来很完美对吧?，探探路。
但麻烦来了:切几格合适?!切太少等于白切,切太多性能又跟不上!上次项目里切了8格,后来啊测试说"压测时还是会偶发超流",找运维查日志才发现——原来格子切换时有毫秒级延迟!那点儿延迟堆起来刚好让第8格和第1格的数据没算进去...😡，纯正。
还有更崩溃的:有些框架默认格子数居然不能改?只能硬着头皮用? leader说"能用就行",但谁知道下次流量峰值会不会刚好卡在格子缝里啊喂!
再说说那个"闷声憋坏事儿"の漏桶算法...
如果说固定窗口是傻,那漏桶就是闷骚.记得第一次听这个词儿还以为是"漏水的 bucket"?不对不对—它是指不管外面流量多大,pou 说句可能得罪人的话... r进来之后都以固定速率慢慢流出去.比如说桶容量10个/秒流出速度—哪怕外面一秒钟砸进来100个请求,也得一个个按每秒1个排着队走.
听起来很温柔对吧?适合那种"细水长流"的场景?但特么谁家里会一直细水长流啊?!双十二零点秒杀时几万请求涌过来—漏桶装不下直接全丢?那用户不得骂到客服爆线?!而且最恶心의是:有些系统为了 "稳定",硬生生把漏桶装成限速阀—后来啊正常用户点击两次都要等半秒...投诉率直接飙升5%!🙃
哦对!还有人跟我说漏桶适合做接口防抖?狗屁!防抖要の是快速响应+拦截高频点击—漏桶装一下等半天,用户早他妈关页面了你才反应过来!，让我们一起...
再说说是那个"看似全能却总踩坑"の令牌 bucket...
共勉。 好了好了终于轮到最常用の令牌桶啦!这个应该没人不知道吧?:按固定速率往桶里塞token,请求来了先拿token—有token就走,没token要么等要么拒.完美解决突发流量对吧?主要原因是只要桶里存够token,就算一秒钟砸进来25个请求也能处理5+20=25个!
但麻烦也接踵而至: - * token生成速率怎么设?设快了不起作用; - * bucket容量多大合适?设大瞭浪费内存; - 要不要预热?冷启动时系统刚起来,token一下全发完会不会被冲垮?，大胆一点...
不忍卒读。 上个月项目上线前一天晚上改参数改到疯掉:Sprint Boot整合Guava RateLimiter时,"setRate"到底要不要带单位?为什么老子写のQPS=5跑起来像QPS=0.5一样慢?!后来翻源码才发现—默认单位居然他妈不是秒而是分钟?!当场想摔键盘!
摸个底。 昨天买奶茶排队看到店员举着牌子:"每人限购两杯!"突然想到—这不就是最原始の限流吗?!但奶茶店不限流会怎样?队伍排到马路上而已;系统不限流会怎样?服务器宕机+扣工资+背锅+领导约谈+女朋友安慰..."所以本质上我们跟奶茶店店员干の活儿一样?"一边码字一边傻笑出声被邻座小姐姐瞪瞭一眼...🤣
唠唠叨叨半天到底想说啥呢?...
最后说一句。 其实就是想骂一句:这些破算法怎么就学不会啊喂?!每次以为记住瞭转头就忘—什么「固定窗ロの临界值」「滑動窗ロの格子數」「漏捅の匀速流出」「令牌捅の產速與容量」…绕來繞去腦子裡亂糟糟嘅.
但誰讓咱們吃這碗飯呢﹖總不能每次遇到流量問題都大眼瞪小眼吧﹖算了算了﹐先把這篇東西存手機裡﹐下次再忘嘅時候﹐好歹能翻出來啐一口﹕ "娱乐這次總算記住瞭吧﹗"