CN115766582A - 流量控制方法、装置和系统、介质和计算机设备 - Google Patents

Abstract

一种流量控制方法、装置和系统、介质和计算机设备，所述方法包括：获取各个客户端在当前周期的流量需求，基于同一存储业务下的各个客户端在当前周期的流量需求确定所述存储业务在当前周期的流量需求；基于所述多个存储业务在当前周期的流量需求确定各个存储业务在下一周期的流量配额；基于同一存储业务下各个客户端在当前周期的流量需求以及对应存储业务在下一周期的流量配额确定对应存储业务下各个客户端在下一周期的流量配额，以使各个客户端基于本客户端在下一周期的流量配额对本客户端在下一周期的各个IO请求进行流量控制；经流量控制后发送的各个IO请求用于发送到服务器，以使所述服务器响应于接收到的IO请求访问所述存储系统。

Description

流量控制方法、装置和系统、介质和计算机设备

技术领域

本公开涉及云存储技术领域，尤其涉及流量控制方法、装置和系统、介质和计算机设备。

背景技术

多个存储业务混部能够有效提高对存储系统的资源利用率。在存储业务混部场景下，存储系统的资源被多个存储业务共享，当某个存储业务的流量需求比较大时，会占用其他存储业务的流量，导致“扰邻”问题。

发明内容

第一方面，本公开实施例提供一种流量控制方法，应用于流量控制节点，用于对多个存储业务进行流量控制，所述多个存储业务共享存储系统的流量资源，同一存储业务下的各个客户端共享该存储业务的流量资源；所述方法包括：获取各个客户端在当前周期的流量需求，基于同一存储业务下的各个客户端在当前周期的流量需求确定所述存储业务在当前周期的流量需求；基于所述多个存储业务在当前周期的流量需求确定各个存储业务在下一周期的流量配额；基于同一存储业务下各个客户端在当前周期的流量需求以及对应存储业务在下一周期的流量配额确定对应存储业务下各个客户端在下一周期的流量配额，以使各个客户端基于本客户端在下一周期的流量配额对本客户端在下一周期的各个IO请求进行流量控制；经流量控制后发送的各个IO请求用于发送到服务器，以使所述服务器响应于接收到的IO请求访问所述存储系统。

在一些实施例中，所述基于所述多个存储业务在当前周期的流量需求确定各个存储业务在下一周期的流量配额，包括：基于所述多个存储业务的权重确定各个存储业务在下一周期的基础流量配额；基于所述多个存储业务在当前周期的流量需求确定各个存储业务在下一周期的补充流量配额；基于每个存储业务在下一周期的基础流量配额和补充流量配额确定所述存储业务在下一周期的流量配额。

在一些实施例中，所述方法还包括：将各个客户端在下一周期的流量配额下发到对应的客户端，以使对应的客户端将本客户端在下一周期的流量配存储在本地；其中，客户端针对本客户端在下一周期的每个IO请求，基于缓存的流量配额以及本客户端在下一周期已消耗的流量配额，对该IO请求进行流量控制。

在一些实施例中，所述客户端用于：若下一周期接收到的IO请求的流量需求与本客户端在下一周期已消耗的流量配额之和大于本客户端在下一周期的流量配额，将下一周期接收到的IO请求加入等待队列；若本客户端的流量配额满足所述等待队列中的IO请求的出队条件，将所述等待队列中的IO请求移出所述等待队列并发送到所述存储系统。

在一些实施例中，所述客户端包括部署在前台IO线程上的流量门禁模块和部署在后台线程上的流量管理模块；所述流量门禁模块用于对本客户端在当前周期的IO请求的流量需求进行统计，并基于本客户端在下一周期的流量配额对本客户端在下一周期的IO请求进行流量控制；所述流量管理模块用于从所述流量门禁模块获取本客户端在当前周期的流量需求并发送至所述流量控制节点，以及从所述流量控制节点获取本客户端在下一周期的流量配额并发送至所述前台IO线程。

在一些实施例中，客户端的流量门禁模块用于基于本客户端在下一周期的各个IO请求所属IO流的优先级对本客户端在下一周期的各个IO请求进行流量控制，IO流的优先级由客户端所属的存储业务下发。

在一些实施例中，客户端的流量门禁模块用于将IO请求所属IO流的优先级发送到所述存储系统，以使所述存储系统基于IO请求所属IO流的优先级对接收到的IO请求进行调度。

在一些实施例中，至少一个客户端分别从属于多个存储业务；从属于多个存储业务的客户端的前台IO线程包括多个流量门禁模块，每个流量门禁模块对应一个存储业务，用于根据对应存储业务的流量配额对本客户端在下一周期与对应存储业务相关的IO请求进行流量控制。

在一些实施例中，所述获取各个客户端在当前周期的流量需求，包括：获取所述客户端在当前周期的上报流量需求；对所述客户端在当前周期的上报流量需求和所述客户端的历史流量需求进行加权平均处理，得到所述客户端在当前周期的流量需求。

在一些实施例中，所述基于同一存储业务下的各个客户端在当前周期的流量需求确定所述存储业务在当前周期的流量需求，包括：获取各个客户端的业务标识，所述业务标识用于表征客户端所属的存储业务；基于同一业务标识的客户端在当前周期的流量需求确定该业务标识对应的存储业务在当前周期的流量需求。

在一些实施例中，所述存储系统的流量资源被划分为集群，所述集群中的流量资源被划分为至少一组业务资源，每组业务资源被划分为至少一组客户端资源；所述多个存储业务共享所述集群中的流量资源，每组业务资源被分配给一个存储业务，同一组业务资源中的各组客户端资源分别被分配给同一存储业务下的各个客户端。

