分布式限流方法、装置、设备及可读存储介质与流程

文档序号:18134599发布日期:2019-07-10 10:30阅读:284来源:国知局
分布式限流方法、装置、设备及可读存储介质与流程

本发明涉及金融科技(finteh)技术领域,尤其涉及金融行业的分布式限流方法、装置、设备及可读存储介质。



背景技术:

随着计算机技术的发展,越来越多的技术应用在金融领域,传统金融业正在逐步向金融科技(finteh)转变,越来越多的技术应用于金融行业,但由于金融行业的安全性及实时性要求,也对技术提出的更高的要求。目前,采用多台计算机组成一个分布式服务系统可以为用户提供比传统的集中式系统更好的服务,特别是可以克服主机资源紧张和响应瓶颈的缺陷,更好地实现任务的分配与优化。可实现调用、监听服务、提供远程通信与信息交换的分布式系统很多,如阿里巴巴旗下开源的分布式服务框架dubbo、开源软件apachehadoop的分布式服务框架协调组件zookeeper等,采用的框架均是java版本的。

在多台相同的服务器需要执行一系列的任务方法时,这些方法往往作为生产者的身份而存在,这些生产者产生最新数据写入缓存服务器或消息队列,以供后续消费者进行消费。而往往在实际应用的过程中,由于生产者生产数据逻辑往往较为单一,导致这些生产者产生数据的速率往往会超过消费者消费的速率,为了使消费者端不至于过载,通常会使用限流方案。

现有的限流方案可以分为两种,一种是针对每个应用服务单独配置限流额度,每个应用限流额度加总为整体应用的限额度;另一种是使用分布式缓存中间件如数据库redis,在数据库redis中设置一个基于总限流额度的令牌桶,每个应用服务器在执行受控方法时去数据库redis中获取一个或多个令牌,根据拿到的令牌数量来控制受控方法的执行次数。

然而,上述两种限流方式存在以下缺陷:

1、单机限流的方案存在静态配置的问题;相对于分布式的限流控制,纯单机的限流在配置上较为不灵活,往往都是做静态配置,也就是在项目部署时为每台应用服务器配置固定的额度,并且在应用运行过程中不易动态调整每台机器的限流额度;

2、基于数据库redis等分布式中间件的令牌桶算法限流方案虽然能够动态调整每台机器的执行频率,并且能够精准的控制多台机器的执行频率,但是往往效率比单机限流低,一是存在分布式锁的高频竞争,二是获得令牌的网络开销较大。



技术实现要素:

本发明的主要目的在于提出一种分布式限流方法、装置、设备及可读存储介质,旨在解决现有技术中动态调整每台服务器的执行频率时效率低,且网络开销大的问题。

为实现上述目的,本发明提供一种分布式限流方法,其特征在于,所述分布式限流方法包括如下步骤:

在应用群集服务器启动时,确定领袖服务器,其中,所述应用群集服务器中所有的服务器均为追随者服务器;

控制所述追随者服务器向所述领袖服务器上传所述当前运行信息;

控制所述领袖服务器基于当前运行信息将限流额度分配至各个所述追随者服务器;

控制各个所述追随者服务器在接收到所述限流额度后,基于当前应用进程获取频次额度,将所述频次额度同步至本地缓存,并基于所述频次额度进行频次限流控制。

优选地,所述控制所述领袖服务器基于当前运行信息将限流额度分配至各个所述追随者服务器的步骤包括:

控制所述领袖服务器基于所述当前运行信息将限流额度分配转化为第一配置结构;

控制所述领袖服务器基于所述第一配置结构将所述限流额度分配至对应的所述跟随者服务器。

优选地,所述控制各个所述追随者服务器在接收到所述限流额度后,基于当前应用进程获取频次额度,将所述频次额度同步至本地缓存,并基于所述频次额度进行频次限流控制的步骤包括:

控制所述跟随者服务器在接收到所述限流额度后,基于所述当前应用进程获取所述频次额度,并将所述第一配置结构及所述频次额度同步至所述本地缓存;

