CN109194586A - 基于分布式令牌桶的削峰处理方法 - Google Patents

Abstract

本发明涉及数据信息处理技术领域，为了解决现在交互的多系统中因为上层系统传输来的业务请求的数据流量大而导致下层系统崩溃的现象，提供了一种基于分布式令牌桶的削峰处理方法，包括以下内容：业务请求流量判断步骤：判断接收到的业务请求的流量是否超过预设的流量峰值，若业务请求的流量超过流量峰值，将该业务请求发送到异步消息队列排队等待，若业务请求的流量不超过流量峰值，将该业务请求发送到下层系统；业务请求处理步骤；异步消息队列消费步骤：对排队等待的业务请求进行消费，判断消费后的业务请求的流量是否超过流量峰值，直到业务请求的流量不超过流量峰值后，将该业务请求发送到下层系统进行处理。

Description

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

技术领域

本发明涉及数据信息处理技术领域，具体为一种基于分布式令牌桶的削峰处理方法。

背景技术

随着近年来SOA(面向服务技术架构)的兴起，越来越多的应用系统开始进行分布式的设计和部署。系统由原来单一的技术架构变成面向服务的多系统架构。原来在一个系统可以完成的业务流程，通过多系统的之间多次交互来实现。

然而由于各个系统的数据传输以及数据接收能力等的不同就会使得各个系统对业务请求的处理能力参差不齐，因此，在交互的过程中，若上层系统的处理能力大于下层系统的处理能力，那么上层系统可以对流量较大的业务请求进行处理，若处理能力小的下层系统此时直接处理上层系统传输来的业务请求，很可能就会因为数据流量过大导致下层系统崩溃。因此，就需要对传输来的业务请求进行预处理，以防止下层系统的崩溃。现有的预处理方法就是对这些业务请求中超出的流量进行拦截，也就是说会将部分业务请求拦截下来，而被拦截下来的业务请求最后要么被阻塞，要么被直接拒绝而不会给出响应，这样一来，就会导致部分业务请求的丢失，而业务请求的丢失就会导致该业务得不到处理或处理结果有误，也就意味着客户的请求得不到结果或得不到想要的结果，从而降低客户的体验。

发明内容

本发明意在提供一种基于分布式令牌桶的削峰处理方法，以解决现在交互的多系统在处理业务请求的过程中，由于各个系统的处理能力不同，下层系统容易因为上层系统传输来的流量较大的业务请求而导致下层系统崩溃的现象。

本发明提供基础方案是：基于分布式令牌桶的削峰处理方法，包括以下内容：

业务请求流量判断步骤：接收到上层系统发送来的业务请求后，判断业务请求的流量是否超过预设的流量峰值，若业务请求的流量超过流量峰值，将该业务请求发送到异步消息队列，若业务请求的流量不超过流量峰值，将该业务请求发送到下层系统；

业务请求处理步骤：下层系统接收到业务请求后调用相应的业务代码进行处理，在此过程中进入到异步消息队列中的业务请求处于排队等待状态；

异步消息队列消费步骤：在下层系统处理完业务请求后，对排队等待的业务请求进行消费，判断消费后的业务请求的流量是否超过流量峰值，若判断不超过流量峰值，将该业务请求发送到下层系统进行处理，若超过，继续消费该业务请求，直到业务请求的流量不超过流量峰值后，将该业务请求发送到下层系统进行处理。

名称解释：

本方法中业务请求从上层系统发往下层系统。

业务：业务是指一个实体单元向另一个实体单元提供的服务。

异步消息队列：异步消息队列是在消息的传输过程中保存消息的容器。其中，消息是独立的资源之间沟通内容的载体，生产者构造消息，消费者使用消息；队列则是存储消息的载体，生产者把消息放到队列中，消费者从队列中取出消息。

消费：指业务请求被取出后进行逻辑处理从而被消费掉，如将取出的业务请求进行显示或执行或将业务请求中的指定内容采用过滤器模块进行过滤。

基础方案的有益效果是：与现有的削峰方式相比较，本方法中，1.在业务请求发送到下层系统的过程中，对大流量的业务请求进行削峰处理，即将超过流量峰值的业务请求发到异步消息队列中进行排队等待而不是直接拒绝或都传送到下层系统去，也就是说，本方法将发往下层系统的业务请求按下层系统的处理能力为界限，提前分为了两部分，第一部分包括的业务请求在下层系统的处理能力范围以内，因此这部分的业务请求被直接发送到下层系统进行处理，第二部分则包括超过了下层系统的处理范围的业务请求，这部分的业务请求被发送到异步消息队列中等待，待第一部分的业务请求被处理完后，此时第二部分的业务请求就会被发送到下层系统进行处理，也就保证系统接收到的所有业务请求都会被处理，避免了业务请求的丢失；

