为什么分布式限流会出现不均衡的情况?

为什么,分布式,流会,出现,均衡,情况 · 浏览次数 : 307

小编点评

**分布式限流会出现「限流不均衡」或「限流误差」的原因:** 1. **批量导致的误差:**每次取令牌不是一个一取,而是取一批,不够了再去取一批。这会导致在总的入口做总的流量限制,比如 500,然后每个实例再自己实现限流。 2. **负载均衡负载不均分布式限流:**当使用负载均衡算法(如轮询、最小连接数、最小连接时间等)以及会话保持策略(如:源地址保持、cookie 保持或特定参数的 hash)时,分到每台的请求就可能是不均衡的,比如 a 实例有 70 个,b 实例有 130 个。这时就出现了「限流不均衡」或「限流偏差」的情况。

正文

概述

在微服务、API 化、云原生大行其道的今天,服务治理不可或缺,而服务治理中限流几乎是必不可少的手段;微服务化往往伴随着分布式的架构,那么仅仅单机限流是不够的,还需要分布式的限流。
那么问题就来了:分布式限流中,往往会出现「限流不均衡」或「限流误差」的情况,这是为什么呢?

限流

国庆假期,限流这个词在新闻中应该能频繁听到,就是「景区限流」。这里以无锡的两个景点为例:

📌示例:

  • 无锡蠡园:最大承载量调整至 20000 人;瞬时最大承载量调整至 4000 人;
  • 无锡东林书院:书院接待日最大承载量即时降至 1500 人,瞬时承载量降至 300 人。

在计算机网络中,限流就是用于控制网络接口控制器发送或接收请求的速率[1],由此延伸为:限制到达系统的并发请求数,以此来保障系统的稳定性(特别是在微服务、API 化、云原生系统上)。

常见的限流算法

  1. 固定窗口计数器
  2. 滑动窗口计数器
  3. 漏桶
  4. 令牌桶

单机限流和分布式限流

本质上单机限流和分布式限流的区别就在于「承载量」存放的位置。

单机限流直接在单台服务器上实现,而在微服务、API 化、云原生系统上,应用和服务是集群部署的,因此需要集群内的多个实例协同工作,以提供集群范围的限流,这就是分布式限流。

🤔为什么分布式限流会出现不均衡的情况?

比如上面提到的滑动窗口的算法,可以将计数器存放至 Redis 这样的 KV 数据库中。
例如滑动窗口的每个请求的时间记录可以利用 Redis 的 zset 存储,利用 ZREMRANGEBYSCORE 删除时间窗口之外的数据,再用 ZCARD 计数。

示例代码[2]如下:

package com.lizba.redis.limit;

import redis.clients.jedis.Jedis;
import redis.clients.jedis.Pipeline;
import redis.clients.jedis.Response;

/**
 * <p>
 *     Limiting current by sliding window algorithm through zset
 * </p>
 *
 * @Author: Liziba
 * @Date: 2021/9/6 18:11
 */
public class SimpleSlidingWindowByZSet {

    private Jedis jedis;

    public SimpleSlidingWindowByZSet(Jedis jedis) {
        this.jedis = jedis;
    }

    /**
     * Judging whether an action is allowed
     *
     * @param userId        User id
     * @param actionKey     Behavior key
     * @param period        Current Limiting Cycle
     * @param maxCount      Maximum number of requests (sliding window size)
     * @return
     */
    public boolean isActionAllowed(String userId, String actionKey, int period, int maxCount) {
        String key = this.key(userId, actionKey);
        long ts = System.currentTimeMillis();
        Pipeline pipe = jedis.pipelined();
        pipe.multi();
        pipe.zadd(key, ts, String.valueOf(ts));
        // Remove data other than sliding windows
        pipe.zremrangeByScore(key, 0, ts - (period * 1000));
        Response<Long> count = pipe.zcard(key);
        // Set the expiration time of the behavior, and if the data is cold, zset will be deleted to save memory space
        pipe.expire(key, period);
        pipe.exec();
        pipe.close();
        return count.get() <= maxCount;
    }


    /**
     * Current limiting key
     *
     * @param userId
     * @param actionKey
     * @return
     */
    public String key(String userId, String actionKey) {
        return String.format("limit:%s:%s", userId, actionKey);
    }

}
复制

像令牌桶也可以将令牌数量放到 Redis 中。

🧠答案一:批量导致的误差

不过以上的方式相当于每一个请求都需要去 Redis 判断一下能不能通过,在性能上有一定的损耗,所以针对大并发系统,有个优化点就是 「批量」。例如每次取令牌不是一个一取,而是取一批,不够了再去取一批。这样可以减少对 Redis 的请求。
但是,批量获取就会导致一定范围内的限流误差。比如 a 实例此刻取了 100 个,等下一秒再用,那下一秒集群总承载量就有可能超过阈值。

这是一种原因。

🧠答案二:负载均衡负载不均

