流量控制方法及装置

本申请涉及通信技术领域，尤其涉及一种流量控制方法及装置。

在分布式存储系统中，提供较精准的流量控制，有利于避免某个租户占用过多的存储系统资源，维持存储系统的性能。

目前，业界存在一种流量控制方法，每一节点采集本地流控数据，例如采集本地当前流量，并将采集的本地流量数据广播至除自身之外的其他全部节点，进而每一节点根据全局流控目标和从其他节点获取的流控数据，计算自身的流控目标，实现本地流量控制。

然而，随着存储系统规模的不断扩大，同一租户需访问的存储系统资源很可能分布在不同的节点上，因此需要在这些不同节点之间做流量整形。由于节点之间需传输流量数据等，且需保证各节点间的流量数据等严格同步，导致节点之间的通信开销大，影响存储系统的整体性能。

本申请提供一种流量控制方法及装置，以减小存储系统中节点之间的通信开销。

为达到上述目的，本申请采用如下技术方案：

第一方面，本申请提供一种流量控制方法，该方法包括：

客户端接收终端发送的业务请求，确定待处理业务所需的令牌的数目大于本地可用令牌的数目且待处理业务所需令牌的数目不超过本地可透支令牌上限时，客户端处理待处理业务，当预设条件触发时，向服务端申请多个令牌。其中，业务请求用于指示待处理业务所需的令牌的数目，待处理业务所需令牌的数目与待处理业务的流量相关联，令牌用于控制待处理业务的流量大小，申请的多个令牌用于补充被待处理业务透支的令牌。

与现有技术中节点之间需频繁通信，导致通信链路开销较大相比，本发明实施例的流量控制方法，当存在待处理业务时，若客户端确定待处理业务所需的令牌数目大于本地可用令牌数目且不超过本地可透支令牌上限，则客户端处理待处理业务。并且，当预设条件触发时，客户端向服务端申请多个令牌。其中，客户端可将待处理业务的流量限制在本地可透支令牌能够支持的流量之内，并且，客户端中与流量限制相关的令牌来源于服务端。也就是说，该客户端仅需与服务端进行令牌交互，无需掌握其他客户端的流量数据，降低了客户端间的通信开销，从而降低流量控制系统的整体性能开销。

在一种可能的设计中，上述预设条件可以为预设周期，也就是说，客户端可每隔预设周期向服务端申请一次令牌。

或者，上述预设条件可以为客户端的本地可用令牌不足以支持当前的业务请求。这样，当客户端本地可用令牌较少时，不必等待下一预设周期到来，可直接向服务端申请令牌，以补充所欠缺的令牌。

在一种可能的设计中，在客户端接收终端发送的业务请求之后，还可以执行如下步骤：

若确定待处理业务所需的令牌的数目小于或等于本地可用令牌的数目，则客户端处理待处理业务。

在一种可能的设计中，在客户端接收终端发送的业务请求之后，还可以执行如下步骤：

确定待处理业务所需的令牌的数目大于本地可用令牌的数目且待处理业务所需令牌的数目超过本地可透支令牌上限时，客户端丢弃待处理业务或者缓存待处理业务。

在一种可能的设计中，客户端向服务端发送查询请求以获知服务端中存在可分配令牌且可分配令牌的数目大于或等于其他待处理业务所需令牌的数目与本地可用令牌的数目的差值，则客户端向服务端申请令牌。也就是说，在客户端缓存待处理业务后，客户端可向服务端申请令牌，并处理待处理业务，恢复终端业务。

在一种可能的设计中，客户端处理待处理业务，具体可以实现为：客户端向终端发送指示信息以指示终端访问客户端关联的资源。

在一种可能的设计中，客户端处理待处理业务，具体还可以实现为：客户端指示终端访问客户端关联的资源。比如，在用户使用手机浏览器浏览网页的场景中，客户端处理待处理业务指的是客户端向终端反馈网页内容，这样，用户能够浏览所需的网页内容。

第二方面，本申请提供一种流量控制装置，该装置包括接收模块、处理模块、申请模块、缓存以及发送模块。

其中，接收模块，用于接收终端发送的业务请求，业务请求用于指示待处理业务所需的令牌的数目，待处理业务所需令牌的数目与待处理业务的流量相关联。处理模块，用于确定待处理业务所需的令牌的数目大于本地可用令牌的数目且待处理业务所需令牌的数目不超过本地可透支令牌上限时，处理待处理业务，令牌用于控制待处理业务的流量大小。申请模块，用于当预设条件触发时，向服务端申请多个令牌，申请的多个令牌用于补充被待处理业务透支的令牌。

