一种全局流控方法及装置与流程

本发明涉及互联网技术领域，尤其涉及一种全局流控方法及装置。

背景技术：

随着电商、互联网金融业的兴起，对于支撑各类在线业务的it系统提出了高并发、高可靠、低延迟、低成本等综合能力要求。

为了保障整个it生态链总体上的健康度，对于接入的子系统进行流控与降级是一种常用的控制手段。随着业务规模的快速增长，往往一个it生态链会涉及数百个子系统，几千至几万台硬件设备，整个系统的风险点急剧上升，为了保障系统整体或部分一直在线，大规模全局系统中的系统架构，一般都会进行分布式的多活部署。而在实际的工程应用中，需要在令牌的发放侧明确令牌的有效期，并将具有相同有效期的令牌分装在一个或者多个子集合中，当应用服务器请求令牌时，则将子集合作为令牌资源进行分配。在传统的单应用/数据节点、单机房情况下，子集合的分配过程中，占用系统资源的问题还不明显。

但是，对于分布式的多活系统，不同节点对于令牌的需求量也不一样，因此为保障令牌分配过程中的均匀性，缓减令牌被闲置占用的问题，设计人员都会想尽办法减小子集合的粒度，提高令牌分配的均匀性。但是，子集合的粒度越小意味同时需要管理的子集合的数量越多，就需要占用更多的系统资源，其结果往往是系统资源的消耗量增加了一个量级。

对于银行、铁路售票等重要部门的系统来说，可以通过增加硬件设备的方式提高系统资源量，从而解决该问题，但是这种方式对于大部分互联网企业来说，成本太高。

技术实现要素：

本发明的实施例提供一种全局流控方法及装置，能够提供一种分布式系统中能够灵活部署的全局流控方案，缓减通过增加硬件设备的方式提高系统资源量从而导致的成本问题。

为达到上述目的，本发明的实施例采用如下技术方案：

在接收到应用服务器发送的请求消息后，确定所述请求消息对应的流控项，其中，所述流控项包括至少一个分项；

根据所述流控项，向中央控制器请求获取令牌；

获取所述中央控制器分配的令牌并反馈至发出请求的应用服务器，其中，针对一个分项所分配的令牌的数量由所述中央控制器根据加总的时间和每秒流控值的获取；所述每秒流控值为：所述中央控制器单位时间内分配的令牌数。

本实施例中提供了一种本地与中央控制相结合的流控体系：在本地组件加载相应的规则引擎，从而判定需要流控的场景，其中，规则引擎可以采用目前已有的技术和算法。中央控制器以每秒流控值和加总的时间计算所需分配的令牌数，从而实现了完全以时间度量的令牌产生数量。并且，由于通过本地组件隔离了应用服务器和中央控制器的直接通信，使得中央控制器的通信压力减少。本实施例尤其适用于大规模、分布式的实时处理系统上，并且通过更改时间阈值和每秒流控值，即可实现大规模、分布式的实时处理系统的快速配置的，快速变更和生效的流控机制，实际应用中可以适应几乎所有的流控场景。

附图说明

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

图1为本发明实施例提供的一种可能的系统架构示意图；

图2为本发明实施例提供的一种方法流程示意图；

图3为本发明实施例提供的另一种方法流程示意图；

图4为本发明实施例提供的具体实例的示意图。

具体实施方式

为使本领域技术人员更好地理解本发明的技术方案，下面结合附图和具体实施方式对本发明作进一步详细描述。下文中将详细描述本发明的实施方式，所述实施方式的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施方式是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的任一单元和全部组合。本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样定义，不会用理想化或过于正式的含义来解释。

本实施例中的方法流程，具体可以在一种如图1所示的系统上执行，该系统包括：应用服务器、中央控制器和本地组件。其中，应用服务器具体用于运行各类在线业务系统，比如：网购提供、物流系统、订单系统、在线金融系统等等，这些应用服务器在运行的过程中，由于预先设定的运行规则和运行机制，往往需要向后台服务器请求令牌。需要说明的是，本实施例中，对于应用服务器为何需要请求令牌的原因和具体的业务规则并不做限定，本实施例的方案主要用于收到令牌请求后的处理过程。

