CN114189478A - 一种基于滑动窗口算法的分布式限流实现方法及系统 - Google Patents

Abstract

本发明公开了一种基于滑动窗口算法的分布式限流实现方法及系统，属于云原生领域；所述的方法具体步骤如下：S1利用Redis对限流数据的存储进行选型；S2选用Redis中的ZSet数据类型作为滑动窗口限流的技术资源；S3在Redis中设置唯一标识作为ZSet的key；S4利用Redis的资源回收机制给每个API的限流资源池设置存活时间；S5基于滑动窗口算法，将请求的Key设置为请求进入时刻的毫秒级时间戳+Redis中的自增Key对应的value数值；S6设置规则对API的流量进行计数并限制；本发明通过使用集群内部署的Redis集群作为限流功能的主要实现组件，保证了网关限流服务的云原生化和对集群环境的高适配性，符合当下大环境对服务生态的基本需求。

Description

一种基于滑动窗口算法的分布式限流实现方法及系统

技术领域

本发明公开一种基于滑动窗口算法的分布式限流实现方法及系统，涉及云原生技术技术领域。

背景技术

随着云原生技术的不断发展，以Kubernetes为代表的容器技术正成为云计算新界面。云原生网关服务在高可用、多实例的业务场景下，如何保证精准的分布式限流，变成了云原生网关的基本问题；常见的限流方案有基于漏桶算法的限频限流，基于令牌桶的按总量限流，但上述方案均会导致不同的问题。基于漏桶算法的限流策略在分布式架构下实现时需要每次更新都加锁，以保证漏桶算法的流量控制策略；基于令牌桶的限流策略会导致令牌桶重置令牌动作的前后流量总量超过设定的单位时间限流次数；故现发明一种基于滑动窗口算法的分布式限流实现方法及系统，以解决上述问题。

发明内容

本发明针对现有技术的问题，提供一种基于滑动窗口算法的分布式限流实现方法及系统，所采用的技术方案为：一种基于滑动窗口算法的分布式限流实现方法，所述的方法具体步骤如下：

S1利用Redis对限流数据的存储进行选型；

S2选用Redis中的ZSet数据类型作为滑动窗口限流的技术资源；

S3在Redis中设置唯一标识作为ZSet的key；

S4利用Redis的资源回收机制给每个API的限流资源池设置存活时间；

S5基于滑动窗口算法，将请求的Key设置为请求进入时刻的毫秒级时间戳+Redis中的自增Key对应的value数值；

S6设置规则对API的流量进行计数并限制。

所述S2选用Redis中的ZSet数据类型作为滑动窗口限流的技术资源的具体步骤如下：

S201记录单位时间内的请求，并利用Redis为每个存储数据成员关联一个分数；

S202利用redis通过分数来为集合中的成员进行从小到大的排序；

S203利用Redis限制请求次数并计算单位时间窗口内的请求数量。

所述S4利用Redis的资源回收机制给每个API的限流资源池设置存活时间的具体步骤如下：

S401运用Redis的资源回收机制对API限流资源池设置与限流周期一致的存活时间；

S402每次拦截API请求时更新限流池的存活时间；

S403在数据无效后自动删除滑动窗口数据。

所述S5基于滑动窗口算法，将请求的Key设置为请求进入时刻的毫秒级时间戳+Redis中的自增Key对应的value数值的具体步骤如下：

S501在Redis中维护一个自增Key，当每进入一个请求就将其加一；

S502拼接毫秒级别时间戳作为请求进入的Key；

S503将请求进入的秒级时间戳作为分数保存给ZSet中指定的Key作为Value值。

所述S6针对每个被限流的API设置多个滑动窗口流量计数池，按照优先级对API进行分布式精准流量限制的具体步骤如下：

S601在记录API请求时将当前限流时间窗口的开始时间作为过期分数节点，将ZSet中分数小于过期分数节点的Key进行批量失效；

