分布式系统架构5：限流设计模式

2024-12-22 44

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 本文是小卷关于分布式系统架构学习的第5篇，重点介绍限流器及4种常见的限流设计模式：流量计数器、滑动窗口、漏桶和令牌桶。限流旨在保护系统免受超额流量冲击，确保资源合理分配。流量计数器简单但存在边界问题；滑动窗口更精细地控制流量；漏桶平滑流量但配置复杂；令牌桶允许突发流量。此外，还简要介绍了分布式限流的概念及实现方式，强调了限流的代价与收益权衡。

这是小卷对分布式系统架构学习的第5篇文章，今天来学习限流器和限流设计模式

1.为什么要限流？

任何一个系统的运算、存储、网络资源都不是无限的，当系统资源不足以支撑外部超过预期的突发流量时，就应该要有取舍，建立面对超额流量自我保护的机制，而这个机制就是微服务中常说的“限流”

2.四种限流设计模式

说到限流，大家直接的想法就是Sentinel，但是Sentinel限流的原理可能很多人没去深入理解，或者限流到底是怎么做的？具体如何进行限流，业界内也有一些常见设计模式。

2.1流量计数器模式

流量计数器是一种最简单的限流方式，通过记录固定时间窗口内的请求次数来判断是否达到限流阈值。如果请求次数超过限制值，则拒绝后续请求。

实现方式：

将时间划分为固定的时间窗口（如 1 秒、1 分钟）。
每个窗口维护一个计数器，记录当前时间窗口内的请求次数。
如果计数器值超过限流阈值，直接拒绝请求；否则增加计数器。

固定窗口边界问题：

在窗口边界的两端，可能存在短时间内超量请求的“临界问题”

比如场景设定：一秒内的TPS大于80时，就限流。

存在问题：即使每一秒的统计流量都没有超过 80 TPS，也不能说明系统没有遇到过大于 80 TPS 的流量压力。比如说系统在连续2秒内都收到60TPS的请求，但是请求发生的时间分别在第1秒的后0.5秒，以及第2秒的前0.5秒。这样系统实际曾在1秒内发生超过80 TPS的请求。

即使连续若干秒统计流量超过阈值，也不能说明流量压力一定超过系统承受能力

假设 10 秒的时间片段中，前 3 秒的 TPS 平均值到了 100，而后 7 秒的平均值是 30 左右，此时系统是否能够处理完这些请求而不产生超时失败？答案是可以的

存在缺陷：造成上面2个问题得原因是流量计数器模式是对时间点进行离散的统计

2.2滑动窗口模式

概念：时间轴上，一个固定大小的窗口随时间平滑滚动。任何时刻，静态地通过窗口内观察到的信息，都等价于一段长度与窗口大小相等的信息。主要是通过记录多个较小时间窗口（子窗口）的请求次数，实现更精细化的限流控制。

假设：准备观察的时间片段为 10 秒，以 1 秒作为统计精度，那可以得到一个长度为 10 的数组。设定限流阈值是最近 10 秒内收到的请求不超过 500 个，那么就需要统计10个子数组的请求总数，是否超过阈值。

限流设计模式1.png

优点：

解决了固定窗口边界问题

缺点：

只适用于否决式限流，超过阈值的流量就必须失败

2.3漏桶模式

漏桶可以简单的理解：小学水池应用题，一个水池，每秒以 X 升速度注水，同时又以 Y 升速度出水，问水池啥时候装满。

概念：将请求视为流入漏桶的水，漏桶以固定速率“漏水”。当请求流量超过漏桶的处理能力时，多余的请求会被丢弃或排队。其核心思想是平滑请求流量

实现方式：

维护一个队列（或计数器），用来模拟漏桶。
新请求到来时，将请求放入桶中。
按固定速率处理桶中的请求。
如果桶已满，则拒绝新请求。

缺点：

比较难确定桶的大小和水流出的速度

2.4令牌桶算法

和漏桶一样是基于缓冲区的限流算法，简单理解就是去银行办事时在排队机号取号的场景。

概念：通过固定速率向桶中添加令牌，请求到来时需要先消耗令牌才能被处理。如果桶中没有足够的令牌，请求会被拒绝。与漏桶算法不同，令牌桶允许一定的突发流量。

实现方式

维护一个桶，桶中存储令牌。
按固定速率（比如限流是1秒100次请求，那么间隔10ms时间放入令牌）向桶中添加令牌，直到桶满为止。
请求到来时从桶中取出令牌，如果没有令牌就马上失败或者进入降级逻辑。

实际开发的时候，不需要专门做放令牌到桶里这件事，只需要在获取令牌前，比较一下时间戳与当前时间，就能算出需要放入多少令牌，下面是示例代码：

private long lastTime = System.currentTimeMillis();
private int tokens = 0; // 当前令牌数
private static final int LIMIT = 100; // 桶容量
private static final int REFILL_RATE = 10; // 令牌添加速率（令牌/秒）

public synchronized boolean tryAcquire() {
   
    long now = System.currentTimeMillis();
    // 添加令牌
    tokens = Math.min(LIMIT, tokens + (int) ((now - lastTime) / 1000) * REFILL_RATE);
    lastTime = now;

    if (tokens > 0) {
   
        tokens--;
        return true;
    }
    return false;
}

3.分布式限流

上面介绍的4种限流算法都只适用于单机限流，或者把系统当做整体来限流。实际应用中仍然需要精细的每个服务的限流。

概念：过将限流逻辑分散到多个节点，同时使用一致性算法保证全局限流的一致性。它结合了本地限流和集中式限流的优点。

实现方式

基于 Redis + Lua 脚本
- 使用 Redis 脚本实现分布式限流，在 Redis 中存储全局的请求计数器
基于一致性算法
- 使用分布式一致性算法（如 Raft、Paxos）维护全局流量状态
分布式网关
- 通过 API 网关（如 Kong、Nginx、Spring Cloud Gateway）实现流量的统一调度和限流。

缺点：

实现复杂度高，且网络通信和一致性操作带来额外延迟。当流量大时，限流本身会降低系统处理能力

总结

今天学习了4种限流设计模式：流量计数器模式、滑动窗口模式、漏桶模式、令牌桶模式，后面2种都是基于缓冲区的限流算法。简单了解了下分布式限流的概念。限流本身是有代价的，实际开发中需要权衡方案的代价和收益。后续有时间补充Sentinel的限流原理和其中用了哪些设计模式。

分布式系统架构5：限流设计模式

1.为什么要限流？