第二方面，本公开实施例提供一种流量控制方法，应用于客户端中的后台线程，所述客户端还包括前台IO线程；所述方法包括：从所述前台IO线程获取本客户端在当前周期的流量需求；将本客户端在当前周期的流量需求上报给流量控制节点，并获取所述流量控制节点确定的本客户端在下一周期的流量配额；其中，所述流量控制节点基于多个存储业务中每个存储业务下各个客户端上报的流量需求确定所述每个存储业务在下一周期的流量配额，并基于同一存储业务下各个客户端在下一周期的流量需求以及对应存储业务的流量配额确定对应存储业务下各个客户端在下一周期的流量配额；所述多个存储业务共享存储系统的流量资源，同一存储业务下的各个客户端共享该存储业务的流量资源；将本客户端在下一周期的流量配额发送到所述前台IO线程，以使所述前台IO线程基于获取的流量配额对本客户端在下一周期的IO请求进行流量控制；经流量控制后发送的各个IO请求用于发送到服务器，以使所述服务器响应于接收到的IO请求访问所述存储系统。

第三方面，本公开实施例提供一种流量控制装置，应用于流量控制节点，用于对多个存储业务进行流量控制，所述多个存储业务共享存储系统的流量资源，同一存储业务下的各个客户端共享该存储业务的流量资源；所述装置包括：第一获取模块，用于获取各个客户端在当前周期的流量需求，基于同一存储业务下的各个客户端在当前周期的流量需求确定所述存储业务在当前周期的流量需求；第一确定模块，用于基于所述多个存储业务在当前周期的流量需求确定各个存储业务在下一周期的流量配额；第二确定模块，用于基于同一存储业务下各个客户端在当前周期的流量需求以及对应存储业务在下一周期的流量配额确定对应存储业务下各个客户端在下一周期的流量配额，以使各个客户端基于本客户端在下一周期的流量配额对本客户端在下一周期的各个IO请求进行流量控制；经流量控制后发送的各个IO请求用于发送到服务器，以使所述服务器响应于接收到的IO请求访问所述存储系统。

第四方面，本公开实施例提供一种流量控制装置，应用于客户端中的后台线程，所述客户端还包括前台IO线程；所述装置包括：第二获取模块，用于从所述前台IO线程获取本客户端在当前周期的流量需求；第三获取模块，用于将本客户端在当前周期的流量需求上报给流量控制节点，并获取所述流量控制节点确定的本客户端在下一周期的流量配额；其中，所述流量控制节点基于多个存储业务中每个存储业务下各个客户端上报的流量需求确定所述每个存储业务在下一周期的流量配额，并基于同一存储业务下各个客户端在下一周期的流量需求以及对应存储业务的流量配额确定对应存储业务下各个客户端在下一周期的流量配额；所述多个存储业务共享存储系统的流量资源，同一存储业务下的各个客户端共享该存储业务的流量资源；发送模块，用于将本客户端在下一周期的流量配额发送到所述前台IO线程，以使所述前台IO线程基于获取的流量配额对本客户端在下一周期的IO请求进行流量控制；经流量控制后发送的各个IO请求用于发送到服务器，以使所述服务器响应于接收到的IO请求访问所述存储系统。

第五方面，本公开实施例提供一种流量控制系统，所述系统包括：流量控制节点，多个存储业务中每个存储业务对应的客户端，以及服务器；所述流量控制节点用于执行本公开第一方面的任一实施例中的方法；和/或每个存储业务对应的客户端用于执行本公开第二方面的任一实施例中的方法；所述服务器用于接收客户端发送的IO请求，并响应于接收到的IO请求访问存储系统。

第六方面，本公开实施例提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现本公开任一实施例所述的方法。

第七方面，本公开实施例提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现本公开任一实施例所述的方法。

本公开实施例按照客户端-存储业务的方式对存储系统的流量资源进行层次化组织，在每个周期，基于同一存储业务下各个客户端在当前周期的流量需求确定存储业务的流量需求，以此来分配存储业务在下一周期的流量配额，再基于存储业务在下一周期的流量配额和当前周期存储业务下各个客户端的流量需求确定各个客户端在下一周期的流量配额，从而使各个客户端能够基于本客户端的流量配额对本客户端在下一周期的各个IO请求进行流量控制，实现了在流量入口处进行流量控制。由于预先基于当前周期的流量需求规划了下一周期的流量配额，使得存储业务在下一周期的流量使用量能够基于规划好的流量配额进行约束，而不会抢占其他存储业务的流量资源，从而减少了“扰邻”问题。

应当理解，以上的一般描述和后文的细节描述仅是示例性和解释性的，而非限制本公开。

附图说明

此处的附图被并入说明书中并构成本公开的一部分，这些附图示出了符合本公开的实施例，并与说明书一起用于说明本公开的技术方案。

图1是本公开实施例的系统架构的示意图。

图2是本公开实施例的流量资源的层次化组织方式的示意图。

图3是本公开实施例的流量控制方法的流程图。

图4是本公开实施例的客户端进行流量控制过程的示意图。

图5是本公开另一实施例的流量控制方法的流程图。

图6是本公开实施例的流量控制装置的框图。

图7是本公开另一实施例的流量控制装置的框图。

图8是本公开实施例的计算机设备的示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

在本公开使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本公开。在本公开和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。另外，本文中术语“至少一种”表示多种中的任意一种或多种中的至少两种的任意组合。

应当理解，尽管在本公开可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

为了使本技术领域的人员更好的理解本公开实施例中的技术方案，并使本公开实施例的上述目的、特征和优点能够更加明显易懂，下面结合附图对本公开实施例中的技术方案作进一步详细的说明。