2.异步消息队列的设置，一方面可以缓解下层系统的压力，不用同时面临大量的业务请求，另一方面，现有的预处理方式中，第二部分的业务请求是被丢弃了的，而且在下层系统处理完第一部分的业务请求后，下层系统就会处于空闲状态，直到下一次业务请求的到来，而本方法中，在下层系统处理完第一部分的业务请求后，又将第二部分的业务请求发送给下层系统继续进行处理，也就是说，利用了下层系统的空闲时间处理第二部分的业务请求，不光是避免了业务请求的丢失，同时也将下层系统的空闲时间利用了起来，提高了下层系统的处理效率。

优选方案一：作为基础方案的优选，业务请求流量判断步骤采用令牌桶算法进行判断，当有业务请求到达时，每向下层系统发送一个业务请求时消耗一个令牌，在令牌桶内令牌被消耗完后，此时到达的业务请求则被发送到异步消息队列。有益效果：考虑到上层系统在高峰期时会向下发送大量的业务请求，因此采用能够允许某种程度的突发传输的令牌桶算法进行判断，在上层系统高峰期的时候，令牌桶这种允许某种程度的突发传输的性质也就可以在一定程度上缓冲下层系统的压力，避免大量的业务请求的堆积。

说明：令牌桶可以看作是一个具有一定容量的可以存放令牌的容器，系统按照规定的速率向桶中注入令牌，当桶中令牌满而溢出时，桶中令牌便不再增加。系统接收到一个单位数据(对于网络传输，可以是一个包或者一个字节；对于Web Service，可以是一个请求，本申请中即为一个业务请求)后，从令牌桶中取出一个令牌，然后对数据或请求进行处理。如果令牌桶中没有令牌了，会直接将数据或者请求丢弃。大小固定的令牌桶可自行以恒定的速率源源不断地产生令牌。如果令牌不被消耗，或者被消耗的速度小于产生的速度，令牌就会不断地增多，直到把桶填满，因此也就允许某种程度的突发传输。后面再产生的令牌就会从桶中溢出，最后桶中可以保存的最大令牌数永远不会超过桶的大小。

突发传输：一般也称为数据突发，其在通信领域中一般指在短时间内进行相对高带宽的数据传输，本申请中指在上层系统高峰期时会向下发送大量的业务请求。

优选方案二：作为优选方案一的优选，业务请求流量判断步骤中，令牌桶中最大的令牌数与下层系统的处理能力相匹配。有益效果：将令牌桶最大的令牌数与下层系统的处理能力相匹配设置，这样一来，就算在允许某种程度的突发传输情况下，下层系统最大的业务请求接收量也不会超过下层系统的处理能力允许的最大值，避免下层系统由于接收到的业务请求量过大而出现崩溃的情况；本方案中的最大令牌数即流量峰值。

优选方案三：作为优选方案二的优选，业务请求流量判断步骤中，令牌桶最大的令牌数可动态调整。有益效果：令牌桶最大的令牌数可动态调整后，也就可以通过调节最大令牌数以实现优化调整。

优选方案四：作为优选方案一的优选，业务请求流量判断步骤中，基于分布式协调组件zookeeper实现分布式令牌桶算法。有益效果：zookeeper在内容变化的时候，可以阻塞回调的方式通知所有在线的client实时更新信息，从而能够完全平衡在分布场景下多台机器的流量分布，并对下游渠道流量做统一控制，便于系统随时优化调整。

说明：ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件。

Client：客户端(Client)或称为用户端，是指与服务器相对应，为客户提供本地服务的程序。

优选方案五：作为优选方案四的优选，异步消息队列消费步骤中采用Kafka消费组件进行消费。有益效果：选用Kafka消费组件进行消费，明确支持消息的分区，通过Kafka服务器和消费者机器的集群分布式消费，维持每一个分区是有序的。

说明：Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统(也可以当做MQ系统)，常见可以用于web/nginx日志、访问日志，消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。

附图说明

图1为本发明基于分布式令牌桶的削峰处理方法实施例的流程图。

具体实施方式

基于分布式令牌桶的削峰处理方法，采用的削峰系统，包括请求接收模块、流量判断模块、异步消息队列、消费组件，请求接收模块接收到上层系统发送来的业务请求后，流量判断模块判断业务请求的流量是否超过预设的流量峰值，若业务请求的流量超过流量峰值，将该业务请求发送到异步消息队列，若业务请求的流量不超过流量峰值，将该业务请求发送到下层系统，下层系统处理业务请求；

在下层系统处理完业务请求后，消费组件对排队等待的业务请求进行消费，流量判断模块判断消费后的业务请求的流量是否超过流量峰值，若判断不超过流量峰值，将该业务请求发送到下层系统进行处理，若超过，消费组件继续消费该业务请求，直到业务请求的流量不超过流量峰值后，将该业务请求发送到下层系统进行处理。