分布式限流还有一种做法是「平分」,比如之前单机限流 100,现在集群部署了 5 个实例,那就让每台继续限流 100,即在总的入口做总的流量限制,比如 500,然后每个实例再自己实现限流。
这种情况下,假设总的入口放入了 500 请求,这些请求需要通过负载均衡算法(如:轮询、最小连接数、最小连接时间等)以及会话保持策略(如:源地址保持、cookie 保持或特定参数的 hash),分到每台的请求就可能是不均衡的,比如 a 实例有 70 个,b 实例有 130 个。那么 a 实例的 70 个会通过,而 b 实例的 130 个可能只有 100 个会通过。这时就出现了「限流不均衡」或「限流偏差」的情况。

这是第二种原因。

总结

由于本人经验所限,本文只列出了我目前能想到的 2 个答案给大家参考,欢迎各位交流补充。
真实的业务场景是很复杂的,具体到一个工程,限流需要考虑的条件和资源有很多。我们要做的就是通过估算、压测、试运行、调整、再生产验证再调整来逼近理想情况。

三人行, 必有我师; 知识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.


  1. Rate limiting - Wikipedia ↩︎

  2. Redis zset for sliding window current limiting (programmer.group) ↩︎

与为什么分布式限流会出现不均衡的情况?相似的内容:

为什么分布式限流会出现不均衡的情况?

概述 在微服务、API 化、云原生大行其道的今天,服务治理不可或缺,而服务治理中限流几乎是必不可少的手段;微服务化往往伴随着分布式的架构,那么仅仅单机限流是不够的,还需要分布式的限流。 那么问题就来了:分布式限流中,往往会出现「限流不均衡」或「限流误差」的情况,这是为什么呢? 限流 国庆假期,限流这

详解Redisson分布式限流的实现原理

摘要:本文将详细介绍下RRateLimiter的具体使用方式、实现原理还有一些注意事项。 本文分享自华为云社区《详解Redisson分布式限流的实现原理》,作者: xindoo。 我们目前在工作中遇到一个性能问题,我们有个定时任务需要处理大量的数据,为了提升吞吐量,所以部署了很多台机器,但这个任务在

大厂内部的压测方案设计分享!

01为什么要做压测 1、什么是压力测试? 不断向被测对象施加压力,测试系统在压力情况下的表现。 2、压力测试的目的是什么? 测试得出系统的极限性能指标,从而给出合理的承诺值或者容量告警; 找出系统的性能瓶颈,对性能做出优化; 测试系统在高负载情况下的稳定性; 验证系统在过载情况下的限流和降级预案;

4.4 x64dbg 绕过反调试保护机制

在Windows平台下,应用程序为了保护自己不被调试器调试会通过各种方法限制进程调试自身,通常此类反调试技术会限制我们对其进行软件逆向与漏洞分析,我们以第一种`IsDebuggerPresent`反调试为例,该函数用于检查当前程序是否在调试器的环境下运行。函数返回一个布尔值,如果当前程序正在被调试,则返回True,否则返回False。函数通过检查特定的内存地址来判断是否有调试器在运行。具体来说,该

大文件分卷压缩方法

大文件的传输一般都会受到尺寸限制,针对这一问题,本文介绍如何利用7-zip压缩工具,将大文件拆分成若干小文件进行分卷压缩传输,以及如何将压缩后的若干小文件合并解压,恢复原始文件。

TiDB的简单介绍以及进行资源限制的方式与方法

TiDB的简单介绍以及进行资源限制的方式与方法 TiDB的简介 TiDB是一个分布式数据库, 简介为: TiDB 是一个开源的分布式关系型数据库,它兼具了分布式数据库的水平扩展性和传统关系型数据库的 ACID 事务特性。 TiDB 最初由 PingCAP 公司开发,并于 2015 年开源发布。创始人

[转帖]innodb表最大列数限制

https://blog.csdn.net/sun_ashe/article/details/52433812 innodb 最大列数限制为1023,其中包含3个内部隐藏列,分别为:DB_ROW_ID(如果没有主键的情况), DB_TRX_ID事务id列,DB_ROLL_PTR回滚指针列。 但是分配

解密IP分片与重组:数据传输中的关键技术

本文介绍了IP分片与重组的工作原理及其在数据传输中的重要性。IP分片将大数据包分割为小分片进行传输,重组则将其重新组合为完整数据包。这种技术能适应不同网络链路的传输单元限制,提高传输效率和可靠性。随着IPv4地址枯竭,IPv6的采用越来越普遍,了解IP分片与重组对于网络优化和IPv6部署至关重要。

华为云CodeArts Req需求管理工具,7大特性限时免费体验

摘要:一图了解什么是华为云CodeArts Req 本文分享自华为云社区《华为云CodeArts Req需求管理工具,7大特性限时免费体验》,作者:华为云PaaS服务小智。 一图了解什么是华为云CodeArts Req。 点击关注,第一时间了解华为云新鲜技术~

论文分享丨Holistic Evaluation of Language Models

摘要:该文为大模型评估方向的综述论文。 本文分享自华为云社区《【论文分享】《Holistic Evaluation of Language Models》》,作者:DevAI。 大模型(LLM)已经成为了大多数语言相关的技术的基石,然而大模型的能力、限制、风险还没有被大家完整地认识。该文为大模型评估