在一种可能的设计中，处理模块用于处理待处理业务，包括：用于向终端发送指示信息以指示终端访问装置关联的资源。

在一种可能的设计中，缓存中保存有其他待处理业务。

发送模块，用于向服务端发送查询请求以获知服务端中存在可分配令牌且可分配令牌的数目大于或等于其他待处理业务所需令牌的数目与本地可用令牌的数目的差值。申请模块，还用于根据发送模块的查询结果向服务端申请令牌。

在第一方面或第二方面的一种可能的设计中，客户端关联的资源包括对象桶、文件块、文件系统、数据库。

在第一方面或第二方面的一种可能的设计中，客户端向服务端申请的多个令牌的数目大于或等于亏欠差值，亏欠差值为待处理业务所需令牌的数目与本地可用令牌的数目的差值。

这样，客户端更新本地可用令牌后，本地可用令牌中的部分令牌可用于补足前次业务请求所透支或者本次业务请求所需透支的令牌，本地可用令牌中的另一部分令牌可用于支持其他终端的业务请求或者用于支持同一终端的下次业务请求。

第三方面，本申请提供一种流量控制装置，该流量控制装置具有实现上述方面任一项的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

第四方面，提供一种流量控制装置，包括：处理器和存储器；该存储器用于存储计算机执行指令，当该流量控制装置运行时，该处理器执行该存储器存储的该计算机执行指令，以使该流量控制装置执行如上述方面中任一项的流量控制方法。

第五方面，提供一种流量控制装置，包括：处理器；处理器用于与存储器耦合，并读取存储器中的指令之后，根据指令执行如上述方面中任一项的流量控制方法。

第六方面，提供一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机可以执行上述方面中任一项的流量控制方法。

第七方面，提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机可以执行上述方面中任一项的流量控制方法。

第八方面，提供一种电路系统，该电路系统包括处理电路，处理电路被配置为执行上述方面任意一项所述的流量控制方法。

其中，第二方面至八方面中任一种设计方式所带来的技术效果可参见方面中不同设计方式所带来的技术效果，此处不再赘述。

图1为本发明实施例提供的系统架构图；

图2为本发明实施例提供的流量控制方法的交互图；

图3为本发明实施例提供的流量控制装置的结构示意图。

本申请的说明书以及附图中的术语“第一”和“第二”等是用于区别不同的对象，或者用于区别对同一对象的不同处理，而不是用于描述对象的特定顺序。此外，本申请的描述中所提到的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括其他没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。需要说明的是，本发明实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本发明实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

本发明实施例提供的流量控制方法应用于流量控制系统中，如图1所示，为本发明实施例的流量控制系统的架构图。如图1，该流量控制系统包括客户端、服务端以及终端。

其中，终端(图中仅示例性的示出一个)可与客户端进行通信，当终端有业务请求时，向业务请求所关联的至少一个客户端申请令牌，以确保业务正常进行。在如图1所示的系统中，将整个系统集划分为数个子集，每一子集包含预设数目的客户端，并将终端的一个业务请求的业务流量关联到预设数目的客户端中，使得每一客户端均分担该业务流量的至少部分流量，实现客户端之间的流量均衡。举例来说，如图1所示系统集中有3个客户端，将3个客户端组成的集划分为两个子集，由其中两个客户端组成一个子集，该子集的两个客户端为终端提供服务。

可选的，本发明实施例所涉及到的终端包括各种具有通信功能的手持设备、可穿戴设备、计算设备或连接到无线调制解调器的其它设备；还可以包括蜂窝电话(cellularphone)、智能电话(smart phone)、无线数据卡、个人数字助理(personal digitalassistant，PDA)电脑、平板型电脑、手持设备(handheld)、膝上型电脑(laptop computer)、机器类型通信(machine type communication,MTC)终端、用户设备(user equipment，UE)，移动台(mobile station，MS)，终端设备(terminal device)等。

客户端用于从服务端获取令牌，并在终端有业务需求时，为终端下发一定数目的令牌，以满足终端的业务需求。其中，客户端在每次为终端下发令牌后更新本地剩余的令牌数目。也就是说，客户端本次为终端下发令牌后，本地剩余的令牌数目为下发令牌前本地剩余令牌数目与下发令牌数目的差值。