控制所述本地缓存基于所述频次额度将所述第一配置结构转换为第二配置结构,以供各个所述跟随者服务器基于所述第二配置结构进行限流控制。

优选地,所述控制所述本地缓存基于所述频次额度将所述第一配置结构转换为第二配置结构,以供各个所述跟随者服务器基于所述第二配置结构进行限流控制的步骤之后,所述分布式限流方法还包括:

控制所述领袖服务器以第一预设时间间隔分配当前集群服务器的限流额度,并控制所述跟随者服务器以第二预设时间间隔刷新所述限流额度,其中所述第二预设时间间隔小于所述第一预设时间间隔;

或;

控制本地缓存由所述领袖服务器广播每个所述跟随者服务器当前限流额度配置。

优选地,所述控制所述本地缓存基于所述频次额度将所述第一配置结构转换为第二配置结构,以供各个所述跟随者服务器基于所述第二配置结构进行限流控制的步骤之后,所述分布式限流方法还包括:

通过配置管理注册任务;

控制所述跟随者服务器基于所述频次额度执行所述任务;

在所述任务执行完毕时,通过配置管理注销所述任务。

优选地,所述在应用群集服务器启动时,确定领袖服务器的步骤包括:

在所述应用群集服务器启动时,确定选举方式;

若选举方式为数据库redis分布式选举方式,则基于数据库redis分布式选举方式在所述群集服务器中产生所述领袖服务器;

若选举方式为协调组件zookeeper分布式选举方式,则基于协调组件zookeeper分布式选举方式在所述群集服务器中产生所述领袖服务器。

优选地,所述基于所述频次额度进行频次限流控制的步骤包括:

在各个所述追随者服务器获取各自的所述频次额度后,确定限流方式;

若所述限流方式为基于容器longadder的刷新策略,则基于容器longadder的刷新策略进行限流控制;

若所述限流方式为基于限流工具ratelimiter的令牌桶策略,则基于限流工具ratelimiter的令牌桶策略进行限流控制。

此外,为实现上述目的,本发明还提供一种分布式限流装置,所述分布式限流装置包括:

选举模块,用于在应用群集服务器启动时,确定领袖服务器,其中,所述应用群集服务器中所有的服务器均为追随者服务器;

上传模块,用于控制所述追随者服务器向所述领袖服务器上传所述当前运行信息;

额度分配模块,用于控制所述领袖服务器基于当前运行信息将限流额度分配至各个所述追随者服务器;

限流控制模块,用于控制各个所述追随者服务器在接收到所述限流额度后,基于当前应用进程获取频次额度,将所述频次额度同步至本地缓存,并基于所述频次额度进行频次限流控制。

优选地,所述额度分配模块还包括:

第一转化单元,用于控制所述领袖服务器基于所述当前运行信息将限流额度分配转化为第一配置结构;

额度分配单元,用于控制所述领袖服务器基于所述第一配置结构将所述限流额度分配至对应的所述跟随者服务器。

优选地,所述限流控制模块还用于:

控制所述跟随者服务器在接收到所述限流额度后,基于所述当前应用进程获取所述频次额度,并将所述第一配置结构及所述频次额度同步至所述本地缓存;

控制所述本地缓存基于所述频次额度将所述第一配置结构转换为第二配置结构,以供各个所述跟随者服务器基于所述第二配置结构进行限流控制。

优选地,所述选举模块还用于:

在所述应用群集服务器启动时,确定选举方式;

若选举方式为数据库redis分布式选举方式,则基于数据库redis分布式选举方式在所述群集服务器中产生所述领袖服务器;

若选举方式为协调组件zookeeper分布式选举方式,则基于协调组件zookeeper分布式选举方式在所述群集服务器中产生所述领袖服务器。

优选地,所述限流控制模块还用于:

在各个所述追随者服务器获取各自的所述频次额度后,确定限流方式;

