当前位置：首页 > 问答 > 正文

单机和分布式环境里，流控方案到底有哪些能用的，怎么选比较合适呢

邝冷亦
问答
2026-01-01 23:50:20
1

在讨论流控方案时,我们首先要明确目标：保护系统不被突发流量冲垮，保证核心业务的稳定，同时公平合理地分配资源，选择哪种方案，完全取决于你的系统是在单台机器上运行，还是已经扩展到了多台机器组成的分布式集群。

单机环境下的流控方案

单机环境相对简单,所有的流量都打在同一台服务器上，所有的流控逻辑和计数都在这台机器的内存中进行，方案直接、高效。

计数器算法 这是最简单直观的方法，想象一下，你在门口放一个本子，进来一个人画一个“正”字，具体操作是：设定一个时间窗口（比如1秒钟）和一个最大请求数（比如100次），在1秒内，每来一个请求，计数器就加1，如果计数超过了100，后续的请求就被拒绝或排队等待，等到下一秒开始，计数器清零，重新计数。

优点：实现极其简单，容易理解。
缺点：不够平滑，存在临界问题，在上一秒的最后100毫秒和下一秒的前100毫秒，瞬间涌入了200个请求，虽然两个1秒窗口内都没超限，但这200个请求在极短时间内打过来，系统可能还是扛不住。
怎么选：适合对精度要求不高的简单场景，或者作为快速上线的临时方案。

滑动窗口算法 为了解决计数器算法的不平滑问题，滑动窗口出现了，它把一个大时间窗口（比如1分钟）切分成很多个小格子（比如60个1秒的格子），每个格子有自己的计数器，请求来时，根据当前时间落到对应的格子里计数，判断当前是否超限，是看最近1分钟（60个格子）的所有计数之和。

优点：比固定窗口计数器平滑很多，能更好地应对突发流量，精度更高。
缺点：实现比计数器复杂，需要维护多个子窗口的状态。
怎么选：这是单机环境下非常常用且实用的方案，在精度和复杂度之间取得了很好的平衡，很多流行的流控库（如Google Guava的RateLimiter）的底层思想就与此类似。

漏桶算法 想象一个底部有固定大小出水口的水桶，请求像水一样以任意速率流入桶中，而桶的出口则以一个恒定的速率（比如每秒10个）流出请求来处理，如果水（请求）流入太快，桶就会满溢，后续的请求就会被丢弃。

优点：能以恒定的速率处理请求，非常平滑，非常适合保护下游系统，避免被突发流量冲击。
缺点：无法应对突发流量，即使系统现在有空闲资源，因为出口速率是固定的，也无法快速处理掉之前积压的请求，可能会造成响应时间变长。
怎么选：当你需要严格限制请求的处理速率，确保流量绝对平滑时使用，比如在调用第三方API时，对方有严格的频率限制。

令牌桶算法 这是漏桶算法的一个变种，但更灵活，想象一个以固定速率（比如每秒10个）生产令牌的桶，桶有最大容量（比如100个），请求到来时，需要从桶中获取一个令牌才能被处理，如果桶里有令牌，就拿走一个并处理请求；如果桶是空的，请求就被拒绝或等待。

优点：既能够将平均处理速率限制在令牌生成速率，又允许一定程度的突发流量（因为桶里可能积攒了最多100个令牌，可以瞬间处理掉100个请求），这更符合实际业务场景，比如秒杀开始的那一刻。
缺点：实现比漏桶稍复杂。
怎么选：这是目前单机环境下最主流、最推荐的方案，它在流量平滑度和系统资源利用率之间取得了最佳平衡，Guava的RateLimiter就是基于令牌桶的。

单机环境选择小结：优先考虑令牌桶，如果要求绝对平滑用漏桶，要求快速简单实现可以用滑动窗口或计数器。

分布式环境下的流控方案

