CN110275780B - 用于限制流量的方法和装置 - Google Patents

Abstract

本申请实施例公开了用于限制流量的方法和装置。该方法的一具体实施方式包括：对于线程池中的线程，接收该线程发送的请求；获取该线程的状态数据，其中，状态数据包括在流控周期内的初始化时间戳、已放行且未消耗令牌的请求数和全局已消耗令牌数；基于该线程的状态数据，确定是否通过批量消耗令牌方式放行；响应于确定通过批量消耗令牌方式放行，放行该线程发送的请求至云端进行处理。该实施方式采用批量消耗令牌方式减少线程之间为了消耗令牌而发生的竞争关系，有效地避免了CPU等待或空转的现象，减少了CPU资源的浪费。同时，在高并发场景下，减小因限流而带来的性能开销，提高系统的并发能力。

Description

用于限制流量的方法和装置

技术领域

本申请实施例涉及计算机技术领域，具体涉及用于限制流量的方法和装置。

背景技术

在高并发场景下，经常会出现瞬间有大量的请求发送到云端的情况。不管这些流量是正常流量还是异常流量，为了有效的保护好服务器，通常都需要对服务器进行限流。因为这些请求的背后往往伴随着大量的逻辑运算，数据查询，远程过程调用等，这些操作都会消耗掉大量的系统性能。如果不对流量进行限制的话，很可能出现服务器被压垮，甚至产生蝴蝶效应，使得整个系统的各服务间来回震荡，产生雪崩。

尽管传统的限流方案能够满足我们的日常需要，但在高并发情形下，传统的限流方案并不能起到很好的效果。原因在于传统的限流方案会针对单个或多个令牌进行加锁，加锁会导致在多核CPU急剧竞争临界资源时产生等待或者空转，对CPU而言是一种浪费。而高并发情形下本来系统资源就十分稀缺，CPU被大量浪费在了获取锁的等待中，导致并发能力下降。

发明内容

本申请实施例提出了用于限制流量的方法和装置。

第一方面，本申请实施例提供了一种用于限制流量的方法，包括：对于线程池中的线程，接收该线程发送的请求；获取该线程的状态数据，其中，状态数据包括在流控周期内的初始化时间戳、已放行且未消耗令牌的请求数和全局已消耗令牌数；基于该线程0的状态数据，确定是否通过批量消耗令牌方式放行；响应于确定通过批量消耗令牌方式放行，放行该线程发送的请求至云端进行处理。

在一些实施例中，该方法还包括：响应于确定不通过批量消耗令牌方式放行，添加该线程发送的请求至队列进行等待。

在一些实施例中，基于该线程的状态数据，确定是否通过批量消耗令牌方式放行，包括：计算当前系统时间戳与该线程的状态数据中的初始化时间戳的差值，作为第一差值；确定第一差值是否大于流控周期；响应于确定不大于流控周期，确定该线程的状态数据中的全局已消耗令牌数是否小于在流控周期内的全局令牌数；响应于确定小于全局令牌数，确定通过批量消耗令牌方式放行。

在一些实施例中，基于该线程的状态数据，确定是否通过批量消耗令牌方式放行，还包括：响应于确定大于流控周期，初始化该线程的状态数据。

在一些实施例中，基于该线程的状态数据，确定是否通过批量消耗令牌方式放行，还包括：响应于确定不小于全局令牌数，确定不通过批量消耗令牌方式放行。

在一些实施例中，确定通过批量消耗令牌方式放行，包括：基于该线程发送的请求的数量，更新该线程的状态数据中的已放行且未消耗令牌的请求数；确定该线程的状态数据中的已放行且未消耗令牌的请求数是否小于批量消耗令牌数；响应于确定小于批量消耗令牌数，确定放行该线程发送的请求。

在一些实施例中，确定通过批量消耗令牌方式放行，还包括：响应于确定等于批量消耗令牌数，确定放行该线程发送的请求，批量消耗令牌，初始化该线程的状态数据中的已放行且未消耗令牌的请求数，以及基于批量消耗令牌数，更新线程池中的线程的状态数据中的全局已消耗令牌数。

在一些实施例中，添加该线程发送的请求至队列进行等待，包括：周期性启动定时器定时读取队列中存储的请求；计算队列中存储的请求被添加至队列的时间戳与当前系统时间戳的差值，作为第二差值；确定第二差值是否小于过期时间；响应于确定不小于过期时间，从队列中丢弃不大于丢弃上限的数目个请求。

在一些实施例中，添加该线程发送的请求至队列进行等待，包括：响应于确定小于过期时间，结束当前定时任务或为队列中存储的请求与线程池中的其他线程争抢令牌。