上述过程中，请求判断模块采用令牌桶算法进行判断，令牌桶的最大的令牌数与下层系统的处理能力相匹配，其中，令牌桶的最大令牌数可动态调整，流量判断模块基于分布式协调组件zookeeper实现分布式令牌桶算法，消费组件为Kafka消费组件。

如图1所示的基于分布式令牌桶的削峰处理方法，包括以下内容：

业务请求流量判断步骤：接收到上层系统发送来的业务请求后，采用基于分布式协调组件zookeeper实现的分布式令牌桶算法判断业务请求的流量是否超过预设的流量峰值，其中，令牌桶中最大的令牌数与下层系统的处理能力相匹配，而且令牌桶最大的令牌数可动态调整；若业务请求的流量超过流量峰值，将该业务请求发送到异步消息队列，若业务请求的流量不超过流量峰值，将该业务请求发送到下层系统；

业务请求处理步骤：下层系统接收到业务请求后调用相应的业务代码进行处理，在此过程中进入到异步消息队列中的业务请求处于排队等待状态；

异步消息队列消费步骤：在下层系统处理完业务请求后，对排队等待的业务请求进行消费，判断消费后的业务请求的流量是否超过流量峰值，若判断不超过流量峰值，将该业务请求发送到下层系统进行处理，若超过，继续消费该业务请求，直到业务请求的流量不超过流量峰值后，将该业务请求发送到下层系统进行处理，本实施例中采用Kafka消费组件进行消费。

先对发送来的业务请求的流量进行判断，并将超过流量峰值的业务请求发送到异步消息队列中进行排队等待，这样一来，发送到下层系统的业务请求的流量是在下层系统处理能力的处理范围内的，也就不会因为数据流量过大而导致下层系统崩溃；而在下层系统将接收到的业务请求处理完后，也就能够处理新的业务请求，此时异步消息队列的业务请求就可以发往下层系统进行处理；

同样的，为了不使得下层系统出现崩溃的情况，在向下层系统发送业务请求前也是需要对异步消息队列中的业务请求的流量进行判断的，判断的结果分为两种，一种是业务请求的流量不大于流量峰值，是在下层系统处理能力以内的，因此此时可以将业务请求直接发送到下层系统进行处理，另一种结果则是业务请求的流量大于流量峰值，此时利用消费组件对业务请求进行消费，然后再对消费后的业务请求的流量进行判断，判断的结果同样也是分为两种，一种是消费后的业务请求的流量已经不再大于流量峰值，此时将业务请求直接发送下层系统进行处理，另一种结果是经过消费后的业务请求的流量还是大于流量峰值，此时消费组件再次对业务请求进行消费，然后再次判断，直到业务请求的流量不大于峰值流量后，才将业务请求发送给下层系统进行处理，这样一来，就保证发送到下层系统的业务请求的流量都是在下层系统处理能力范围内的，下层系统在处理这些业务请求的时候也就不会发生崩溃的情况。

如，假定每条业务请求的流量在假定值X±x的范围以内，下层系统的处理能力为Y，因此，当接收到业务请求后，如流量是小于Y的，此时这批业务请求被直接发往下层系统进行处理，而若是流量是大于Y的，如一共发来的是23条业务请求，假定前11条的业务请求总流量小于Y，则在经过令牌桶算法判断后，前面11条业务请求被直接发送下层系统进行处理，而后面的12条业务请求被发送到异步消息队列中进行排队等待，在下层系统将前11条的业务请求处理完成后，此时消费组件对排队的12条信息进行消费，本实施例中采用过滤的方式进行消费，将这12条业务请求中的指定内容过滤掉，指定内容可以预先进行设定，且设定的指定内容对于业务请求的处理并不会有影响，然后对过滤后的12条业务请求的流量进行判断，若这12条的总流量小于Y，则发往下层系统进行处理，若还是大于Y，则继续进行消费，直到总流量小于了Y后被发往下层系统进行处理。