若所述限流方式为基于容器longadder的刷新策略,则基于容器longadder的刷新策略进行限流控制;

若所述限流方式为基于限流工具ratelimiter的令牌桶策略,则基于限流工具ratelimiter的令牌桶策略进行限流控制。

此外,为实现上述目的,本发明还提供一种分布式限流设备,所述分布式限流设备包括:存储器、处理器及存储在所述存储器上并可在所述处理器上运行的分布式限流程序,所述分布式限流程序被所述处理器执行时实现如上所述的分布式限流方法的步骤。

此外,为实现上述目的,本发明还提供一种可读存储介质,所述可读存储介质上存储有分布式限流程序,所述分布式限流程序被处理器执行时实现如上所述的分布式限流方法的步骤。

本发明提出的分布式限流方法,首先,通过在应用群集服务器中确定领袖服务器,通过领袖服务器进行限流额度分配,跟随者服务器只负责监听,所以在redis配置管理端无计算竞争消耗时长;其次,跟随者服务器在执行控制的过程中无需每次访问redis配置管理端,相比一次一访问的方式网络开销要小很多;再者,跟随者服务器的频次额度刷新使用异步线程更新,任务执行的线程将不会有这部分的网络开销延迟。

附图说明

图1是本发明实施例方案涉及的硬件运行环境的设备结构示意图;

图2为本发明分布式限流方法第一实施例的流程示意图;

图3为本发明分布式限流方法第一实施例的的结构示意图;

图4为本发明实施例中当前运行信息的结构示意图;

图5为本发明实施例中第一配置结构的示意图;

图6为本发明实施例中第二配置结构的示意图;

图7为本发明分布式限流装置的结构示意图。

本发明目的的实现、功能特点及优点将结合实施例,参照附图做进一步说明。

具体实施方式

应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。

如图1所示,图1是本发明实施例方案涉及的硬件运行环境的设备结构示意图。

本发明实施例终端可以是pc机或服务器设备。

如图1所示,该终端可以包括:处理器1001,例如cpu,网络接口1004,用户接口1003,存储器1005,通信总线1002。其中,通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(display)、输入单元比如键盘(keyboard),可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如wi-fi接口)。存储器1005可以是高速ram存储器,也可以是稳定的存储器(non-volatilememory),例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解,图1中示出的设备结构并不构成对设备的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。

如图1所示,作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及分布式限流程序。

在图1所示的设备中,网络接口1004主要用于连接见证参与方节点,与见证参与方节点进行数据通信;用户接口1003主要用于连接客户端(用户端),与客户端进行数据通信;而处理器1001可以用于调用存储器1005中存储的分布式限流程序,并执行下述分布式限流方法各个实施例中的操作。

基于上述硬件结构,提出本发明分布式限流方法实施例。

参照图2,图2为本发明分布式限流方法第一实施例的流程示意图,所述方法包括:

步骤s10,在应用群集服务器启动时,确定领袖服务器,其中,所述应用群集服务器中所有的服务器均为追随者服务器;

本实施例分布式限流方法应用于java平台,在应用群集服务器启动时,进行领袖服务器选举,当然,应用群集服务器中任一台应用服务器都能选举成为领袖服务器,并且,应用群集服务器中所有的应用服务器均为追随者服务器。

领袖服务器,即leader服务器,主要负责限流额度的配置管理;跟随者服务器,即follower服务器,主要负责监听最新的额度配置,根据领袖服务器给自己分配的额度进行单机的限流控制。

具体地,选举方式有两种,一种是基于数据库redis分布式选举方式在所述群集服务器中产生所述领袖服务器,另一种是基于协调组件zookeeper分布式选举方式在所述群集服务器中产生所述领袖服务器。其中,redis是一种基于内存的键值对存储数据库,因此,基于redis分布式选举方式为基于内存的键值对存储数据库方式;zookeeper是一种分布式的应用协调服务,可以提供诸如分布式服务配置以及分布式锁等功能。如图3所示,通过redis或zookeeper方式都能确定领袖服务器,将应用服务器1选举为领袖服务器,则应用服务器1、2和3均为跟随者服务器,各个跟随者服务器拉取数据源,处理后输出至本地缓存或消息队列中,消息队列是消息传输过程中保存消息的容器,是分布式系统的重要组件;并且,通过数据库redis配置管理,实现领袖服务器对各个跟随者服务器的额度配置。