S602计算失效后的剩余有效请求数量，与单位时间内允许通过的限流次数进行对比；

S603若小于限流次数，则允许通过并按照规则保存进ZSet；

S604若大于等于限流次数，则拦截本次请求，不允许通过。

一种基于滑动窗口算法的分布式限流实现系统，所述的系统具体包括存储选型模块、资源选定模块、标识设置模块、时间设置模块、数值设置模块和规则设置模块：

存储选型模块：利用Redis对限流数据的存储进行选型；

资源选定模块：选用Redis中的ZSet数据类型作为滑动窗口限流的技术资源；

标识设置模块：在Redis中设置唯一标识作为ZSet的key；

时间设置模块：利用Redis的资源回收机制给每个API的限流资源池设置存活时间；

数值设置模块：基于滑动窗口算法，将请求的Key设置为请求进入时刻的毫秒级时间戳+Redis中的自增Key对应的value数值；

规则设置模块：设置规则对API的流量进行计数并限制。

所述资源选定模块具体包括分数关联模块、成员排序模块和请求计算模块：

分数关联模块：记录单位时间内的请求，并利用Redis为每个存储数据成员关联一个分数；

成员排序模块：利用redis通过分数来为集合中的成员进行从小到大的排序；

请求计算模块：利用Redis限制请求次数并计算单位时间窗口内的请求数量。

所述时间设置模块具体包括时间统一模块、时间更新模块和数据删除模块：

时间统一模块：运用Redis的资源回收机制对API限流资源池设置与限流周期一致的存活时间；

时间更新模块：每次拦截API请求时更新限流池的存活时间；

数据删除模块：在数据无效后自动删除滑动窗口数据。

所述数值设置模块具体包括自增维护模块、请求拼接模块和分数保存模块：

自增维护模块：在Redis中维护一个自增Key，当每进入一个请求就将其加一；

请求拼接模块：拼接毫秒级别时间戳作为请求进入的Key；

分数保存模块：将请求进入的秒级时间戳作为分数保存给ZSet中指定的Key作为Value值。

所述规则设置模块针对每个被限流的API设置多个滑动窗口流量计数池，按照优先级对API进行分布式精准流量限制，规则设置模块具体包括节点处理模块、请求核算模块、请求保存模块和请求拦截模块：

节点处理模块：在记录API请求时将当前限流时间窗口的开始时间作为过期分数节点，将ZSet中分数小于过期分数节点的Key进行批量失效；

请求核算模块：计算失效后的剩余有效请求数量，与单位时间内允许通过的限流次数进行对比；

请求保存模块：若小于限流次数，则允许通过并按照规则保存进ZSet；

请求拦截模块：若大于等于限流次数，则拦截本次请求，不允许通过。

本发明的有益效果为：本发明方法对于限流业务的有益效果如下：

通过使用集群内部署的Redis集群作为限流功能的主要实现组件，保证了网关限流服务的云原生化和对集群环境的高适配性，符合当下大环境对服务生态的基本需求；

通过选用Redis中自带的ZSet作为存储限流池的数据类型，减少了自定义数据存储规则带来的额外工作量和复杂度，降低了异常发生的机率，增加了功能的健壮性；

通过全局自增保证了任意时刻的API请求都能被准确记录并按照流量限制需求进行限流，最大限度保护上游服务安全；

通过对资源设置有效期，避免了对资源的无效占用，达到了对资源的高利用率和良好的资源回收机制；

通过滑动窗口算法实现API限流规则，保证了任意单位限流时间内，API的访问数量被限制在用户设置的限流规则内，实现了流量的精准限制。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本发明方法的流程图；图2是发明的设计结构示意图；图3是本发明实施例的流量限流逻辑图。

具体实施方式

下面结合附图和具体实施例对本发明作进一步说明，以使本领域的技术人员可以更好地理解本发明并能予以实施，但所举实施例不作为对本发明的限定。

实施例一：

一种基于滑动窗口算法的分布式限流实现方法，所述的方法具体步骤如下：