考虑到在业务请求不符合填写标准的时候，下层系统处理到该业务请求的时候会将该业务请求打回去，请求人需要对该业务请求进行修改后重新提交，也就意味着请求人的该业务请求需要重新排队进行处理，从而使得该业务请求的处理时间延长，而且对于下层系统来说，处理的业务量也被增加了；因此，本系统中还包括有预审子系统，预审子系统包括有分发模块、验证码发送模块、确认模块、结果处理模块、队列调整模块和验证码组合模块，验证码发送模块预存有需要识别的图像分割信息，如客户上传的一些图像信息，如手写说明的复印件，在处理前需要对该图像信息进行识别，若干个图像分割信息可拼合成一个完整的图像信息；分发模块将异步消息队列中排队靠前的业务请求随机发送给排队靠后的业务请求的请求人，同时验证码发送模块将预存的一个图像分割信息发送给该请求人，如请求人A的业务请求a此时排队第8位，请求人B的业务请求b此时排队第18位，分发模块将业务请求a发送给请求人B，请求人在接收到分发模块发送来的业务请求后对该业务请求进行审核，即请求人B接收到业务请求a并对业务请求a进行审核，同时也对接收到的图像分割信息进行识别，然后将审核结果以及识别出的图形分割信息的文字信息通过确认模块发送到结果处理模块，若审核结果为否，则异步信息队列将该业务请求发回请求人进行重新填写，即将业务请求a发回给请求人A进行修改或重新填写，若审核结果为是，结果处理模块则将该识别出的文字信息与该业务请求进行关联存储，然后，在下层系统对异步消息队列中的业务请求进行处理时，即对请求人A的请求业务a进行处理时，在处理的过程中，若该请求业务能够被正常处理，则说明该业务请求是符合填写标准的，即审核结果是准确的，也就是说请求人B的审核结果是正确的，因此队列调整模块则将该审核结果提交人，即请求人B的业务请求b的排队顺序提前一位，请求业务b的排队顺序被调至第17位，同时将关联存储的文字信息发送到验证码组合模块进行存储；若该请求业务不能被正常处理，即该业务请求是不符合填写标准的，也就是说审核人在进行审核的时候并没有仔细审核，此时队列调整模块则将该审核结果提交人的业务请求的排队顺序后延一位，即请求人B的业务请求b的排队顺序被调至第19位，同时将提交的文字信息丢弃；验证码发送模块在接受到文字信息后，验证码组合模块对这些文字信息进行组合得到验证码发送模块中图像信息的文字信息，也就省去了系统对该图形信息的识别操作。

以上所述的仅是本发明的实施例，方案中公知的具体结构及特性等常识在此未作过多描述，所属领域普通技术人员知晓申请日或者优先权日之前发明所属技术领域所有的普通技术知识，能够获知该领域中所有的现有技术，并且具有应用该日期之前常规实验手段的能力，所属领域普通技术人员可以在本申请给出的启示下，结合自身能力完善并实施本方案，一些典型的公知结构或者公知方法不应当成为所属领域普通技术人员实施本申请的障碍。应当指出，对于本领域的技术人员来说，在不脱离本发明结构的前提下，还可以作出若干变形和改进，这些也应该视为本发明的保护范围，这些都不会影响本发明实施的效果和专利的实用性。本申请要求的保护范围应当以其权利要求的内容为准，说明书中的具体实施方式等记载可以用于解释权利要求的内容。

Claims (6)

1.基于分布式令牌桶的削峰处理方法，其特征在于：包括以下内容：

业务请求流量判断步骤：接收到上层系统发送来的业务请求后，判断业务请求的流量是否超过预设的流量峰值，若业务请求的流量超过流量峰值，将该业务请求发送到异步消息队列，若业务请求的流量不超过流量峰值，将该业务请求发送到下层系统；

业务请求处理步骤：下层系统接收到业务请求后调用相应的业务代码进行处理，在此过程中进入到异步消息队列中的业务请求处于排队等待状态；

异步消息队列消费步骤：在下层系统处理完业务请求后，对排队等待的业务请求进行消费，判断消费后的业务请求的流量是否超过流量峰值，若判断不超过流量峰值，将该业务请求发送到下层系统进行处理，若超过，继续消费该业务请求，直到业务请求的流量不超过流量峰值后，将该业务请求发送到下层系统进行处理。

2.根据权利要求1所述的基于分布式令牌桶的削峰处理方法，其特征在于：所述业务请求流量判断步骤采用令牌桶算法进行判断，当有业务请求到达时，每向下层系统发送一个业务请求时消耗一个令牌，在令牌桶内令牌被消耗完后，此时到达的业务请求则被发送到异步消息队列。

3.根据权利要求2所述的基于分布式令牌桶的削峰处理方法，其特征在于：所述业务请求流量判断步骤中，令牌桶中最大的令牌数与下层系统的处理能力相匹配。

4.根据权利要求3所述的基于分布式令牌桶的削峰处理方法，其特征在于：所述业务请求流量判断步骤中，所述令牌桶最大的令牌数可动态调整。

5.根据权利要求2所述的基于分布式令牌桶的削峰处理方法，其特征在于：所述业务请求流量判断步骤中，基于分布式协调组件zookeeper实现分布式令牌桶算法。

6.根据权利要求5所述的基于分布式令牌桶的削峰处理方法，其特征在于：所述异步消息队列消费步骤中采用Kafka消费组件进行消费。