第二方面，本申请实施例提供了一种用于限制流量的装置，包括：接收单元，被配置成对于线程池中的线程，接收该线程发送的请求；获取单元，被配置成获取该线程的状态数据，其中，状态数据包括在流控周期内的初始化时间戳、已放行且未消耗令牌的请求数和全局已消耗令牌数；确定单元，被配置成基于该线程的状态数据，确定是否通过批量消耗令牌方式放行；放行单元，被配置成响应于确定通过批量消耗令牌方式放行，放行该线程发送的请求至云端进行处理。

在一些实施例中，该装置还包括：添加单元，被配置成响应于确定不通过批量消耗令牌方式放行，添加该线程发送的请求至队列进行等待。

在一些实施例中，确定单元包括：第一计算子单元，被配置成计算当前系统时间戳与该线程的状态数据中的初始化时间戳的差值，作为第一差值；第一确定子单元，被配置成确定第一差值是否大于流控周期；第二确定子单元，被配置成响应于确定不大于流控周期，确定该线程的状态数据中的全局已消耗令牌数是否小于在流控周期内的全局令牌数；第三确定子单元，被配置成响应于确定小于全局令牌数，确定通过批量消耗令牌方式放行。

在一些实施例中，确定单元还包括：初始化子单元，被配置成响应于确定大于流控周期，初始化该线程的状态数据。

在一些实施例中，确定单元还包括：第四确定子单元，被配置成响应于确定不小于全局令牌数，确定不通过批量消耗令牌方式放行。

在一些实施例中，第三确定子单元包括：更新模块，被配置成基于该线程发送的请求的数量，更新该线程的状态数据中的已放行且未消耗令牌的请求数；第一确定模块，被配置成确定该线程的状态数据中的已放行且未消耗令牌的请求数是否小于批量消耗令牌数；第二确定模块，被配置成响应于确定小于批量消耗令牌数，确定放行该线程发送的请求。

在一些实施例中，第三确定子单元还包括：第三确定模块，被配置成响应于确定等于批量消耗令牌数，确定放行该线程发送的请求，批量消耗令牌，初始化该线程的状态数据中的已放行且未消耗令牌的请求数，以及基于批量消耗令牌数，更新线程池中的线程的状态数据中的全局已消耗令牌数。

在一些实施例中，添加单元包括：读取子单元，被配置成周期性启动定时器定时读取队列中存储的请求；第二计算子单元，被配置成计算队列中存储的请求被添加至队列的时间戳与当前系统时间戳的差值，作为第二差值；第五确定子单元，被配置成确定第二差值是否小于过期时间；丢弃子单元，被配置成响应于确定不小于过期时间，从队列中丢弃不大于丢弃上限的数目个请求。

在一些实施例中，添加单元还包括：结束子单元，被配置成响应于确定小于过期时间，结束当前定时任务或为队列中存储的请求与线程池中的其他线程争抢令牌。

第三方面，本申请实施例提供了一种电子设备，该电子设备包括：一个或多个处理器；存储装置，其上存储有一个或多个程序；当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现如第一方面中任一实现方式描述的方法。

第四方面，本申请实施例提供了一种计算机可读介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如第一方面中任一实现方式描述的方法。

本申请实施例提供的用于限制流量的方法和装置，对于线程池中的线程，在接收到该线程发送的请求的情况下，获取该线程的状态数据；基于该线程的状态数据，确定是否通过批量消耗令牌方式放行；在确定通过批量消耗令牌方式放行的情况下，放行该线程发送的请求至云端进行处理。采用批量消耗令牌方式减少线程之间为了消耗令牌而发生的竞争关系，有效地避免了CPU等待或空转的现象，减少了CPU资源的浪费。同时，在高并发场景下，减小因限流而带来的性能开销，提高系统的并发能力。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1是本申请可以应用于其中的示例性系统架构；

图2是根据本申请的用于限制流量的方法的一个实施例的流程图；

图3是根据本申请的用于限制流量的方法的又一个实施例的流程图；

图4是根据本申请的用于限制流量的方法的另一个实施例的流程图；

图5是根据本申请的用于限制流量的装置的一个实施例的结构示意图；

图6是适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

图1示出了可以应用本申请的用于限制流量的方法或用于限制流量的装置的实施例的示例性系统架构100。

如图1所示，系统架构100中可以包括终端设备101、102、103，服务器104，云服务器105和网络106、107。网络106用以在终端设备101、102、103和服务器104之间提供通信链路的介质。网络107用以在服务器104和云服务器105之间提供通信链路的介质。网络106、107可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

终端设备101、102、103可以通过网络106与服务器104交互，以接收或发送消息等。终端设备101、102、103可以是硬件，也可以是软件。当终端设备101、102、103为硬件时，可以是各种电子设备。包括但不限于智能手机、平板电脑、便携式计算机、台式计算机、电视机、冰箱、洗衣机和智能音箱等等。当终端设备101、102、103为软件时，可以安装在上述电子设备中。其可以实现成多个软件或软件模块，也可以实现成单个软件或软件模块。在此不做具体限定。