S1利用Redis对限流数据的存储进行选型；

S2选用Redis中的ZSet数据类型作为滑动窗口限流的技术资源；

S3在Redis中设置唯一标识作为ZSet的key；

S4利用Redis的资源回收机制给每个API的限流资源池设置存活时间；

S5基于滑动窗口算法，将请求的Key设置为请求进入时刻的毫秒级时间戳+Redis中的自增Key对应的value数值；

S6设置规则对API的流量进行计数并限制；

首先对限流数据存储进行选型，Redis(Remote Dictionary Server)，即远程字典服务，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API，与我们目前的LUA技术栈较为契合；因此我们选择在Kubernetes集群中部署Redis集群作为网关的CAS限流资源存放中心；对比于常规的本地限流，Redis可以支撑较高的并发量，使用Redis可以最大减轻流控对用户请求产生的额外延迟；

所述S2选用Redis中的ZSet数据类型作为滑动窗口限流的技术资源的具体步骤如下：

S201记录单位时间内的请求，并利用Redis为每个存储数据成员关联一个分数；

S202利用redis通过分数来为集合中的成员进行从小到大的排序；

S203利用Redis限制请求次数并计算单位时间窗口内的请求数量；

针对Redis中支持的多种数据类型，参照我们的业务需求，首先对单位时间内的请求进行计录，其次需要保存该数据的数据标识与数据产生时间；因此我们在进行比对分析后，选用Redis中的ZSet数据类型作为滑动窗口限流的计数资源，ZSet(sorted set)作为string类型元素的集合，存储数据成员具有不允许重复的特性，同时每个成员元素都会关联一个分数(分数可以重复)，redis通过分数来为集合中的成员进行从小到大的排序；对比于常规流控算法只对请求次数进行限制，本次选用的方案，在计次之外，额外保留了唯一标识与请求时间，运用ZSet的数据特性，可以相对简便的划定时间窗口，计算单位时间窗口内的请求数量；

对分布式限流业务而言，针对每个请求保留其唯一标识，是保证流量限制精准性的有效依据，我们选择按照S3在Redis中设置唯一标识作为ZSet的key，同时可以保证限流资源池中每次请求的唯一性，保证限流资源池中不会出现重复等错误记录；对比常规限流，我们保留了请求的唯一标识，通过唯一标识，可以保证不会出现重复计数等问题，保证了限流功能的准确性，且通过设计存储规则，并使用ZSet数据结构的数据特性，保证限流操作的稳定高效

所述S4利用Redis的资源回收机制给每个API的限流资源池设置存活时间的具体步骤如下：

S401运用Redis的资源回收机制对API限流资源池设置与限流周期一致的存活时间；

S402每次拦截API请求时更新限流池的存活时间；

S403在数据无效后自动删除滑动窗口数据；

给每个API的限流资源池设置存活时间，存活时间与限流周期一致，并在每次拦截API请求时更新限流资源池的存活时间，保证有效数据的存活，以及无效数据的及时清理，设置存活时间，可以运用Redis本身的资源回收机制，减少额外的资源回收操作，减少对Redis的额外操作请求，减轻Redis负担；对比常规的漏桶算法，需要在共享存储中持续保存令牌桶数据，导致不必要的存储资源浪费，我们本次设计的方案，针对这种常见现象，设置滑动窗口有效寿命，保证在数据有效的情况下，滑动窗口数据存活，数据无效后，滑动窗口数据自动删除，提高了资源利用率，减少了对存储资源的长时间占用；

所述S5基于滑动窗口算法，将请求的Key设置为请求进入时刻的毫秒级时间戳+Redis中的自增Key对应的value数值的具体步骤如下：

S501在Redis中维护一个自增Key，当每进入一个请求就将其加一；

S502拼接毫秒级别时间戳作为请求进入的Key；

S503将请求进入的秒级时间戳作为分数保存给ZSet中指定的Key作为Value值；