在存储业务混部场景下，可能出现扰邻问题。例如，在一种相关技术中，以TrafficGroup(多个客户端组成的群组)为粒度进行管理，在同一个TrafficGroup中的客户端有相似的资源和延迟需求。每个TrafficGroup分配一个TrafficClass，不同的TrafficClass对应不同的延迟敏感度，流量资源通过TrafficClass来进行优先级控制和分配。

客户端采用rate limiter来管理全局流量资源，rate limiter通过一个分布式的计数器记录每个存储业务和TrafficGroup上的资源需求。rate limiter采用漏桶算法进行限流。每次客户端收到IO请求，先确定本客户端的TrafficGroup中是否存在空闲的流量资源，之后确定同一存储业务中的其他TrafficGroup中是否存在空闲的流量资源，最后确定其他存储业务是否存在空闲的流量资源。如果客户端发现存在空闲流量资源，则将IO请求发送到存储系统。否则，根据超时时间决定IO请求被延迟或拒绝。

在这种情况下，压力大(即IO请求并发度高)的TrafficGroup/存储业务无形中会抢占压力小的TrafficGroup/存储业务的流量资源，而这部分流量资源本应该被压力小的TrafficGroup/存储业务使用。最终，出现非预期的“扰邻”问题。

此外，上述方案还存在以下缺陷：

(1)rate limiter作为全局控制点，客户端每次收到IO请求，都需要和全局控制点交互，确定是否有空闲资源允许IO请求通过。一方面，rate limiter容易成为性能瓶颈；另一方面，在每次IO请求的发送流程上，客户端与rate limiter的交互会不可避免地增加IO时延，影响系统整体的性能。

(2)每次客户端收到IO请求，如果本客户端的TrafficGroup没有空闲流量资源，会确定其他TrafficGroup/存储业务是否有空闲资源。但是，由于存储业务的IO请求不是连续地发送给存储系统，而是以一定的并发度发送，只有当前序发送的IO请求返回后才会发送后面的请求。在一个存储业务等待前序IO请求的过程中，会被压力较大的其他存储业务误以为该存储业务处于空闲状态，从而使得该存储业务的流量资源被其他存储业务抢占。这种现象称为“deceptive idleness”。

基于此，本公开实施例提供一种流量控制方法、装置和系统、介质和计算机设备。本公开实施例按照客户端-存储业务的方式对存储系统的流量资源进行层次化组织，在每个周期，基于同一存储业务下各个客户端在当前周期的流量需求确定存储业务的流量需求，以此来分配存储业务在下一周期的流量配额，再基于存储业务在下一周期的流量配额和当前周期存储业务下各个客户端的流量需求确定各个客户端在下一周期的流量配额，从而使各个客户端能够基于本客户端的流量配额对本客户端在下一周期的各个IO请求进行流量控制，实现了在流量入口处进行流量控制。由于预先基于当前周期的流量需求规划了下一周期的流量配额，使得存储业务在下一周期的流量使用量能够基于规划好的流量配额进行约束，而不会抢占其他存储业务的流量资源，从而减少了“扰邻”问题。

下面首先结合图1对本公开实施例的系统架构进行示例性说明。如图1所示，本公开实施例的系统架构包括流量控制节点102、存储业务104、客户端106和存储系统108。其中，流量控制节点102可以与客户端106和存储系统108进行通信，以便获取客户端106上报的流量需求以及存储系统108的流量资源，并基于客户端106上报的流量需求以及存储系统108的流量资源对多个存储业务进行流量控制。存储业务104可以包括但不限于弹性块存储(Elastic Block Store，EBS)、对象存储服务(Object Storage Service，OSS)、表格存储(Open Table Service，OTS)等存储业务。在存储业务混部场景下，存储业务的数量大于1，图中以存储业务包括EBS和OSS为例进行说明。每个存储业务下可以包括一个或多个客户端106，客户端106是为客户提供文件系统服务的程序，客户端106可以通过网络以特定的通信协议与服务器(chunkserver)110沟通，进而通过服务器110访问存储系统108完成文件存储等读写操作。存储系统108可以是一个分布式存储系统，通过网络使用分散在多个存储节点上的流量资源，并将这些分散的流量资源构成一个虚拟的存储设备，使数据分散地存储在多个存储节点上。在存储系统108是一个分布式存储系统的情况下，服务器110的数量可以大于1，每台服务器110可以对应于一个存储节点，用于接收针对该存储节点的IO请求，并将接收到的IO请求发送到对应的存储节点，以访问该存储节点。

本公开实施例的流量控制方法可应用于图1所示的系统架构中的流量控制节点102。流量控制节点102可以对多个存储业务进行流量控制。参见图2，本公开实施例将流量资源按照集群(Cluster)-业务(Service)资源-客户端(Client)资源的方式来层次化组织。最顶层是集群，表示分布式存储系统总的流量资源。集群之下一层是业务资源。对于混部场景，多个存储业务104会共享同一个集群的流量资源，即同一集群中的流量资源可以划分为至少一组业务资源。最底层是客户端资源，同一存储业务104下的各个客户端106共享该存储业务104的流量资源，客户端106根据从属于的存储业务104，使用对应存储业务104的流量资源。即每组业务资源被划分为至少一组客户端资源，同一组业务资源中的各组客户端资源分别被分配给同一存储业务104下的各个客户端106。

基于上述流量模型，流量控制节点102可以自下而上地汇总流量信息，然后自上而下地分配流量配额给每个客户端106。整个流程如图3所示，包括以下步骤：

步骤302：获取各个客户端106在当前周期的流量需求，基于同一存储业务104下的各个客户端106在当前周期的流量需求确定所述存储业务104在当前周期的流量需求；

