拒绝服务雪崩!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)

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

目录
相关文章
|
Java 数据安全/隐私保护 Sentinel
面试官:Sentinel是如何实现限流的?
面试官:Sentinel是如何实现限流的?
1982 1
|
安全 Java 编译器
阿里巴巴Dragonwell
阿里巴巴Dragonwell
|
NoSQL 算法 Java
Java Redis多限流
通过本文的介绍,我们详细讲解了如何在Java中使用Redis实现三种不同的限流策略:固定窗口限流、滑动窗口限流和令牌桶算法。每种限流策略都有其适用的场景和特点,根据具体需求选择合适的限流策略可以有效保护系统资源和提高服务的稳定性。
407 18
|
8月前
|
算法 网络协议 Java
Spring Boot 的接口限流算法
本文介绍了高并发系统中流量控制的重要性及常见的限流算法。首先讲解了简单的计数器法,其通过设置时间窗口内的请求数限制来控制流量,但存在临界问题。接着介绍了滑动窗口算法,通过将时间窗口划分为多个格子,提高了统计精度并缓解了临界问题。随后详细描述了漏桶算法和令牌桶算法,前者以固定速率处理请求,后者允许一定程度的流量突发,更符合实际需求。最后对比了各算法的特点与适用场景,指出选择合适的算法需根据具体情况进行分析。
728 56
Spring Boot 的接口限流算法
|
缓存 NoSQL 关系型数据库
Redis与MySQL的数据一致性
在高并发环境下,保持 Redis 和 MySQL 的数据一致性是一个复杂但重要的问题。通过采用读写穿透、写穿透、分布式锁、双写一致性保障和延时双删策略,可以有效地减少数据不一致的风险,确保系统的稳定性和可靠性。通过合理的缓存策略和数据同步机制,可以显著提升系统的性能和用户体验。
637 22
|
算法 NoSQL Java
springboot整合redis及lua脚本实现接口限流
springboot整合redis及lua脚本实现接口限流
779 0
|
存储 算法 安全
HashMap的实现原理,看这篇就够了
关注【mikechen的互联网架构】,10年+BAT架构经验分享。深入解析HashMap,涵盖数据结构、核心成员、哈希函数、冲突处理及性能优化等9大要点。欢迎交流探讨。
HashMap的实现原理,看这篇就够了
|
消息中间件 JSON Java
Spring Boot、Spring Cloud与Spring Cloud Alibaba版本对应关系
Spring Boot、Spring Cloud与Spring Cloud Alibaba版本对应关系
32605 0
|
人工智能 自然语言处理 Java
Spring AI,Spring团队开发的新组件,Java工程师快来一起体验吧
文章介绍了Spring AI,这是Spring团队开发的新组件,旨在为Java开发者提供易于集成的人工智能API,包括机器学习、自然语言处理和图像识别等功能,并通过实际代码示例展示了如何快速集成和使用这些AI技术。
Spring AI,Spring团队开发的新组件,Java工程师快来一起体验吧