通过两种方式,均能在应用群集服务器中确定领袖服务器,负责限流额度的配置管理,且跟随者服务器只负责监听,因此,在redis配置管理端无计算竞争消耗时长。

步骤s20,控制所述追随者服务器向所述领袖服务器上传所述当前运行信息;

该步骤中,在确定了领袖服务器之后,应用群集服务器中所有的应用服务器均为跟随者服务器,为了使领袖服务器能够知道集群中应用运行的状态统计,因此,控制各个追随者服务器主动汇报当前运行信息,当前运行信息包括当前应用编号、当前运行的任务数以及任务属性。

比如,有三台应用服务器1、2、3,并且有三种不同的优先级,且共享限流控制的任务1、2、3,三台应用服务器输出的总频控要求为30000次/秒,其中任务3优先级最高,任务1优先级最低,任务1、2和3最大占用限流频次为20000、20000和30000。如图4所示,假设当前时刻,当前运行信息具体为:任务1在应用1、2和3上的运行数量分别为15、5和5;任务2在应用1和应用2上的运行数量分别为10和10;任务3在应用1和应用3上的运行数量分别为10和5。

因此,跟随者服务器需要将上述当前运行信息主动上传给领袖服务器,使得领袖服务器能够得知上述当前运行信息,以便于领袖服务器能够根据当前运行信息进行限流额度分配。

步骤s30,控制所述领袖服务器基于当前运行信息将限流额度分配至各个所述追随者服务器。

该步骤中,在跟随者服务器将上述当前运行信息主动汇报到领袖服务器时,领袖服务器基于当前运行信息将限流额度分配至各个所述追随者服务器。

首先,领袖服务器根据上述当前运行信息将额度分配转化为第一配置结构,包括各个任务对应的跟随者服务器的频次分配。再者,领袖服务器基于所述第一配置结构将所述限流额度分配至对应的所述跟随者服务器。

步骤s40,控制各个所述追随者服务器在接收到所述限流额度后,基于当前应用进程获取频次额度,将所述频次额度同步至本地缓存,并基于所述频次额度进行频次限流控制。

该步骤中,在各个追随者服务器接收到限流额度后,根据当前应用进程获取自身的频次额度,同时,将自身的频次额度同步至本地缓存中,并且,基于频次额度进行频次限流控制。具体为:

控制所述跟随者服务器在接收到所述限流额度后,基于所述当前应用进程获取所述频次额度,并将所述第一配置结构及所述频次额度同步至所述本地缓存;

控制所述本地缓存基于所述频次额度将所述第一配置结构转换为第二配置结构,以供各个所述跟随者服务器基于所述第二配置结构进行限流控制。

如图5所示,由于任务3的优先级最高,所述任务3会先占用其中的20000额度,并按照任务数量比例进行分配;任务2优先级次之,所以会占用剩下的10000额度,并且根据任务数量等分;任务1由于没有剩下的额度,所以暂时没有额度。频次额度在同步到本地缓存后,本地缓存会将第一配置结构转换为第二配置结构。

第二配置结构如图6所示,在应用服务器1的应用进程1中,任务1的频次为0,任务2的频次为5000,任务3的频次为13333;在应用服务器2的应用进程2中,任务1的频次为0,任务2的频次为5000;在应用服务器3的应用进程3中,任务1的频次为0,任务3的频次为6667。