步骤304：基于所述多个存储业务104在当前周期的流量需求确定各个存储业务104在下一周期的流量配额；

步骤306：基于同一存储业务104下各个客户端106在当前周期的流量需求以及对应存储业务104在下一周期的流量配额确定对应存储业务104下各个客户端106在下一周期的流量配额，以使各个客户端106基于本客户端106在下一周期的流量配额对本客户端106在下一周期的各个IO请求进行流量控制；经流量控制后发送的各个IO请求用于发送到服务器，以使所述服务器响应于接收到的IO请求访问所述存储系统。

在步骤302中，各个客户端106可以周期性地向流量控制节点102上报本客户端的流量需求，客户端106上报的流量需求称为该客户端106的上报流量需求。客户端106发送给存储系统108的每个IO请求中可以携带该IO请求的流量需求(例如，2M)。客户端106可以对同一周期内各个IO请求的流量需求进行汇总，得到本客户端106在该周期内的上报流量需求。

在一些实施例中，可以将客户端106在一个周期的上报流量需求作为客户端106在该周期的流量需求。在另一些实施例中，流量控制节点102可以获取所述客户端106在一个周期的上报流量需求；对所述客户端在该周期的上报流量需求和所述客户端的历史流量需求进行加权平均处理，得到所述客户端在该周期的流量需求。所述加权平均处理可以采用指数加权移动平均法(EWMA)等算法，本公开对此不做限制。通过上述方式，可以平滑短期业务压力随机波动带来的误差影响。

例如，流量控制节点102可以对客户端106在第k个周期的上报流量需求与客户端106在第k-1个周期的流量需求进行加权平均处理，得到客户端106在第k个周期的流量需求，k为大于1的整数。进一步地，可以对客户端106在第k+1个周期的上报流量需求与客户端106在第k个周期的流量需求(通过对客户端106在第k个周期的上报流量需求与客户端106在第k-1个周期的流量需求进行加权平均处理得到)进行加权平均处理，得到客户端106在第k+1个周期的流量需求。以此类推，从而得到客户端106在每个周期的流量需求。

进一步地，流量控制节点102可以获取每个客户端106的业务标识，所述业务标识用于表征客户端106所属的存储业务104，属于同一存储业务104的各个客户端106具有相同的业务标识。基于同一业务标识的客户端106在一个周期的流量需求，流量控制节点102可以确定该业务标识对应的存储业务104在该周期的流量需求。进而，流量控制节点102可以按照存储业务→客户端的层次，对各个客户端106和存储业务104的流量需求进行维护。

例如，在图2中，存储业务Service₁下包括Client₁到Client_i这i个客户端，存储业务Service₂下包括Client_i+1到Client_n这n-i个客户端，则Client₁到Client_i的业务标识相同(均记为标识1)，Client_i+1到Client_n的业务标识也相同(均记为标识2)，且标识1与标识2不同。从而可以将具有标识1的各个客户端(即Client₁到Client_i)在同一周期的流量需求进行汇总求和，得到Service₁在该周期的流量需求，并将具有标识2的各个客户端(即Client_i+1到Client_n)在同一周期的流量需求进行汇总求和，得到Service₂在该周期的流量需求。

在步骤304中，流量控制节点102可以基于所述多个存储业务104在当前周期的流量需求确定各个存储业务104在下一周期的流量配额。由于基于当前周期的流量需求提前规划了下一周期的流量配额，使得即便下一周期某个存储业务104的流量需求激增，在下一周期也不会过度抢占其他存储业务104的流量配额而造成“扰邻”问题。例如，假设存储系统108的流量资源为100，并假设在当前周期两个存储业务104的流量需求相同，则可以按照1:1的比例确定这两个存储业务104在下一周期的流量配额，从而这两个存储业务104在下一周期均获得50的流量配额。即便在下一周期，其中一个存储业务104的流量需求激增，但在下一周期该存储业务104的流量配额仍为50。而按照相关技术中的流量控制方式，当其中一个存储业务104的流量需求激增时，该存储业务104下的客户端106会抢占其他空闲存储业务104的流量资源，结果可能导致其他空闲存储业务104被分配到的流量配额只有20，从而无法为各个存储业务104提供性能一致且可预期的流量服务。

在一些实施例中，可以基于所述多个存储业务104的权重确定各个存储业务104在下一周期的基础流量配额；基于所述多个存储业务104在当前周期的流量需求确定各个存储业务104在下一周期的补充流量配额；基于每个存储业务104在下一周期的基础流量配额和补充流量配额确定所述存储业务104在下一周期的流量配额。

其中，存储业务104的权重用于表征该存储业务104的重要程度，存储业务104的基础流量配额与该存储业务104的权重正相关。通过为存储业务104设置权重，能够为重要程度较高的存储业务104分配较多的基础流量配额。在不同的情况下，同一存储业务104的权重可能发生改变。在一些实施例中，可以为每个存储业务104设置流量配额上限和流量配额下限，则存储业务104的基础流量配额不低于该存储业务104的流量配额下限。在确定各个存储业务104在下一周期的基础流量配额之后，可以基于所述存储系统108的流量资源以及各个存储业务104在下一周期的基础流量配额，确定所述存储系统108的剩余流量配额。如果剩余流量配额大于0，则可以进一步基于所述多个存储业务104在当前周期的流量需求确定各个存储业务104在下一周期的补充流量配额。进一步地，存储业务104在下一周期的流量配额不超过该存储业务104的流量配额上限。这样，在某个存储业务104压力空闲时，可以将存储系统108的流量资源适度倾斜给其他压力较大的存储业务104，从而提高存储系统108的流量资源利用率，同时又不会使一个存储业务104过度地抢占其他存储业务104的流量资源而造成“扰邻”问题。