可选的，本发明实施例中的客户端可以为服务器、电脑等设备，或者与服务器、电脑具备相似功能的设备。

服务端用于管理至少一个客户端，并向所管理的客户端下发令牌。其中，服务端中设置有令牌桶，并每隔预设时间产生预设数目的令牌，以供客户端申请使用。比如，服务端可以每隔0.1ms产生一个令牌，或者，服务端每隔0.3ms产生3个令牌。服务端间隔多长时间产生令牌以及每次产生令牌的数目可根据实际业务需求设定，本发明实施例对此不进行限制。

其中，图1中给出3个服务端，其中，实线框的服务端为主服务端，虚线框所示的两个服务端为备份服务端。

可选的，本发明实施例中的服务端可以为独立设备，例如为服务器，电脑，或者，还可作为功能模块集成在上述客户端中。

需要说明的是，可按照资源类型为不同资源设置不同数目的令牌，资源可为对象桶、文件系统、数据库等中的资源。如图1所示，示例性的示出主服务端将对象桶中资源的令牌分配给客户端的过程。

以下结合附图对本发明实施例的流量控制方法进行描述。其中，如上文描述，本发明实施例将一个待处理业务的流量关联到预设数目的客户端上，每个客户端分担待处理业务的至少部分流量。以下实施例主要从预设数目的多个客户端中的一个客户端的角度进行描述，在此统一说明，下文不再赘述。

如图2所示，本发明实施例的流量控制方法包括如下步骤：

S201、终端向客户端发送业务请求。

相应的，客户端接收终端发送的业务请求。

其中，所述业务请求用于请求处理待处理业务且指示待处理业务所需的令牌的数目，所述待处理业务所需令牌的数目与所述待处理业务的流量相关联。具体的，待处理业务的流量越大，待处理业务所需的令牌越多，待处理业务的流量越小，待处理业务所需的令牌越少。比如，用户在浏览网页时触发终端向客户端发送业务请求，业务请求指示的待处理业务为大小为100M的数据包，假定每10M数据包所需令牌数目为1，则该100M数据包所需的令牌数目为10。

S202、客户端判断待处理业务所需令牌的数目是否大于本地可用令牌数目，若待处理业务所需令牌的数目小于或等于本地可用令牌数目，则执行S204，若待处理业务所需令牌的数目大于本地可用令牌数目，则执行S203。

其中，客户端本地可用令牌为客户端当前本地剩余的令牌。

通常，令牌被用于控制待处理业务的流量大小，客户端本地可用令牌数目越多，意味着客户端能够接收并处理越多流量，客户端本地可用令牌数目越少，则接收、处理的流量越少。

S203、客户端判断待处理业务所需令牌的数目是否超过本地可透支令牌上限，若待处理业务所需令牌的数目超过(即大于)本地可透支令牌上限，则执行S206，若待处理业务所需令牌的数目不超过(即小于或等于)本地可透支令牌上限，则执行S204。

S204、所述客户端处理所述待处理业务。

作为可能的实现方式，客户端处理所述待处理业务指的是客户端向终端发送客户端所关联的资源。其中，客户端向终端发送资源的方式如下：

方式1：客户端向所述终端发送指示信息以指示所述终端访问所述客户端关联的资源。

在如下两种场景中，客户端按照方式1处理待处理业务：

场景1：客户端本地剩余的令牌数目满足当前业务请求，即待处理业务所需的令牌数目小于或等于客户端本地剩余的令牌数目。

在场景1中，客户端按照方式1处理待处理业务，即客户端向终端发送指示信息，以指示待处理业务申请成功，并向终端反馈需访问且客户端关联的资源。

其中，客户端关联的资源包括对象桶(bucket)、文件块(block)、文件系统(FileSystem，FS)、数据库(Database)。对象桶为用于存储对象的一种存储结构，客户端通过应用程序编程接口(Application Programming Interface，API)来管理对象桶，包括对象桶的读操作、写操作等。文件块可以为分布式存储系统中文件的分块，例如，文件块可以为Hadoop分布式文件系统(Hadoop Distributed File System，HDFS)中的分块。文件系统可以为用于管理和存储数据的软件。数据库可以为按照数据结构来组织、存储和管理数据的仓库。例如，常见数据库包括MySQL、oracle等。数据库中包含至少一个数据表，每一数据表中包含至少一个数据。