本发明提出的分布式限流方法,首先,通过在应用群集服务器中确定领袖服务器,通过领袖服务器进行限流额度分配,跟随者服务器只负责监听,所以在redis配置管理端无计算竞争消耗时长;其次,跟随者服务器在执行控制的过程中无需每次访问redis配置管理端,相比一次一访问的方式网络开销要小很多;再者,跟随者服务器的频次额度刷新使用异步线程更新,任务执行的线程将不会有这部分的网络开销延迟。

进一步地,基于本发明分布式限流方法第一实施例,提出本发明分布式限流方法第二实施例。

在本实施例中,上述步骤s30可以包括:

控制所述领袖服务器基于所述当前运行信息将限流额度分配转化为第一配置结构;

控制所述领袖服务器基于所述第一配置结构将所述限流额度分配至对应的所述跟随者服务器。

具体地,领袖服务器根据上述当前运行信息将额度分配转化为第一配置结构,包括各个任务对应的跟随者服务器的频次分配。再者,领袖服务器基于所述第一配置结构将所述限流额度分配至对应的所述跟随者服务器。如图5所示,由于任务3的优先级最高,所述任务3会先占用其中的20000额度,并按照任务数量比例进行分配;任务2优先级次之,所以会占用剩下的10000额度,并且根据任务数量等分;任务1由于没有剩下的额度,所以暂时没有额度。频次额度在同步到本地缓存后,本地缓存会将第一配置结构转换为第二配置结构。

通过领袖服务器基于所述当前运行信息将限流额度分配转化为第一配置结构的方式,实现领袖服务器对各个跟随者服务器对应的限流额度的分配。

进一步地,基于本发明分布式限流方法第二实施例,提出本发明分布式限流方法第三实施例。

在本实施例中,上述步骤s40可以包括:获取所述目标文件对应的合法企业证书;

控制所述跟随者服务器在接收到所述限流额度后,基于所述当前应用进程获取所述频次额度,并将所述第一配置结构及所述频次额度同步至所述本地缓存;

控制所述本地缓存基于所述频次额度将所述第一配置结构转换为第二配置结构,以供各个所述跟随者服务器基于所述第二配置结构进行限流控制。

在本实施例中,控制所述跟随者服务器在接收到所述限流额度后,基于所述当前应用进程获取所述频次额度,并将所述第一配置结构及所述频次额度同步至所述本地缓存;控制所述本地缓存基于所述频次额度将所述第一配置结构转换为第二配置结构。

当前应用进程如图4所示,任务1在应用1、2和3的跟随者服务器上的运行数量分别为15、5和5;任务2在应用1和应用2上的运行数量分别为10和10;任务3在应用1和应用3上的运行数量分别为10和5。

如图5所示,由于任务3的优先级最高,所述任务3会先占用其中的20000额度,并按照任务数量比例进行分配;任务2优先级次之,所以会占用剩下的10000额度,并且根据任务数量等分;任务1由于没有剩下的额度,所以暂时没有额度。频次额度在同步到本地缓存后,本地缓存会将第一配置结构转换为第二配置结构。

第二配置结构如图6所示,在应用服务器1的应用进程1中,任务1的频次为0,任务2的频次为5000,任务3的频次为13333;在应用服务器2的应用进程2中,任务1的频次为0,任务2的频次为5000;在应用服务器3的应用进程3中,任务1的频次为0,任务3的频次为6667。

进一步地,步骤s40之后,本发明还可以包括:控制所述领袖服务器以第一预设时间间隔分配当前集群服务器的限流额度,并控制所述跟随者服务器以第二预设时间间隔刷新所述限流额度,其中所述第二预设时间间隔小于所述第一预设时间间隔;

或;

控制本地缓存由所述领袖服务器广播每个所述跟随者服务器当前限流额度配置。

在本实施例中,追随者服务器需要定期同步“redis配置管理”中的由领袖服务器所维护的限流额度配置信息,用于更新本地的限流信息。可以使用如下两种模式:

一种是领袖服务器以t1的第一预设时间间隔定期分配当前集群的限流额度,追随者服务器以t2的第二预设时间间隔定期刷新限额额度配置,t2<t1;