在同时考虑存储业务104的权重以及流量需求的实施例中，可以调用weightedmax min fairness算法或者其他基于权重和需求的分配算法，将存储系统108的流量资源分配给每个存储业务104。

在一些实施例中，流量控制节点102还可以周期性(比如1s)地遍历分布式历存储系统的每个存储节点，获取该存储节点的流量资源，对各个存储节点的流量资源进行汇总后得到整个分布式存储系统(即集群)的流量资源。流量控制节点102可以基于各个存储业务104的流量需求、各个存储业务104的权重以及整个分布式存储系统的流量资源共同为各个存储业务104分配流量配额。

应当说明的是，流量控制节点102可以周期性地，或者在一定的触发条件的触发下，确定各个存储业务104和各个客户端106的流量配额。在流量控制节点102周期性地确定流量配额的实施例中，流量控制节点102确定流量配额的周期与客户端进行流量控制的周期和存储节点上报流量资源的周期可以不同。例如，存储节点可以以较长的第一周期上报本存储节点的流量资源，客户端106可以以较短的第二周期(第二周期小于第一周期)上报本节点的流量需求并从流量控制节点102查询本客户端106的流量配额以进行流量控制，而流量控制节点102产生流量配额的第三周期可以大于、等于或小于第二周期。本公开实施例中的“当前周期”、“下一周期”等可以是上述第二周期。如果第三周期大于第二周期，则客户端106在相邻多个第二周期内可能查询到相同的流量配额。如果第三周期小于第二周期，则流量控制节点102在相邻的多个第三周期可能产生相同的流量配额。但无论第二周期与第三周期的大小关系如何，客户端106可以在每个第二周期均获取流量控制节点102最后一次产生的流量配额，并以此为依据进行流量控制。

在步骤306中，流量控制节点102可以将各个客户端106在下一周期的流量配额下发到对应的客户端106，以使对应的客户端106对本客户端在下一周期的各个IO请求进行流量控制。

在为各个客户端106分配流量配额时，可以基于同一存储业务104下各个客户端106的权重确定所述各个客户端106在下一周期的基础流量配额，客户端106的权重用于表征该客户端106的重要程度(可选地，可以将同一存储业务104下各个客户端106的权重均设为1)；基于所述各个客户端106在当前周期的流量需求确定所述各个客户端106在下一周期的补充流量配额；基于每个客户端106在下一周期的基础流量配额和补充流量配额确定所述客户端106在下一周期的流量配额。在同时考虑客户端106的权重以及流量需求的实施例中，可以调用weighted max min fairness算法或者其他基于权重和需求的分配算法，将各个客户端106所属存储业务104的流量配额分配给该存储业务104下的每个客户端106。

上述流量资源分配流程中，在存储业务104间分配流量配额时，分配算法会考虑每个存储业务104的权重占比和流量需求，这样做的好处是，当多个混部的存储业务104的IO压力都很大，而出现流量资源争抢时，更重要的(即权重占比高的)存储业务104会分配到更多的流量资源；当某个存储业务104的IO压力空闲时，该存储业务104空闲出的磁盘流量资源会适度地倾斜给其他压力大的存储业务104，以有效提升流量资源的利用率。

同样地，在存储业务104内为各个客户端106分配流量配额时，分配算法也会考虑每个客户端106的流量需求，这样可以在某些客户端106的IO压力空闲时，将流量资源分配给其他压力大的客户端106。

客户端106可以将本客户端106在下一周期的流量配存储在本地；其中，客户端106针对本客户端106在下一周期的每个IO请求，基于缓存的流量配额以及本客户端106在下一周期已消耗的流量配额，对该IO请求进行流量控制。其中，客户端106在一个周期内可以向存储系统108发送一个或多个IO请求，每个IO请求都会消耗一定的流量配额，一个IO请求消耗的流量配额可以基于该IO请求中携带的流量需求确定。客户端106针对本客户端106可以对一个周期内已发送的各个IO请求消耗的流量需求进行汇总求和，得到本客户端106在该周期已消耗的流量配额。

参见图4，在获取到新的IO请求之后，可以确定该新的IO请求中携带的流量需求与本客户端在下一周期已消耗的流量配额之和是否大于缓存的流量配额。如果是，则需要对该新的IO请求进行限流，即，将下一周期接收到的IO请求加入等待队列。其中，每个IO流对应一个等待队列，可以根据IO请求所属的IO流，将该IO请求加入对应的等待队列。如果新的IO请求中携带的流量需求与本客户端在下一周期已消耗的流量配额之和不大于本客户端在下一周期的流量配额，则无需对该新的IO请求进行限流，可以直接将该新的IO请求发送到存储系统108。

进一步地，若本客户端106的流量配额满足所述等待队列中的IO请求的出队条件，则本客户端106可以将所述等待队列中的IO请求移出所述等待队列并发送到所述存储系统108。其中，出队条件可以是本客户端106的流量配额被补充，且大于等待队列中的IO请求的流量需求。例如，当新的周期到来后，客户端106可以获得新的流量配额。如果新的流量配额大于等待队列中的IO请求的流量需求，则可以将等待队列中的IO请求出队并发送到服务器110，并通过服务器110将IO请求转发到所述存储系统108。