当然，随着技术的演进，上述客户端关联的资源还可以为文件系统、对象桶等的演进版本或使用演进技术产生的资源，也可以为其他能够提供访问服务的资源，本发明实施例对此不进行限制。

需要说明的是，上述对象桶、文件块、文件系统、数据库等可位于客户端中，也可以位于其他独立的存储设备上，例如，可以位于HDFS设备上，本发明实施例对此不进行限制。

作为一个场景1的示例，当待处理业务所需令牌数目小于或等于客户端本地剩余的令牌数目时，客户端向终端发送用于指示待处理业务申请成功的指示信息，并向终端反馈数据库1中数据表1的数据。

场景2:客户端本地剩余的令牌数目不足以支持当前业务请求，并且待处理业务所需令牌数目不超过客户端本地可透支令牌上限。

在场景2中，客户端按照上述方式1处理待处理业务。比如，在一个时间段内需要100个令牌来支持终端进行网页浏览业务，客户端中有60个可用令牌，不足以支持当前的网页浏览业务，而客户端本地可透支令牌上限(110)大于当前待处理业务所需的令牌数目(100)，客户端向终端发送用于指示网页浏览业务申请成功的指示信息，并向终端发送网页内容，从而用户通过终端浏览器可浏览网页内容。

方式2：客户端直接指示所述终端访问所述客户端关联的资源。

方式2与方式1的不同之处在于，方式2中，客户端不再向终端发送指示信息，而是直接向终端发送所关联的资源，可以节约部分链路资源，减缓链路中数据包拥塞的概率。

同样的，在场景1和场景2中，客户端均可按照方式2处理待处理业务。在场景1和场景2中按照方式2处理待处理业务的具体流程可参见在场景1、场景2中按照方式1处理待处理业务的流程，这里不再赘述。

S205、当预设条件触发时，客户端向服务端申请多个令牌。

其中，预设条件可以包括如下两种：

1、预设条件为预设周期，即客户端每隔预设周期向服务端申请令牌。预设周期可根据实际应用情况设定，本发明实施例对此不进行限制。比如，预设周期可以为10ms，客户端每隔10ms向服务端申请一次令牌。

由于客户端周期性的向服务端申请令牌，可以看出，S205以在S201至S204或S206之前、之后、或者同时进行，本发明实施例不对S205执行时机进行限制。

可选的，在客户端本地剩余令牌不足以支持当前业务请求且当前待处理业务所需令牌数目小于或等于客户端本地可透支令牌上限的情况下，先执行S205，即客户端向服务端申请令牌，并判断服务端中是否存在可分配令牌，若服务端中存在可分配令牌，则客户端从服务端中获取一定数目的令牌，并执行S204，处理待处理业务。

若服务端中不存在可分配令牌，则客户端丢弃或缓存待处理业务。或者，若服务端中不存在可分配令牌，则客户端启动定时器，若时器超之前，服务端中新产生可分配令牌，则客户端从服务端获取令牌并处理待处理业务，若直至定时器超时，服务端中始终不存在可分配令牌，则客户端丢弃或缓存待处理业务。

也就是说，在客户端的本地可用令牌不足以支持当前的业务请求的情况下，只有当客户端确定服务端中当前或者在定时器超时时段内存在足够的令牌时，才处理待处理业务。其中，定时器超时时间可根据业务需求设定，对时延较为敏感的业务，定时器超时时间可设置一个较小的数值，对于时延要求不高的业务，定时器超时时间可设置一个较大的数值。

可选的，在客户端本地剩余令牌不足以支持当前业务请求且当前待处理业务所需令牌数目小于或等于客户端本地可透支令牌上限的情况下，先执行S204，再执行S205，也就是客户端先处理待处理业务，再向服务端申请令牌以补足透支的令牌，可降低业务时延。

可以理解的是，客户端每次向服务端申请的令牌数目可根据实际应用场景确定，并且客户端每次向服务端申请令牌后，更新本地可用令牌的数目，更新后的令牌用于支持终端的业务请求。

2、预设条件为客户端本地可用令牌数目不足以支持当前的业务请求。

可选的，客户端向服务端申请的多个令牌的数目大于或等于亏欠差值，亏欠差值为所述待处理业务所需令牌的数目与所述本地可用令牌的数目的差值。这样一来，客户端所申请令牌不仅可以补充因之前业务请求或本次业务请求透支的令牌，多余的令牌还可用于支持该终端的下次业务请求或者支持其他终端的业务请求。