在之前的设计中我们已经选用Redis作为CAS流量限制中心，并为每个限流API的限流资源池设置了唯一Key，之后需要在ZSet中按照规则记录每次请求，S5我们基于滑动窗口算法，将请求的Key设置为请求进入时刻的毫秒级时间戳+Redis中的自增Key对应的value数值，此处为保证高并发场景下的每个API都可以收到安全的流量限制保护，我们在Redis中维护一个自增Key当每进入一个请求，就将其加一，并拼接毫秒级时间戳作为请求进入的Key；对比于常规单体限流场景，我们使用Redis自增Key作为全局唯一标识，既保证了唯一Key的生成效率，还保证了分布式情况下的请求唯一性；

其次我们需要设置一个Value值，基于滑动窗户算法，并结合ZSet的数据存储特性，以及我们目前业务逻辑的流量限制时间粒度；我们将请求进入的秒级时间戳作为分数保存给ZSet中指定的Key作为Value值；对比于常规单体限流场景，我们将请求时间戳保存为Value内容，这样做可以很轻易的计算出单位时间内的请求数量

所述S6针对每个被限流的API设置多个滑动窗口流量计数池，按照优先级对API进行分布式精准流量限制的具体步骤如下：

S601在记录API请求时将当前限流时间窗口的开始时间作为过期分数节点，将ZSet中分数小于过期分数节点的Key进行批量失效；

S602计算失效后的剩余有效请求数量，与单位时间内允许通过的限流次数进行对比；

S603若小于限流次数，则允许通过并按照规则保存进ZSet；

S604若大于等于限流次数，则拦截本次请求，不允许通过；

再次我们需要设置一个规则用来对API的流量进行计数并限制，我们的业务逻辑设计为在每次记录API请求时，根据当前时间计算当前所在限流时间窗口的开始时间，将开始时间作为过期分数节点，将ZSet中分数小于过期分数节点的Key进行批量失效，并计算失效后的剩余有效请求数量，与单位时间内允许通过的限流次数进行对比；若小于限流次数，则允许通过并按照规则保存进ZSet，若大于等于限流次数，则拦截本次请求，不允许通过；我们通过对之前保存的Value进行比较，比较Value与过期分数之间的大小，来确认该请求数据是否还有效，对超过单位时间窗口时间的无效请求，在比较后进行统一清除，避免对存储资源的无效占用，提高资源利用率；

最后，针对业务需求中需要的多层次限流功能，我们可以针对每个被限流的API设置多个滑动窗口流量计数池，按照限流规则设置不同的限流池Key，按照优先级，从多个层次对API进行分布式精准流量限制；对比常规限流模式，在分布式的需求环境下，固定窗口算法存在单位时间内流量超过流控限制的极端情况；在分布式环境下使用漏桶算法或令牌桶算法时，我们需要维护一个定时的可用流量入桶规则或令牌入桶规则，需要维护规则与分布式多实例之间的联系，其复杂度会导致对Redis的额外压力，导致在高并发环境下，限流逻辑会导致较大的额外延迟；而我们这种设计模式在高并发环境下，可以更好的支持多层次多角度的流控需求，可以定义多个维度的限流规则，支持定义多种限流属性，例如：请求时间、请求来源、请求大小等，提供复杂条件下的多重流控功能，可以满足分布式限流场景下的多种业务需求；

本发明方法对于限流业务的有益效果如下：

通过使用集群内部署的Redis集群作为限流功能的主要实现组件，保证了网关限流服务的云原生化和对集群环境的高适配性，符合当下大环境对服务生态的基本需求；

通过选用Redis中自带的ZSet作为存储限流池的数据类型，减少了自定义数据存储规则带来的额外工作量和复杂度，降低了异常发生的机率，增加了功能的健壮性；

通过全局自增保证了任意时刻的API请求都能被准确记录并按照流量限制需求进行限流，最大限度保护上游服务安全；