上述实施例在流量控制节点102获取到各个客户端106的流量配额之后，客户端106可以直接将本客户端106的流量配额缓存到本地，这样，客户端106在下一周期无需每次接收到IO请求之后都与流量控制节点102进行交互来确定当前接收到的IO请求是否需要进行限流，减少了IO延迟，提高了系统整体的性能。此外，由于一个周期的IO请求是按照一定的并发度发送的，通过采用上述方式，由于每个客户端106在下一周期的流量配额已经预先规划好了，即便一个客户端106并发地发送完一次IO请求，并进入等待状态以后，其他IO压力较大的客户端106也不会过多地占用该进入等待状态的客户端106的流量资源，从而解决了“deceptive idleness”问题。

在一些实施例中，一个客户端106包括部署在前台IO线程上的流量门禁模块(Resource Guard)和部署在后台线程上的流量管理模块(Resource Manager)。所述流量门禁模块用于对本客户端106在当前周期的IO请求的流量需求进行统计，并基于本客户端106在下一周期的流量配额对本客户端106在下一周期的IO请求进行流量控制；所述流量管理模块用于从所述流量门禁模块获取本客户端106在当前周期的流量需求并发送至所述流量控制节点102，以及从所述流量控制节点102获取本客户端106在下一周期的流量配额并发送至所述前台IO线程。本公开实施例将流量控制与IO调度进行解耦，其中，客户端106中的流量资源门禁模块部署在前台IO线程上，决策IO请求是否被限流。在这个过程中不需要和全局控制点(即流量控制节点102)或是其他模块交互，完全在本线程内轻量化地完成决策，对于IO时延的影响仅在ns量级，降低了IO延迟。流量资源的分配则由后台线程上的流量资源管理模块和流量控制节点102交互完成。这个流程完全在后台执行，通过后台资源调度和前台IO调度的解耦，可以避免流量资源调度对前台读写IO性能的影响。

在一些实施例中，每个客户端106可以部署一个流量管理模块，同一客户端106上的每个前台IO线程可以部署一个流量门禁模块。部署在一个前台IO线程上的流量门禁模块可以对该前台IO线程在一个周期内的IO请求的流量需求进行统计，并将统计的流量需求发送到该客户端106的流量管理模块。该客户端106的流量管理模块可以对该客户端106上各个前台IO线程的流量门禁模块在同一周期统计的流量需求进行汇总求和，得到该客户端106在对应周期的流量需求。

在一些实施例中，至少一个客户端106分别从属于多个存储业务104；从属于多个存储业务104的客户端的前台IO线程包括多个流量门禁模块，每个流量门禁模块对应一个存储业务，用于根据对应存储业务的流量配额对本客户端在下一周期与对应存储业务相关的IO请求进行流量控制。例如，仍假设存储业务104的数量为2，两个存储业务104分别记为Service₁和Service₂，其中，Service₁和Service₂下均包括客户端Client₁，则客户端Client₁可以分别获得流量控制节点102分配的对应于Service₁的流量配额(称为Q₁)和对应于Service₂的流量配额(称为Q₂)。在这种情况下，客户端Client₁的流量门禁模块包括对应于Service₁的流量门禁模块(称为Guard₁)和对应于Service₂的流量门禁模块(称为Guard₂)，且流量门禁模块Guard₁用于根据对应于Service₁的流量配额Q₁对客户端Client₁在下一周期与Service₁相关的IO请求进行流量控制，流量门禁模块Guard₂用于根据对应于Service₂的流量配额Q₂对客户端Client₁在下一周期与Service₂相关的IO请求进行流量控制。

此外，因为存储业务104内部会存在不同workload类型的IO流，且这些IO流的优先级可能不同，所以客户端106允许存储业务104对IO流打标优先级。例如，可以设置P0-P4共5个从高到低的优先级，可选地，可以将EBS的前台读写IO流打标为P1优先级，后台GC IO流打标为P3优先级。本领域技术人员可以理解，优先级的数量以及各个IO流的优先级排序不限于上述实施例中所述的情况。存储业务104可以将打标后的优先级下发到该存储业务104下的各个客户端106。客户端106的流量门禁模块可以基于本客户端106在下一周期的各个IO请求所属IO流的优先级对本客户端106在下一周期的各个IO请求进行流量控制。具体来说，流量门禁模块可以按照各个IO请求所属的IO流的优先级从高到低的顺序，依次对各个IO请求进行调度。如果当前IO请求需要被限流，则将该IO请求加入所属IO流的等待队列，如图4所示，在设置5个优先级的情况下，等待队列的数量也是5，各个等待队列分别记为p0，……，p4。如果当前IO请求不需要被限流，则将该IO请求发送到存储系统108。在客户端106的流量配额被补充后，可以按照各个IO流的优先级，依次将各个IO流对应的等待队列中的IO请求出队并发送到存储系统108。将IO请求从等待队列出队时，可以按照预先确定的调度算法，例如，加权循环(Weighted Round Robin，WRR)，对等待队列中的IO请求进行调度。通过上述优先级调度的方式，能够实现客户端106被限流时优先保障高优先级IO流的性能。高优先级IO流的IO压力下降时，低优先级IO流可以使用空闲流量，从而减少流量资源浪费。

在一个IO请求未被限流的情况下，客户端106可以将该IO请求发送到服务器110。在服务器110内部可以实现与客户端106类似的优先级调度功能。客户端106的流量门禁模块可以将IO请求所属IO流的优先级发送到服务器110，以使服务器110基于IO请求所属IO流的优先级对接收到的IO请求进行调度。具体来说，服务器110可以将IO请求加入对应的优先级队列，并根据确定的调度策略调度各个优先级队列中的IO请求，从而实现服务器110上的优先级调度。当一个IO请求被调度时，服务器110可以将该IO请求发送到存储系统108，以访问存储系统108。