比如，在一个时间段内需要100个令牌来支持终端进行网页浏览业务，客户端中有60个可用令牌，不足以支持当前的网页浏览业务，客户端本地可透支令牌上限(110)大于网页浏览业务所需的令牌数目，此时触发客户端向服务端申请N个令牌，这N个令牌中的40个令牌用于补足客户端所透支的40(即所需令牌与本地可用令牌的差值)个令牌，N个令牌中的N-40个令牌可以用于响应并支持其他终端的业务请求。

如此，在客户端本地可用令牌数目较少时，不必等待下一个预设周期的到来，而是可以直接向服务端申请令牌，降低申请令牌的时延。

可选的，除了上述预先设定客户端每次向服务端申请的令牌数目，还可以根据当前业务请求确定客户端申请的令牌数目。具体的，客户端申请的令牌数目与所述待处理业务所需的令牌、所述服务端中的可分配令牌、用于分担所述待处理业务的客户端的预设数目、客户端的历史申请令牌数目以及用于分担所述待处理业务的多个客户端总的流量上限相关联。可选的，客户端申请的令牌数目可用如下公式表示：

公式(1)：

allocToken＝r*TokenAdv+(1-r)*TokenDem

其中，公式(1)中的TokenAdv、TokenDem可分别用公式(2)和公式(3)表示：

公式(2)：

TokenAdv＝Min[2*requireToken,Max(requireToken,ceiling(remainToken/NodeNum))]

公式(3)：

TokenDem＝(QosClientDemand/MaxLimit)*remainToken

allocToken为一个客户端向服务端申请的令牌数目，也可视为服务端向一个客户端分配的令牌数目，TokenAdv为按照预设算法得到的服务端向该客户端分配的令牌数目，TokenDem为按照业务需求得到的服务端向该客户端分配的令牌数目，r为大于或等于0的权重因子，requireToken为一个待处理业务所需的令牌数目，其为正整数，Min为求取最小值的函数，Max为求取最大值的函数，ceiling为向上取整函数，remainToken为服务端的令牌桶中剩余的令牌数目，其为大于或等于0的整数，NodeNum为用于分担该待处理业务流量的客户端数目，其为大于0的整数，QosClientDemand为根据经验值或者统计信息得到的该客户端的历史申请令牌数目，其为正整数，MaxLimit为用于分担该待处理业务流量的多个客户端总的流量上限，其为正数。流量上限指的是期待客户端所接收流量的上限。比如，由于该客户端的能力有限，设置该客户端的流量上限为100M，但是，由于通信网络通常需承载高流量，并且可能存在突发流量的情况。因此，虽然期待的客户端流量上限为100M，但是，为了提升终端业务的接入成功率，在业务流量稍大于客户端流量上限时，客户端接收并处理的业务流量可超过100M，也就是说客户端可为终端透支一定数目的令牌。

S206、客户端丢弃待处理业务，或者客户端缓存待处理业务。

可以理解的是，当待处理业务所需令牌数目大于客户端本地可用令牌数目，说明客户端本地剩余令牌不足以支持待处理业务，此时，若客户端经判断确定待处理业务所需令牌数目大于客户端本地可透支令牌上限，则为了维持系统的性能，客户端限制待处理业务的流量。其中，客户端限制待处理业务流量的方式包括如下两种：

方式1：丢弃待处理业务。

可选的，客户端向终端发送第一消息，以指示终端待处理业务申请失败。并且，客户端丢弃待处理业务。这里，客户端可以先向终端发送第一消息，再丢弃待处理业务，使得用户尽快得知待处理业务申请失败。客户端还可以先丢弃待处理业务，再向终端发送第一消息。本发明实施例发送第一消息和丢弃待处理业务这两个步骤的执行顺序不做限制。

方式2：客户端缓存待处理业务。

可选的，客户端向终端发送第二消息，以指示终端待处理业务的状态为待处理状态。并且，客户端缓存待处理业务。类似的，本发明实施例对发送第二消息和缓存待处理业务这两个步骤的执行顺序不做限制。

具体的，客户端包含缓存结构，例如缓存队列和缓存栈等。客户端可在待处理业务流量较高时将待处理业务入栈、入队列。