服务器104可以提供各种服务。例如服务器104可以对获取到的线程池中的线程发送的请求等数据进行分析等处理，并根据处理结果确定是放行该线程发送的请求至云服务器105，还是添加该线程发送的请求至队列。

需要说明的是，服务器104可以是硬件，也可以是软件。当服务器104为硬件时，可以实现成多个服务器组成的分布式服务器集群，也可以实现成单个服务器。当服务器104为软件时，可以实现成多个软件或软件模块(例如用来提供分布式服务)，也可以实现成单个软件或软件模块。在此不做具体限定。

云服务器105可以用于处理请求，包括但不限于逻辑运算、数据查询和远程过程调用等等。

需要说明的是，本申请实施例所提供的用于限制流量的方法一般由服务器104执行，相应地，用于限制流量的装置一般设置于服务器104中。

应该理解，图1中的终端设备、服务器、云服务器和网络的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、服务器、云服务器和网络。

继续参考图2，其示出了根据本申请的用于限制流量的方法的一个实施例的流程200。该用于限制流量的方法，包括以下步骤：

步骤201，对于线程池中的线程，接收该线程发送的请求。

在本实施例中，用于限制流量的方法的执行主体(例如图1所示的服务器104)可以接收线程池中的线程发送的请求。通常，上述执行主体可以与大量终端设备(例如图1所示的终端设备101、102、103)通信连接。终端设备发送的请求可以通过线程池中的线程发送至上述执行主体。

实践中，处理请求需要使用线程池。通常，线程池中的线程数可以是CPU核心数的两倍。也就是说，如果CPU的核心数为80，那么线程池中的线程数为160。

步骤202，获取该线程的状态数据。

在本实施例中，对于线程池中的线程，上述执行主体可以获取该线程的状态数据。

通常，线程池中的每一个线程都具有自己专属的状态数据(LimitData)。状态数据可以被保存在本地线程中。各线程之间的状态数据不存在竞争关系。其中，状态数据可以用于记录线程在流控周期内的状态信息，包括但不限于在流控周期内的初始化时间戳(startTs)、已放行且未消耗令牌的请求数(passedCount)和全局已消耗令牌数(limiterCount)等等。在一些情况下，如果线程尚未存在状态数据，上述执行主体还可以为线程生成一个全新的状态数据，此时，状态数据中的初始化时间戳可以是当前系统时间戳，状态数据中的已放行且未消耗令牌的请求数和全局已消耗令牌数可以为0。

应当理解的是，和传统的限流算法一样的是，需要一个能持续产生令牌的限流器配合，以固定的频率产生令牌。以计数器限流算法为例，如果流控QPS(Query Per Second，每秒查询率)参数是2000/秒，那么每秒钟将会产生2000个令牌。并且，若这2000个令牌在这1秒内被消耗完，在这1秒内将不再产生令牌。若这2000个令牌在这1秒没有被消耗完，在下1秒内会将剩余的令牌全部清零，并重新产生2000个令牌。通常，放行一个请求至云端需要消耗一个令牌。也就是说，如果规定流控周期(gapTime)是1秒，那么在流控周期内的全局令牌数为2000，每秒钟允许放行至云端的最大请求数(totalLimit)为2000。同时，由于传统的限流算法中争抢锁资源的操作往往发生在线程与线程之间，而同一个线程执行的任意多个请求之间是不存在锁资源竞争的。既然每次消耗令牌都会去争抢令牌，这也是性能的关键损耗，因此这里通过批量消耗令牌方式放行请求以减少竞争次数来提高系统性能。也就是说，如果批量消耗令牌数(localLimit)为5，那么线程每放行5个请求至云端，才会一次性批量消耗5个令牌。

这里，状态数据在每个流控周期内被初始化一次，因此，状态数据中的初始化时间戳可以是在流控周期内该状态数据生成或者初始化的时间戳。同时，通过批量消耗令牌方式放行请求，因此，状态数据中的已放行且未消耗令牌的请求数通常不会大于批量消耗令牌数。在流控周期内产生固定数目的令牌，且被全部消耗完不再产生令牌，因此，状态数据中的全局已消耗令牌数通常不会大于在流控周期内的全局令牌数。

步骤203，基于该线程的状态数据，确定是否通过批量消耗令牌方式放行。

在本实施例中，对于线程池中的线程，上述执行主体可以对该线程的状态数据进行分析，以确定是否通过批量消耗令牌方式放行。在确定通过批量消耗令牌方式放行的情况下，上述执行主体可以执行步骤204。

通常，上述执行主体可以预先设定条件。在状态数据满足预先设定的条件的情况下，上述执行主体可以确定通过批量消耗令牌的方式放行。其中，预设条件可以例如是状态数据中的已放行且未消耗令牌小于批量消耗令牌数，且全局已消耗令牌数小于在流控周期内的全局令牌数。

