基于分布式令牌桶的削峰处理方法技术

技术编号:20081356 阅读:24 留言:0更新日期:2019-01-15 02:42
本发明专利技术涉及数据信息处理技术领域,为了解决现在交互的多系统中因为上层系统传输来的业务请求的数据流量大而导致下层系统崩溃的现象,提供了一种基于分布式令牌桶的削峰处理方法,包括以下内容:业务请求流量判断步骤:判断接收到的业务请求的流量是否超过预设的流量峰值,若业务请求的流量超过流量峰值,将该业务请求发送到异步消息队列排队等待,若业务请求的流量不超过流量峰值,将该业务请求发送到下层系统;业务请求处理步骤;异步消息队列消费步骤:对排队等待的业务请求进行消费,判断消费后的业务请求的流量是否超过流量峰值,直到业务请求的流量不超过流量峰值后,将该业务请求发送到下层系统进行处理。

Peak Cutting Method Based on Distributed Token Bucket

The invention relates to the field of data information processing technology. In order to solve the problem that the lower system crashes due to the large data flow of service requests transmitted by the upper system in the interactive multi-system, a peak-shaving method based on distributed token bucket is provided, which includes the following contents: the flow determination step of service requests: judging whether the flow of received service requests is or not. If the traffic flow exceeds the preset peak value, the service request is sent to the asynchronous message queue to wait. If the traffic flow exceeds the peak value, the service request is sent to the lower system; the service request processing step; the asynchronous message queue consumption step: consume the queued service request and judge the consumption after consumption. Whether the traffic of the service request exceeds the peak value of the traffic, until the traffic of the service request exceeds the peak value of the traffic, the service request is sent to the lower system for processing.

【技术实现步骤摘要】
基于分布式令牌桶的削峰处理方法
本专利技术涉及数据信息处理
,具体为一种基于分布式令牌桶的削峰处理方法。
技术介绍
随着近年来SOA(面向服务技术架构)的兴起,越来越多的应用系统开始进行分布式的设计和部署。系统由原来单一的技术架构变成面向服务的多系统架构。原来在一个系统可以完成的业务流程,通过多系统的之间多次交互来实现。然而由于各个系统的数据传输以及数据接收能力等的不同就会使得各个系统对业务请求的处理能力参差不齐,因此,在交互的过程中,若上层系统的处理能力大于下层系统的处理能力,那么上层系统可以对流量较大的业务请求进行处理,若处理能力小的下层系统此时直接处理上层系统传输来的业务请求,很可能就会因为数据流量过大导致下层系统崩溃。因此,就需要对传输来的业务请求进行预处理,以防止下层系统的崩溃。现有的预处理方法就是对这些业务请求中超出的流量进行拦截,也就是说会将部分业务请求拦截下来,而被拦截下来的业务请求最后要么被阻塞,要么被直接拒绝而不会给出响应,这样一来,就会导致部分业务请求的丢失,而业务请求的丢失就会导致该业务得不到处理或处理结果有误,也就意味着客户的请求得不到结果或得不到想要的结果,从而降低客户的体验。
技术实现思路
本专利技术意在提供一种基于分布式令牌桶的削峰处理方法,以解决现在交互的多系统在处理业务请求的过程中,由于各个系统的处理能力不同,下层系统容易因为上层系统传输来的流量较大的业务请求而导致下层系统崩溃的现象。本专利技术提供基础方案是:基于分布式令牌桶的削峰处理方法,包括以下内容:业务请求流量判断步骤:接收到上层系统发送来的业务请求后,判断业务请求的流量是否超过预设的流量峰值,若业务请求的流量超过流量峰值,将该业务请求发送到异步消息队列,若业务请求的流量不超过流量峰值,将该业务请求发送到下层系统;业务请求处理步骤:下层系统接收到业务请求后调用相应的业务代码进行处理,在此过程中进入到异步消息队列中的业务请求处于排队等待状态;异步消息队列消费步骤:在下层系统处理完业务请求后,对排队等待的业务请求进行消费,判断消费后的业务请求的流量是否超过流量峰值,若判断不超过流量峰值,将该业务请求发送到下层系统进行处理,若超过,继续消费该业务请求,直到业务请求的流量不超过流量峰值后,将该业务请求发送到下层系统进行处理。名称解释:本方法中业务请求从上层系统发往下层系统。业务:业务是指一个实体单元向另一个实体单元提供的服务。异步消息队列:异步消息队列是在消息的传输过程中保存消息的容器。其中,消息是独立的资源之间沟通内容的载体,生产者构造消息,消费者使用消息;队列则是存储消息的载体,生产者把消息放到队列中,消费者从队列中取出消息。消费:指业务请求被取出后进行逻辑处理从而被消费掉,如将取出的业务请求进行显示或执行或将业务请求中的指定内容采用过滤器模块进行过滤。基础方案的有益效果是:与现有的削峰方式相比较,本方法中,1.在业务请求发送到下层系统的过程中,对大流量的业务请求进行削峰处理,即将超过流量峰值的业务请求发到异步消息队列中进行排队等待而不是直接拒绝或都传送到下层系统去,也就是说,本方法将发往下层系统的业务请求按下层系统的处理能力为界限,提前分为了两部分,第一部分包括的业务请求在下层系统的处理能力范围以内,因此这部分的业务请求被直接发送到下层系统进行处理,第二部分则包括超过了下层系统的处理范围的业务请求,这部分的业务请求被发送到异步消息队列中等待,待第一部分的业务请求被处理完后,此时第二部分的业务请求就会被发送到下层系统进行处理,也就保证系统接收到的所有业务请求都会被处理,避免了业务请求的丢失;2.异步消息队列的设置,一方面可以缓解下层系统的压力,不用同时面临大量的业务请求,另一方面,现有的预处理方式中,第二部分的业务请求是被丢弃了的,而且在下层系统处理完第一部分的业务请求后,下层系统就会处于空闲状态,直到下一次业务请求的到来,而本方法中,在下层系统处理完第一部分的业务请求后,又将第二部分的业务请求发送给下层系统继续进行处理,也就是说,利用了下层系统的空闲时间处理第二部分的业务请求,不光是避免了业务请求的丢失,同时也将下层系统的空闲时间利用了起来,提高了下层系统的处理效率。优选方案一:作为基础方案的优选,业务请求流量判断步骤采用令牌桶算法进行判断,当有业务请求到达时,每向下层系统发送一个业务请求时消耗一个令牌,在令牌桶内令牌被消耗完后,此时到达的业务请求则被发送到异步消息队列。有益效果:考虑到上层系统在高峰期时会向下发送大量的业务请求,因此采用能够允许某种程度的突发传输的令牌桶算法进行判断,在上层系统高峰期的时候,令牌桶这种允许某种程度的突发传输的性质也就可以在一定程度上缓冲下层系统的压力,避免大量的业务请求的堆积。说明:令牌桶可以看作是一个具有一定容量的可以存放令牌的容器,系统按照规定的速率向桶中注入令牌,当桶中令牌满而溢出时,桶中令牌便不再增加。系统接收到一个单位数据(对于网络传输,可以是一个包或者一个字节;对于WebService,可以是一个请求,本申请中即为一个业务请求)后,从令牌桶中取出一个令牌,然后对数据或请求进行处理。如果令牌桶中没有令牌了,会直接将数据或者请求丢弃。大小固定的令牌桶可自行以恒定的速率源源不断地产生令牌。如果令牌不被消耗,或者被消耗的速度小于产生的速度,令牌就会不断地增多,直到把桶填满,因此也就允许某种程度的突发传输。后面再产生的令牌就会从桶中溢出,最后桶中可以保存的最大令牌数永远不会超过桶的大小。突发传输:一般也称为数据突发,其在通信领域中一般指在短时间内进行相对高带宽的数据传输,本申请中指在上层系统高峰期时会向下发送大量的业务请求。优选方案二:作为优选方案一的优选,业务请求流量判断步骤中,令牌桶中最大的令牌数与下层系统的处理能力相匹配。有益效果:将令牌桶最大的令牌数与下层系统的处理能力相匹配设置,这样一来,就算在允许某种程度的突发传输情况下,下层系统最大的业务请求接收量也不会超过下层系统的处理能力允许的最大值,避免下层系统由于接收到的业务请求量过大而出现崩溃的情况;本方案中的最大令牌数即流量峰值。优选方案三:作为优选方案二的优选,业务请求流量判断步骤中,令牌桶最大的令牌数可动态调整。有益效果:令牌桶最大的令牌数可动态调整后,也就可以通过调节最大令牌数以实现优化调整。优选方案四:作为优选方案一的优选,业务请求流量判断步骤中,基于分布式协调组件zookeeper实现分布式令牌桶算法。有益效果:zookeeper在内容变化的时候,可以阻塞回调的方式通知所有在线的client实时更新信息,从而能够完全平衡在分布场景下多台机器的流量分布,并对下游渠道流量做统一控制,便于系统随时优化调整。说明:ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件。Client:客户端(Client)或称为用户端,是指与服务器相对应,为客户提供本地服务的程序。优选方案五:作为优选方案四的优选,异步消息队列消费步骤中采用Kafka消费组件进行消费。有益效果:选用Kafka消费本文档来自技高网...