另一种是使用本地缓存/消息队列由领袖服务器广播每个追随者服务器当前限流额度配置被更新。

上述这两种模式都将大大降低由分布式令牌桶限流模式所带来的令牌获取网络开销。

进一步地,步骤s40之后,本发明还可以包括:

通过配置管理注册任务;

控制所述跟随者服务器基于所述频次额度执行所述任务;

在所述任务执行完毕时,通过配置管理注销所述任务。

在本实施例中,当一个任务通过绑定一个线程运行时,在真正执行任务时向“数据库redis配置管理”注册任务,并在任务结束时进行注销,即该线程开始运行的时候,会往数据库redis发送一条记录,登记自己为运行状态,也就是数量+1。

进一步地,步骤10可以包括:

在所述应用群集服务器启动时,确定选举方式;

若选举方式为数据库redis分布式选举方式,则基于数据库redis分布式选举方式在所述群集服务器中产生所述领袖服务器;

若选举方式为协调组件zookeeper分布式选举方式,则基于协调组件zookeeper分布式选举方式在所述群集服务器中产生所述领袖服务器。

本实施例中,选举方式有两种,一种是基于数据库redis分布式选举方式在所述群集服务器中产生所述领袖服务器,另一种是基于协调组件zookeeper分布式选举方式在所述群集服务器中产生所述领袖服务器。其中,redis是一种基于内存的键值对存储数据库,因此,基于数据库redis分布式选举方式为基于内存的键值对存储数据库方式;zookeeper是一种分布式的应用协调服务,可以提供诸如分布式服务配置以及分布式锁等功能。如图3所示,通过redis或zookeeper方式都能确定领袖服务器,将应用服务器1选举为领袖服务器,则应用服务器1、2和3均为跟随者服务器,各个跟随者服务器拉取数据源,处理后输出至本地缓存或消息队列中,消息队列是消息传输过程中保存消息的容器,是分布式系统的重要组件;并且,通过redis配置管理,实现领袖服务器对各个跟随者服务器的额度配置。

进一步地,步骤s40还可以包括:

在各个所述追随者服务器获取各自的所述频次额度后,确定限流方式;

若所述限流方式为基于容器longadder的刷新策略,则基于容器longadder的刷新策略进行限流控制;

若所述限流方式为基于限流工具ratelimiter的令牌桶策略,则基于限流工具ratelimiter的令牌桶策略进行限流控制。

在本实施例中,在各个所述追随者服务器获取各自的所述频次额度后,确定限流方式;若所述限流方式为基于容器longadder的刷新策略,则基于容器longadder的刷新策略进行限流控制;若所述限流方式为基于限流工具ratelimiter的令牌桶策略,则基于限流工具ratelimiter的令牌桶策略进行限流控制。实际的限流功能,如限流时是使用基于容器longadder的刷新策略还是使用基于限流工具ratelimiter的令牌桶策略;过载时是使用线程阻塞策略还是使用拒绝策略,其中,拒绝策略即如果任务发现受限而不能执行,则可以选择抛弃本次执行,向外抛出信息,或者选择等待直到可以执行为止。

令牌桶策略一种算法,是网络流量整形和速率限制中最常用的一种算法。典型情况下,令牌桶算法用来控制发送到网络上的数据的数目,并允许突发数据的发送。

以应用服务器1分配到100次/秒的执行频率为例,容器longadder是一种线程安全的java类型,常用做高并发环境下的数量统计及累计的容器,具体为:任务首先检查执行开关是否打开,如果打开,则执行;任务每执行一次就向容器longadder中累加1次,由另一个辅助线程每100毫秒检查容器longadder是否超过100,如果超过,则执行开关关闭,直到下一秒打开开关;限流工具ratelimiter是谷歌开源的基于令牌桶算法的限流软件工具,具体为:将本地的限流工具ratelimiter设置为100次/秒,应用服务器1每执行一次任务动作,就向限流工具ratelimiter拿令牌,拿到则执行任务。