实践中，当大量请求到来时，首先会经过增强限流器。增强限流器对于每一个线程而言，维护了该线程的状态数据，以及决定是否通过批量消耗令牌方式放行。此外，增强限流器还可以决定向全局限流器批量申请消耗令牌的时间，以及是否将请求添加至队列。

步骤204，放行该线程发送的请求至云端进行处理。

在本实施例中，在确定通过批量消耗令牌方式放行的情况下，上述执行主体可以放行该线程发送的请求至云端(例如图1所示的云服务器105)进行处理。通常，云端可以基于请求进行大量的逻辑运算、数据查询、远程过程调用等等。

在本实施例的一些可选的实现方式中，在确定不通过批量消耗令牌的方式放行的情况下，上述执行主体可以根据实际情况对该线程发送的请求进行处理。例如，立即丢弃该线程发送的请求，等待一段时间后丢弃该线程发送的请求，或者与线程池中的其他线程争抢令牌等等。

本申请实施例提供的用于限制流量的方法，对于线程池中的线程，在接收到该线程发送的请求的情况下，获取该线程的状态数据；基于该线程的状态数据，确定是否通过批量消耗令牌方式放行；在确定通过批量消耗令牌方式放行的情况下，放行该线程发送的请求至云端进行处理。采用批量消耗令牌方式减少线程之间为了消耗令牌而发生的竞争关系，有效地避免了CPU等待或空转的现象，减少了CPU资源的浪费。同时，在高并发场景下，减小因限流而带来的性能开销，提高系统的并发能力。

进一步参考图3，其示出了根据本申请的用于限制流量的方法的又一个实施例的流程300。该用于限制流量的方法，包括以下步骤：

步骤301，对于线程池中的线程，接收该线程发送的请求。

步骤302，获取该线程的状态数据。

在本实施例中，步骤301-302的具体操作已在图2所示的实施例中步骤201-202中进行了详细的介绍，在此不再赘述。

步骤303，计算当前系统时间戳与该线程的状态数据中的初始化时间戳的差值，作为第一差值。

在本实施例中，对于线程池中的线程，用于限制流量的方法的执行主体(例如图1所示的服务器104)可以计算当前系统时间戳与该线程的状态数据中的初始化时间戳的差值(deltaTime)，并作为第一差值。

步骤304，确定第一差值是否大于流控周期。

在本实施例中，对于线程池中的线程，上述执行主体可以将第一差值与流控周期进行比较，以确定第一差值是否大于流控周期。若第一差值不大于流控周期，说明该线程的状态数据记录的是该线程在当前流控周期内的状态信息，该线程的状态数据未过期，此时，执行步骤305；反之，说明该线程的状态数据记录的是该线程在上一流控周期内的状态信息，该线程的状态数据已过期，此时，执行步骤310。

步骤305，确定该线程的状态数据中的全局已消耗令牌数是否小于在流控周期内的全局令牌数。

在本实施例中，对于线程池中的线程，在第一差值不大于流控周期的情况下，上述执行主体可以将该线程的状态数据中的全局已消耗令牌数与在流控周期内的全局令牌数进行比较，以确定该线程的状态数据中的全局已消耗令牌数是否小于全局令牌数。若该线程的状态数据中的全局已消耗令牌数小于全局令牌数，说明该流控周期内产生的令牌尚未被消耗完，此时，执行步骤306；反之，说明该流控周期内产生的令牌已被消耗完，此时，执行步骤308。

步骤306，确定通过批量消耗令牌方式放行。

在本实施例中，在该线程的状态数据中的全局已消耗令牌数小于全局令牌数的情况下，上述执行主体可以确定通过批量消耗令牌方式放行。随后，继续执行步骤307。

步骤307，放行该线程发送的请求至云端进行处理。

在本实施例中，步骤307的具体操作已在图2所示的实施例中步骤204中进行了详细的介绍，在此不再赘述。

步骤308，确定不通过批量消耗令牌方式放行。

在本实施例中，在该线程的状态数据中的全局已消耗令牌数不小于全局令牌数的情况下，上述执行主体可以确定不通过批量消耗令牌方式放。随后，执行步骤309。

步骤309，添加该线程发送的请求至队列进行等待。

在本实施例中，在确定不通过批量消耗令牌方式放行的情况下，上述执行主体可以添加该线程发送的请求至队列进行等待。

这里，上述执行主体通常不会将存储在队列中的请求立即丢弃，而是等队列中存储的请求过期后丢弃。

通常，存储到队列中的请求并没有得到执行，而是在队列中等待过期，当过期后则拒绝请求或者关闭通道，相当于拒绝此次请求。在物联网领域中，如果检测到超过限流器容量直接拒绝请求，则终端设备会立即将请求再次发送到服务器，相当于服务器压力并不会减少，而是立即收到同样的请求，因此将请求存储在队列中进行等待是非常有必要的。等到请求过期再丢弃则会大大减小服务器的压力。