【技术保护点】
1.基于分布式令牌桶的削峰处理方法,其特征在于:包括以下内容:业务请求流量判断步骤:接收到上层系统发送来的业务请求后,判断业务请求的流量是否超过预设的流量峰值,若业务请求的流量超过流量峰值,将该业务请求发送到异步消息队列,若业务请求的流量不超过流量峰值,将该业务请求发送到下层系统;业务请求处理步骤:下层系统接收到业务请求后调用相应的业务代码进行处理,在此过程中进入到异步消息队列中的业务请求处于排队等待状态;异步消息队列消费步骤:在下层系统处理完业务请求后,对排队等待的业务请求进行消费,判断消费后的业务请求的流量是否超过流量峰值,若判断不超过流量峰值,将该业务请求发送到下层系统进行处理,若超过,继续消费该业务请求,直到业务请求的流量不超过流量峰值后,将该业务请求发送到下层系统进行处理。

【技术特征摘要】
1.基于分布式令牌桶的削峰处理方法,其特征在于:包括以下内容:业务请求流量判断步骤:接收到上层系统发送来的业务请求后,判断业务请求的流量是否超过预设的流量峰值,若业务请求的流量超过流量峰值,将该业务请求发送到异步消息队列,若业务请求的流量不超过流量峰值,将该业务请求发送到下层系统;业务请求处理步骤:下层系统接收到业务请求后调用相应的业务代码进行处理,在此过程中进入到异步消息队列中的业务请求处于排队等待状态;异步消息队列消费步骤:在下层系统处理完业务请求后,对排队等待的业务请求进行消费,判断消费后的业务请求的流量是否超过流量峰值,若判断不超过流量峰值,将该业务请求发送到下层系统进行处理,若超过,继续消费该业务请求,直到业务请求的流量不超过流量峰值后,将该业务请求发送到下层系统进行处理。2.根据权利要求1所述的基于分布式令牌桶的削峰处理方法...

【专利技术属性】
技术研发人员:胡昇
申请(专利权)人:重庆富民银行股份有限公司
类型:发明
国别省市:重庆,50

网友询问留言 已有0条评论
  • 还没有人留言评论。发表了对其他浏览者有用的留言会获得科技券。

1