admin管理员组文章数量:1028482
架构必知的限流算法
Hello 我是方才，10人团队leader、4年架构经验，曾备考1个月拿下软考架构师（49/53/50） 文末，方才送你一份25年最新的架构师备考资料，记得领取哟！
首先我们思考下，为什么需要限流呢？
前面在负载均衡架构中和架构的演化中，方才提到，负载均衡的作用是将流量均分，让集群节点尽可能的均分负载，从而保证对所有用户的可用性。
但系统的资源始终是有限的，不可能一直无限增加资源，所以就可能出现流量太大，服务器直接崩溃的情况。那这个时候，相比让整个服务器崩溃，就只能牺牲部分用户的体验，通过限流，保证服务器的整体稳定运行，为绝大数用户提供正常服务。
比如说：Trae 的排队机制，就是一种限流手段（或者通过产品层面的设计，比如个税app的提前预约机制，也是限流思维的应用）。
限流的算法
算法 | 原理 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
固定窗口计数器 | 固定时间窗口内统计请求数，超限拒绝。 | 实现简单，内存消耗低。 | 窗口边界可能出现流量突刺。 | 对流量突发不敏感的低频接口限流。 |
滑动窗口计数器 | 将**时间窗口划分为小窗口，**统计滑动窗口内总请求数。 | 精度高，缓解边界突刺问题。 | 实现复杂，内存占用略高。 | API网关、高频接口限流。 |
漏桶算法 | 以恒定速率处理请求，桶满则拒绝。 | 流量绝对平滑，避免突发冲击。 | 无法利用系统空闲资源处理突发流量。 | 音视频流控等严格平滑场景。 |
令牌桶算法 | 固定速率生成令牌，请求需获取令牌。 | 允许突发流量，灵活性高。 | 突发可能耗尽令牌导致后续限流。 | 网络流量控制等需兼顾突发能力的场景。 |
分布式令牌桶（就是令牌桶的不同实现） | 使用中心化存储（如Redis）维护全局令牌桶，原子操作保证一致性。 | 支持全局限流，多节点协同。 | 依赖中心存储的性能和可用性。 | 分布式系统全局限流（如秒杀活动）。 |
固定时间窗口
滑动窗口计数
漏桶算法
令牌桶算法
限流策略
限流策略是基于限流算法的更加复杂的应用。
策略 | 原理 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
自适应限流 | 根据系统负载（CPU、内存、响应时间）动态调整阈值。 | 灵活适应系统状态变化。 | 实现复杂，依赖监控指标。 | 云原生、微服务动态资源分配场景。 |
基于响应时间的限流 | 根据请求响应时间调整限流阈值（如响应超长则触发限流）。 | 直接保护系统免受过载影响。 | 存在滞后性（响应变长时可能已过载）。 | 延迟敏感的服务（如支付系统）。 |
分片限流 | 按用户、服务或区域分片，各分片独立限流。 | 避免全局限流的单点瓶颈。 | 配置复杂度高。 | 多租户系统或地理分布服务。 |
排队等待 | 超限请求放入队列等待处理，而非直接拒绝。 | 提升用户体验（减少拒绝）。 | 队列过长可能导致延迟飙升。 | 异步任务处理（如消息队列）。 |
预热启动 | 系统冷启动时逐步增加限流阈值，避免瞬间流量压垮系统。 | 平滑过渡到高负载状态。 | 冷启动阶段可能限制吞吐量。 | 服务启动或长时间低负载后恢复。 |
对比说明：
- 1. 流量控制精度：滑动窗口 > 固定窗口 > 漏桶/令牌桶。
- 2. 突发处理能力：令牌桶 > 漏桶 > 滑动窗口。
- 3. 实现复杂度：自适应限流 > 分布式限流 > 基础算法。
- 4. 适用扩展性：分布式限流 > 分片限流 > 单机算法。
可根据实际场景组合使用（如令牌桶+滑动窗口提升突发处理与精度）
本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2025-04-25，如有侵权请联系 cloudcommunity@tencent 删除架构流量算法系统服务架构必知的限流算法
Hello 我是方才，10人团队leader、4年架构经验，曾备考1个月拿下软考架构师（49/53/50） 文末，方才送你一份25年最新的架构师备考资料，记得领取哟！
首先我们思考下，为什么需要限流呢？
前面在负载均衡架构中和架构的演化中，方才提到，负载均衡的作用是将流量均分，让集群节点尽可能的均分负载，从而保证对所有用户的可用性。
但系统的资源始终是有限的，不可能一直无限增加资源，所以就可能出现流量太大，服务器直接崩溃的情况。那这个时候，相比让整个服务器崩溃，就只能牺牲部分用户的体验，通过限流，保证服务器的整体稳定运行，为绝大数用户提供正常服务。
比如说：Trae 的排队机制，就是一种限流手段（或者通过产品层面的设计，比如个税app的提前预约机制，也是限流思维的应用）。
限流的算法
算法 | 原理 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
固定窗口计数器 | 固定时间窗口内统计请求数，超限拒绝。 | 实现简单，内存消耗低。 | 窗口边界可能出现流量突刺。 | 对流量突发不敏感的低频接口限流。 |
滑动窗口计数器 | 将**时间窗口划分为小窗口，**统计滑动窗口内总请求数。 | 精度高，缓解边界突刺问题。 | 实现复杂，内存占用略高。 | API网关、高频接口限流。 |
漏桶算法 | 以恒定速率处理请求，桶满则拒绝。 | 流量绝对平滑，避免突发冲击。 | 无法利用系统空闲资源处理突发流量。 | 音视频流控等严格平滑场景。 |
令牌桶算法 | 固定速率生成令牌，请求需获取令牌。 | 允许突发流量，灵活性高。 | 突发可能耗尽令牌导致后续限流。 | 网络流量控制等需兼顾突发能力的场景。 |
分布式令牌桶（就是令牌桶的不同实现） | 使用中心化存储（如Redis）维护全局令牌桶，原子操作保证一致性。 | 支持全局限流，多节点协同。 | 依赖中心存储的性能和可用性。 | 分布式系统全局限流（如秒杀活动）。 |
固定时间窗口
滑动窗口计数
漏桶算法
令牌桶算法
限流策略
限流策略是基于限流算法的更加复杂的应用。
策略 | 原理 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
自适应限流 | 根据系统负载（CPU、内存、响应时间）动态调整阈值。 | 灵活适应系统状态变化。 | 实现复杂，依赖监控指标。 | 云原生、微服务动态资源分配场景。 |
基于响应时间的限流 | 根据请求响应时间调整限流阈值（如响应超长则触发限流）。 | 直接保护系统免受过载影响。 | 存在滞后性（响应变长时可能已过载）。 | 延迟敏感的服务（如支付系统）。 |
分片限流 | 按用户、服务或区域分片，各分片独立限流。 | 避免全局限流的单点瓶颈。 | 配置复杂度高。 | 多租户系统或地理分布服务。 |
排队等待 | 超限请求放入队列等待处理，而非直接拒绝。 | 提升用户体验（减少拒绝）。 | 队列过长可能导致延迟飙升。 | 异步任务处理（如消息队列）。 |
预热启动 | 系统冷启动时逐步增加限流阈值，避免瞬间流量压垮系统。 | 平滑过渡到高负载状态。 | 冷启动阶段可能限制吞吐量。 | 服务启动或长时间低负载后恢复。 |
对比说明：
- 1. 流量控制精度：滑动窗口 > 固定窗口 > 漏桶/令牌桶。
- 2. 突发处理能力：令牌桶 > 漏桶 > 滑动窗口。
- 3. 实现复杂度：自适应限流 > 分布式限流 > 基础算法。
- 4. 适用扩展性：分布式限流 > 分片限流 > 单机算法。
可根据实际场景组合使用（如令牌桶+滑动窗口提升突发处理与精度）
本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2025-04-25，如有侵权请联系 cloudcommunity@tencent 删除架构流量算法系统服务本文标签： 架构必知的限流算法
版权声明：本文标题：架构必知的限流算法 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://it.en369.cn/jiaocheng/1747517495a2170249.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论