通常情况下，突发流量是由于某些异常情况引起的，比如服务端某台服务器挂掉或者重启，也可能是大量终端设备集体出现问题。如果定期执行未处理完的请求，会导致部分旧的请求和新的请求争抢资源。同时，这部分请求由于长时间保存在队列中已过期，处理起来比较复杂，因此这里通常采用的策略是等队列中存储的请求过期后丢弃。

步骤310，初始化该线程的状态数据。

在本实施例中，在第一差值大于流控周期的情况下，上述执行主体可以初始化该线程的状态数据，即，将初始化时间戳初始化为当前系统时间戳，将已放行且未消耗令牌的请求数和全局已消耗令牌数均初始化为0。随后，返回继续执行步骤303。

从图3中可以看出，与图2对应的实施例相比，本实施例中的用于限制流量的方法的流程300突出了确定是否通过批量消耗令牌方式放行的步骤，同时增加了不通过批量消耗令牌方式放行时请求的处理步骤。由此，本实施例描述的方案能够快速地确定是否通过批量消耗令牌方式放行请求。同时，在不通过批量消耗令牌方式放行的情况下，添加该线程发送的请求至队列进行等待，等到请求过期再丢弃能够大大减小服务器的压力。

进一步参考图4，其示出了根据本申请的用于限制流量的方法的另一个实施例的流程400。该用于限制流量的方法，包括以下步骤：

步骤401，对于线程池中的线程，接收该线程发送的请求。

步骤402，获取该线程的状态数据。

步骤403，计算当前系统时间戳与该线程的状态数据中的初始化时间戳的差值，作为第一差值。

步骤404，确定第一差值是否大于流控周期。

步骤405，确定该线程的状态数据中的全局已消耗令牌数是否小于在流控周期内的全局令牌数。

在本实施例中，步骤401-405的具体操作已在图3所示的实施例中步骤301-305中进行了详细的介绍，在此不再赘述。

步骤406，基于该线程发送的请求的数量，更新该线程的状态数据中的已放行且未消耗令牌的请求数。

在本实施例中，对于线程池中的线程，在该线程的状态数据中的全局已消耗令牌数小于全局令牌数的情况下，用于限制流量的方法的执行主体(例如图1所示的服务器104)可以基于该线程发送的请求的数量，更新该线程的状态数据中的已放行且未消耗令牌的请求数。通常，同一线程在同一时间内仅能发送一个请求，因此，该线程的状态数据中的已放行且未消耗令牌的请求数会增加1。

步骤407，确定该线程的状态数据中的已放行且未消耗令牌的请求数是否小于批量消耗令牌数。

在本实施例中，对于线程池中的线程，上述执行主体可以将该线程的状态数据中的已放行且未消耗令牌的请求数与批量消耗令牌数进行比较，以确定该线程的状态数据中的已放行且未消耗令牌的请求数是否小于批量消耗令牌数。若该线程的状态数据中的已放行且未消耗令牌的请求数小于批量消耗令牌数，说明尚未到达批量消耗令牌的时间，此时，执行步骤408；反之，说明已到达批量消耗令牌的时间，此时，执行步骤409。

步骤408，确定放行该线程发送的请求。

在本实施例中，在该线程的状态数据中的已放行且未消耗令牌的请求数小于批量消耗令牌数的情况下，上述执行主体可以确定放行该线程发送的请求。随后，继续执行步骤410。

步骤409，确定放行该线程发送的请求，批量消耗令牌，初始化该线程的状态数据中的已放行且未消耗令牌的请求数，以及基于批量消耗令牌数，更新线程池中的线程的状态数据中的全局已消耗令牌数。

在本实施例中，在该线程的状态数据中的已放行且未消耗令牌的请求数等于批量消耗令牌数的情况下，上述执行主体可以确定放行该线程发送的请求，批量消耗令牌，初始化该线程的状态数据中的已放行且未消耗令牌的请求数，以及基于批量消耗令牌数，更新线程池中的线程的状态数据中的全局已消耗令牌数。随后，继续执行步骤410。这里，上述执行主体可以将该线程的状态数据中的已放行且未消耗令牌的请求数初始化为0，将线程池中的线程的状态数据中的全局已消耗令牌数增加批量消耗令牌数。

需要说明的是，如果CPU的核心数为80，那么线程池中的线程数为160。如果批量消耗令牌数为5，会在消耗令牌之前多放行800个请求。也就是说，如果产生的全局令牌数是2000，那么每秒钟实际放行的请求数为2800，因此需要多参数配置做额外的处理。例如，例如可以将全局已消耗令牌数限制为1200来实现每秒钟放行至云端的最大请求数为2000。

