CN112214269A - 基于zookeeper的滑动窗口限流解决方案 - Google Patents

Abstract

本发明公开了一种基于zookeeper的滑动窗口限流解决方案，为解决固定窗口计数带来的周期切换处流量突发问题，可以使用滑动窗口计数，与股固定窗口计数法相比较，除了计数周期T及周期内最大访问（调用）数N两个参数，增加一个参数M，用于设置周期T内的滑动窗口数。本发明解决了现有技术中存在的服务器性能低、接口不可配以及多用户并发时服务器可用性低的问题，实现高性能、高可用的分布式的限流目的。

Description

基于zookeeper的滑动窗口限流解决方案

技术领域

本发明涉及互联网金融领域，特别涉及基于zookeeper的滑动窗口限流解决方案。

背景技术

在分布式架构中，一般分为服务提供方和服务调用方。服务提供方对外提供dubbo接口，服务调用方通过提供方提供出的dubbo接口进行服务调用。服务方在系统涉及支出就会有一个预估的tps/qps阈值，如果系统长时间承受高于设计的tps值，应用系统有可能会被压垮，最终扩散到整个一整串的服务，形成雪崩效应，导致服务不可用。为了避免这种情况，就需要对API请求进行限流。限流的目的是通过对并发访问请求进行限速或者一个时间窗口内的请求数量进行限速来保护系统，一旦达到限制速率则可以拒绝服务、排队或等待。在金融领域会存在多个服务调用方，服务提供方提供的API接口被调用时，一般是通过设置缓存、队列、令牌、动态滑动窗口计数、分流等技术方式来实现限流，目前的API接口限流的方法都属于限流，即当交易数量发起过多时，服务提供方的应用系统的负载能力有限，如果非预期的请求对系统压力过大而拖垮整个业务应用系统，服务提供方和服务调用方的损失极为惨重，如果仅仅通过上述的被动限流方式将交易进行限流，该类方法灵活性较差，不能够进行灵活配置及精准高效的限流及相应的权限校验，且因金融交易存在业务特性，更需要进行灵活合理的限流。现有技术中存在的问题是：

本地JVM级限流仅仅能在单机服务中进行应用，服务器性能及高可用都会存在问题；不可配的接口限流策略往往不能满足可变的、多样性的用户限流需求；单一的用户级限流在用户日益增长的过程中，多用户并发时容易触发服务器性能瓶颈，影响服务其他功能的可用性。因此，需要一种分布式限流的实现方法，解决现有技术中存在的服务器性能低、接口不可配以及多用户并发时服务器可用性低的问题，实现高性能、高可用的分布式的限流目的。

发明内容

本发明要解决的技术问题是克服现有技术的缺陷，提供基于zookeeper的滑动窗口限流解决方案，解决现有技术中存在的服务器性能低、接口不可配以及多用户并发时服务器可用性低的问题，实现高性能、高可用的分布式的限流目的。

为了解决上述技术问题，本发明提供了如下的技术方案：

本发明一种基于zookeeper的滑动窗口限流解决方案，包括以下步骤：

S1：当前请求过鉴权服务，生成authkey；

S2：判断当前请求是否请求安全策略；

S3：根绝请求的code去zk中/auth/code文件查询出窗口的时长、要访问的目标服务器地址、最大请求量N、滑动窗口的时间间隔、每个滑动窗口的计数器的数值；

S4：算出所有的滑动窗口的时间间隔的所有的计数器的和N1；

S5：判断N1>N；

S6：如果N1>N，那么直接出发限流策略；

S7：如果N1<=N,那么正常接收请求，并且当前滑动窗口的计数器值+1，重复S4动作；

S8：如果当前已经到达下一个滑动窗口时间，则滑动窗口向下移动一格；重复S4动作。

与现有技术相比，本发明的有益效果如下：

本发明解决了现有技术中存在的服务器性能低、接口不可配以及多用户并发时服务器可用性低的问题，实现高性能、高可用的分布式的限流目的。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

图1是本发明的步骤图；

图2是本发明的限流流程图。

具体实施方式

以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。

实施例1

如图1-2所示，本发明提供一种基于zookeeper的滑动窗口限流解决方案，包括以下步骤：

S1：当前请求过鉴权服务，生成authkey；

S2：判断当前请求是否请求安全策略；

S3：根绝请求的code去zk中/auth/code文件查询出窗口的时长、要访问的目标服务器地址、最大请求量N、滑动窗口的时间间隔、每个滑动窗口的计数器的数值；

S4：算出所有的滑动窗口的时间间隔的所有的计数器的和N1；

S5：判断N1>N；

S6：如果N1>N，那么直接出发限流策略；

S7：如果N1<=N,那么正常接收请求，并且当前滑动窗口的计数器值+1，重复S4动作；

S8：如果当前已经到达下一个滑动窗口时间，则滑动窗口向下移动一格；重复S4动作。

实现原理：

滑动窗口计数法与股固定窗口计数法相比较，除了计数周期T及周期内最大访问（调用）数N两个参数，增加一个参数M，用于设置周期T内的滑动窗口数，限流流程如图2所示。

与现有技术相比，本发明的有益效果如下：

本发明解决了现有技术中存在的服务器性能低、接口不可配以及多用户并发时服务器可用性低的问题，实现高性能、高可用的分布式的限流目的。

最后应说明的是：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (1)

1.基于zookeeper的滑动窗口限流解决方案，其特征在于，包括以下步骤：

S1：当前请求过鉴权服务，生成authkey；

S2：判断当前请求是否请求安全策略；

S3：根绝请求的code去zk中/auth/code文件查询出窗口的时长、要访问的目标服务器地址、最大请求量N、滑动窗口的时间间隔、每个滑动窗口的计数器的数值；

S4：算出所有的滑动窗口的时间间隔的所有的计数器的和N1；

S5：判断N1>N；

S6：如果N1>N，那么直接出发限流策略；

S7：如果N1<=N,那么正常接收请求，并且当前滑动窗口的计数器值+1，重复S4动作；

S8：如果当前已经到达下一个滑动窗口时间，则滑动窗口向下移动一格；重复S4动作。

Images