面试官逼问10WQPS高并发如何限流？别慌！实战派工程师的避坑指南

大家好，欢迎来到IT知识分享网。

“系统崩了，扣你绩效！”——这是每个程序员最怕听到的话。去年双十一，我们团队就因为漏桶算法的一个参数配置失误，眼睁睁看着服务器在5分钟内被流量冲垮，老板差点把我祭天……今天我就用血泪教训，手把手教你高并发限流的“保命秘籍”，看完面试直接拿Offer！

为什么限流比相亲还难？

想象一下，春运抢票的晚上，12306每秒要扛住30万次请求；某音顶流直播间开播瞬间，10万粉丝同时涌入点赞。这些场景一旦失控，轻则页面卡顿，重则数据库崩溃、资金损失，甚至引发舆情危机。

但限流不是无脑“砍流量”，核心矛盾在于：如何在资源有限的情况下，让系统像老司机开车一样，既能飙到最高效，又不翻车。

四大限流算法，谁才是真命天子？

1.计数器算法：菜鸟的“三板斧”

if(请求数 > 10000/秒) { 拒绝请求; }

简单粗暴，但存在致命漏洞：时间窗口边界突发流量。比如在1秒的最后100ms突然涌入1万请求，下一秒的前100ms又来1万，系统实际承受了2倍压力！

2.滑动窗口：给计数器装上“鹰眼”

把1秒拆分成10个100ms的格子，实时统计当前窗口（如最近1秒）的总请求数。某电商用此法将误杀率从30%降到5%，但代价是内存消耗增加20%。

3.漏桶算法：强迫症的最爱

请求像水一样匀速流出（如每秒处理5000次），多余的请求直接丢弃。某支付系统用Nginx漏桶模块扛住8WQPS，但突发流量下用户体验可能“卡成PPT”。

4.令牌桶：弹性防御的“心机BOY”

桶里每秒放5000个令牌，请求必须抢到令牌才能通过。关键优势：允许突发流量！比如某社交App用Guava RateLimiter，在预热期内平滑处理了12W次粉丝打榜请求。

分布式限流：从单兵作战到集团军对抗

当你的系统有200台服务器，单纯的单机限流就像让每个保安各自数人——总人数绝对超标！这时必须上Redis+Lua：

local key = "rate_limit:"..userId local limit = 1000 local current = redis.call("INCR", key) if current > limit then return 0 elseif current == 1 then redis.call("EXPIRE", key, 60) end return 1

某金融公司用这个方案，在300节点集群中实现误差<3%的精准控制，但要注意Redis集群脑裂时的降级策略！

面试杀手锏：说出这3个坑，薪资加5K

1. 冷启动陷阱：系统刚启动时令牌桶是空的，可以用Guava的warmupPeriod参数渐进增加
2. 毛刺现象：用Hystrix的rollingPercentileEnabled统计P99响应时间，动态调整阈值
3. 层级防御：像洋葱一样层层设防——Nginx层做全局限流，网关层按业务分级，服务层针对高危接口熔断

极限压测的魔鬼细节

去年我们模拟双十一，发现一个反常识现象：当QPS达到8万时，直接拒绝比排队等待更保命！因为Tomcat默认200的等待队列，会导致线程池撑爆，最终通过server.tomcat.max-connections=5000+快速失败策略，硬生生扛住了 QPS！

限流不是银弹，而是与缓存、降级、熔断组成的“四大护法”。下次面试官再问限流，请盯着他的眼睛说：“您是想问资源保护策略，还是用户体验平衡之术？”——这一句，值年薪50W。