拒绝服务雪崩!4种经典限流算法图文详解(附Java实战代码)

简介: 限流是保护系统的“保险丝”,防止突发流量导致服务雪崩。常见算法有:固定窗口(简单但有突刺)、滑动窗口(精准平滑)、漏桶(恒定处理速率)和令牌桶(允许突发,最常用)。单机限流可用计数器或Guava,分布式场景则依赖Redis实现全局控制。

为什么要限流?

想象一下,你开了一家网红奶茶店,只有3名店员做奶茶。

  • 正常情况:每分钟来5个客人,店员从容应对,大家都很开心。
  • 突发情况:由于某音爆火,突然一分钟涌入100个客人!

如果不做任何限制,店员会瞬间手忙脚乱,点单系统崩溃,甚至做错饮料,最后所有客人都得不到服务(服务雪崩)。

限流(Rate Limiting) 就是为了解决这个问题:在流量过大时,通过限制请求速率,牺牲一部分请求,来保证系统的整体可用性。


1. 固定窗口算法 (Fixed Window)

原理

这是最简单粗暴的算法。我们规定单位时间(比如1秒)内,只能处理固定数量(比如5个)的请求。

  • 维护一个计数器。
  • 每来一个请求,计数器+1。
  • 如果计数器超过阈值,拒绝请求。
  • 每过单位时间,计数器清零。

图解

image.png

Java 代码示例

import java.util.concurrent.atomic.AtomicInteger;

public class FixedWindowRateLimiter {
   
    // 阈值:每秒最多5个请求
    private static final int LIMIT = 5; 
    // 窗口大小:1000毫秒
    private static final long WINDOW_SIZE = 1000; 

    private static AtomicInteger counter = new AtomicInteger(0);
    private static long lastTime = System.currentTimeMillis();

    public static synchronized boolean tryAcquire() {
   
        long currentTime = System.currentTimeMillis();
        // 如果当前时间已经超过了上一个窗口,重置计数器
        if (currentTime - lastTime > WINDOW_SIZE) {
   
            counter.set(0);
            lastTime = currentTime;
        }

        // 如果未达到阈值,允许通过
        if (counter.get() < LIMIT) {
   
            counter.incrementAndGet();
            return true;
        }
        return false;
    }
}

致命缺陷:临界突刺

假设限制是 1秒5个
如果在 0.8秒到1.0秒 来了5个请求,1.0秒到1.2秒 又来了5个请求。
虽然每个独立的1秒窗口都没超标,但在 0.8秒到1.2秒 这短短0.4秒内,处理了 10个 请求!这可能会瞬间压垮系统。


2. 滑动窗口算法 (Sliding Window)

原理

为了解决固定窗口的“临界突刺”问题,我们把时间窗口划分得更细。
比如把1秒分成5个小格子(每个200ms)。随着时间流逝,窗口像幻灯片一样平滑地向右移动,每次只丢弃最老的一个小格子。

图解

image.png

Java 代码示例 (简化版思路)

import java.util.LinkedList;
import java.util.Iterator;

public class SlidingWindowRateLimiter {
   
    private static final int LIMIT = 5;
    private static final long WINDOW_SIZE = 1000;

    // 使用链表记录每个请求的时间戳
    private LinkedList<Long> timestamps = new LinkedList<>();

    public synchronized boolean tryAcquire() {
   
        long now = System.currentTimeMillis();

        // 1. 移除窗口之外的过期请求(比如1秒前的)
        while (!timestamps.isEmpty() && (now - timestamps.peekFirst() > WINDOW_SIZE)) {
   
            timestamps.removeFirst();
        }

        // 2. 检查当前窗口内的请求数
        if (timestamps.size() < LIMIT) {
   
            timestamps.addLast(now);
            return true;
        }

        return false;
    }
}

优缺点

  • 优点:解决了流量突刺问题,限流更精准。
  • 缺点:算法稍复杂,需要存储更多的时间戳数据。Sentinel 等主流框架常用此算法。

3. 漏桶算法 (Leaky Bucket)

原理

把请求想象成水,倒入一个漏桶中。

  • 进水:请求进来的速度是不确定的(可能暴增)。
  • 出水:桶底有一个孔,水以固定速率流出(处理请求)。
  • 溢出:如果桶满了,新进来的水(请求)就会被丢弃。

图解

image.png

Java 代码示例

public class LeakyBucketRateLimiter {
   
    private long capacity = 10; // 桶容量
    private long water = 0;     // 当前水量
    private long leakRate = 2;  // 出水速率:每秒2滴
    private long lastTime = System.currentTimeMillis();

    public synchronized boolean tryAcquire() {
   
        long now = System.currentTimeMillis();
        // 计算过去这段时间流出了多少水
        long leakedWater = (now - lastTime) / 1000 * leakRate;

        // 更新水量(不能小于0)
        water = Math.max(0, water - leakedWater);
        lastTime = now;

        // 尝试加水(处理请求)
        if (water < capacity) {
   
            water++;
            return true;
        }
        return false;
    }
}

核心特点

  • 强行削峰填谷:无论外面流量多大,系统内部处理速率永远是恒定的。
  • 适用场景:适合保护那些处理能力有限的稀缺资源(如数据库连接)。

4. 令牌桶算法 (Token Bucket) - 推荐

原理

