限流算法对比表格
| 算法类型 | 核心原理 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|---|
| 固定窗口 | 将时间划分为固定长度窗口（如1秒），每个窗口内允许固定数量请求。 | - 实现简单 - 计算成本低 | - 窗口边界流量突刺（双倍流量风险） - 精度低 | 简单低频控制（如短信验证码、低频接口） |
| 滑动窗口 | 将时间划分为多个子窗口，动态统计最近N个单位时间内的总请求量。 | - 流量控制更平滑 - 精度较高 | - 内存占用高（需维护子窗口） - 实现复杂度高 | 高精度控制（如API网关、分布式服务） |
| 令牌桶 | 系统以恒定速率生成令牌到桶中，请求需获取令牌才能通过，允许突发消费。 | - 支持突发流量 - 弹性限流 | - 突发可能导致过载 - 时间精度依赖时钟同步 | 允许突发的场景（如秒杀系统、网络流量整形） |
| 漏桶 | 请求像水一样进入漏桶，以恒定速率流出处理，强制平滑流量。 | - 绝对流量平滑 - 保护下游系统 | - 不支持突发 - 请求延迟可能较高 | 恒定速率处理（如数据库写入、日志采集） |
对比说明
- 流量突刺问题
-
- 固定窗口在窗口切换时可能允许双倍流量（如1秒窗口最后100ms+下个窗口前100ms）
- 滑动窗口通过子窗口划分避免该问题
- 令牌桶允许突发但可控，漏桶完全平滑
- 典型应用
-
- Nginx限流模块：固定窗口+滑动窗口
- Guava RateLimiter：令牌桶
- Kafka生产者：漏桶算法控制吞吐
- Redis + Lua：滑动窗口（分布式场景）
选型建议
- 需要允许突发流量 → 令牌桶（如秒杀场景）
- 严格保护下游系统 → 漏桶（如数据库限流）
- 高精度控制 → 滑动窗口（如API网关）
- 简单快速实现 → 固定窗口（低频接口）
算法实现如下：
顶层接口
抽象类，模板方法设计模式
固定窗口算法实现
滑动窗口算法实现
漏斗算法实现
令牌桶算法实现
如何在在项目中使用限流算法，思路如下，自定义注解，利用Spring的AOP机制进行拦截
自定义注解
AOP
目前我们利用AOP与自己写的限流算法实现了一个限流框架，但是我们框架还有一下的不足。
1.不支持分布式的限流算法
2.不支持用户自定义限流算法
下一章我们继续完善我们框架
获取方式 扫码，关注后，
发送：002
**Springboot3
Springboot · 目录**
上一篇Springboot技术专家 从0到1基于模板模式实现自己的服务限流框架（下）
