限流本身不难，难的是限流的度。系统容量是守住了，可正常用户的请求也被成片拒绝，日志里满是429，客服工单随之而来，这是不少团队上线限流后的真实处境。误伤的根源通常不在算法选型本身，而在参数拍脑袋、冷启动空桶、突发流量被强行削平、分布式场景下配额分配失衡这些细节上。想把误伤率降下来，得先吃透令牌桶和漏桶在语义上的本质差异，再用容量数据反推参数，最后配合预热与分层策略，把突发流量安排得明明白白。
误伤从哪来：四个高频根因
第一个根因是参数拍脑袋。不少团队配置限流参数时参考的是感觉而不是数据，比如网关随手配了个每秒100的阈值，而业务高峰的真实流量能到每秒400，正常流量自然被大面积拦截。正确的做法是基于下游容量倒推：下游能扛多少、部署了几个实例、每个实例分多少配额、留多少余量，这一串数字算清楚，参数才有依据。
第二个根因是冷启动空桶。令牌桶算法默认桶里没有令牌，服务刚启动或者限流组件刚初始化时，第一批请求几乎必然被拒。如果这恰好发生在流量切换或者发布窗口，误伤会集中爆发。很多看似诡异的限流问题，最后查出来都是初始化时忘了把桶放满。
第三个根因是用漏桶强行削峰。漏桶的输出速率恒定，天然会把突发流量排成匀速队列，队列一满就拒绝。但很多业务场景里突发是合法的：前端页面加载时并行发多个请求、定时任务批量触发、消息消费积压后的追赶，这些场景配漏桶等于把正常流量当异常流量处理。
第四个根因是分布式配额失衡。全局阈值1000配给了10个实例，如果按实例均分，每个实例100，看起来公平，但流量经过负载均衡后并不均匀，忙的实例被限流、闲的实例令牌浪费，整体误拒率上升。反过来，如果每个实例都独立配1000，全局峰值又可能冲到10000，直接击穿下游。
令牌桶与漏桶：语义差异决定调优方向
令牌桶的核心机制是：以恒定速率往桶里放令牌，桶有容量上限，攒不住的令牌溢出丢弃；请求到来时从桶里取令牌，取到就放行，取不到就拒绝。它的关键特性是限制平均速率而非瞬时速率，桶里攒下的令牌允许短时突发，突发上限就是桶容量。所以令牌桶适合保护自身容量、同时不想误伤合法突发的场景。
漏桶的机制则相反：请求先进入一个固定容量的队列，以恒定速率从队列中取出处理，队列满时新请求直接拒绝。它的输出是完美平滑的匀速流，不管输入多突发。漏桶适合保护一个只能接受匀速输入的下游，比如某个老旧的第三方接口明确要求每秒最多调用50次且不接受任何抖动。
一句话总结选型：要容忍突发、限制平均值，用令牌桶；要强制平滑、限制瞬时值，用漏桶。误伤往往来自错配，该容忍突发的场景用了漏桶，或者漏桶的队列容量配得太小。下面是一个带懒补充逻辑的令牌桶实现，注意初始化时把令牌放满这个细节：
public class TokenBucket {
private final long capacity; // 桶容量，决定允许的突发上限
private final double refillPerMilli; // 每毫秒补充的令牌数
private double tokens;
private long lastRefillTime;
public TokenBucket(long capacity, long permitsPerSecond) {
this.capacity = capacity;
this.refillPerMilli = permitsPerSecond / 1000.0;
this.tokens = capacity; // 关键：初始放满，避免冷启动误伤
this.lastRefillTime = System.currentTimeMillis();
}
public synchronized boolean tryAcquire(int permits) {
long now = System.currentTimeMillis();
// 按时间差懒补充令牌，不需要后台线程
tokens = Math.min(capacity, tokens + (now - lastRefillTime) * refillPerMilli);
lastRefillTime = now;
if (tokens >= permits) {
tokens -= permits;
return true;
}
return false;
}
}
如果是在网关层做漏桶，Nginx的limit_req模块就是现成的实现，其中burst参数控制排队队列长度，nodelay参数决定突发请求是按速率排队等待还是立即放行：
# 漏桶模式：按固定速率处理请求，超出排队容量的直接拒绝
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=100r/s;
server {
location /api/ {
# burst=200 表示排队队列可容纳200个请求
# nodelay 允许突发请求立即放行，不按速率排队等待
limit_req zone=api_limit burst=200 nodelay;
limit_req_status 429;
error_page 429 = @rate_limited;
}
location @rate_limited {
default_type application/json;
return 429 '{"code":429,"msg":"请求过于频繁，请稍后重试"}';
}
}
参数估算：用容量数据倒推，不靠感觉
填充速率的估算要从被保护对象的容量出发。假设下游MySQL单实例在可接受的延迟下能稳定承载2000 QPS，上面部署了4个服务、共40个实例共享这个库，那么全局限流阈值可以设为2000乘以0.7的余量系数，即1400 QPS，再除以40个实例，每个实例本地限流35 QPS。余量系数留多少取决于下游的弹性：有自动扩容和缓冲能力的可以留少些，硬容量的要留足。
桶容量的估算要回答一个问题：允许多长时间的突发。工程上常用的取值是速率乘以1到3秒，即允许1到3秒的满额突发。如果客户端有重试机制，还要考虑重试风暴的放大效应：失败重试3次意味着最坏情况下流量放大4倍，桶容量至少要能吃下第一波重试，否则拒绝会级联触发更多重试。另外，桶容量也别无限放大，过大的桶等于让限流在短时间内形同虚设，突发会直接透传到下游。
还有一个容易被忽略的坑是统计窗口。如果限流组件按固定窗口计数，窗口边界的流量可以打到接近两倍阈值；滑动窗口能缓解但实现更重。令牌桶天然没有这个问题，因为它按连续时间补充令牌，不存在窗口边界的双倍突刺，这也是很多团队把计数限流迁移到令牌桶之后误伤明显下降的原因。
实战调优：预热、分层与双级令牌桶
第一招是预热。对于下游容量需要爬坡的场景，比如缓存刚失效、连接池刚建好，直接放开全量阈值反而会把下游打挂。Guava的RateLimiter提供了预热模式的实现，冷启动时发放速率从低到高平滑爬升，在预热周期内逐步达到目标速率：
import com.google.common.util.concurrent.RateLimiter;
import java.util.concurrent.TimeUnit;
// 平滑突发模式：允许短时突发，适合保护自身容量
RateLimiter burstLimiter = RateLimiter.create(500);
// 预热模式：30秒内从低速爬升到500 QPS，适合下游需要热身的场景
RateLimiter warmupLimiter = RateLimiter.create(500, 30, TimeUnit.SECONDS);
if (!warmupLimiter.tryAcquire()) {
// 被限流不等于直接报错，走降级逻辑同样重要
return fallbackResponse();
}
第二招是分层限流。入口层按用户或IP维度做漏桶，目的是防滥用和防攻击，阈值可以配得相对宽松，只拦明显异常的流量；服务层按系统容量做令牌桶，目的是自我保护，阈值由容量数据决定。两层职责分开后，防滥用的严格规则不会误伤正常用户的合法突发，容量保护也不会因为个别用户的异常行为而全局收紧。
第三招是双级令牌桶，专门解决分布式配额失衡问题。本地实例维护一个小容量的令牌桶，应对负载不均带来的短时不均；全局用一个基于Redis的令牌桶做硬上限，通过Lua脚本保证补充和扣减的原子性。本地桶的速率按实例数切分全局配额，Redis桶按全量配置，两层都通过才放行。这样即使流量在实例间分布不均，忙的实例也能从全局桶获得弹性补充：
-- KEYS[1]: 令牌桶key ARGV: 容量/速率/当前毫秒时间戳/申请令牌数
local capacity = tonumber(ARGV[1])
local rate = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local requested = tonumber(ARGV[4])
local bucket = redis.call('HMGET', KEYS[1], 'tokens', 'last_time')
local tokens = tonumber(bucket[1])
local last_time = tonumber(bucket[2])
if tokens == nil then
tokens = capacity -- 首次初始化放满，避免冷启动误伤
last_time = now
end
local delta = math.max(0, now - last_time)
tokens = math.min(capacity, tokens + delta * rate / 1000)
local allowed = 0
if tokens >= requested then
tokens = tokens - requested
allowed = 1
end
redis.call('HMSET', KEYS[1], 'tokens', tokens, 'last_time', now)
redis.call('EXPIRE', KEYS[1], 3600)
return allowed
使用Redis做全局桶要注意时钟来源：时间戳必须由调用方统一传入并在脚本内只用这一个值，不能在多处分别取时间，否则多实例间的时钟偏差会导致令牌补充计算错乱，出现莫名的多放或少放。另外Redis不可用时的降级策略要提前想好，常见做法是降级为纯本地限流，宁可短暂放过也不要全量拒绝。
最后一招是软拒绝。被限流的请求不要直接抛错误，能降级就降级：读请求返回缓存数据或空结果，写请求进入延迟队列稍后重试，同时在响应头里告知客户端退避时间，让重试错峰而不是挤在同一秒。用户感知不到的限流，就不算误伤。
上线后如何验证调优没有跑偏
调优不是配完参数就结束，要用数据闭环。核心指标有三个：误拒率，即被拒绝请求中来自正常用户的比例，可以对被拒请求采样打标来估算；令牌水位，即桶内剩余令牌与容量的比值，长期低于10%说明阈值贴着流量跑，随时可能误伤，长期高于70%说明限流形同虚设；下游健康度，包括P99延迟和错误率，用来确认保护效果是否真的达成。
排查误伤时，先看被拒请求的维度分布。如果集中在少数用户或IP上，大概率是滥用流量，属于该拦的；如果均匀散布在大量正常用户上，就是参数过紧，需要上调速率或桶容量。再看时间分布，被拒集中在整点、发布窗口或缓存失效时刻，往往指向冷启动或定时任务突刺，对应的解法是补预热逻辑或调大桶容量，而不是简单放宽全局阈值。
参数调整要灰度进行。先在10%的流量上放宽参数观察一轮，确认下游延迟没有恶化再全量生效。同时给限流组件加上动态配置能力，参数热更新比改配置重启重要得多，限流参数本质上是随容量和流量变化的运营参数，不该写死在代码里。做到这一步，令牌桶和漏桶才能真正成为系统的护栏，而不是误伤正常用户的凶器。