概述

在微服务、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 编写.

Footnotes

  1. Rate limiting – Wikipedia ↩

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