通过对资源设置有效期，避免了对资源的无效占用，达到了对资源的高利用率和良好的资源回收机制；

通过滑动窗口算法实现API限流规则，保证了任意单位限流时间内，API的访问数量被限制在用户设置的限流规则内，实现了流量的精准限制。

实施例二：

一种基于滑动窗口算法的分布式限流实现系统，所述的系统具体包括存储选型模块、资源选定模块、标识设置模块、时间设置模块、数值设置模块和规则设置模块：

存储选型模块：利用Redis对限流数据的存储进行选型；

资源选定模块：选用Redis中的ZSet数据类型作为滑动窗口限流的技术资源；

标识设置模块：在Redis中设置唯一标识作为ZSet的key；

时间设置模块：利用Redis的资源回收机制给每个API的限流资源池设置存活时间；

数值设置模块：基于滑动窗口算法，将请求的Key设置为请求进入时刻的毫秒级时间戳+Redis中的自增Key对应的value数值；

规则设置模块：设置规则对API的流量进行计数并限制；

进一步的，所述资源选定模块具体包括分数关联模块、成员排序模块和请求计算模块：

分数关联模块：记录单位时间内的请求，并利用Redis为每个存储数据成员关联一个分数；

成员排序模块：利用redis通过分数来为集合中的成员进行从小到大的排序；

请求计算模块：利用Redis限制请求次数并计算单位时间窗口内的请求数量；

进一步的，所述时间设置模块具体包括时间统一模块、时间更新模块和数据删除模块：

时间统一模块：运用Redis的资源回收机制对API限流资源池设置与限流周期一致的存活时间；

时间更新模块：每次拦截API请求时更新限流池的存活时间；

数据删除模块：在数据无效后自动删除滑动窗口数据；

进一步的，所述数值设置模块具体包括自增维护模块、请求拼接模块和分数保存模块：

自增维护模块：在Redis中维护一个自增Key，当每进入一个请求就将其加一；

请求拼接模块：拼接毫秒级别时间戳作为请求进入的Key；

分数保存模块：将请求进入的秒级时间戳作为分数保存给ZSet中指定的Key作为Value值；

再进一步的，所述规则设置模块针对每个被限流的API设置多个滑动窗口流量计数池，按照优先级对API进行分布式精准流量限制，规则设置模块具体包括节点处理模块、请求核算模块、请求保存模块和请求拦截模块：

节点处理模块：在记录API请求时将当前限流时间窗口的开始时间作为过期分数节点，将ZSet中分数小于过期分数节点的Key进行批量失效；

请求核算模块：计算失效后的剩余有效请求数量，与单位时间内允许通过的限流次数进行对比；

请求保存模块：若小于限流次数，则允许通过并按照规则保存进ZSet；

请求拦截模块：若大于等于限流次数，则拦截本次请求，不允许通过。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种基于滑动窗口算法的分布式限流实现方法，其特征是所述的方法具体步骤如下：

S1利用Redis对限流数据的存储进行选型；

S2选用Redis中的ZSet数据类型作为滑动窗口限流的技术资源；

S3在Redis中设置唯一标识作为ZSet的key；

S4利用Redis的资源回收机制给每个API的限流资源池设置存活时间；

S5基于滑动窗口算法，将请求的Key设置为请求进入时刻的毫秒级时间戳+Redis中的自增Key对应的value数值；

S6设置规则对API的流量进行计数并限制。

2.根据权利要求1所述的方法，其特征是所述S2选用Redis中的ZSet数据类型作为滑动窗口限流的技术资源的具体步骤如下：

S201记录单位时间内的请求，并利用Redis为每个存储数据成员关联一个分数；

S202利用redis通过分数来为集合中的成员进行从小到大的排序；

S203利用Redis限制请求次数并计算单位时间窗口内的请求数量。

3.根据权利要求2所述的方法，其特征是所述S4利用Redis的资源回收机制给每个API的限流资源池设置存活时间的具体步骤如下：