中央控制器具体可以设置在：用于管理应用服务器集群的后台服务器、数据中心等分布式系统中通常被称为“后台”的一侧。本实施例中所揭示的应用服务器以及中央控制器，具体可以是服务器、工作站、超级计算机等设备，或者是由多个服务器组成的一种用于数据处理的服务器集群系统。

需要说明的是，在实际应用中，本地组件可以实现在一个独立的服务器设备上；或者，应用服务器和本地组件集成在同一个服务器集群中，即通过同一个服务器集群同时承担应用服务器和本地组件的功能，例如：在应用服务器的服务器集群系统中，建立虚拟机并用于运行用于实现本地组件的具体功能的程序代码。

从程序代码层面上，本地组件功能要求，可以包括：采用一种高效的规则引擎，能够快速的根据请求判定出涉及的流控项；与中央控制器高效交互，获得各分项的令牌值，并在无令牌时以合适的方式通知本地的应用系统；采取适合的机制确保整个获取令牌的过程在确定的时间阈值内结束(比尔：10ms以内)。即在本实施例中，采用专门的本地组件向中央控制器发送令牌请求，而不是海量的应用服务器直接向中央控制器发送令牌请求，从而减少中央控制器的通信压力。

从程序代码层面上，中央控制器可以实现为：部署为大量java应用服务集群+redis高可用集群；redis中主要通过incr指令来完成本实施例中所涉及的算法要求。本地组件以jar包方式提供给应用服务器，从而以透明的方式提供流控功能，即对于应用服务器来说，本地组件是不可见的，应用服务器一侧也不需要进行额外的改造，从而降低本实施例方案的实现成本。中央控制器可以独占性服务存在，即系统全局只有一个。中央控制器在硬件层面可以集群方式部署，所有组成部分不存在单点。

本发明实施例提供一种全局流控方法，可以实现在如图1所示的本地组件上，如图2所示，包括：

s11、在接收到应用服务器发送的请求消息后，确定所述请求消息对应的流控项。

其中，所述流控项包括至少一个分项。所述请求消息用于应用服务器向后台侧请求获取令牌。中央控制器具体可以设置在：用于管理应用服务器集群的后台服务器、数据中心等分布式系统中通常被称为“后台”的一侧。在现有的技术中，应用服务器是与“后台”的一侧直接进行通信兵请求获取令牌的，本实施例中则通过本地组件接受请求消息，并统计一段时间内一个或者多个应用服务器发送的请求消息，再生成流控项，之后通过流控项向中央控制器请求获取令牌，从而降低中央控制器的访问次数，降低通信压力。

s12、根据所述流控项，向中央控制器请求获取令牌。

在本实施例中，可以由本地组件判断并确定哪些作为流控分项，其中，一个分项对应一个场景主键。场景主键具体可以是数字、字母等字符，用于标识某一个业务场景，比如订单业务、促销业务等。在本实施例的优选方案中，场景主键用于标识业务场景中的各个业务环节，比如：接受用户下订单的业务中，业务环节分为：订单建立--订单信息校对--商品库存校对--反馈确收消息，则可以通过4个场景主键分别标识这4个业务环节，且由于实际应用中由于业务量很大，每一个业务环节通常会通过至少一个应用服务器集群进行处理。在技术层面上，每一台应用服务器在全局系统中通常会被划分为一个线程，比如：承担订单建立的应用服务器如果有100台，则存在100个同时向中央控制器请求令牌的线程。s13、获取所述中央控制器分配的令牌并反馈至发出请求的应用服务器。

其中，针对一个分项所分配的令牌的数量由所述中央控制器根据加总的时间和每秒流控值的获取。

所述中央控制器针对每一个接收到的令牌请求分配时间片，并在第二时间轴上将时间点向前移动，直至所述第二时间轴上的时间点的值达到第一时间轴当前的时间值，时间点向前移动的量等于所分配出的时间片的量，所述第一时间轴对应自然时间，每次分配的时间片各自对应一个分项。

所述每秒流控值为：所述中央控制器单位时间内分配的令牌数。

目前流控机制的思路大致有2种：

1、在一定的时间内连接数有限的情况下，控制并发量，主要适用于各类大型促销活动(比如双十一、双十二)中缓减负载压力。

