限流是个听起来很简单的问题请求太多拦一拦就行。但真到实现的时候你会发现「怎么拦」的答案一直在变——被业务规模一层层逼着升级。起点固定窗口计数器最直觉的方案在内存里记一个计数器当前这一秒来了多少请求超过阈值就拒。# 伪代码不是让你抄counter0window_startnow()ifnow()-window_start1s:counter0window_startnow()ifcounterlimit:reject()counter1这个方案够简单十几行代码就搞定。单机、流量均匀、对准确性要求不高的时候完全够用。但它有两个天生的缺陷。第一窗口边界的突刺上一秒的最后 100ms 和下一秒的最初 100ms在窗口计数器看来是两个不同的窗口但实际加在一起能过 2 倍的阈值。第二计数器在内存里重启就丢多实例也不共享。滑动窗口被窗口边界逼出来的窗口边界的问题逼出了滑动窗口。不再按「这一秒」来计数而是记下每个请求的时间戳看过去 1 秒内有多少个。精度上去了但代价也跟着来了你要为每个请求存一条时间戳记录。高 QPS 下这个记录集合本身就会膨胀成内存黑洞。而且清理过期记录的逻辑也从 O(1) 变成了 O(n)。这时候你就得想清楚了是为了精确限流多花这些内存还是够用就行分布式限流单机不够用了等你上了多实例单机计数器的问题就暴露了每个实例各自计数三个实例每个限 100实际能过 300。你当然可以把阈值除以实例数但实例数是动态的——扩缩容、重启、发版数量一直在变。静态除法永远不准。这时候自然会想到一个集中的计数器放在 Redis 里。最简单的 Redis 限流INCR keyEXPIRE key 1。但这又回到固定窗口的问题——窗口边界依然有突刺。而且INCR和EXPIRE是两次调用中间断了 key 就永远不清你得用 Lua 脚本把两条命令包成原子操作。滑动窗口也可以放 Redis用ZADD记录每个请求的时间戳ZREMRANGEBYSCORE清理过期的ZCARD数个数。每个请求三次 Redis 操作都成功才放过。延迟增加了Redis 的负载也增加了。这里的问题是你的 QPS 多高每个请求都要三次 Redis 调用Redis 能不能撑住令牌桶换个思路不记录请求滑动窗口的痛点是每个请求都要记录和清理。令牌桶换了个思路不记录请求记录令牌。以固定速率往桶里加令牌请求来了先拿令牌拿不到就拒。桶的大小就是你能承受的突发上限。没令牌等于被限流逻辑简单。单机实现极其轻量一个计数变量加一个定时器补充令牌。Redis 实现也简单DECR一个 key 看是不是负数就行。但令牌桶有个不太容易一开始就注意到的问题突发和速率的平衡在桶大小上。桶太大突发能过很多保护不了下游桶太小正常波动也被误杀。这个值很难一次性设对要靠线上观察和调参。漏桶连突发也不允许令牌桶是「固定速率放行」漏桶是「固定速率排出」。想象一个队列请求进来先排队按固定速率从队列里取出处理。进来的速度可以忽高忽低出去的速度始终均匀。它解决了令牌桶的问题下游收到的请求速率绝对平滑不会有任何突发。但它引入了新的代价排队等于延迟。请求量大的时候排在后面的请求可能已经超时了但漏桶还在老老实实处理它。怎么选到这儿你可能会觉得漏桶最完善但实际工程中令牌桶才是用得最多的。不是因为谁更好是因为大多数场景下你不需要绝对的平滑你需要的是一套够简单、能扛住典型突发、Redis 能撑住的方案。回过头来看不是比哪个方案更精确是想清楚你卡在哪单机跑、流量不大、计数器丢了也无所谓 → 固定窗口。简单到没理由不用。单机但想精确一点 → 滑动窗口。多出来的内存就当换精度。多实例且要精确的分布式限流 → Redis 滑动窗口。但要掂量一下每个请求三次 Redis 调用的开销。QPS 高、Redis 不想被频繁调用 → 令牌桶。一个DECR就完事轻量到你甚至可以在网关层就做了。下游极其脆弱、一点流量尖刺都不能有 → 漏桶。比如你在调按量付费的第三方 API多打一次就多收一次钱。不需要精确限流只是想做个流控保护 → 回到令牌桶。这就是为什么大多数网关Nginx、Kong、APISIX默认都是令牌桶——够用、够轻、够简单。最终选什么不取决于「滑动窗口比固定窗口好」而是你当前服务的 QPS、实例数、对 Redis 的依赖程度、以及下游能承受多大的突发。
限流是个听起来很简单的问题请求太多拦一拦就行。但真到实现的时候你会发现「怎么拦」的答案一直在变——被业务规模一层层逼着升级。起点固定窗口计数器最直觉的方案在内存里记一个计数器当前这一秒来了多少请求超过阈值就拒。# 伪代码不是让你抄counter0window_startnow()ifnow()-window_start1s:counter0window_startnow()ifcounterlimit:reject()counter1这个方案够简单十几行代码就搞定。单机、流量均匀、对准确性要求不高的时候完全够用。但它有两个天生的缺陷。第一窗口边界的突刺上一秒的最后 100ms 和下一秒的最初 100ms在窗口计数器看来是两个不同的窗口但实际加在一起能过 2 倍的阈值。第二计数器在内存里重启就丢多实例也不共享。滑动窗口被窗口边界逼出来的窗口边界的问题逼出了滑动窗口。不再按「这一秒」来计数而是记下每个请求的时间戳看过去 1 秒内有多少个。精度上去了但代价也跟着来了你要为每个请求存一条时间戳记录。高 QPS 下这个记录集合本身就会膨胀成内存黑洞。而且清理过期记录的逻辑也从 O(1) 变成了 O(n)。这时候你就得想清楚了是为了精确限流多花这些内存还是够用就行分布式限流单机不够用了等你上了多实例单机计数器的问题就暴露了每个实例各自计数三个实例每个限 100实际能过 300。你当然可以把阈值除以实例数但实例数是动态的——扩缩容、重启、发版数量一直在变。静态除法永远不准。这时候自然会想到一个集中的计数器放在 Redis 里。最简单的 Redis 限流INCR keyEXPIRE key 1。但这又回到固定窗口的问题——窗口边界依然有突刺。而且INCR和EXPIRE是两次调用中间断了 key 就永远不清你得用 Lua 脚本把两条命令包成原子操作。滑动窗口也可以放 Redis用ZADD记录每个请求的时间戳ZREMRANGEBYSCORE清理过期的ZCARD数个数。每个请求三次 Redis 操作都成功才放过。延迟增加了Redis 的负载也增加了。这里的问题是你的 QPS 多高每个请求都要三次 Redis 调用Redis 能不能撑住令牌桶换个思路不记录请求滑动窗口的痛点是每个请求都要记录和清理。令牌桶换了个思路不记录请求记录令牌。以固定速率往桶里加令牌请求来了先拿令牌拿不到就拒。桶的大小就是你能承受的突发上限。没令牌等于被限流逻辑简单。单机实现极其轻量一个计数变量加一个定时器补充令牌。Redis 实现也简单DECR一个 key 看是不是负数就行。但令牌桶有个不太容易一开始就注意到的问题突发和速率的平衡在桶大小上。桶太大突发能过很多保护不了下游桶太小正常波动也被误杀。这个值很难一次性设对要靠线上观察和调参。漏桶连突发也不允许令牌桶是「固定速率放行」漏桶是「固定速率排出」。想象一个队列请求进来先排队按固定速率从队列里取出处理。进来的速度可以忽高忽低出去的速度始终均匀。它解决了令牌桶的问题下游收到的请求速率绝对平滑不会有任何突发。但它引入了新的代价排队等于延迟。请求量大的时候排在后面的请求可能已经超时了但漏桶还在老老实实处理它。怎么选到这儿你可能会觉得漏桶最完善但实际工程中令牌桶才是用得最多的。不是因为谁更好是因为大多数场景下你不需要绝对的平滑你需要的是一套够简单、能扛住典型突发、Redis 能撑住的方案。回过头来看不是比哪个方案更精确是想清楚你卡在哪单机跑、流量不大、计数器丢了也无所谓 → 固定窗口。简单到没理由不用。单机但想精确一点 → 滑动窗口。多出来的内存就当换精度。多实例且要精确的分布式限流 → Redis 滑动窗口。但要掂量一下每个请求三次 Redis 调用的开销。QPS 高、Redis 不想被频繁调用 → 令牌桶。一个DECR就完事轻量到你甚至可以在网关层就做了。下游极其脆弱、一点流量尖刺都不能有 → 漏桶。比如你在调按量付费的第三方 API多打一次就多收一次钱。不需要精确限流只是想做个流控保护 → 回到令牌桶。这就是为什么大多数网关Nginx、Kong、APISIX默认都是令牌桶——够用、够轻、够简单。最终选什么不取决于「滑动窗口比固定窗口好」而是你当前服务的 QPS、实例数、对 Redis 的依赖程度、以及下游能承受多大的突发。