步骤410，放行该线程发送的请求至云端进行处理。

步骤411，确定不通过批量消耗令牌方式放行。

在本实施例中，步骤410-411的具体操作已在图3所示的实施例中步骤307-308中进行了详细的介绍，在此不再赘述。

步骤412，周期性启动定时器定时读取队列中存储的请求。

在本实施例中，在确定不通过批量消耗令牌方式放行的情况下，上述执行主体可以周期性启动定时器定时读取队列中的存储的请求。通常，队列中不仅会存储请求，还会同时存储请求被添加至队列的时间戳。例如，设置一个过期时间(expireTime)为6000毫秒，启动一个定时器，其周期(periodTime)为30ms。这样，就有一个定时任务持续读取队列中存储的请求。

步骤413，计算队列中存储的请求被添加至队列的时间戳与当前系统时间戳的差值，作为第二差值。

在本实施例中，上述执行主体可以计算队列中存储的请求被添加至队列的时间戳与当前系统时间戳的差值，作为第二差值。

步骤414，确定第二差值是否小于过期时间。

在本实施例中，上述执行主体可以将第二差值与过期时间进行比较，以确定第二差值是否小于过期时间。若第二差值不小于过期时间，说明该请求已经过期，则执行步骤415；反之，说明该请求尚未过期，则执行步骤416。

步骤415，从队列中丢弃不大于丢弃上限的数目个请求。

在本实施例中，在第二差值不小于过期时间的情况下，上述执行主体可以从队列中丢弃不大于丢弃上限(maxHandleCount)的数目个请求。通常，如果队列中存储的过期请求的数目不大于丢弃上限，那么直接丢弃所有过期请求。如果队列中存储的过期请求的数目大于丢弃上限，从队列中存储的过期请求中随机丢弃不大于丢弃上限的数目个请求。

这里，通过定时任务实现分批丢弃，可以有效地保护系统。因为如果大量过期的请求同时丢弃，会导致这些请求会立即再次发送至服务器，造成服务器压力增大。如果每个周期丢弃不大于丢弃上限的数目个请求，避免了出现大量请求再次同时发送至服务器的情况。

步骤416，结束当前定时任务或为队列中存储的请求与线程池中的其他线程争抢令牌。

在本实施例中，在第二差值小于过期时间的情况下，上述执行主体可以结束当前定时任务或为队列中存储的请求与线程池中的其他线程争抢令牌。通常，在物联网领域，由于检测到超过限流器容量直接拒绝请求，终端设备会立即将请求再次发送到服务器，因此上述执行主体可以结束当前定时任务，等待下一个定时任务周期，直至请求过期被丢弃。在互联网领域，由于请求是必需处理的，因此上述执行主体可以为队列中存储的请求与线程池中的其他线程争抢令牌，抢到就执行，没有抢到就等待。

步骤417，初始化该线程的状态数据。

在本实施例中，步骤417的具体操作已在图3所示的实施例中步骤310中进行了详细的介绍，在此不再赘述。

从图4中可以看出，与图3对应的实施例相比，本实施例中的用于限制流量的方法的流程400突出了确定通过批量消耗令牌方式放行的步骤，同时增加了同时增加了不通过批量消耗令牌方式放行时请求的处理步骤。由此，本实施例描述的方案能够快速地确定批量消耗令牌的时间。同时，分批丢弃队列中存储的请求，避免再次给服务器造成压力。

进一步参考图5，作为对上述各图所示方法的实现，本申请提供了一种用于限制流量的装置的一个实施例，该装置实施例与图2所示的方法实施例相对应，该装置具体可以应用于各种电子设备中。

如图5所示，本实施例的用于限制流量的装置500可以包括：接收单元501、获取单元502、确定单元503和放行单元504。其中，接收单元501，被配置成对于线程池中的线程，接收该线程发送的请求；获取单元502，被配置成获取该线程的状态数据，其中，状态数据包括在流控周期内的初始化时间戳、已放行且未消耗令牌的请求数和全局已消耗令牌数；确定单元503，被配置成基于该线程的状态数据，确定是否通过批量消耗令牌方式放行；放行单元504，被配置成响应于确定通过批量消耗令牌方式放行，放行该线程发送的请求至云端进行处理。

在本实施例中，用于限制流量的装置500中：接收单元501、获取单元502、确定单元503和放行单元504的具体处理及其所带来的技术效果可分别参考图2对应实施例中的步骤201、步骤202、步骤203和步骤204的相关说明，在此不再赘述。

在本实施例的一些可选的实现方式中，用于限制流量的装置500还包括：添加单元(图中未示出)，被配置成响应于确定不通过批量消耗令牌方式放行，添加该线程发送的请求至队列进行等待。