2、控单位时间内的令牌发放量。比如：2000订单由100台服务器处理，需要负载均衡，但是不同的服务器的实际性能有区别，有的能处理200，有的只能处理50，就需要针对不同的服务器封装不同大小的令牌子集合并分配给发出请求的应用服务器，即通过时间戳标识的子集合打包令牌，再分配子集合。

本实施例中提供了一种本地与中央控制相结合的流控体系：在本地组件加载相应的规则引擎，从而判定需要流控的场景，其中，规则引擎可以采用目前已有的技术和算法。中央控制器以每秒流控值和加总的时间计算所需分配的令牌数，从而实现了完全以时间度量的令牌产生数量。并且，由于通过本地组件隔离了应用服务器和中央控制器的直接通信，使得中央控制器的通信压力减少。例如：如图4所示的本地组件判定流程。

本实施例尤其适用于大规模、分布式的实时处理系统上，并且通过更改时间阈值和每秒流控值，即可实现大规模、分布式的实时处理系统的快速配置的，快速变更和生效的流控机制，实际应用中可以适应几乎所有的流控场景。例如：可以按场景配置，如一个典型的互金类系统，可以控制到在每周10点到12点，用户a的账户支付处理流控为每秒5笔。并且通过可以被实时调整的每秒流控值，改善令牌产生和获取机制，使出入的令牌可以平滑连续，解决令牌桶切换点前后计数不准确的问题。

本实施例中，针对每一个接收到的令牌请求分配时间片，并在第二时间轴上将时间点向前移动，直至所述第二时间轴上的时间点的值达到第一时间轴当前的时间值，时间点向前移动的量等于所分配出的时间片的量，所述第一时间轴对应自然时间，每次分配的时间片各自对应一个分项。从而实现了完全以时间度量的令牌产生和分配方式。第二时间轴上的时间点，依据所分配的时间片不断小步趋近当前时间，每次令牌请求，会在中央控制器索取一个个小分片，直到第二时间轴上的时间点追上第一时间轴上的时间点(即自然时间)，而加总时间指的是：第二时间轴上的时间点追上自然时间后，对在这“不断小步趋近”的过程中所分配出的时间片求和。在本实施例中，向中央控制器请求获取令牌的具体，包括：判定本地是否缓存了所述流控项中各个分项对应的令牌，并筛选出在本地没有缓存令牌的分项。依据筛选后的分项向中央控制器请求获取令牌。本地组件所在的服务器设备，缓存由中央控制器返回的令牌，本地组件未消耗完令牌之前不再向中央控制器请求，从而进一步减小中央控制器的负载。举例来说：一般系统间的交互都会以某种协议格式做为系统间的通讯标准。本地组件拆解这种协议，并将各请求分项输入到规则引擎当中，规则引擎必须高效的解析出这组请求涉及到的所有“流控场景”。

规则引擎输出所有流控场景的键值。本地组件遍历请求项的键值列表。判断本地组件是否缓冲有某一键值的令牌，有则消耗本地缓存。将遍历判定的所有本地无缓冲令牌的键值形成新列表发送中央控制器。中央控制器返回要求的所有键值的令牌值。本地组件将返回的令牌列表缓存并消耗。在这个过程中，出现无令牌的情况，都表明触发了流控。

进一步的，还包括：当向中央控制器请求获取令牌失败时，可以继续降级运行，降级的意思即，本地组件生成一点令牌并给应用服务器，应用服务器的请求大都被打回，但是依旧一部分得到本地产生的令牌从而正常运行，比如：本地组件生成令牌；从发出请求的应用服务器中筛选应用服务器，向筛选出的应用服务器反馈令牌，其中，所述本地组件生成令牌少于所有应用服务器请求的令牌数。从而确保即使在无法与中央控制器连通等情况下仍能以合适的降级机制运行，使应用系统不受影响。

本实施例提供一种全局流控方法，可以实现在如图1所示的中央控制器上，如图3所示的，该方法包括：

s21、接受本地组件发送的令牌请求。

其中，所述令牌请求中记录流控项，所述流控项包括至少一个分项。具体的，一个分项对应一个场景主键。在向所述本地组件分配令牌后，覆写各个分项对应的场景主键。