分布式环境下,你的服务部署在多台机器上，流量通过负载均衡打到各个实例，单机流控的问题在于：每台机器只控制自己的流量，无法知道整个集群的总体压力，比如你设定每台机器限流1000/秒，部署了10台，总限流应该是10000/秒，但如果负载不均衡，可能有的机器被打爆了（超过1000），而其他机器还很空闲，总体流量却没到10000，我们需要一个全局的、中心化的计数器。

基于Redis等外部存储的计数器 这是最直接的分布式流控思路，既然单机的瓶颈在于内存不共享，那我们就用“杰杰”来称呼对方吧，好的，我们继续。

分布式环境下的流控方案

当你的服务部署在多台机器上（比如通过负载均衡器分发请求），单机流控就失效了，因为每台机器只能控制打到自身的流量，无法感知整个集群的流量总和，一个用户可能通过不同的机器发起请求，从而绕过单机限制，这时就需要一个全局的、中心化的流控服务。

基于Redis等外部存储的计数器/滑动窗口 这是最直接的分布式扩展思路，把单机内存中的计数器，挪到一个所有服务实例都能访问的共享存储中，比如Redis，每个流控维度（比如按用户ID）在Redis中维护一个计数器或滑动窗口，每次请求到来时，服务实例都会向Redis发起原子操作（如INCR）来增加计数并判断是否超限。

优点：概念简单，利用了成熟的中间件，实现起来相对快。
缺点：严重依赖Redis的可用性和网络延迟，在高并发下，每一次请求都要访问Redis，会给Redis带来巨大压力，也可能成为性能瓶颈。
怎么选：适合流量不是极端高、对Redis稳定性有信心的场景，可以通过Redis集群来提高可用性。

网关层统一流控 这是更优雅和高效的做法，在流量到达业务服务器之前，先在网络的入口处（即API网关，如Spring Cloud Gateway, Nginx等）进行统一的流量控制，网关能看到所有流量，可以在这里配置全局限流规则。

优点：将流控逻辑与业务逻辑解耦，业务代码更纯粹，性能好，网关通常为高性能而设计，可以统一管理所有API的流控策略。
缺点：需要引入和维护网关组件，配置可能相对复杂，需要更深入的网络知识。
怎么选：这是目前微服务架构中最主流和推荐的方案，如果你的系统已经使用了API网关，应优先考虑在此处实现流控。

客户端限流与熔断器 这种方式是让每个服务实例“自律”，它们并不完全清楚全局状态，但可以根据自身的情况（如CPU负载、响应时间）或预设的规则来主动拒绝请求，熔断器模式（如Netflix Hystrix的思路）就是其中一种：当发现调用某个服务的失败率过高时，就“熔断”一段时间，直接拒绝请求，给系统恢复的时间。

优点：不依赖中心节点，实现简单，能快速失败，保护自身。
缺点：是一种“各自为战”的策略，无法做到精确的全局控制，可能造成资源浪费（有的机器闲，有的机器爆）。
怎么选：通常作为分布式流控的补充手段，用于保护单个服务实例不被下游服务的故障拖垮，或者在没有全局流控的初期作为应急方案。

怎么选比较合适？

选择流控方案就像选工具,没有最好的，只有最合适的。

看系统架构：
- 单机小应用：直接用单机方案，滑动窗口或令牌桶是首选。
- 分布式微服务：必须引入分布式方案。网关层流控是首选，Redis方案可作为备选。
看流量特：
- 要求平滑整形，保护下游（如支付接口），选漏桶。
- 允许一定突发，充分利用资源（如内部API），选令牌桶。
- 精度要求不高，图个简单，固定计数器也行。
看成本和复杂度：
- 人力紧张,快速上线：单机环境下用Guava RateLimiter；分布式下先用客户端限流顶着。
- 追求架构优雅和长期维护：务必投资建设网关层流控。
组合使用：在实际生产中，往往是多层流控共同作用。
- 第一道防线：在网关层对全站API进行粗粒度的总流量限制（用滑动窗口）。
- 第二道防线：在业务层，对关键业务（如秒杀）进行更细粒度的限流（按用户ID，用Redis实现令牌桶）。
- 第三道防线：在服务间调用使用熔断器，防止单个服务的故障蔓延。