S401运用Redis的资源回收机制对API限流资源池设置与限流周期一致的存活时间；

S402每次拦截API请求时更新限流池的存活时间；

S403在数据无效后自动删除滑动窗口数据。

4.根据权利要求3所述的方法，其特征是所述S5基于滑动窗口算法，将请求的Key设置为请求进入时刻的毫秒级时间戳+Redis中的自增Key对应的value数值的具体步骤如下：

S501在Redis中维护一个自增Key，当每进入一个请求就将其加一；

S502拼接毫秒级别时间戳作为请求进入的Key；

S503将请求进入的秒级时间戳作为分数保存给ZSet中指定的Key作为Value值。

5.根据权利要求4所述的方法，其特征是所述S6针对每个被限流的API设置多个滑动窗口流量计数池，按照优先级对API进行分布式精准流量限制的具体步骤如下：

S601在记录API请求时将当前限流时间窗口的开始时间作为过期分数节点，将ZSet中分数小于过期分数节点的Key进行批量失效；

S602计算失效后的剩余有效请求数量，与单位时间内允许通过的限流次数进行对比；

S603若小于限流次数，则允许通过并按照规则保存进ZSet；

S604若大于等于限流次数，则拦截本次请求，不允许通过。

6.一种基于滑动窗口算法的分布式限流实现系统，其特征是所述的系统具体包括存储选型模块、资源选定模块、标识设置模块、时间设置模块、数值设置模块和规则设置模块：

存储选型模块：利用Redis对限流数据的存储进行选型；

资源选定模块：选用Redis中的ZSet数据类型作为滑动窗口限流的技术资源；

标识设置模块：在Redis中设置唯一标识作为ZSet的key；

时间设置模块：利用Redis的资源回收机制给每个API的限流资源池设置存活时间；

数值设置模块：基于滑动窗口算法，将请求的Key设置为请求进入时刻的毫秒级时间戳+Redis中的自增Key对应的value数值；

规则设置模块：设置规则对API的流量进行计数并限制。

7.根据权利要求6所述的系统，其特征是所述资源选定模块具体包括分数关联模块、成员排序模块和请求计算模块：

分数关联模块：记录单位时间内的请求，并利用Redis为每个存储数据成员关联一个分数；

成员排序模块：利用redis通过分数来为集合中的成员进行从小到大的排序；

请求计算模块：利用Redis限制请求次数并计算单位时间窗口内的请求数量。

8.根据权利要求7所述的系统，其特征是所述时间设置模块具体包括时间统一模块、时间更新模块和数据删除模块：

时间统一模块：运用Redis的资源回收机制对API限流资源池设置与限流周期一致的存活时间；

时间更新模块：每次拦截API请求时更新限流池的存活时间；

数据删除模块：在数据无效后自动删除滑动窗口数据。

9.根据权利要求8所述的系统，其特征是所述数值设置模块具体包括自增维护模块、请求拼接模块和分数保存模块：

自增维护模块：在Redis中维护一个自增Key，当每进入一个请求就将其加一；

请求拼接模块：拼接毫秒级别时间戳作为请求进入的Key；

分数保存模块：将请求进入的秒级时间戳作为分数保存给ZSet中指定的Key作为Value值。

10.根据权利要求9所述的系统，其特征是所述规则设置模块针对每个被限流的API设置多个滑动窗口流量计数池，按照优先级对API进行分布式精准流量限制，规则设置模块具体包括节点处理模块、请求核算模块、请求保存模块和请求拦截模块：

节点处理模块：在记录API请求时将当前限流时间窗口的开始时间作为过期分数节点，将ZSet中分数小于过期分数节点的Key进行批量失效；

请求核算模块：计算失效后的剩余有效请求数量，与单位时间内允许通过的限流次数进行对比；

请求保存模块：若小于限流次数，则允许通过并按照规则保存进ZSet；

请求拦截模块：若大于等于限流次数，则拦截本次请求，不允许通过。

Images