在本实施例的一些可选的实现方式中，确定单元503包括：第一计算子单元(图中未示出)，被配置成计算当前系统时间戳与该线程的状态数据中的初始化时间戳的差值，作为第一差值；第一确定子单元(图中未示出)，被配置成确定第一差值是否大于流控周期；第二确定子单元(图中未示出)，被配置成响应于确定不大于流控周期，确定该线程的状态数据中的全局已消耗令牌数是否小于在流控周期内的全局令牌数；第三确定子单元(图中未示出)，被配置成响应于确定小于全局令牌数，确定通过批量消耗令牌方式放行。

在本实施例的一些可选的实现方式中，确定单元503还包括：初始化子单元(图中未示出)，被配置成响应于确定大于流控周期，初始化该线程的状态数据。

在本实施例的一些可选的实现方式中，确定单元504还包括：第四确定子单元(图中未示出)，被配置成响应于确定不小于全局令牌数，确定不通过批量消耗令牌方式放行。

在本实施例的一些可选的实现方式中，第三确定子单元包括：更新模块(图中未示出)，被配置成基于该线程发送的请求的数量，更新该线程的状态数据中的已放行且未消耗令牌的请求数；第一确定模块(图中未示出)，被配置成确定该线程的状态数据中的已放行且未消耗令牌的请求数是否小于批量消耗令牌数；第二确定模块(图中未示出)，被配置成响应于确定小于批量消耗令牌数，确定放行该线程发送的请求。

在本实施例的一些可选的实现方式中，第三确定子单元还包括：第三确定模块(图中未示出)，被配置成响应于确定等于批量消耗令牌数，确定放行该线程发送的请求，批量消耗令牌，初始化该线程的状态数据中的已放行且未消耗令牌的请求数，以及基于批量消耗令牌数，更新线程池中的线程的状态数据中的全局已消耗令牌数。

在本实施例的一些可选的实现方式中，添加单元包括：读取子单元(图中未示出)，被配置成周期性启动定时器定时读取队列中存储的请求；第二计算子单元(图中未示出)，被配置成计算队列中存储的请求被添加至队列的时间戳与当前系统时间戳的差值，作为第二差值；第五确定子单元(图中未示出)，被配置成确定第二差值是否小于过期时间；丢弃子单元(图中未示出)，被配置成响应于确定不小于过期时间，从队列中丢弃不大于丢弃上限的数目个请求。

在本实施例的一些可选的实现方式中，添加单元还包括：结束子单元(图中未示出)，被配置成响应于确定小于过期时间，结束当前定时任务或为队列中存储的请求与线程池中的其他线程争抢令牌。

下面参考图6，其示出了适于用来实现本申请实施例的电子设备(例如图1所示的服务器104)的计算机系统600的结构示意图。图6示出的电子设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图6所示，计算机系统600包括中央处理单元(CPU)601，其可以根据存储在只读存储器(ROM)602中的程序或者从存储部分608加载到随机访问存储器(RAM)603中的程序而执行各种适当的动作和处理。在RAM 603中，还存储有系统600操作所需的各种程序和数据。CPU 601、ROM 602以及RAM 603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线604。

以下部件连接至I/O接口605：包括键盘、鼠标等的输入部分606；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分607；包括硬盘等的存储部分608；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分609。通信部分609经由诸如因特网的网络执行通信处理。驱动器610也根据需要连接至I/O接口605。可拆卸介质611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器610上，以便于从其上读出的计算机程序根据需要被安装入存储部分608。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分609从网络上被下载和安装，和/或从可拆卸介质611被安装。在该计算机程序被中央处理单元(CPU)601执行时，执行本申请的方法中限定的上述功能。

需要说明的是，本申请所述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言或其组合来编写用于执行本申请的操作的计算机程序代码，所述程序设计语言包括面向目标的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如”C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或电子设备上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中，例如，可以描述为：一种处理器包括接收单元、获取单元、确定单元和放行单元。其中，这些单元的名称在种情况下并不构成对该单元本身的限定，例如，接收单元还可以被描述为“对于线程池中的线程，接收该线程发送的请求的单元”。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该电子设备执行时，使得该电子设备：对于线程池中的线程，接收该线程发送的请求；获取该线程的状态数据，其中，状态数据包括在流控周期内的初始化时间戳、已放行且未消耗令牌的请求数和全局已消耗令牌数；基于该线程的状态数据，确定是否通过批量消耗令牌方式放行；响应于确定通过批量消耗令牌方式放行，放行该线程发送的请求至云端进行处理。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (11)

1.一种用于限制流量的方法，包括：

对于线程池中的线程，接收该线程发送的请求；

获取该线程的状态数据，其中，状态数据包括在流控周期内的初始化时间戳、已放行且未消耗令牌的请求数和全局已消耗令牌数；

基于该线程的状态数据，确定是否通过批量消耗令牌方式放行；

响应于确定通过批量消耗令牌方式放行，放行该线程发送的请求至云端进行处理；