本实施例中的令牌发放方式，可以理解为一种以完全时间度量的令牌算法。通过场景主键标注某个流控场景(比如下订单、预购、在线理财赎回等需要应用服务器与后台侧进行数据交互的场景)，并建立场景主键时的时间作为场景主键的实际内容。当一个应用服务器针对某一个流控场景发出令牌请求后，本地组件可以覆写场景主键的内容，比如刷新场景主键中记载的时间值，并以覆写场景主键的内容作为处理下一个应用服务器请求的充要条件，从而避免多个应用服务器同时发出请求时，本地组件接受请求混乱的问题。而每一次的覆写，第二时间轴上的时间点都可以一种较小的值逼进真实的当前时间，直到等于或晚于当前时间。比如：当前时间为1:10:10:10(单位为时:分:秒:毫秒，即精确到至少毫秒)，流控项中的各个分项的场景主键被生成的时间为，1:10:10:00，则每一次本地组件接收到一个应用服务器发送的请求后，就覆写主键中记录的时间值，每一次覆写可以增加2毫秒，比如应用服务器1、2、3，分别在这10毫秒内都发出了请求，例如：

应用服务器1、2、3在当前时间走到1:10:10:01时，分别发出一次请求，则场景主键的内容覆写顺序为：1:10:10:02→1:10:10:04→1:10:10:06；

应用服务器2在当前时间走到1:10:10:07又发出一次请求，则场景主键的内容覆写为1:10:10:08；

应用服务器3在当前时间走到1:10:10:08又发出一次请求，则场景主键的内容覆写为1:10:10:10；

应用服务器1在当前时间走到1:10:10:10又发出一次请求，则场景主键的内容覆写为1:10:10:12，由于1:10:10:12超过了当前时间1:10:10:00，因此本次不再覆写，向应用服务器1发出退回消息，或者等待下一周期中再次计数。即每一次应用服务器计时的覆写是互斥的，只能累加，若有同时收到的请求，则所有请求都累加

s22、针对每一个接收到的令牌请求分配时间片，并在第二时间轴上将时间点向前移动，直至第二时间轴上的时间点的值达到第一时间轴当前的时间值。

其中，时间点向前移动的量等于所分配出的时间片的量，所述第一时间轴对应自然时间，每次分配的时间片各自对应一个分项。使得第二时间轴的时间点，根据分配出去的时间片不断往前步进，第一时间轴即为全局系统的自然时间。第二号时间轴上的时间点不断前进，直至追上第一时间轴上的自然时间点，即追上当前时间。

s23、对分配给每一个分项的时间片进行加总得到加总的时间，根据所述加总的时间和每秒流控值，获取所述流控项中的每一个分项的令牌的数量，并根据所述数量向所述本地组件分配令牌。

在本实施例中。所述每秒流控值为：所述中央控制器单位时间内分配的令牌数。

具体的，所述根据加总的时间和每秒流控值，获取所述流控项中的每一个分项的令牌的数量，包括：

在超过所述时间阈值之前，接收所述本地组件向所述中央控制器发出的所有令牌请求。

根据接收到的令牌请求，获取针对每一个分项被请求的时间段。

将针对每一个分项被请求的时间段求和，得到针对每一个分项的加总的时间。

将每一个分项的加总的时间与所述每秒流控值相乘，得到所述流控项中的每一个分项的令牌的数量。即令牌数＝加总的时间*每秒流控值。

例如：在第二时间轴的时间点追上第一时间轴的当前时间的过程中，

共有90个应用服务器通过本地组件请求了令牌，本地组件则分3次向中央控制器上报了流控项，中央控制器针对每一次的上报，分别分配了时间片10ms、2ms、3ms，因此加总的时间为15ms，而每秒流控值＝10000/s即10/ms，则中央控制器应反馈的令牌数为15ms*10/ms＝150个。

本地组件在每一个时间区间内不断地向中央控制器发送流控项。通过中央控制器和本地组件的二层配合，使得中央控制器对令牌的填充可以均匀、流式的注入。令牌分发时：确保在统计意义上，分发给各请求方的令牌是准确并平均的。

