限流算法对比：高并发场景下的系统保护盾
（常见限流场景示意图）
面试资料福利：2025年最新Java面试宝典已整理，包含分布式、高并发等高频考点👉
百度网盘链接
提取码：9b3g
什么是限流算法？
当面试官问起限流算法，本质是在考察你对高并发场景的系统保护能力。限流算法就像系统的安全阀，当流量洪峰来袭时，通过限制请求数量保证核心服务不崩溃。尤其在分布式系统中，这是必须掌握的基础技能。
主流限流算法详解
计数器法（固定窗口）
这是最简单的限流算法，想象一个计数器：
- 每来一个请求 +1
- 当计数超过阈值（如1000次/分钟）直接拒绝
- 每到新时间窗口重置计数器
优点：实现简单，内存消耗低
缺点：窗口边界可能突发双倍流量（如59秒和1秒的请求挤在一起）
适用场景：对精度要求不高的简单服务
滑动窗口算法
（滑动窗口原理示意）
为解决计数器法的边界问题，滑动窗口将时间切割成多个小格子：
- 每个格子独立计数（如将1分钟分成6个10秒格子）
- 窗口随时间向前滑动
- 当前窗口计数 = 最新N个格子的计数总和
实战技巧：面试中常被追问如何实现滑动窗口，可以提到环形队列或Redis的zset结构（用时间戳作score）
漏桶算法
想象一个底部有孔的桶：
- 请求像水一样流入桶中
- 桶以恒定速率漏水（处理请求）
- 当桶满时新请求被丢弃
关键特点：强行限制处理速率，无论流量多么突发，出口始终匀速。适合需要绝对平滑的场景，但可能造成请求延迟过高。
令牌桶算法
（令牌桶在网关中的典型应用）
这是生产环境最常用的方案：
- 系统以固定速率生成令牌存入桶中
- 请求到达时需获取令牌才能执行
- 桶空时触发限流
核心优势：允许突发流量（只要桶中有令牌），同时保证长期平均速率稳定。Guava RateLimiter就是经典实现。
关键对比维度
| 算法类型 | 平滑度 | 突发流量处理 | 实现复杂度 | 典型应用场景 | |----------------|--------|--------------|------------|--------------------| | 固定窗口计数器 | 低 | 不支持 | ⭐ | 简易API限流 | | 滑动窗口 | 中 | 部分支持 | ⭐⭐ | 网关基础限流 | | 漏桶 | 高 | 不支持 | ⭐⭐⭐ | 流量整形（如支付） | | 令牌桶 | 高 | 支持 | ⭐⭐⭐⭐ | 秒杀、开放平台API |
面试实战技巧
当面试官让你设计限流方案时，可以这样分层回答：
-
明确需求：
“我需要先确认场景需求，比如是要防突发流量还是做平滑控制？系统能接受的延迟范围是多少？” -
算法选择：
“对于电商秒杀这种需要允许短暂突发的场景，我会选令牌桶；如果是支付接口则用漏桶保证绝对平稳” -
分布式实现：
“在分布式环境下，常用Redis+Lua脚本实现原子计数，或通过RedisCell模块直接使用令牌桶”
🚀 面试鸭小贴士：如果你需要开通面试鸭会员解锁更多真题解析，通过面试鸭返利网找我下单可返现25元，海量题库+精准押题帮你快速通关！
关键点回顾：真正理解限流算法的核心在于明白时间窗口与令牌机制的博弈，根据业务容忍度做选择才是工程思维的本质。