后续，随着客户端接收的待处理业务的增加，客户端的缓存结构中可能会保存有多个待处理业务。在本申请的一些实施例中，客户端向所述服务端发送查询请求，以查询服务端中的令牌数目。当获知所述服务端中存在可分配令牌且所述可分配令牌的数目大于或等于所述所缓存待处理业务所需令牌的数目与本地可用令牌的数目的差值，所述客户端向所述服务端申请令牌，并处理所缓存的待处理业务。

可选的，客户端为多个待处理业务设置优先级，并优先处理高优先级的待处理业务。比如，客户端缓存有3个待处理业务，按照优先级由高到低依次为待处理业务2、待处理业务1、待处理业务3。客户端周期性的向服务端申请令牌，当某次申请令牌后客户端中的令牌数据足够支持待处理业务2时，客户端处理待处理业务2。之后，当某次申请令牌后客户端中的令牌足够支持待处理业务1时，客户端处理待处理业务1。类似的，客户端可处理待处理业务3。

或者，客户端也可优先处理所需令牌数目较少的待处理业务。举例来说，待处理业务1所需令牌数目为20、待处理业务2所需令牌数目为50、待处理业务1所需令牌数目为200。在某次向服务端申请令牌后客户端中更新的令牌数目为100，客户端优先处理待处理业务1，之后，若客户端中仍存在剩余的足够令牌，客户端处理待处理业务2，类似的，客户端处理待处理业务3。

当然，客户端也可以根据待处理业务的优先级和所需令牌数目两个指标确定各个待处理业务的处理顺序。另外，客户端还可以根据其他指标，或者根据实际场景确定待处理业务的处理顺序，本发明实施例对此不进行限制。

与现有技术中节点之间需频繁通信，导致通信链路开销较大相比，本发明实施例的流量控制方法，当存在待处理业务时，若客户端确定待处理业务所需的令牌数目大于本地可用令牌数目且不超过本地可透支令牌上限，则客户端处理待处理业务。并且，当预设条件触发时，客户端向服务端申请多个令牌。其中，客户端可将待处理业务的流量限制在本地可透支令牌能够支持的流量之内，并且，客户端中与流量限制相关的令牌来源于服务端。也就是说，该客户端仅需与服务端进行令牌交互，无需掌握其他客户端的流量数据，降低了客户端间的通信链路开销，从而降低流量控制系统的整体性能开销。

上述主要从流量控制装置工作过程的角度对本发明实施例提供的方案进行了介绍。可以理解的是，流量控制装置为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本发明实施例可以根据上述方法示例对流量控制装置进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本发明实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

在采用对应各个功能划分各个功能模块的情况下，图3示出了上述实施例中所涉及的流量控制装置的一种可能的结构示意图。流量控制装置300可以包括：接收模块301、处理模块302、申请模块303以及发送模块304。接收模块301用于支持流量控制装置300执行图2中的过程S201。作为另一种实现方式，当流量控制装置中设置有收发器时，可由流量控制装置中的收发器来执行S201。处理模块302用于支持流量控制装置300执行图2中的过程S202、S203、S204、S206。作为另一种实现方式，当流量控制装置中设置有处理器时，可由流量控制装置中的处理器执行图2中的过程S202、S203、S204、S206。申请模块303用于支持流量控制装置300执行图2中的过程S205。作为另一种实现方式，当流量控制装置中设置有处理器时，可由流量控制装置中的处理器执行图2中的过程S205。发送模块304用于支持流量控制装置向服务端发送查询请求，以获知服务端中的令牌数目。作为另一种实现方式，当流量控制装置中设置有收发器时，可由流量控制装置中的收发器向服务端发送查询请求。其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。

本发明实施例尽管在此结合各实施例对本申请进行了描述，然而，在实施所要求保护的本申请过程中，本领域技术人员通过查看所述附图、公开内容、以及所附权利要求书，可理解并实现所述公开实施例的其他变化。在权利要求中，“包括”(comprising)一词不排除其他组成部分或步骤，“一”或“一个”不排除多个的情况。单个处理器或其他单元可以实现权利要求中列举的若干项功能。相互不同的从属权利要求中记载了某些措施，但这并不表示这些措施不能组合起来产生良好的效果。

尽管结合具体特征及其实施例对本申请进行了描述，显而易见的，在不脱离本申请的精神和范围的情况下，可对其进行各种修改和组合。相应地，本说明书和附图仅仅是所附权利要求所界定的本申请的示例性说明，且视为已覆盖本申请范围内的任意和所有修改、变化、组合或等同物。显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。