|
Hello 我是方才，10人团队leader、4年架构履历，曾备考1个月拿下软考架构师（49/53/50）
文末，方才送你一份25年最新的架构师备考资料，记得领取哟！
首先我们思考下，为什么需要限流呢？
前面在负载平衡架构中和架构的演化中，方才提到，负载平衡的作用是将流量均分，让集群节点尽可能的均分负载，从而包管对全部效户的可用性。
但系统的资源始终是有限的，不可能一直无穷增加资源，所以就可能出现流量太大，服务器直接瓦解的环境。那这个时候，相比让整个服务器瓦解，就只能牺牲部分用户的体验，通过限流，包管服务器的整体稳定运行，为绝大数用户提供正常服务。
比如说：Trae 的排队机制，就是一种限流手段（大概通过产物层面的计划，比如个税app的提前预约机制，也是限流思维的应用）。
限流的算法
| 算法 | 原理 | 优点 | 缺点 | 适用场景 | | 固定窗口计数器 | 固定时间窗口内统计请求数，超限拒绝。
| 实现简单，内存消耗低。
| 窗口边界可能出现流量突刺。
| 对流量突发不敏感的低频接口限流。
| | 滑动窗口计数器 | 将**时间窗口分别为小窗口，**统计滑动窗口内总请求数。
| 精度高，缓解边界突刺题目。
| 实现复杂，内存占用略高。
| API网关、高频接口限流。
| | 漏桶算法 | 以恒定速率处置惩罚请求，桶满则拒绝。
| 流量绝对平滑，避免突发打击。
| 无法使用系统空闲资源处置惩罚突发流量。
| 音视频流控等严格平滑场景。
| | 令牌桶算法 | 固定速率生成令牌，请求需获取令牌。
| 允许突发流量，机动性高。
| 突发可能耗尽令牌导致后续限流。
| 网络流量控制等需兼顾突发本领的场景。
| 分布式令牌桶（就是令牌桶的差别实现）
| 使用中央化存储（如Redis）维护全局令牌桶，原子操作包管一致性。
| 支持全范围流，多节点协同。
| 依靠中央存储的性能和可用性。
| 分布式系统全范围流（如秒杀运动）。
|
固定时间窗口
滑动窗口计数
漏桶算法
令牌桶算法
限流计谋
限流计谋是基于限流算法的更加复杂的应用。
| 计谋 | 原理 | 优点 | 缺点 | 适用场景 | 自顺应限流
| 根据系统负载（CPU、内存、相应时间）动态调整阈值。
| 机动顺应系统状态变化。
| 实现复杂，依靠监控指标。
| 云原生、微服务动态资源分配场景。
| 基于相应时间的限流
| 根据请求相应时间调整限流阈值（如相应超长则触发限流）。
| 直接掩护系统免受过载影响。
| 存在滞后性（相应变长时可能已过载）。
| 延长敏感的服务（如支付系统）。
| 分片限流
| 按用户、服务或地域分片，各分片独立限流。
| 避免全范围流的单点瓶颈。
| 配置复杂度高。
| 多租户系统或地理分布服务。
| 排队等待
| 超限请求放入队列等待处置惩罚，而非直接拒绝。
| 提升用户体验（减少拒绝）。
| 队列过长可能导致延长飙升。
| 异步使命处置惩罚（如消息队列）。
| 预热启动
| 系统冷启动时逐步增加限流阈值，避免瞬间流量压垮系统。
| 平滑过渡到高负载状态。
| 冷启动阶段可能限制吞吐量。
| 服务启动或长时间低负载后规复。
|
对比阐明：
- 1. 流量控制精度：滑动窗口 > 固定窗口 > 漏桶/令牌桶。
- 2. 突发处置惩罚本领：令牌桶 > 漏桶 > 滑动窗口。
- 3. 实现复杂度：自顺应限流 > 分布式限流 > 基础算法。
- 4. 适用扩展性：分布式限流 > 分片限流 > 单机算法。
可根据实际场景组合使用（如令牌桶+滑动窗口提升突发处置惩罚与精度）。
2025最新的架构师备考资料和备考交流群，扫码即可领取加入：
末了，方才软考架构师刷题系统已经上线了，欢迎各人使用（公众号后台回复【666】，即可一键体验，pc端地点：https://fangcaicoding.cn/papers）。
保举阅读：2025-软考架构教程专栏，助你高效备考
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 | 