这是目前最常用的算法(如 Google Guava 的 RateLimiter)。

  • 有一个令牌桶,系统以固定速率往里面放入令牌
  • 请求来了,必须从桶里拿到一个令牌才能被处理。
  • 如果桶满了,令牌就溢出(浪费掉)。
  • 如果桶空了,请求就被拒绝(或等待)。

图解

image.png

漏桶 vs 令牌桶

  • 漏桶:限制了流出速率,不能应对突发流量。
  • 令牌桶:限制了流入速率,但允许突发流量(只要桶里有存货,可以瞬间拿走大量令牌)。

Java 代码示例 (使用 Guava)

工业级开发中,我们通常直接使用 Google Guava 库:

import com.google.common.util.concurrent.RateLimiter;

public class TokenBucketDemo {
   
    // 每秒生成5个令牌
    private static RateLimiter rateLimiter = RateLimiter.create(5.0);

    public static void doSomething() {
   
        // 尝试获取令牌,如果拿不到会阻塞等待(也可以用 tryAcquire 非阻塞)
        rateLimiter.acquire(); 
        System.out.println("处理请求: " + System.currentTimeMillis());
    }
}

5. 进阶:分布式限流

上面的算法都是针对单机的。如果是微服务架构,几十台服务器,怎么办?
这时通常使用 Redis 来实现。

Redisson 分布式限流

利用 Redis 的原子性,结合 Lua 脚本实现全系统的流量控制。

// 伪代码示例
RRateLimiter rateLimiter = redissonClient.getRateLimiter("myKey");
// 初始化:每秒最多10个
rateLimiter.trySetRate(RateType.OVERALL, 10, 1, RateIntervalUnit.SECONDS);

if (rateLimiter.tryAcquire()) {
   
    // 处理业务
} else {
   
    // 限流
}

总结

算法 特点 优点 缺点 适用场景
固定窗口 简单计数 实现极其简单 存在临界突刺问题 流量平稳的简单场景
滑动窗口 细分时间格 解决临界问题,精度高 实现稍繁琐 很多限流框架的底层实现 (如 Sentinel)
漏桶 宽进严出 输出速率恒定,平滑流量 无法处理突发流量 保护下游严格受限的系统
令牌桶 严进宽出 允许突发流量 实现稍复杂 最常用,兼顾稳定与突发 (如 Guava)

希望这篇文章能帮你搞懂限流!如果觉得有用,记得点赞收藏哦!

目录
相关文章
|
存储 缓存 NoSQL
即将开源 | 阿里云 Tair KVCache Manager:企业级全局 KVCache 管理服务的架构设计与实现
阿里云 Tair 联合团队推出企业级全局 KVCache 管理服务 Tair KVCache Manager,通过中心化元数据管理与多后端存储池化,实现 KVCache 的跨实例共享与智能调度。该服务解耦算力与存储,支持弹性伸缩、多租户隔离及高可用保障,显著提升缓存命中率与资源利用率,重构大模型推理成本模型,支撑智能体时代的规模化推理需求。
|
16天前
|
人工智能 安全 调度
AI工程vs传统工程 —「道法术」中的变与不变
本文从“道、法、术”三个层面对比AI工程与传统软件工程的异同,指出AI工程并非推倒重来,而是在传统工程坚实基础上,为应对大模型带来的不确定性(如概率性输出、幻觉、高延迟等)所进行的架构升级:在“道”上,从追求绝对正确转向管理概率预期;在“法”上,延续分层解耦、高可用等原则,但建模重心转向上下文工程与不确定性边界控制;在“术”上,融合传统工程基本功与AI新工具(如Context Engineering、轨迹可视化、多维评估体系),最终以确定性架构驾驭不确定性智能,实现可靠价值交付。
243 39
AI工程vs传统工程 —「道法术」中的变与不变
|
26天前
|
人工智能 安全 API
Nacos 安全护栏:MCP、Agent、配置全维防护,重塑 AI Registry 安全边界
Nacos安全新标杆:精细鉴权、无感灰度、全量审计!
537 65
|
16天前
|
数据采集 人工智能 IDE
告别碎片化日志:一套方案采集所有主流 AI 编程工具
本文介绍了一套基于MCP架构的轻量化、多AI工具代码采集方案,支持CLI、IDE等多类工具,实现用户无感、可扩展的数据采集,已对接Aone日志平台,助力AI代码采纳率分析与研发效能提升。
367 46
告别碎片化日志:一套方案采集所有主流 AI 编程工具
|
23天前
|
SQL 人工智能 分布式计算
从工单、文档到结构化知识库:一套可复用的 Agent 知识采集方案
我们构建了一套“自动提取 → 智能泛化 → 增量更新 → 向量化同步”的全链路自动化 pipeline,将 Agent 知识库建设中的收集、提质与维护难题转化为简单易用的 Python 工具,让知识高效、持续、低门槛地赋能智能体。
282 36
|
2月前
|
存储 消息中间件 Apache
ZooKeeper 实战指南:从入门到场景解析
Apache ZooKeeper是分布式系统的协调核心,本文带你快速搭建环境,掌握Znode操作与Watcher机制,深入理解其在分布式锁、配置管理、服务发现等场景的应用,并解析美团Leaf中的实践案例。
428 169
|
2月前
|
数据采集 人工智能 运维
AgentRun 实战:快速构建 AI 舆情实时分析专家
搭建“舆情分析专家”,函数计算 AgentRun 快速实现从数据采集到报告生成全自动化 Agent。
795 57
|
安全 Java 编译器
阿里巴巴Dragonwell
阿里巴巴Dragonwell

热门文章

最新文章