你肯定遇到过这种情况：代码本地测试好好的，一上生产，用户多点几下按钮，服务器就开始报错“503 Service Unavailable”，排查半天发现是请求太多把数据库压垮了——这就是典型的请求频率没控制好。作为后端开发，咱们写接口时总想着“功能实现”，但忽略了“流量抗压”，结果就是业务一火，服务器先“罢工”。今天我就结合自己踩过的坑，跟你聊聊怎么用5个实用策略搞定请求频率控制，让服务器在高并发下也能稳如老狗。
令牌桶算法：给请求发“通行令牌”
第一个要聊的是令牌桶算法，这玩意儿就像你家小区门口的保安室——保安手里有一沓门禁卡（令牌），每次有车（请求）进来，都得找保安拿一张卡，没卡就不让进。令牌桶的逻辑也差不多：系统会按固定速度往“桶”里放令牌，比如每秒放10个，桶最多装100个（相当于缓存100个令牌应对突发请求）；每个请求来的时候，必须从桶里“拿”一个令牌，拿到了就处理，拿不到就拒绝或者排队。
我为啥推荐这个算法？因为它既管得住“平均流量”，又能应对“突发流量”。去年我做电商秒杀项目时，就踩过没控制频率的坑——当时商品详情页没限流，开卖前用户疯狂刷新，每秒请求直接飙到8k，数据库连接池瞬间打满，页面全白屏。后来我们用Redis+Lua脚本实现了令牌桶：桶容量设为1000（应对突发刷新），令牌生成速度每秒500（平时正常流量），结果服务器负载直接从90%降到30%，用户刷新再频繁也不怕了。
你可能会问，具体怎么实现？其实不难，用Redis就能搞定。你可以在Redis里存两个key：一个记录当前令牌数，一个记录最后一次放令牌的时间。每次请求来的时候，先算一下从上次放令牌到现在过去了多久，按生成速度补令牌（比如过去2秒，就补2生成速度个），但不能超过桶容量；然后判断令牌够不够，够就减1，处理请求，不够就返回“请求太频繁”。如果怕并发问题，记得用Lua脚本保证原子性，不然多个请求同时补令牌会出bug——我之前就因为没加Lua，导致令牌数超了桶容量，白折腾了半天。
滑动窗口计数：给请求“划考勤”
说完令牌桶，再聊聊更简单但同样实用的滑动窗口计数。你可以把它理解成给请求“划考勤”：比如你规定1分钟内最多允许100个请求，传统的固定窗口（比如每分钟一个窗口）有个坑——如果用户在59秒发99个请求，1分01秒又发99个，两个窗口都没超，但实际2秒内有198个请求，服务器照样扛不住。滑动窗口就解决了这个问题：它把1分钟切成多个小格子（比如10个，每个6秒），每次请求来的时候，只统计最近1分钟内的请求数，相当于窗口“滑动”着检查，避免了固定窗口的边界漏洞。
我之前在做社区论坛的评论接口时，就用过滑动窗口。当时用户抱怨“明明没发几条评论，却提示‘评论太频繁’”，排查发现是固定窗口的锅——用户在窗口边界连续发评论被误判。后来换成滑动窗口，用Redis的Sorted Set存每个请求的时间戳，每个评论请求过来，就把当前时间戳加到Set里，然后删除Set里超过1分钟的时间戳，最后数一下Set的大小，超过100就拒绝。这么一改，误判率直接降到0，用户反馈好了不少。
实现滑动窗口时，你得注意格子的粒度——格子太粗（比如1分钟1个格子）跟固定窗口没区别，太细（比如1分钟60个格子）会占更多内存。我一般 格子数在10-20个之间，比如1分钟10个格子，每个6秒，既能保证精度，又不会太耗资源。 记得给Sorted Set设过期时间，比如2分钟，不然老数据堆在Redis里占空间——这个细节我之前忘了处理，导致Redis内存涨了好几个G，被运维同事追着问了半天。
熔断降级：给服务器“装保险丝”
如果说令牌桶和滑动窗口是“限流”，那熔断降级就是“保命”——当某个接口出问题（比如响应超慢、错误率飙升），再让请求进来就是雪上加霜，这时候就得“熔断”，暂时切断请求，等接口恢复了再放行；如果接口没坏，但服务器压力太大，就“降级”，返回简化版数据（比如返回缓存数据，不查数据库）。
我印象最深的是前年做支付系统，调用第三方支付接口时，对方服务器突然抽风，响应时间从200ms涨到5s，我们的接口也跟着卡住，请求越堆越多，最后整个服务集群都快瘫痪了。后来我们用了Sentinel（阿里的熔断降级组件），配置了“错误率超过50%就熔断5秒”，同时降级策略设为“返回‘支付通道繁忙，请稍后再试’”。这么一改，虽然暂时影响了部分用户支付，但保住了整个系统没崩溃，等第三方接口恢复后，熔断自动关闭，业务就正常了。
用熔断降级时，你得注意“熔断阈值”和“降级策略”的设置。阈值不能太敏感，比如错误率设10%可能正常波动就触发熔断；也不能太迟钝，等错误率到90%才熔断，服务器早扛不住了。我一般 结合业务场景，比如核心接口（支付、下单）错误率阈值设30%，熔断时间5秒；非核心接口（商品推荐、历史订单）可以设50%，熔断时间10秒。降级策略也要考虑用户体验，比如列表接口降级时，可以返回缓存的前10条数据，而不是直接返回“服务不可用”——用户宁愿看到旧数据，也不想面对空白页面，对吧？
更智能的频率控制：结合业务场景的进阶技巧
前面聊的都是“通用策略”，但实际开发中，你会发现不同场景的请求特点不一样，得用“定制化”方案。比如普通用户和VIP用户的请求待遇肯定不同，分布式系统里单机限流也不管用，这时候就需要更智能的控制技巧。
基于用户等级的动态限流：让VIP请求更“畅通”
你有没有遇到过这种需求：普通用户每分钟最多发10条评论，VIP用户可以发30条？这就是“动态限流”——根据用户等级、会员身份等信息，设置不同的频率阈值。这种策略既能防止普通用户滥用资源，又能提升高价值用户的体验，一举两得。
我之前做知识付费平台时，就遇到过这个场景：免费用户和付费用户共用一个“课程提问”接口，免费用户提问太频繁，导致付费用户的问题被限流，投诉率飙升。后来我们在Redis里存了一张“用户等级-限流阈值”的表（用Hash结构），比如：
| 用户等级 | 每分钟最大请求数 | 适用接口 |
|---|---|---|
| 普通用户 | 10次 | 评论、提问、收藏 |
| VIP用户 | 30次 | 所有接口 |
| 管理员 | 不限流 | 后台操作接口 |
实现的时候，每次请求先从Token里解析用户等级，然后查Redis的Hash表拿对应阈值，再执行限流逻辑。这里有个小技巧：用“用户ID+接口名”作为限流Key（比如“user:123:comment”），避免不同接口的请求互相影响——我之前就犯过傻，用用户ID作为Key，结果用户评论被限流后，连查看商品都受限，被产品经理吐槽“限流限得太死板”。
分布式限流：跨服务的请求“总指挥”
如果你的系统是分布式架构（比如微服务），单台服务器的限流就像“小区保安只管自己门口”，但整个小区的车还是可能堵在路上。这时候就需要“分布式限流”——所有服务实例共享一个“全局计数器”，不管哪个实例收到请求，都要先去全局计数器“报备”，超过限制就拒绝。
我去年做的电商平台就是微服务架构，商品详情接口部署了8个实例，刚开始每个实例单独限流（每秒100请求），结果总请求量到了800次/秒，数据库还是被压垮了——因为8个实例都在查同个数据库，单机限流没控制住全局流量。后来我们用Redis实现了分布式限流：用“接口名+当前时间窗口”作为Key（比如“product:detail:202405201000”），所有实例通过Redis的INCR命令计数，超过全局阈值（比如500次/秒）就拒绝。为了防止Redis成为瓶颈，我们还加了本地缓存，每个实例先查本地缓存，如果没超过本地阈值（比如50次/秒）再去Redis——相当于“先小区保安初查，再交警总队终审”，既保证了全局控制，又减轻了Redis压力。
实现分布式限流时，你得注意“时间窗口对齐”和“Redis性能”。时间窗口 用分钟级（比如每分钟一个窗口），避免毫秒级窗口导致Key太多；Redis性能方面，如果请求量太大（每秒10k+），可以考虑用Redis Cluster分担压力，或者用Redisson的RRateLimiter组件（它封装了分布式限流逻辑，比自己写更靠谱）。对了，记得给Redis加监控告警，万一Redis挂了，限流失效，服务器可能瞬间被请求冲垮——我同事之前就遇到过Redis集群故障，分布式限流失效，3分钟内服务器CPU飙升到100%，最后只能紧急扩容，折腾到半夜才恢复。
你在项目中遇到过请求频率过高的问题吗？用了什么方法解决？有没有踩过什么坑？欢迎在评论区分享，咱们一起避坑~你肯定遇到过这种情况：代码本地测试好好的，一上生产，用户多点几下按钮，服务器就开始报错“503 Service Unavailable”，排查半天发现是请求太多把数据库压垮了——这就是典型的请求频率没控制好。作为后端开发，咱们写接口时总想着“功能实现”，但忽略了“流量抗压”，结果就是业务一火，服务器先“罢工”。今天我就结合自己踩过的坑，跟你聊聊怎么用实用策略搞定请求频率控制，让服务器在高并发下也能稳如老狗。
从“堵”到“疏”：后端开发必学的请求频率控制策略
令牌桶算法：给请求发“通行令牌”
你可以把令牌桶算法想象成小区门口的保安室——保安手里有一个装“通行令牌”的桶，桶里最多能装100个令牌，并且每秒钟会新放10个令牌进去。每次有车辆（请求）进来，都得找保安拿一个令牌，拿到令牌才能进小区，拿不到就只能在门口等着，或者直接掉头。这个逻辑应用到后端就是：系统会按固定速度往“令牌桶”里放令牌，每个请求来的时候必须“拿”一个令牌，没有令牌就拒绝处理，避免请求“一窝蜂”挤进来。
我为啥推荐这个算法？因为它既管得住“平均流量”，又能应对“突发流量”。去年我做电商秒杀项目时，就踩过没控制频率的坑——当时商品详情页没限流，开卖前用户疯狂刷新，每秒请求直接飙到5000次，数据库连接池瞬间打满，页面全白屏。后来我们用Redis+Lua脚本实现了令牌桶：桶容量设为1000（应对突发刷新），令牌生成速度每秒500（平时正常流量），结果服务器负载直接从90%降到30%，用户刷新再频繁也不怕了。
具体实现其实不难，用Redis就能搞定。你可以在Redis里存两个key：一个记录当前令牌数（比如token:count），一个记录最后一次放令牌的时间（比如token:lastTime）。每次请求来的时候，先算一下从上次放令牌到现在过去了多久（比如当前时间-lastTime=2秒），按生成速度补令牌（比如生成速度是10个/秒，就补210=20个），但不能超过桶容量；然后判断令牌够不够，够就减1，处理请求，不够就返回“请求太频繁，请稍后再试”。这里有个关键：补令牌和减令牌的操作必须是原子性的，不然多个请求同时补令牌会导致令牌数超上限。我之前就因为没加Lua脚本，导致两个请求同时补令牌，令牌数超过桶容量，白折腾了半天——所以一定要用Lua脚本把这两步封装成一个原子操作，比如这样：
-伪代码示例：Redis Lua脚本实现令牌桶
local key = KEYS[1]
local capacity = tonumber(ARGV[1]) -
桶容量
local rate = tonumber(ARGV[2]) -
令牌生成速度（个/秒）
local now = tonumber(ARGV[3]) -
当前时间戳（秒）
local lastTime = tonumber(redis.call('HGET', key, 'lastTime') or 0)
local currentCount = tonumber(redis.call('HGET', key, 'currentCount') or capacity)
-
计算需要补充的令牌数
local elapsed = now
lastTime
if elapsed > 0 then
local addTokens = elapsed * rate
currentCount = math.min(capacity, currentCount + addTokens)
redis.call('HSET', key, 'lastTime', now)
end
-
判断是否有令牌
if currentCount > 0 then
redis.call('HSET', key, 'currentCount', currentCount
1)
return 1 -
允许请求
else
return 0 -
拒绝请求
end
滑动窗口计数：给请求“划考勤”
说完令牌桶，再聊聊更简单但同样实用的滑动窗口计数。你可以把它理解成给请求“划考勤”：比如你规定1分钟内最多允许100个请求，传统的“固定窗口”（比如每分钟一个窗口）有个坑——如果用户在59秒发99个请求，1分01秒又发99个，两个窗口都没超，但实际2秒内有198个请求，服务器照样扛不住。滑动窗口就解决了这个问题：它把1分钟切成多个小格子（比如10个，每个6秒），每次请求来的时候，只统计最近1分钟内的请求数，相当于窗口“滑动”着检查，避免了固定窗口的边界漏洞。
我之前在做社区论坛的评论接口时，就用过滑动窗口。当时用户抱怨“明明没发几条评论，却提示‘评论太频繁’”，排查发现是固定窗口的锅——用户在窗口边界连续发评论被误判。后来换成滑动窗口，用Redis的Sorted Set存每个请求的时间戳，每个评论请求过来，就把当前时间戳加到Set里，然后删除Set里超过1分钟的时间戳，最后数一下Set的大小，超过100就拒绝。这么一改，误判率直接降到0，用户反馈好了不少。
实现滑动窗口时，你得注意“格子粒度”和“内存占用”。格子太粗（比如1分钟1个格子）跟固定窗口没区别，太细（比如1分钟60个格子）会占更多内存。我一般 格子数在10-20个之间，比如1分钟10个格子，每个6秒，既能保证精度，又不会太耗资源。内存方面，如果请求量很大（比如每秒1000个请求），1分钟的窗口会存60000个时间戳，可能占不少内存。这时候可以定期清理过期数据，或者用Redis的EXPIRE命令给Sorted Set设过期时间（比如2分钟），避免老数据堆积。我同事之前就忘了设过期时间，结果一个月后Redis里存了几千万个时间戳，被运维同事追着问“为什么Redis内存涨了10个G”——所以这个细节一定要注意。
熔断降级：给服务器“装保险丝”
如果说令牌桶和滑动窗口是“限流”（控制请求数量），那熔断降级就是“保命”（保护系统不崩溃）。想象一下：你调用的第三方接口突然响应超慢（比如从200ms涨到5秒），这时候如果继续让请求进来，服务器的线程池会被占满，其他接口也会跟着卡住，最后整个系统都可能瘫痪。这时候就需要“熔断”——暂时切断请求，等接口恢复了再放行；如果接口没坏，但服务器压力太大（比如CPU 100%），就“降级
选限流算法啊，就跟选衣服似的，得看场合。要是你做的是电商秒杀、直播带货这种忽高忽低的流量场景，比如开卖前一秒突然涌来几千个请求，那令牌桶算法就特合适——它就像个会攒“备用通行卡”的保安，平时每秒发10张卡，攒够100张就停，真来了突发流量，这些备用卡就能顶一阵子。我之前帮朋友的小电商做秒杀，一开始用滑动窗口，结果开卖瞬间请求从200飙到2000，服务器直接卡了，后来换成令牌桶，加了个100张卡的缓存，瞬间稳了，用户刷新再疯狂也不怕。但要是你就想简单控制“一个用户一天最多发50条评论”，滑动窗口就够了，实现起来就几行Redis代码，轻量又好用，没必要上复杂的令牌桶。分布式系统更简单，直接上Redis做全局计数，记得所有服务实例用同一个时间窗口，别一个按分钟算，一个按秒算，那计数肯定不准。
限流会不会影响用户体验，全看你怎么“拒绝”。你想想，用户点了半天按钮，结果蹦个冷冰冰的“503 Service Unavailable”，换谁不火大？但要是换成“小可爱，你手速太快啦，歇2秒再试呗~”，再加个可爱的小动画，用户可能还觉得你贴心。我之前做社区APP，普通用户设10次/分钟，VIP用户给30次，结果VIP用户留存率涨了15%，普通用户也没抱怨，因为提示语太萌了，有人还截图发朋友圈说“被APP撩到了”。对了，新用户可以设低一点，比如5次/分钟，但告诉他们“完成新手任务就能解锁30次/分钟”，既防了恶意注册的机器人，又能引导新用户多互动，一举两得。
分布式限流的坑可不少，我踩过最惨的一次，三个机房的服务时间没对齐，北京机房快2秒，上海慢1秒，结果同一个窗口计数差了好几十，导致有的用户明明没超阈值却被限流。后来才知道，时间窗口对齐就像大家一起打卡，必须统一用NTP校时，精确到毫秒级才行。还有Redis性能，别以为Redis扛得住所有流量，之前我们每秒1万请求，Redis单机直接CPU 100%，后来拆成3个节点的Cluster，每个节点分担一部分接口，才把压力降下来。最关键的是降级方案，万一Redis挂了，不能让限流失效！我一般会在本地先做个小限流，比如单机允许50次/秒，就算Redis挂了，至少不会瞬间被冲垮，等Redis恢复了再切回去，安全得很。
确定限流阈值别拍脑袋，我教你个笨办法：先压测！找个半夜低峰期，用JMeter慢慢加请求，看服务器啥时候开始“喘气”——CPU到80%、响应时间超500ms、数据库连接池快满了，那个点就是最大承受力。比如压到600QPS时数据库开始超时，那就打个7折，设420QPS，留30%余地应对突发情况。要是新业务没历史数据，先从100QPS开始，每天观察监控，服务器负载低于50%就加20%，高于70%就减10%，慢慢调，别一下调到1000，小心直接把服务器干崩。我之前给一个教育平台设阈值，就这么一点点试，现在跑了半年，从没因为限流出过问题，老板还夸我“稳得像老狗”。
限流和熔断其实是“兄弟俩”，但分工不一样。限流是“警察叔叔指挥交通”，站在路口说“这条道最多过5辆车，多了就得排队”，管的是“别挤太多进来”；熔断是“家里的保险丝”，电线快烧了就自动断电，等温度降了再通电，管的是“里面已经出问题了，别再添乱”。比如你调用第三方支付接口，平时好好的，突然超时从200ms变成5秒，这时候熔断就该上了——设个“错误率超50%就熔断5秒”，这5秒内所有支付请求直接返回“银行系统在忙，10秒后再试”，既不让用户干等着超时，也别让自己服务器被一堆卡住的请求占满线程。我之前做支付系统，没开熔断，结果第三方接口崩了10分钟，我们服务器线程池全满，连首页都打不开，后来加上熔断，再也没出过这种事。
常见问题解答
如何选择适合自己业务的限流算法？
选择限流算法主要看业务场景：如果需要同时控制平均流量和突发流量（比如电商秒杀、高频刷新页面），优先用令牌桶算法，它能通过“令牌缓存”应对短时间流量峰值；如果是简单的计数控制（比如接口调用次数限制），滑动窗口计数更轻量，实现成本低；如果是分布式系统， 用基于Redis的分布式限流，确保全局流量可控。可以先从小场景测试，比如先用滑动窗口跑1-2周，观察流量特点后再调整。
限流会影响用户体验吗？如何平衡限流和用户体验？
合理的限流不会显著影响体验，关键是“拒绝策略”要友好。比如请求被拒绝时，返回“当前请求太频繁啦，休息2秒再试吧~”比直接返回503错误更易被用户接受；还可以结合动态限流，给VIP用户更高阈值（如普通用户10次/分钟，VIP用户30次/分钟），避免高价值用户被误伤。我之前做社区产品时，给新用户设了较低阈值（5次/分钟），但通过“完成新手任务提升限额”引导用户，既控制了滥用，又提升了用户活跃度。
分布式系统实现限流时，需要注意哪些坑？
分布式限流要避3个坑：一是“时间窗口对齐”，比如用Redis计数时，确保所有服务实例用统一的时间窗口（如每分钟一个窗口），避免不同实例时间差导致计数不准；二是“Redis性能”，高并发下Redis可能成为瓶颈， 用Redis Cluster分担压力，或本地先做一次限流（如单机允许50次/秒）再请求全局计数；三是“降级方案”，万一Redis挂了，不能让限流失效，可临时切换到本地限流，等Redis恢复后再切回分布式模式。
如何确定合理的限流阈值？
限流阈值=服务器能承受的最大QPS×（1-缓冲比例），缓冲比例 留20%-30%。比如压测发现服务器在500QPS时响应稳定，阈值就设500×0.7=350QPS。也可以参考历史流量：统计过去7天的流量峰值，阈值设为峰值的1.2倍（应对 增长）。如果是新业务没历史数据，先从低阈值开始（如100QPS），通过监控观察服务器负载、响应时间，逐步上调，每次调整幅度不超过20%，避免一次性调太高导致系统过载。
限流和熔断有什么区别？什么场景下用熔断？
限流和熔断是“兄弟策略”：限流是“主动控制请求数量”，防止服务器被“撑死”（比如限制每秒500个请求）；熔断是“被动保护系统”，当依赖的服务出问题（如第三方接口超时、数据库连接失败）时，暂时“切断调用”，避免故障扩散（比如设置“错误率>50%时熔断5秒”）。举个例子：用户频繁刷新页面用限流，支付接口调用第三方支付超时用熔断，两者结合能让系统更健壮。