本发明还提供一种分布式限流装置。如图7所示,本发明所述分布式限流装置包括:

选举模块,负责应用集群中的领袖选举功能,用于在应用群集服务器启动时,确定领袖服务器,其中,所述应用群集服务器中所有的服务器均为追随者服务器;

上传模块,用于控制所述追随者服务器向所述领袖服务器上传所述当前运行信息;

额度分配模块,负责限流额度的分配功能,包含额度分配的算法实现,用于控制所述领袖服务器基于当前运行信息将限流额度分配至各个所述追随者服务器;

限流控制模块,负责实际的限流功能,如限流时是使用基于容器longadder的刷新策略还是使用基于限流工具ratelimiter的令牌桶策略;过载时是使用线程阻塞策略还是使用拒绝策略,用于控制各个所述追随者服务器在接收到所述限流额度后,基于当前应用进程获取频次额度,将所述频次额度同步至本地缓存,并基于所述频次额度进行频次限流控制。

进一步地,第一转化单元,用于控制所述领袖服务器基于所述当前运行信息将限流额度分配转化为第一配置结构;

额度分配单元,负责限流额度的分配功能,包含额度分配的算法实现,用于控制所述领袖服务器基于所述第一配置结构将所述限流额度分配至对应的所述跟随者服务器。

进一步地,所述限流控制模块还用于:

控制所述跟随者服务器在接收到所述限流额度后,基于所述当前应用进程获取所述频次额度,并将所述第一配置结构及所述频次额度同步至所述本地缓存;

控制所述本地缓存基于所述频次额度将所述第一配置结构转换为第二配置结构,以供各个所述跟随者服务器基于所述第二配置结构进行限流控制。

进一步地,所述分布式限流装置还包括:

健康汇报模块,负责应用集群中各应用实例的健康汇报以及保障整体功能不会因单点故障而崩溃,用于对所述当前应用进程进行实时健康汇报;

代理模块,用于通过配置管理注册任务,控制所述跟随者服务器基于所述频次额度执行所述任务,且在所述任务执行完毕时,通过配置管理注销所述任务。

线程/线程池模块:负责底层的线程基础功能,携带任务名称,总限流配额,优先级等属性,提供统一的线程运行环境以及每种类型任务的特殊线程池。并且将提供基本的任务注册和注销功能。

配置模块:负责初始化及运行时的各类参数配置功能,以及与spring框架的集成功能。

注解模块:提供各类即插即用的注解,用来为限流功能设置切面或字节码织入式的代理。

进一步地,选举模块包括中间适配件模块,负责与各类分布式中间件的适配功能,如选举时是使用数据库redis还是使用协调组件zookeeper;所述选举模块还用于:

在所述应用群集服务器启动时,确定选举方式;

若选举方式为数据库redis分布式选举方式,则基于数据库redis分布式选举方式在所述群集服务器中产生所述领袖服务器;

若选举方式为协调组件zookeeper分布式选举方式,则基于协调组件zookeeper分布式选举方式在所述群集服务器中产生所述领袖服务器。

进一步地,所述限流控制模块还用于:

在各个所述追随者服务器获取各自的所述频次额度后,确定限流方式;

若所述限流方式为基于容器longadder的刷新策略,则基于容器longadder的刷新策略进行限流控制;

若所述限流方式为基于限流工具ratelimiter的令牌桶策略,则基于限流工具ratelimiter的令牌桶策略进行限流控制。

本发明还提供一种计算机可读存储介质。

本发明计算机可读存储介质上存储有分布式限流程序,所述分布式限流程序被处理器执行时实现如上所述的分布式限流方法的步骤。

其中,在所述处理器上运行的分布式限流程序被执行时所实现的方法可参照本发明分布式限流方法各个实施例,此处不再赘述。

需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。

通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在如上所述的一个存储介质(如rom/ram、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,空调器,或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例,并非因此限制本发明的专利范围,凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本发明的专利保护范围内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1