参见图5，本公开实施例还提供另一种流量控制方法，应用于客户端中的后台线程，所述客户端还包括前台IO线程；所述方法包括：

步骤502：从所述前台IO线程获取本客户端在当前周期的流量需求；

步骤504：将本客户端在当前周期的流量需求上报给流量控制节点，并获取所述流量控制节点确定的本客户端在下一周期的流量配额；其中，所述流量控制节点基于多个存储业务中每个存储业务下各个客户端上报的流量需求确定所述每个存储业务在下一周期的流量配额，并基于同一存储业务下各个客户端在下一周期的流量需求以及对应存储业务的流量配额确定对应存储业务下各个客户端在下一周期的流量配额；所述多个存储业务共享存储系统的流量资源，同一存储业务下的各个客户端共享该存储业务的流量资源；

步骤506：将本客户端在下一周期的流量配额发送到所述前台IO线程，以使所述前台IO线程基于获取的流量配额对本客户端在下一周期的IO请求进行流量控制；经流量控制后发送的各个IO请求用于发送到服务器，以使所述服务器响应于接收到的IO请求访问所述存储系统。

本公开实施例的具体细节详见前述方法实施例，此处不再赘述。

本领域技术人员可以理解，在具体实施方式的上述方法中，各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定，各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。

参见图6，本公开实施例还提供一种流量控制装置，应用于流量控制节点，用于对多个存储业务进行流量控制，所述多个存储业务共享存储系统的流量资源，同一存储业务下的各个客户端共享该存储业务的流量资源；所述装置包括：

第一获取模块602，用于获取各个客户端在当前周期的流量需求，基于同一存储业务下的各个客户端在当前周期的流量需求确定所述存储业务在当前周期的流量需求；

第一确定模块604，用于基于所述多个存储业务在当前周期的流量需求确定各个存储业务在下一周期的流量配额；

第二确定模块606，用于基于同一存储业务下各个客户端在当前周期的流量需求以及对应存储业务在下一周期的流量配额确定对应存储业务下各个客户端在下一周期的流量配额，以使各个客户端基于本客户端在下一周期的流量配额对本客户端在下一周期的各个IO请求进行流量控制；经流量控制后发送的各个IO请求用于发送到服务器，以使所述服务器响应于接收到的IO请求访问所述存储系统。

参见图7，本公开实施例还提供另一种流量控制装置，应用于客户端中的后台线程，所述客户端还包括前台IO线程；所述装置包括：

第二获取模块702，用于从所述前台IO线程获取本客户端在当前周期的流量需求；

第三获取模块704，用于将本客户端在当前周期的流量需求上报给流量控制节点，并获取所述流量控制节点确定的本客户端在下一周期的流量配额；其中，所述流量控制节点基于多个存储业务中每个存储业务下各个客户端上报的流量需求确定所述每个存储业务在下一周期的流量配额，并基于同一存储业务下各个客户端在下一周期的流量需求以及对应存储业务的流量配额确定对应存储业务下各个客户端在下一周期的流量配额；所述多个存储业务共享存储系统的流量资源，同一存储业务下的各个客户端共享该存储业务的流量资源；

发送模块706，用于将本客户端在下一周期的流量配额发送到所述前台IO线程，以使所述前台IO线程基于获取的流量配额对本客户端在下一周期的IO请求进行流量控制；经流量控制后发送的各个IO请求用于发送到服务器，以使所述服务器响应于接收到的IO请求访问所述存储系统。

在一些实施例中，本公开实施例提供的装置具有的功能或包含的模块可以用于执行上文方法实施例描述的方法，其具体实现可以参照上文方法实施例的描述，为了简洁，这里不再赘述。

本公开实施例还提供一种计算机设备，其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现前述任一实施例所述的方法。

图8示出了本公开实施例所提供的一种更为具体的计算设备硬件结构示意图，该设备可以包括：处理器802、存储器804、输入/输出接口806、通信接口808和总线810。其中处理器802、存储器804、输入/输出接口806和通信接口808通过总线810实现彼此之间在设备内部的通信连接。

处理器802可以采用通用的中央处理器(Central Processing Unit，CPU)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本公开实施例所提供的技术方案。处理器802还可以包括显卡，所述显卡可以是Nvidia titan X显卡或者1080Ti显卡等。