响应于确定不通过批量消耗令牌方式放行，添加该线程发送的请求至队列进行等待，待所述队列中存储的请求过期后丢弃；

其中，所述基于该线程的状态数据，确定是否通过批量消耗令牌方式放行，包括：

响应于确定当前系统时间戳与该线程的状态数据中的初始化时间戳的差值不大于所述流控周期，且该线程的状态数据中的全局已消耗令牌数小于所述流控周期内的全局令牌数，确定通过批量消耗令牌方式放行；

其中，所述确定通过批量消耗令牌方式放行，包括：

基于该线程发送的请求的数量，更新该线程的状态数据中的已放行且未消耗令牌的请求数；

响应于确定该线程的状态数据中的已放行且未消耗令牌的请求数小于批量消耗令牌数，确定放行该线程发送的请求。

2.根据权利要求1所述的方法，其中，所述基于该线程的状态数据，确定是否通过批量消耗令牌方式放行，包括：

计算当前系统时间戳与该线程的状态数据中的初始化时间戳的差值，作为第一差值；

确定所述第一差值是否大于所述流控周期；

响应于确定不大于所述流控周期，确定该线程的状态数据中的全局已消耗令牌数是否小于在所述流控周期内的全局令牌数；

响应于确定小于所述全局令牌数，确定通过批量消耗令牌方式放行。

3.根据权利要求2所述的方法，其中，所述基于该线程的状态数据，确定是否通过批量消耗令牌方式放行，还包括：

响应于确定大于所述流控周期，初始化该线程的状态数据。

4.根据权利要求2所述的方法，其中，所述基于该线程的状态数据，确定是否通过批量消耗令牌方式放行，还包括：

响应于确定不小于所述全局令牌数，确定不通过批量消耗令牌方式放行。

5.根据权利要求2所述的方法，其中，所述确定通过批量消耗令牌方式放行，包括：

基于该线程发送的请求的数量，更新该线程的状态数据中的已放行且未消耗令牌的请求数；

确定该线程的状态数据中的已放行且未消耗令牌的请求数是否小于批量消耗令牌数；

响应于确定小于所述批量消耗令牌数，确定放行该线程发送的请求。

6.根据权利要求5所述的方法，其中，所述确定通过批量消耗令牌方式放行，还包括：

响应于确定等于所述批量消耗令牌数，确定放行该线程发送的请求，批量消耗令牌，初始化该线程的状态数据中的已放行且未消耗令牌的请求数，以及基于所述批量消耗令牌数，更新所述线程池中的线程的状态数据中的全局已消耗令牌数。

7.根据权利要求6所述的方法，其中，所述添加该线程发送的请求至队列进行等待，包括：

周期性启动定时器定时读取所述队列中存储的请求；

计算所述队列中存储的请求被添加至所述队列的时间戳与当前系统时间戳的差值，作为第二差值；

确定所述第二差值是否小于过期时间；

响应于确定不小于所述过期时间，从所述队列中丢弃不大于丢弃上限的数目个请求。

8.根据权利要求7所述的方法，其中，所述添加该线程发送的请求至队列进行等待，还包括：

响应于确定小于所述过期时间，结束当前定时任务或为所述队列中存储的请求与所述线程池中的其他线程争抢令牌。

9.一种用于限制流量的装置，包括：

接收单元，被配置成对于线程池中的线程，接收该线程发送的请求；

获取单元，被配置成获取该线程的状态数据，其中，状态数据包括在流控周期内的初始化时间戳、已放行且未消耗令牌的请求数和全局已消耗令牌数；

确定单元，被配置成基于该线程的状态数据，确定是否通过批量消耗令牌方式放行；

放行单元，被配置成响应于确定通过批量消耗令牌方式放行，放行该线程发送的请求至云端进行处理；

添加单元，被配置成响应于确定不通过批量消耗令牌方式放行，添加该线程发送的请求至队列进行等待，待所述队列中存储的请求过期后丢弃；

其中，所述确定单元包括：

确定子单元，被配置成响应于确定当前系统时间戳与该线程的状态数据中的初始化时间戳的差值不大于所述流控周期，且该线程的状态数据中的全局已消耗令牌数小于所述流控周期内的全局令牌数，确定通过批量消耗令牌方式放行；

其中，所述确定子单元进一步被配置成：

基于该线程发送的请求的数量，更新该线程的状态数据中的已放行且未消耗令牌的请求数；

响应于确定该线程的状态数据中的已放行且未消耗令牌的请求数小于批量消耗令牌数，确定放行该线程发送的请求。

10.一种电子设备，包括：

一个或多个处理器；

存储装置，其上存储有一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-8中任一所述的方法。

11.一种计算机可读介质，其上存储有计算机程序，其中，所述计算机程序被处理器执行时实现如权利要求1-8中任一所述的方法。

Images