本实施例中提供了一种本地与中央控制相结合的流控体系：在本地组件加载相应的规则引擎，从而判定需要流控的场景，其中，规则引擎可以采用目前已有的技术和算法。中央控制器以每秒流控值和加总的时间计算所需分配的令牌数，从而实现了完全以时间度量的令牌产生数量。并且，由于通过本地组件隔离了应用服务器和中央控制器的直接通信，使得中央控制器的通信压力减少。

本实施例尤其适用于大规模、分布式的实时处理系统上，并且通过更改时间阈值和每秒流控值，即可实现大规模、分布式的实时处理系统的快速配置的，快速变更和生效的流控机制，实际应用中可以适应几乎所有的流控场景。例如：可以按场景配置，如一个典型的互金类系统，可以控制到在每周10点到12点，用户a的账户支付处理流控为每秒5笔。并且通过可以被实时调整的每秒流控值，改善令牌产生和获取机制，使出入的令牌可以平滑连续，解决令牌桶切换点前后计数不准确的问题。

本发明实施例还提供一种用于全局流控的本地组件，包括：

预处理模块，用于在接收到应用服务器发送的请求消息后，确定所述请求消息对应的流控项，其中，所述流控项包括至少一个分项；

交互模块，用于根据所述流控项，向中央控制器请求获取令牌；

处理模块，用于获取所述中央控制器分配的令牌并反馈至发出请求的应用服务器，其中，针对一个分项所分配的令牌的数量由所述中央控制器根据加总的时间和每秒流控值的获取；所述中央控制器针对每一个接收到的令牌请求分配时间片，并在第二时间轴上将时间点向前移动，直至所述第二时间轴上的时间点的值达到第一时间轴当前的时间值，时间点向前移动的量等于所分配出的时间片的量，所述第一时间轴对应自然时间，每次分配的时间片各自对应一个分项；所述每秒流控值为：所述中央控制器单位时间内分配的令牌数。

本发明实施例还提供一种用于全局流控的中央控制器，包括：

接收模块，用于接受本地组件发送的令牌请求，其中，所述令牌请求中记录流控项，所述流控项包括至少一个分项；

管理模块，用于针对每一个接收到的令牌请求分配时间片，并在第二时间轴上将时间点向前移动，直至第二时间轴上的时间点的值达到第一时间轴当前的时间值，其中，时间点向前移动的量等于所分配出的时间片的量，所述第一时间轴对应自然时间，每次分配的时间片各自对应一个分项；

流控模块，用于对分配给每一个分项的时间片进行加总得到加总的时间，根据所述加总的时间和每秒流控值，获取所述流控项中的每一个分项的令牌的数量，并根据所述数量向所述本地组件分配令牌。

具体的，所述流控模块，具体用于：

在超过所述时间阈值之前，接收所述本地组件向所述中央控制器发出的所有令牌请求；根据接收到的令牌请求，获取针对每一个分项被请求的时间段，其中，所述时间阈值为时间区间的最后时刻，所述时间区间被划分为至少2个时间段；将针对每一个分项被请求的时间段求和，得到针对每一个分项的加总的时间；将每一个分项的加总的时间与所述每秒流控值相乘，得到所述流控项中的每一个分项的令牌的数量。

本实施例中提供了一种本地与中央控制相结合的流控体系：在本地组件加载相应的规则引擎，从而判定需要流控的场景，其中，规则引擎可以采用目前已有的技术和算法。中央控制器以每秒流控值和加总的时间计算所需分配的令牌数，从而实现了完全以时间度量的令牌产生数量。并且，由于通过本地组件隔离了应用服务器和中央控制器的直接通信，使得中央控制器的通信压力减少。例如：如图4所示的本地组件判定流程。

本实施例尤其适用于大规模、分布式的实时处理系统上，并且通过更改时间阈值和每秒流控值，即可实现大规模、分布式的实时处理系统的快速配置的，快速变更和生效的流控机制，实际应用中可以适应几乎所有的流控场景。例如：可以按场景配置，如一个典型的互金类系统，可以控制到在每周10点到12点，用户a的账户支付处理流控为每秒5笔。并且通过可以被实时调整的每秒流控值，改善令牌产生和获取机制，使出入的令牌可以平滑连续，解决令牌桶切换点前后计数不准确的问题。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。