存储器804可以采用只读存储器(Read Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、静态存储设备，动态存储设备等形式实现。存储器804可以存储操作系统和其他应用程序，在通过软件或者固件来实现本公开实施例所提供的技术方案时，相关的程序代码保存在存储器804中，并由处理器802来调用执行。

输入/输出接口806用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口808用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线810包括一通路，在设备的各个组件(例如处理器802、存储器804、输入/输出接口806和通信接口808)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器802、存储器804、输入/输出接口806、通信接口808以及总线810，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本公开实施例方案所必需的组件，而不必包含图中所示的全部组件。

本公开实施例还提供一种流量控制系统，所述系统包括：

流量控制节点102，多个存储业务104中每个存储业务104对应的客户端106；以及服务器110；

所述流量控制节点102可以执行前述任一方法实施例中由流量控制节点102执行的步骤；和/或每个客户端106可以执行前述任一方法实施例中客户端106执行的步骤；所述服务器110可以接收客户端发送的IO请求，并响应于接收到的IO请求访问存储系统。

本公开实施例的流量控制系统的具体架构可参见图1以及前述方法实施例，此处不再赘述。

本公开实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述任一实施例所述的方法。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本公开实施例可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本公开实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开实施例各个实施例或者实施例的某些部分所述的方法。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机装置或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

本公开中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本公开实施例方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅是本公开实施例的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本公开实施例原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本公开实施例的保护范围。

Claims (14)

1.一种流量控制方法，应用于流量控制节点，用于对多个存储业务进行流量控制，所述多个存储业务共享存储系统的流量资源，同一存储业务下的各个客户端共享该存储业务的流量资源；所述方法包括：

获取各个客户端在当前周期的流量需求，基于同一存储业务下的各个客户端在当前周期的流量需求确定所述存储业务在当前周期的流量需求；

基于所述多个存储业务在当前周期的流量需求确定各个存储业务在下一周期的流量配额；

基于同一存储业务下各个客户端在当前周期的流量需求以及对应存储业务在下一周期的流量配额确定对应存储业务下各个客户端在下一周期的流量配额，以使各个客户端基于本客户端在下一周期的流量配额对本客户端在下一周期的各个IO请求进行流量控制；经流量控制后发送的各个IO请求用于发送到服务器，以使所述服务器响应于接收到的IO请求访问所述存储系统。

2.根据权利要求1所述的方法，所述基于所述多个存储业务在当前周期的流量需求确定各个存储业务在下一周期的流量配额，包括：

基于所述多个存储业务的权重确定各个存储业务在下一周期的基础流量配额；

基于所述多个存储业务在当前周期的流量需求确定各个存储业务在下一周期的补充流量配额；

基于每个存储业务在下一周期的基础流量配额和补充流量配额确定所述存储业务在下一周期的流量配额。

3.根据权利要求1所述的方法，所述方法还包括：

将各个客户端在下一周期的流量配额下发到对应的客户端，以使对应的客户端将本客户端在下一周期的流量配存储在本地；其中，客户端针对本客户端在下一周期的每个IO请求，基于缓存的流量配额以及本客户端在下一周期已消耗的流量配额，对该IO请求进行流量控制。

4.根据权利要求3所述的方法，所述客户端用于：

若下一周期接收到的IO请求的流量需求与本客户端在下一周期已消耗的流量配额之和大于本客户端在下一周期的流量配额，将下一周期接收到的IO请求加入等待队列；

若本客户端的流量配额满足所述等待队列中的IO请求的出队条件，将所述等待队列中的IO请求移出所述等待队列并发送到所述存储系统。

5.根据权利要求1所述的方法，所述客户端包括部署在前台IO线程上的流量门禁模块和部署在后台线程上的流量管理模块；

所述流量门禁模块用于对本客户端在当前周期的IO请求的流量需求进行统计，并基于本客户端在下一周期的流量配额对本客户端在下一周期的IO请求进行流量控制；

所述流量管理模块用于从所述流量门禁模块获取本客户端在当前周期的流量需求并发送至所述流量控制节点，以及从所述流量控制节点获取本客户端在下一周期的流量配额并发送至所述前台IO线程。

6.根据权利要求5所述的方法，客户端的流量门禁模块用于基于本客户端在下一周期的各个IO请求所属IO流的优先级对本客户端在下一周期的各个IO请求进行流量控制，IO流的优先级由客户端所属的存储业务下发。

7.根据权利要求6所述的方法，客户端的流量门禁模块用于将IO请求所属IO流的优先级发送到所述存储系统，以使所述存储系统基于IO请求所属IO流的优先级对接收到的IO请求进行调度。

8.根据权利要求5所述的方法，至少一个客户端分别从属于多个存储业务；从属于多个存储业务的客户端的前台IO线程包括多个流量门禁模块，每个流量门禁模块对应一个存储业务，用于根据对应存储业务的流量配额对本客户端在下一周期与对应存储业务相关的IO请求进行流量控制。

9.根据权利要求1所述的方法，所述获取各个客户端在当前周期的流量需求，包括：

获取所述客户端在当前周期的上报流量需求；

对所述客户端在当前周期的上报流量需求和所述客户端的历史流量需求进行加权平均处理，得到所述客户端在当前周期的流量需求。

10.根据权利要求1所述的方法，所述存储系统的流量资源被划分为集群，所述集群中的流量资源被划分为至少一组业务资源，每组业务资源被划分为至少一组客户端资源；所述多个存储业务共享所述集群中的流量资源，每组业务资源被分配给一个存储业务，同一组业务资源中的各组客户端资源分别被分配给同一存储业务下的各个客户端。

11.一种流量控制方法，应用于客户端中的后台线程，所述客户端还包括前台IO线程；所述方法包括：

从所述前台IO线程获取本客户端在当前周期的流量需求；

将本客户端在当前周期的流量需求上报给流量控制节点，并获取所述流量控制节点确定的本客户端在下一周期的流量配额；其中，所述流量控制节点基于多个存储业务中每个存储业务下各个客户端上报的流量需求确定所述每个存储业务在下一周期的流量配额，并基于同一存储业务下各个客户端在下一周期的流量需求以及对应存储业务的流量配额确定对应存储业务下各个客户端在下一周期的流量配额；所述多个存储业务共享存储系统的流量资源，同一存储业务下的各个客户端共享该存储业务的流量资源；

将本客户端在下一周期的流量配额发送到所述前台IO线程，以使所述前台IO线程基于获取的流量配额对本客户端在下一周期的IO请求进行流量控制；经流量控制后发送的各个IO请求用于发送到服务器，以使所述服务器响应于接收到的IO请求访问所述存储系统。

12.一种流量控制系统，所述系统包括：

流量控制节点，多个存储业务中每个存储业务对应的客户端，以及服务器；

所述流量控制节点用于执行权利要求1-10任一项所述的方法；和/或

每个存储业务对应的客户端用于执行权利要求11所述的方法；

所述服务器用于接收客户端发送的IO请求，并响应于接收到的IO请求访问存储系统。

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

14.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现权利要求1至11任意一项所述的方法。

Images