CN117076157B - 请求管理方法、装置、计算机可读存储介质及计算机设备 - Google Patents

请求管理方法、装置、计算机可读存储介质及计算机设备 Download PDF

Info

Publication number
CN117076157B
CN117076157B CN202311223206.6A CN202311223206A CN117076157B CN 117076157 B CN117076157 B CN 117076157B CN 202311223206 A CN202311223206 A CN 202311223206A CN 117076157 B CN117076157 B CN 117076157B
Authority
CN
China
Prior art keywords
request
access node
amount
access
target
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202311223206.6A
Other languages
English (en)
Other versions
CN117076157A (zh
Inventor
周木桂
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202311223206.6A priority Critical patent/CN117076157B/zh
Publication of CN117076157A publication Critical patent/CN117076157A/zh
Application granted granted Critical
Publication of CN117076157B publication Critical patent/CN117076157B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/547Remote procedure calls [RPC]; Web services
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061Partitioning or combining of resources
    • G06F9/5072Grid computing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/54Indexing scheme relating to G06F9/54
    • G06F2209/541Client-server

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本公开提供了一种请求管理方法、装置、存储介质及计算机设备。其中,方法包括获取第一请求管理时段内目标对象的数据访问请求在每一接入节点中消耗的第一请求资源量,接入节点为目标对象对应的接入节点集合中的接入节点;获取目标对象在第二请求管理时段内可支配的第二请求资源量;根据第一请求资源量与第二请求资源量,计算第二请求管理时段内每一接入节点对应的请求资源管控量;在第二请求管理时段内,当检测到第一目标接入节点中目标对象的数据访问请求消耗的请求资源量大于对应的请求资源管控量时,禁止第一目标接入节点向存储节点发送目标对象的数据访问请求。该方法可以提升请求管理的准确性,进而可以提升对数据库的访问效率。

Description

请求管理方法、装置、计算机可读存储介质及计算机设备
技术领域
本公开涉及计算机技术领域,特别是涉及一种请求管理方法、装置、计算机可读存储介质及计算机设备。
背景技术
近年来,随着互联网技术和计算机技术的不断发展,各类计算机应用的用户数量都在不断增加,这使得各类计算机应用的应用数据也在不断增长。如何对不断增长的应用数据进行稳定且安全的存储,成为需要解决的问题。其中,数据库技术通过将应用数据存储在大量分布式布置的存储节点中,并将数据在多个存储节点中进行多备份,从而实现大容量存储以及安全存储。
由于数据库包含的分布式布置的存储节点数量众多,且会同时存在大量对象对数据库中的数据进行访问,当数据库的访问量过大时容易导致数据库负载过大影响数据访问效率,因此需要对每个对象的访问请求进行限流控制。然而,目前采用的限流方法的精确性较差,在一些情况下会产生不必要的限流,从而降低了对象对数据库的访问效率。
发明内容
本公开实施例提供了一种请求管理方法、装置、存储介质及计算机设备,该方法可以提升请求管理的准确性,进而可以提升对象对数据库的访问效率。
根据本公开的一方面,提供了一种请求管理方法,包括:
获取第一请求管理时段内目标对象的数据访问请求在每一接入节点中消耗的第一请求资源量,所述接入节点为所述目标对象对应的接入节点集合中的接入节点;
获取所述目标对象在第二请求管理时段内可支配的第二请求资源量;
根据所述第一请求资源量与所述第二请求资源量计算第二请求管理时段内每一接入节点对应的请求资源管控量;
在所述第二请求管理时段内,当检测到第一目标接入节点中所述目标对象的数据访问请求消耗的请求资源量大于对应的请求资源管控量时,禁止所述第一目标接入节点向存储节点发送所述目标对象的数据访问请求。
根据本公开的一方面,提供了一种请求管理装置,包括:
第一获取单元,用于获取第一请求管理时段内目标对象的数据访问请求在每一接入节点中消耗的第一请求资源量,所述接入节点为所述目标对象对应的接入节点集合中的接入节点;
第二获取单元,用于获取所述目标对象在第二请求管理时段内可支配的第二请求资源量;
计算单元,用于根据所述第一请求资源量与所述第二请求资源量计算第二请求管理时段内每一接入节点对应的请求资源管控量;
控制单元,用于在所述第二请求管理时段内,当检测到第一目标接入节点中所述目标对象的数据访问请求消耗的请求资源量大于对应的请求资源管控量时,禁止所述第一目标接入节点向存储节点发送所述目标对象的数据访问请求。
可选地,在一些实施例中,所述计算单元,包括:
第一计算子单元,用于根据所述第一请求资源量,计算第一请求管理时段内消耗的请求资源在所述接入节点中的分布信息;
第二计算子单元,用于根据所述分布信息与所述第二请求资源量,计算第二请求管理时段内每一所述接入节点对应的请求资源管控量。
可选地,在一些实施例中,第二计算子单元,包括:
分配模块,用于基于所述分布信息将所述第二请求资源量在多个所述接入节点中进行分配,得到第二请求管理时段内每一所述接入节点对应的第三请求资源量;
第一计算模块,用于根据所述第三请求资源量计算每一所述接入节点对应的第四请求资源量,所述第四请求资源量为备用的请求资源量;
第二计算模块,用于根据所述第三请求资源量与所述第四请求资源量,计算每一所述接入节点对应的请求资源管控量。
可选地,在一些实施例中,本公开提供的请求管理装置,还包括:
第一获取子单元,用于在所述第二请求管理时段内,获取每一所述接入节点对应的多个对象使用的备用请求资源量,所述备用请求资源量为对象在所述接入节点中的数据访问请求消耗的请求资源量与对应的请求资源分配量之间的差值;
第三计算子单元,用于计算所述多个对象使用的所述备用请求资源量的和,得到每一接入节点对应的备用请求资源使用总量;
第一控制子单元,用于当第二目标接入节点对应的所述备用请求资源使用总量达到预设请求资源量阈值时,禁止所述第二目标接入节点向存储节点发送使用了备用请求资源的对象对应的数据访问请求。
可选地,在一些实施例中,本公开提供的请求管理装置,还包括:
第二获取子单元,用于响应于所述目标对象的目标数据访问请求,获取第三请求管理时段内所述目标数据访问请求对应的第三目标接入节点对应的第一请求资源剩余量;
第二控制子单元,用于当所述第一请求资源剩余量小于所述目标数据访问请求所消耗的请求资源量时,禁止所述第三目标接入节点向存储节点发送所述目标对象的数据访问请求。
可选地,在一些实施例中,所述第三请求管理时段包括多个第二请求管理时段,所述第二获取子单元,包括:
第一获取模块,用于获取每一第二请求管理时段内,所述目标数据访问请求对应的第三目标接入节点的请求资源管控量与请求资源消耗量;
第三计算模块,用于计算每一第二请求管理时段内,所述请求资源管控量与所述请求资源消耗量之间的差值,得到多个第二请求资源剩余量;
第四计算模块,用于计算所述多个第二请求资源剩余量之和,得到第三请求管理时段对应的第一请求资源剩余量。
可选地,在一些实施例中,所述第二控制子单元,包括:
第二获取模块,用于当所述第一请求资源剩余量小于所述目标数据访问请求所消耗的请求资源量时,获取与所述目标对象对应的多个接入节点在所述第三请求管理时段内的请求资源剩余量之和,得到第三请求资源剩余量;
控制模块,用于当所述第三请求资源剩余量小于所述目标数据访问请求所消耗的请求资源量时,禁止所述第三目标接入节点向存储节点发送所述目标对象的数据访问请求。
可选地,在一些实施例中,本公开提供的请求管理装置,还包括:
第一发送子单元,用于当所述第一请求资源剩余量不小于所述目标数据访问请求所消耗的请求资源量时,向所述目标对象的客户端发送所述目标数据访问请求对应的处理结果;以及,
第二发送子单元,用于基于所述第三目标接入节点向存储节点发送所述目标对象的数据访问请求。
可选地,在一些实施例中,本公开提供的请求管理装置,还包括:
第一确定子单元,用于确定与所述目标对象对应的目标接入节点集合;
获取子单元,用于获取所述目标接入节点集合中每一接入节点接入的数据访问请求的数量;
第二确定子单元,用于根据所述数据访问请求的数量在所述目标接入节点集合中确定第三目标接入节点。
可选地,在一些实施例中,所述计算单元,包括:
第四计算子单元,用于根据所述第一请求资源量,计算所述第一请求管理时段内所述目标对象的数据访问请求消耗的请求资源总量;
第五计算子单元,用于计算所述第二请求资源量与所述请求资源总量之间的差值;
第六计算子单元,用于根据所述差值与所述第一请求资源量,计算第二请求管理时段内每一接入节点对应的请求资源管控量。
根据本公开的一方面,提供了一种存储介质,所述存储介质存储有计算机程序,所述计算机程序被处理器执行时实现如上所述的请求管理方法。
根据本公开的一方面,提供了一种计算机程序产品,该计算机程序产品包括计算机程序,所述计算机程序被计算机设备的处理器读取并执行,使得该计算机设备执行如上所述的请求管理方法。
本公开实施例中,通过获取第一请求管理时段内目标对象的数据访问请求在每一接入节点中消耗的第一请求资源量,接入节点为目标对象对应的接入节点集合中的接入节点;获取目标对象在第二请求管理时段内可支配的第二请求资源量;根据第一请求资源量与第二请求资源量,计算第二请求管理时段内每一接入节点对应的请求资源管控量;在第二请求管理时段内,当检测到第一目标接入节点中目标对象的数据访问请求消耗的请求资源量大于对应的请求资源管控量时,禁止第一目标接入节点向存储节点发送目标对象的数据访问请求。以此,在本公开实施例中,可以根据第一请求管理时段内目标对象在各接入节点中消耗的请求资源,来自动调节第二请求管理时段内对各接入节点的请求资源管控量,从而可以避免不合理的限流导致影响目标对象对数据库的访问效率。即本方案可以提升请求管理的精确度,进而可以提升目标对象对数据库的访问效率。
本公开的其他特征和优点将在随后的说明书中阐述,并且,部分地从说明书中变得显而易见,或者通过实施本公开而了解。本公开的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。
附图说明
附图用来提供对本公开技术方案的进一步理解,并且构成说明书的一部分,与本公开的实施例一起用于解释本公开的技术方案,并不构成对本公开技术方案的限制。
附图用来提供对本公开技术方案的进一步理解,并且构成说明书的一部分,与本公开的实施例一起用于解释本公开的技术方案,并不构成对本公开技术方案的限制。
图1是根据本公开的实施例的请求管理方法应用的系统构架图;
图2是相关技术中按存储分区进行限流的示意图;
图3是本公开的实施例的请求管理方法的一个流程示意图;
图4是本公开提供的数据库系统的后端架构示意图;
图5a是第一请求管理时段内租户A的请求资源使用情况示意图;
图5b是第二请求管理时段内租户A的请求资源使用情况示意图;
图5c是第二请求管理时段内租户A的请求资源使用情况的另一示意图;
图6是相关技术中采用GAC模块进行限流控制的示意图;
图7a是本公开实施例中对大查询进行处理的一个示意图;
图7b本公开提供的在节点间协调累计ru处理大查询的示意图;
图8是本公开中对租户的数据访问请求进行处理的过程示意图;
图9a是本公开提供的请求管理方法的另一流程示意图;
图9b是限流管理模块和接入节点池之间的交互示意图;
图10是本公开实施例的请求管理装置的结构示意图;
图11是实施根据本公开的一个实施例的各方法的终端结构图;
图12是实施根据本公开的一个实施例的各方法的服务器结构图。
具体实施方式
为了使本公开的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本公开进行进一步详细说明。应当理解,此处所描述的具体实施例仅用以解释本公开,并不用于限定本公开。
对本公开实施例进行进一步详细说明之前,对本公开实施例中涉及的名词和术语进行说明,本公开实施例中涉及的名词和术语适用于如下的解释:
数据库(Database):简而言之可视为电子化的文件柜——存储电子文件的处所,用户可以对文件中的数据进行新增、查询、更新、删除等操作。所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。根据数据库类型一般可以分为关系型数据库(如MySQL)和非关系型数据库(NoSQL),其中SQL表示结构化查询语言(Structured Query Language)。云数据库包括接入层和存储层,接入层用于对租户的访问请求进行接入管理;存储层包括分布式布置的多个存储节点(因此也称分布式数据库),用于进行数据存储以及相应租户的访问请求进行数据读写处理。数据库管理系统(英语:Database Management System,简称DBMS)是为管理数据库而设计的电脑软件系统,一般具有存储、截取、安全保障、备份等基础功能。数据库管理系统可以依据它所支持的数据库模型来作分类,例如关系式、XML(Extensible Markup Language,即可扩展标记语言);或依据所支持的计算机类型来作分类,例如服务器群集、移动电话;或依据所用查询语言来作分类,例如SQL(结构化查询语言(Structured Query Language)、XQuery;或依据性能冲量重点来作分类,例如最大规模、最高运行速度;亦或其他的分类方式。不论使用哪种分类方式,一些DBMS能够跨类别,例如,同时支持多种查询语言。
分区:分布式数据库会将对象数据拆分成多个小表,每个小表就是一个分区,这些小表分布在多个存储节点上,保证水平扩展。
接入节点:分布式数据库的接入模块,接入节点为无状态节点。
接入节点池:将接入层的接入节点划分成多个接入节点池,每个接入节点池绑定一部分租户。
请求单元(request unit,ru):一种面向请求的资源度量方法和资源度量单位,用于度量每个请求对资源的消耗。Ru通常与云计算和分布式系统中的资源管理和计费相关。
租户:租用数据库的对象,例如数据库应用的用户。
多租户分布式数据库可以为不同租户提供数据存储和访问服务,租户可以将数据存储在分布式数据库中,并使用多租户分布式数据库中存储层提供的接口进行数据的读取和写入。由于当大量租户同时对分布式数据库进行访问时,会存在由于访问量过大导致分布式数据库负载过大而影响租户访问效率的情况;而且,租户对分布式数据库中存储的数据进行访问的行为会消耗一定的资源,为避免异常访问行为导致的资源消耗过多而对租户产生大量不必要的代价,分布式数据库会对租户的访问行为进行适当的限流控制。相关技术中,一个租户的数据可能存储在分布式数据库的存储层中的多个分区中,分布式数据库将租户购买的请求资源量平分到各个分区中以对多个分区进行分别的限流。然而,当租户对不同分区中存储的数据的访问需求不均衡时,会导致部分分区的请求资源量不足而过早被限流,而部分分区请求资源量利用率低的情况。如图2所示,为按存储分区进行限流示意图。如图所示,租户A通过接入层210对存储层220中存储的数据进行访问。租户A存储在存储层220中的表1被分别存储在存储节点1的分区1、存储节点2的分区2以及存储节点3的分区N中。假设租户A购买了300ru的访问资源用于访问表1。此时分布式数据库会将这300ru分别分配到存储节点1的分区1、存储节点2的分区2以及存储节点3的分区N进行限流控制。当存储层检测到存储节点1的分区1、存储节点2的分区2和存储节点3的分区N中的任一分区的数据访问请求消耗到100ru时,便触发租户A对该分区中存储的资源的访问限流。当租户A对这三个分区中存储的数据的访问频率均衡时,这种限流方式还比较合理;但当租户A对这三个分区中存储的数据的访问频率不均衡时,例如存储节点2中的分区2中存储的数据为租户A较常访问的热点数据时,便可能存在该分区分配的100ru不够使用,过早地触发对该分区的限流,使得租户A在其他分区还存在剩余访问资源的情况下已经无法对需要访问的数据进行访问,从而极大地影响租户对分布式数据库的访问体验。对此,本公开提供了一种请求管理方法,以期能够在一定程度上避免现有限流方式导致数据访问不均衡时出现不必要的限流以及访问资源利用率不高的问题。
图1是根据本公开的实施例的请求管理方法所应用的系统构架图。它包括终端140、互联网130、接入服务器120、存储服务器110等。
终端140括桌面电脑、膝上型电脑、PDA(个人数字助理)、手机、智能语音交互设备、智能家电、车载终端、飞行器等等多种形式。另外,它可以是单台设备,也可以是多台设备组成的集合。终端140可以以有线或无线的方式与互联网130进行通信,交换数据。
存储服务器110用于存储和管理不同租户的数据,租户的数据可以被安全地隔离和访问,以确保数据的保密性和完整性。存储服务器110可以具有较大的存储空间,可以提供数据备份和恢复功能,以确保租户数据的可靠性和持久性。在分布式数据库系统中,存储服务器110可以为多台,分布式部署在不同地区。
接入服务器120用于管理租户的访问请求,将租户的访问请求通过存储服务器110提供的接口接入存储服务器110进行数据访问(包括数据读取和写入)。接入服务器可以为实体服务器也可以为云服务器。
本公开实施例的请求管理方法具体可以在接入服务器120中实现;具体地,接入服务器120可以获取第一请求管理时段内目标对象的数据访问请求在每一接入节点中消耗的第一请求资源量,接入节点为目标对象对应的接入节点集合中的接入节点;获取目标对象在第二请求管理时段内可支配的第二请求资源量;根据第一请求资源量与第二请求资源量,计算第二请求管理时段内每一接入节点对应的请求资源管控量;在第二请求管理时段内,当检测到第一目标接入节点中目标对象的数据访问请求消耗的请求资源量大于对应的请求资源管控量时,禁止第一目标接入节点向存储节点发送目标对象的数据访问请求。
本公开实施例可以应用在对数据库中的数据进行访问时的限流控制场景中。具体地,数据库可以为多租户、分布式NoSQL数据库,接入服务器中具有限流管理模块,用于对租户的访问请求进行限流管理,接入层中包括多个接入节点池,每个接入节点池中包含多个可以接入存储服务器的接入节点,每个租户都与一个接入节点池绑定,并通过绑定的接入节点池中的接入节点将访问请求发送到对应的存储服务器中进行数据访问。当目标租户对分布式NoSQL数据库进行访问时,接入层中的限流管理模块可以每2秒获取目标租户的数据访问请求在绑定的接入节点池中每一接入节点中消耗的请求资源量,然后根据前2秒每一接入节点中消耗的请求资源量对目标租户购买的请求资源进行重新分配,并根据每一接入节点重新分配的请求资源对接下来2秒的访问请求进行限流控制。然后重复上述过程,不断根据前2秒每一接入节点中消耗的请求资源量来更新每一接入节点的限流控制线。如此可以避免存储节点中某一分区热点数据导致目标租户购买的请求资源剩余较多的情况下就出现限流,进而导致请求资源利用率不高、数据库使用体验差的问题。
根据本公开的一个实施例,提供了一种请求管理方法。该方法可以用于前述对数据库数据进行访问时的限流场景中。
如图3所示,为本公开提供的请求管理方法的一个流程示意图。该方法可以应用于请求管理装置,该请求管理装置可以集成在计算机设备中,计算机设备可以为前述接入服务器。该请求管理方法可以包括:
步骤310,获取第一请求管理时段内目标对象的数据访问请求在每一接入节点中消耗的第一请求资源量。
其中,本公开提供的请求管理方法具体可以应用于在数据库访问的限流场景中,且本公开提供的请求管理方法是一种在接入层进行访问请求控制的限流方法。具体地,在本公开实施例中,接入层具有多个接入节点池,每个接入节点池与一定量的租户绑定,此处接入节点池也可以称为接入节点集合。当有新租户注册数据库应用时,可以将其绑定到一个接入节点池中,若现有的接入节点池绑定的租户数量均已达到上限时,可以新建一个接入节点池,并将新注册的租户绑定到新建的接入节点池中。每个接入节点池包含了多个接入节点,绑定一个接入节点池的租户可以通过该接入节点池中的接入节点接入存储层以访问存储层的数据。
如图4所示,为本公开提供的数据库系统的后端架构示意图。如图所示,在接入层210中,包含了多个接入节点池410,在每个接入节点池410中包含了多个接入节点411。当接入层210中接收到租户发送的数据访问请求时,可以先找到与该租户绑定的接入节点池410,然后使用接入节点池410中的接入节点411将数据访问请求发送到存储层220中进行数据访问。
基于上述架构,租户在进行数据访问时,可以先申请一定量的ru,并将申请到的ru平均分配到接入节点池中的各个接入节点中。例如,租户A申请了10万的ru,与租户A绑定的接入节点池中包含了10个接入节点,均分到每个接入节点,每个接入节点分配到1万ru。此时便以1万ru对每个接入节点进行限流,当某个接入节点的数据访问请求消耗的ru达到了1万,便会触发该接入节点的限流,禁止该接入节点向存储层发送租户A的数据访问请求。其中,租户申请的10万ru和接入节点分配到的1万ru均是以单位时间(例如1秒)进行处理的。即租户申请的10万ru具体为每秒申请10万ru,在每个接入节点也是以每秒1万ru的管控线来进行限流的。由于该方案的限流策略通过在接入层实现限流,接入层的每个节点都可以对存储层中的热点数据进行访问,相对于在存储层中每个分区进行限流控制,可以避免存储层中的热点数据导致过早触发限流的问题,从而可以实现更为均衡、更为合理的限流。
然而,即使采用上述在接入层进行限流控制的方法,在一些情况下也会出现各个接入节点中负载不均衡的情况。例如,在一些情况下,当租户采用长连接入到某个或多个接入节点中,如此该租户的多个数据访问请求便会都通过该访问节点来对存储层中的数据进行访问,这种情况也会导致不同接入节点中负载不均衡的情况。此时若还是根据平均分配的请求资源来对不同接入节点进行限流,仍会导致不必要的限流以及请求资源使用率不高的问题,进而导致对数据库的访问效率下降。对此,本公开提供了一种请求管理方法,以期解决上述接入节点中负载不均衡情况导致的不必要的限流和请求资源使用率低,进而导致对数据库的访问效率低的问题。下面将对本公开的方案进行详细介绍。
首先,可以在租户对数据库进行访问的过程中,获取第一请求管理时段内目标对象的数据访问请求在每一接入节点中消耗的第一请求资源量。其中,第一请求管理时段可以为一个预设的时段,例如1秒、2秒、10秒、1分钟以及5分钟等。在同一个请求管理时段内,对接入节点进行限流的管控限可以不发生变化。例如第一请求管理时段为2秒,那么在这个2秒开始时每个接入节点的限流管控线为1万ru每秒,那么到这个2秒结束的整个过程中,对每个接入节点的限流管控线都是1万ru每秒。目标对象可以为数据库应用中的一个具体的租户。数据访问请求可以为读请求也可以为写请求,由于读请求若未被处理可以重新发起请求,影响的只是数据读取的效率,而写请求若未被处理可能会导致数据的丢失,因此一般写请求的优先级高于读请求。即在接入队列中会先将读请求发送给存储层,存储层的请求处理队列中也会优先处理写请求对应的任务。接入节点为与目标对象对应的接入节点,即与目标对象绑定的接入节点池中的多个节点。在第一请求管理时段内,目标对象的数据访问请求可能在每一接入节点中都消耗了请求资源,也可能只在一部分接入节点中消耗了请求资源,在其他接入节点中没有消耗请求资源。请求资源量为数据访问请求所消耗的资源,具体可以采用前述单位时间消耗的ru来量化。第一请求资源量为第一请求管理时段内目标对象在每一接入节点消耗的请求资源量,即第一请求资源量与多个接入节点一一对应。
如图5a所示,为第一请求管理时段内租户A的请求资源使用情况示意图。如图所示,租户A在第一请求管理时段内申请了4000ru/s,在第一请求管理时段内的消耗为3000ru/s。具体地,与租户A绑定的接入节点池中包含4个接入节点,租户A在第一请求管理时段内申请的4000ru/s被平均分配到这4个接入节点中,每个接入节点分配了1000ru/s的请求资源,即每个接入节点以1000ru/s对租户A的数据访问请求进行限流。在第一请求管理时段内,租户A在接入节点1、接入节点2以及接入节点3中的数据访问请求实际消耗的请求资源量为500ru/s,在接入节点4中的数据访问请求实际消耗的请求资源量为1500ru/s。其中,由于接入层将租户的数据访问请求发送至存储层后,接入层并不清楚数据访问请求会消耗多少的请求资源,只有存储层可以实时确定处理数据请求消耗的请求资源。存储层在处理完数据访问请求后,会将该数据访问请求消耗的请求资源量返回给对应的接入节点,并存储在接入节点中。因此,获取第一请求管理时段内租户在不同接入节点中消耗的请求资源量,具体可以从租户对应的每一接入节点中进行获取。由于数据访问请求消耗的请求资源量是由存储层返回的,因此会存在限流滞后的问题,即实际消耗的请求资源大于分配的请求资源后才开始限流的情况。如图5a中接入节点4中,可能存在一种情况,例如本来租户A在接入节点4中的数据访问请求消耗的请求资源量为900ru/s,此时不会触发接入节点4的限流,因此当下一个数据访问请求到达接入节点4时,接入节点4便将该数据访问请求发送至存储层中进行处理。然而,该数据访问请求消耗的请求资源量较大,为600ru/s。当存储层返回该数据访问请求消耗的资源量到接入节点4时,接入节点4才发现此时该接入节点中的数据访问请求实际的请求资源量以及超过分配的请求资源量,那么租户A的下一个数据访问请求到达接入节点4时,接入节点4便不会将其发送给存储层处理,从而实现限流。
然而,由于租户在第一请求管理时段内申请了4000ru/s的资源量,实际使用量才达到3000ru/s便感知到了限流,因此这种限流方法一方面导致租户的请求资源的使用率不高,另一方面还影响租户对数据库的访问体验。
步骤320,获取目标对象在第二请求管理时段内可支配的第二请求资源量。
在本公开实施例中,在获取到第一请求管理时段内租户在不同接入节点中消耗的请求资源量后,便可以根据租户在不同接入节点中消耗的请求资源量来重新规划对申请到的请求资源的分配情况,即重新设计限流规则。具体地,可以根据第一请求管理时段内租户在不同接入节点中消耗的请求资源量和第二请求管理时段内目标对象可支配的第二请求资源量来重新设计限流规则。其中,第二请求管理时段可以为在第一请求管理时段之后的管理时段,第二请求管理时段可以为与第一请求管理时段时长相同的时段,也可以为与第一请求管理时段时长不同的时段。例如当第一请求管理时段为2秒时,第二请求管理时段可以为2秒,也可以为3秒或者5秒等。第二请求管理时段可以为在第一请求管理时段之后,与第一请求管理时段相邻的请求管理时段;也可以为在第一请求管理时段之后,与第一请求管理时段不相邻的请求管理时段。
其中,当第二请求管理时段的时长与第一请求管理时段的时长相同,例如都是2秒时,目标对象在第二请求管理时段中可支配的请求资源(例如申请的ru)可以与第一请求管理时段相同,也可以与第一请求管理时段不同。例如第一请求管理时段中,租户A申请了4000ru/s,那么第二请求管理时段租户可能申请了4000ru/s,也可能申请了5000ru/s,即本方案对目标对象在不同请求管理时段中申请的请求资源量不作限制。
步骤330,根据第一请求资源量与第二请求资源量,计算第二请求管理时段内每一接入节点对应的请求资源管控量。
在获取到第一请求管理时段内目标对象的数据访问请求在每一接入节点中消耗的第一请求资源量以及第二请求管理时段内目标对象可支配的第二请求资源量后,便可以进一步计算第二请求管理时段内每一接入节点对应的请求资源管控量。其中,此处请求资源管控量为在第二请求管理时段内每一接入节点对目标对象的数据访问请求消耗的请求资源进行管控的标准。即请求资源管控量只针对目标对象,不影响其他对象在该接入节点池中各个接入节点接入的数据访问请求。
其中,在一些实施例中,根据第一请求资源量与第二请求资源量,计算第二请求管理时段内每一接入节点对应的请求资源管控量,包括:
根据第一请求资源量,计算第一请求管理时段内消耗的请求资源在接入节点中的分布信息;
根据分布信息与第二请求资源量,计算第二请求管理时段内每一接入节点对应的请求资源管控量。
在本公开实施例中,可以先根据第一请求管理时段内目标对象的数据访问请求在对应的接入节点池中各节点消耗的第一请求资源量计算出第一请求管理时段内消耗的请求资源在接入节点中的分布信息。接入节点中的分布信息具体可以为第一请求管理时段内请求资源消耗量的比例,如图5a中,多个接入节点在第一请求管理时段内消耗的请求资源的比例为500ru/s:500ru/s:500ru/s:1500ru/s=1:1:1:3。然后,可以进一步根据分布信息与第二请求资源量,计算出第二请求管理时段内每一接入节点对应的请求资源管控量。然后根据计算得到的第二请求管理时段内每一接入节点对应的请求资源管控量对第二时段内目标对象的数据访问请求进行限流管理,便可以避免不必要的限流,提升请求资源的利用率。
如图5b所示,为第二请求管理时段内租户A的请求资源使用情况示意图。假设第二请求管理时段内租户A可支配的第二请求资源量也是4000ru/s,且租户A在各接入节点中消耗的请求资源量相对于第一请求管理时段内未发生变化,一般情况下,当第一请求管理时段和第二请求管理时段的时长较短(秒级,例如均设置为2秒)时,租户A在多个接入节点中消耗的资源量发生变化的可能性也较小。此时,由于根据第一请求管理时段内租户A在多个接入节点中消耗的请求资源的分布信息对第二请求资源量进行了重新分配,得到第二管理时段内每一接入节点对应的新的请求资源管控量。即重新给接入节点1、接入节点2和接入节点3分配了(2000/3)ru/s,给接入节点4分配了2000ru/s。如此,当租户A在各接入节点中的请求资源消耗量保持稳定时,便可以避免不必要的限流,保证了租户A在多个接入节点中正常进行数据库的访问,提升了请求资源的利用率和数据库的使用体验。
在一些实施例中,根据第一请求资源量与第二请求资源量,计算第二请求管理时段内每一接入节点对应的请求资源管控量,包括:
根据第一请求资源量,计算第一请求管理时段内目标对象的数据访问请求消耗的请求资源总量;
计算第二请求资源量与请求资源总量之间的差值;
根据差值与第一请求资源量,计算第二请求管理时段内每一接入节点对应的请求资源管控量。
其中,在获取到第一请求管理时段内目标对象的数据访问请求在每一接入节点中消耗的第一请求资源量,以及第二请求管理时段内目标对象可支配的第二请求资源量后,可以先计算第一请求管理时段内目标对象的数据访问请求消耗的请求资源总量,然后计算第二请求资源量与请求资源总量之间的差值。进一步地,可以根据该差值与每一接入节点对应的第一请求资源量,计算第二请求管理时段内每一接入节点对应的请求资源管控量。即在本公开实施例中,不再根据第一请求管理时段中消耗的请求资源在接入节点中的分布信息来对第二请求管理时段中的第二请求资源量进行重新分配,而是先计算出第一请求管理时段中目标对象在多个接入节点中消耗的请求资源总量,然后根据第二请求资源量与第一请求管理时段中消耗的请求资源总量的差值计算出第二请求管理时段可能的请求资源剩余量,进一步地,可以将第二请求管理时段中的请求资源剩余量均分到各个接入节点中。由于目标对象的数据访问请求分配到每一接入节点的概率是随机且均衡的,即在已知第一请求管理时段中各接入节点资源消耗量的基础上,目标对象在第二请求管理时段新增的数据访问请求在多个接入节点中的新增量也是均衡的,因此也应当保持多个接入节点剩余请求资源量相同,以进一步提升限流管理的合理性。
如图5c所示,为第二请求管理时段内租户A的请求资源使用情况的另一示意图。其中,第二管理时段租户A仍申请了4000ru/s的请求资源,而在第一请求管理时段中,租户A在四个接入节点中消耗的请求资源总量为3000ru/s,若在第二请求管理时段中租户A在四个接入节点中消耗的请求资源量保持稳定,那么第二请求管理时段应当剩余的请求资源量为1000ru/s。进一步地,将这剩余1000ru/s均分到四个接入节点中,然后拿均分得到的250ru/s与第一请求管理时段中每一接入节点实际消耗的请求资源量相加,便可以得到第二请求管理时段中每一接入节点对应的请求资源管控量。具体为接入节点1至3的请求资源管控量为750ru/s,接入节点4的请求资源管控量为1750ru/s。
步骤340,在第二请求管理时段内,当检测到第一目标接入节点中目标对象的数据访问请求消耗的请求资源量大于对应的请求资源管控量时,禁止第一目标接入节点向存储节点发送目标对象的数据访问请求。
其中,在根据目标对象在第一请求管理时段内多个接入节点中消耗的第一请求资源量和第二请求管理时段内可支配的第二请求资源量计算得到第二请求管理时段内每一接入节点对应的请求资源管控量后,便可以基于每一接入节点对应的请求资源管控量来对目标对象的访问请求进行管控。
具体地,在任一接入节点,此处称为第一目标接入节点中,当目标对象的访问请求消耗的请求资源量不大于对应的请求资源管控量时,当目标对象有新的数据访问请求被分配到该第一目标接入节点时,第一目标接入节点可以将该新的数据访问请求发送到存储节点以进行数据访问。当目标对象的访问请求消耗的请求资源量大于对应的请求资源管控量时,若目标对象有新的数据访问请求被分配到该第一目标接入节点,则禁止第一目标接入节点将新的数据访问请求发送到存储节点中,以实现对目标对象在第一目标接入节点中的限流。其中,此处存储节点为存储层中的任一存储节点,具体可以为与数据访问请求对应的存储节点。
本公开实施例提供的请求管理方法,首先通过在接入层进行限流控制,相对于在存储层进行限流控制,既避免了热点数据导致负载不均衡从而触发不必要的限流的问题,还可以减小存储层的计算资源开销,提升对数据库的数据访问效率。
在一些实施例中,根据分布信息与第二请求资源量,计算第二请求管理时段内每一接入节点对应的请求资源管控量,包括:
基于分布信息将第二请求资源量在多个接入节点中进行分配,得到第二请求管理时段内每一接入节点对应的第三请求资源量;
根据第三请求资源量计算每一接入节点对应的第四请求资源量,第四请求资源量为备用的请求资源量;
根据第三请求资源量与第四请求资源量,计算每一接入节点对应的请求资源管控量。
其中,在本公开实施例中,为了进一步提升对象使用数据库的使用体验,可以进一步对每一接入节点设置一定量的备用请求资源。具体地,当根据分布信息将第二请求资源量在目标对象对应的接入节点池中的多个接入节点中进行分配,得到第二请求管理时段内每一接入节点对应的第三请求资源量。然后,可以进一步根据每一接入节点分配到的第三请求资源量来计算每一接入节点对应的备用请求资源量,此处可称为第四请求资源量。然后,可以计算每一接入节点对应的第三请求资源量和备用请求资源量的和,得到每一接入节点对应的请求资源管控量。具体地,在一些实施例中,可以设置每个接入节点对应的备用请求资源量为分配到的第三请求资源量的两倍。如此,当某一接入节点中目标对象的数据访问请求消耗的请求资源量达到分配的第三请求资源量时,可以不触发该节点对目标对象的数据访问请求的限流,目标对象可以继续使用该接入节点中的备用请求资源量来实现对数据库的访问。如此,可以大大提升对象使用数据库的使用体验。
在一些实施例中,根据第三请求资源量与第四请求资源量,计算每一接入节点对应的请求资源管控量之后,还包括:
在第二请求管理时段内,获取每一接入节点对应的多个对象使用的备用请求资源量,备用请求资源量为对象在接入节点中的数据访问请求消耗的请求资源量与对应的请求资源分配量之间的差值;
计算多个对象使用的备用请求资源量的和,得到每一接入节点对应的备用请求资源使用总量;
当第二目标接入节点对应的备用请求资源使用总量达到预设请求资源量阈值时,禁止第二目标接入节点向存储节点发送使用了备用请求资源的对象对应的数据访问请求。
其中,在本公开实施例中,由于一个接入节点池绑定了多个对象,绑定的多个对象可以共用该接入节点池中的多个接入节点来对接入到存储层中实现对存储层数据的访问。即对每一接入节点,都可能有多个对象在同时使用该接入节点访问存储层中存储的数据。那么在一个接入节点中,也就可以对多个对象设置分别对应的备用请求资源量,此外,为了避免大量对象同时使用备用请求资源,导致存储层出现过载的情况,本公开还可以对每一接入节点设置一个备用请求资源总量的限制,即限定每一接入节点中多个对象使用的备用请求资源总量不可超过一个预设请求资源量阈值。
具体地,在第二请求管理时段内,可以实时获取每一接入节点对应的多个对象使用的备用请求资源量,此处接入节点对应的多个对象具体可以为前述与该接入节点所在的接入节点池绑定的对象,多个对象使用的备用请求资源量为对象使用的请求资源量超出分配的请求资源量的部分。例如某一对象在某一接入节点根据第一请求管理时段对应的分布信息分配得到的请求资源量为100ru/s,那么如果每一节点为对象配备的备用请求资源为分配量的2倍时,则确定该接入节点为该对象配置的备用请求资源为200ru/s。当该对象在该接入节点中的数据访问请求消耗的请求资源为150ru/s时,则可以确定该对象在该接入节点中使用的备用请求资源量为50ru/s。可以理解的是,并非接入节点对应的所有对象都会使用到备用请求资源,若某一对象在某一接入节点中的数据访问请求消耗的请求资源量小于其分配的请求资源量时,那么该对象在该节点中使用的备用请求资源量便为0。
然后,可以计算多个对象使用的备用请求资源量的和,便可以得到每一接入节点对应的备用请求资源使用总量。当某一接入节点对应的备用请求资源使用总量未达到其对应的预设请求资源量阈值时,只要对象在该接入节点中的数据访问请求消耗的资源量未超出其对应的请求资源管控量(分配的请求资源量与备用请求资源量之和),该接入节点便不对相应对象的数据访问请求进行限流。当某一接入节点对应的备用请求资源使用总量达到其对应的预设请求资源量阈值时,则禁止该接入节点向存储节点发送使用了备用请求资源的对象对应的数据访问请求。即当某一接入节点的备用请求资源量用完后,只有数据访问请求消耗的请求资源量未超出其分配量的对象可以继续通过该接入节点访问存储层中的数据,其他对象都将被限流。此处某一接入节点可以为目标对象对应的接入节点池中的任一接入节点,此处可以称为第二目标接入节点。该方法可以避免大量对象同时使用备用请求资源导致存储层过载,可以提升数据库运行的稳定性。
其中,在相关技术中,也提供了一种在接入层进行限流管控的方案。该方案采用一个全局准入控制(global admission control,GAC)模块在接入层对租户访问进行限流。GAC模块采用令牌桶算法来管理租户的ru,接入层中的接入模块定时从GAC集群中获取一定量的ru,然后根据获取到的ru进行限流。
如图6所示,为相关技术中采用GAC模块进行限流控制的示意图。如图所示,接入层210中包含了多个接入模块610,多个接入模块定期从GAC模块620中获取ru,GAC模块620中包括了多个GAC节点621,每个GAC节点可以与多个接入模块绑定。当接入模块610接收到对象发送的数据访问请求时,可以先检测自身缓存的ru量是否大于0,若大于0则释放数据访问请求到存储层。存储层返回数据访问请求消耗的ru量后,接入模块610便从缓存的ru中扣除数据访问请求消耗的ru量。同时,接入模块610定期从GAC模块620中的GAC节点621中获取ru,具体例如每秒获取100ru,然后根据获取到的ru更新自身缓存。在一些情况下,存储层返回的数据访问请求消耗的ru量大于接入模块自身缓存的ru量,则接入模块扣除消耗的ru量后自身缓存的ru量为负值。此时接入模块便对相应对象进行限流,不释放数据访问请求至存储层,直至接入模块中缓存的ru量经不断补充变为正值。其中,为了避免数据访问请求消耗过多请求资源,一般会对接入模块中缓存的ru量的负值设置一个下限,例如1000ru。如此,当对象发送的数据访问请求为一个延时较大的大查询请求时,可能存在消耗的请求资源过多,接入模块中缓存的ru不够扣的问题。因此该方案无法支持对大查询请求的处理。
在一些实施例中,本公开提供的请求处理方法,还包括:
响应于目标对象的目标数据访问请求,获取第三请求管理时段内目标数据访问请求对应的第三目标接入节点对应的第一请求资源剩余量;
当第一请求资源剩余量小于目标数据访问请求所消耗的请求资源量时,禁止第三目标接入节点向存储节点发送目标对象的数据访问请求。
其中,此处目标数据访问请求可以为一个大查询请求,第三请求管理时段可以为一个预设的时段,具体可以为自查询请求开始计时到当前时间点的时段。第三请求管理时段可以设置有最大值,例如可以设置为60秒的时段。第三目标接入节点为接入目标数据访问请求的接入节点,第一请求资源剩余量具体可以为接入节点中分配的请求资源与实际消耗的请求资源之间的差值。其中,此处实际消耗的请求资源具体可以为写请求消耗的请求资源,因为相对于查询请求,写请求具有更高的优先级。例如,第三目标接入节点分配的请求资源为500ru/s,而实际消耗的请求资源为200ru/s,目标数据访问请求的执行时间为5秒,那么第三请求管理时段内第三目标接入节点对应的第一请求资源剩余量便为300ru/s*5s=1500ru。然后,可以获取存储层返回的目标数据访问请求消耗的请求资源量,当第一请求资源剩余量小于目标数据访问请求消耗的请求资源量时,便触发第三目标接入节点对目标对象的限流。而且,此时不向目标对象返回目标数据访问请求对应的处理结果,而是将处理结果在返回队列中进行排队,直至累积的第一请求资源剩余量达到目标数据访问请求消耗的请求资源量。
其中,在一些实施例中,第三请求管理时段包括多个第二请求管理时段,获取第三请求管理时段内目标数据访问请求对应的第三目标接入节点对应的第一请求资源剩余量,包括:
获取每一第二请求管理时段内,目标数据访问请求对应的第三目标接入节点的请求资源管控量与请求资源消耗量;
计算每一第二请求管理时段内,请求资源管控量与请求资源消耗量之间的差值,得到多个第二请求资源剩余量;
计算多个第二请求资源剩余量之和,得到第三请求管理时段对应的第一请求资源剩余量。
其中,在本公开实施例中,由于第三请求管理时段可以为时序场景中的时段,是一个较长的时段。该较长的时段具体可以由多个较短的时段,例如第二请求管理时段组成。例如第三请求管理时段为时长60秒的时段,而第二请求管理时段为时长2秒的时段。那么第三请求管理时段便可以由多个第二请求管理时段组成。在每一第二请求管理时段中,每一接入节点中分配到的请求资源量都会根据上一第二请求管理时段中不同接入节点中实际消耗的请求资源量进行变更。因此,获取第三请求管理时段内第三目标接入节点对应的第一请求资源剩余量,具体可以获取每一第二请求管理时段内,第三目标节点的请求资源管控量和请求资源消耗量,然后据此计算得到每一第二请求管理时段内第三目标节点对应的第二请求资源剩余量。进一步地,可以计算多个第二请求管理时段内第二请求资源剩余量之和,便可以得到第三请求管理时段对应的第一请求资源剩余量。
在一些实施例中,响应于目标对象的目标数据访问请求,获取第三请求管理时段内目标数据访问请求对应的第三目标接入节点对应的第一请求资源剩余量之后,还包括:
当第一请求资源剩余量不小于目标数据访问请求所消耗的请求资源量时,向目标对象的客户端发送目标数据访问请求对应的处理结果;以及,
基于第三目标接入节点向存储节点发送目标对象的数据访问请求。
其中,在本公开实施例中,当第三目标节点在第三请求管理时段内累积的第一请求资源剩余量达到目标数据访问请求消耗的请求资源量时,便可以返回该目标数据访问请求的处理结果。同时,可以不对第三目标接入节点中目标对象的数据访问请求进行限流,继续通过第三目标接入节点向存储节点发送数据访问请求。
如图7a所示,为本公开实施例中对大查询进行处理的一个示意图。如图所示,接入节点在T1时刻至T3时刻处理完目标对象的写请求后剩余的请求资源量均为500ru,在T1时刻也发起了一个大查询,存储节点于T3时刻返回了查询结果以及消耗的请求资源量1500ru。此时,自该大查询起到当前时刻接入节点中累计的剩余ru足够扣除大查询对请求资源的消耗量,此时便可以通过累计ru来扣除该大查询所需的请求资源,并返回查询结果给目标对象。
在一些实施例中,当第一请求资源剩余量小于目标数据访问请求所消耗的请求资源量时,禁止第三目标接入节点向存储节点发送目标对象的数据访问请求,包括:
当第一请求资源剩余量小于目标数据访问请求所消耗的请求资源量时,获取与目标对象对应的多个接入节点在第三请求管理时段内的请求资源剩余量之和,得到第三请求资源剩余量;
当第三请求资源剩余量小于目标数据访问请求所消耗的请求资源量时,禁止第三目标接入节点向存储节点发送目标对象的数据访问请求。
在本公开实施例中,当请求资源剩余量累计的时间达到了第三请求管理时段的时长,例如累计时间已经达到了60s,但累计的请求资源剩余量仍小于大查询消耗的请求资源量时,可以进一步调度目标对象在其他接入节点中的累计请求资源剩余量,从而可以提升对象的请求资源的利用率。此外,本公开的方案相对于GAC方案可以避免接入层的主动依赖,即无需向GAC模块发送ru获取请求,可以降低数据访问请求的时延,提升数据访问效率。
具体地,当第一请求资源量小于目标数据访问请求所消耗的请求资源量时,可以获取与目标对象对应的多个接入节点在第三请求管理时段内的请求资源剩余量之和,得到第三请求资源剩余量。若第三请求资源剩余量大于目标数据访问请求消耗的请求资源量时,便可以返回目标数据访问请求对应的处理结果。如果第三请求资源剩余量也小于目标数据访问请求所消耗的请求资源量时,则触发第三目标接入节点对目标对象的数据访问请求的限流。
如图7b所示,为本公开提供的在节点间协调累计ru处理大查询的示意图。如图所示,目标对象在接入节点1和接入节点2在T1至T3时刻剩余ru均为500ru,接入节点3在T1至T3时刻没有剩余ru。若接入节点3在T1时刻发起了一个目标对象的大查询,存储节点在T3时刻返回查询结果,并返回大查询消耗的请求资源量为2000ru,接入节点3没有累计ru用于扣除,此时可以将目标对象在接入节点1和接入节点2在T1时刻和T2时刻的累计ru调度到接入节点3用于扣除该大查询所消耗的请求资源。如此,则可以避免接入节点3在下一时刻被限流。如果大查询消耗的请求资源量特别大,例如消耗了5000ru,此时调度目标对象在其他接入节点中的累计ru也不足以扣除大查询消耗的请求资源量时,可以先暂不返回查询结果,继续累计目标对象在多个接入节点中的剩余ru,直至达到大查询消耗的请求资源量才返回查询结果给目标对象,在该时段内可以对目标对象在接入节点3中的查询请求进行限流。或者,如果当累计时间达到预设时间,例如60s,累计ru总和仍不足以抵扣大查询消耗的ru,可以先将查询结果返回给目标对象。然后在接下来的时间内,继续累计ru进行抵扣,并持续对接入节点3中的查询请求进行限流。
在一些实施例中,获取第三请求管理时段内目标数据访问请求对应的第三目标接入节点对应的第一请求资源剩余量之前,还包括:
确定与目标对象对应的目标接入节点集合;
获取目标接入节点集合中每一接入节点接入的数据访问请求的数量;
根据数据访问请求的数量在目标接入节点集合中确定第三目标接入节点。
其中,在本公开实施例中,在接收到对象的查询请求时,可以先采用负载均衡机制来确定处理接收到的查询请求的接入节点,从而在接入时就进行均衡控制,避免单个接入节点接入过多数据访问请求导致ru分配不均衡进而触发不必要的限流。具体地,可以先确定与目标对象绑定的目标接入节点集合,然后,可以获取目标接入节点集合中每一接入节点接入的数据访问请求的数量。进一步地,可以根据数据访问请求的数量在目标接入节点集合中确定第三目标接入节点,其中,可以将当前接入的数据访问请求数量最少的接入节点确定为第三目标接入节点。
如图8所示,为本公开中对租户的数据访问请求进行处理的过程示意图。如图所示,当接收到数据访问请求时,可以先采用负载均衡模块810来确定将数据访问请求分配到接入节点池410中的具体的接入节点。然后再由确定的具体的接入节点将数据访问请求发送到存储层220中进行处理。
综上,采用本公开提供的请求管理方法,通过获取第一请求管理时段内目标对象的数据访问请求在每一接入节点中消耗的第一请求资源量,接入节点为目标对象对应的接入节点集合中的接入节点;获取目标对象在第二请求管理时段内可支配的第二请求资源量;根据第一请求资源量与第二请求资源量,计算第二请求管理时段内每一接入节点对应的请求资源管控量;在第二请求管理时段内,当检测到第一目标接入节点中目标对象的数据访问请求消耗的请求资源量大于对应的请求资源管控量时,禁止第一目标接入节点向存储节点发送目标对象的数据访问请求。以此,在本公开实施例中,可以根据第一请求管理时段内目标对象在各接入节点中消耗的请求资源,来自动调节第二请求管理时段内对各接入节点的请求资源管控量,从而可以避免不合理的限流导致影响目标对象对数据库的访问效率。即本方案可以提升请求管理的精确度,进而可以提升目标对象对数据库的访问效率。
如图9a所示,为本公开提供的请求管理方法的另一流程示意图。在本公开实施例中,将结合具体的硬件执行模块对本公开提供的请求管理方法进行详细的介绍。方法具体包括如下步骤:
步骤901,当接收到目标租户的数据访问请求时,接入服务器确定与目标租户绑定的目标接入节点池。
其中,在本公开实施例中,接入层中设置有多个接入节点池,每个租户都绑定了一个接入节点池,由接入节点池中的接入节点处理租户的数据访问请求。其中,一个接入节点池可以绑定一个租户,也可以绑定多个租户。接入层中还包括了负载均衡模块和限流管理模块,负载均衡模块用于将租户的数据访问请求均衡地分配到各个接入节点中,以提升租户的整体的数据库访问效率。限流管理模块用于自适应调整各个接入节点的限流管控线,避免在租户的请求资源量未用完的情况下就发生不必要的限流,从而可以提升请求管理的精确性,进而可以提升租户对数据库的访问效率。
因此,当接入服务器接收到目标租户的数据访问请求时,便可以在多个接入节点池中确定与目标租户绑定的接入节点池。其中,此处目标租户只是一个示例,对于任意一个租户,都可以作为目标租户,采用本公开提供的方法进行请求管理。目标租户的数据访问请求可以为一个数据访问请求也可以为多个数据访问请求。目标租户的数据访问请求可以为持续发送的访问请求。
步骤902,限流管理模块每两秒从目标接入节点池中的接入节点获取请求资源消耗量。
其中,当确定了与目标租户绑定的目标接入节点池后,接入服务器中的限流管理模块便可以每两秒从目标接入节点池中的接入节点获取这两秒中,目标租户在每一接入节点消耗的请求资源量。此处的请求资源量具体可以采用前述ru/s来具体量化,其中此处请求资源消耗量为该租户发送的数据访问请求在每一接入节点中消耗的请求资源量。
步骤903,限流管理模块根据获取到的请求资源消耗量计算每一接入节点的请求资源管控量,并将请求资源管控量发送给每一接入节点。
限流管理模块在获取到每一接入节点在两秒内的请求资源消耗量后,便可以根据前两秒的请求资源消耗量来计算接下来两秒内每一接入节点对目标租户消耗的请求资源的请求资源管控量。此处请求资源管控量也就是限流量,当目标租户在某一接入节点中消耗的请求资源量达到该限流量时,便会触发该接入节点对目标租户的数据访问请求的限流。其中,基于前两秒的请求资源消耗量计算接下来两秒内每一接入节点对目标租户的请求资源管控量,具体可以根据前两秒的不同接入节点对应的请求资源消耗量的比值来对接下来两秒可支配的请求资源量进行重新分配计算,也可以根据前两秒多个接入节点的请求资源消耗总量和接下来两秒可支配的请求资源量的差值来进行重新分配计算。具体计算方式已经在前述实施例中进行了详细介绍,此处不再赘述。
在一些实施例中,在计算每一接入节点的请求资源管控量时,还可以在分配的请求资源量的基础上加上相应的备用资源量,备用资源量具体可以为分配的请求资源量的两倍。如此,可以在一定程度上降低租户访问被限流的概率,提升租户对数据库的使用体验。
进一步地,限流管理模块在计算得到每一接入节点在接下来两秒的请求资源管控量后,便可以将计算得到的请求资源管控量对应发送给每一接入节点,以使得每一接入节点根据接收到的请求资源管控量对接下来两秒内目标租户在每一接入节点中的数据访问请求进行限流管控。
如图9b所示,为限流管理模块和接入节点池之间的交互示意图。如图所示,限流管理模块910从接入节点池410中的每一接入节点411中获取各节点ru消耗量,然后限流管理模块910根据获取到的各节点ru消耗量计算出各个接入节点的合理的ru管控量。进一步地,限流管理模块910将各节点ru管控量发送给接入节点池410中的每一接入节点411。上述交互流程可以按照一定的频率重复执行,例如每2秒执行一次。
步骤904,负载均衡模块获取目标接入节点池中每个接入节点的负载信息,并根据负载信息将数据访问请求分配到对应节点中。
当接入服务器接收到目标租户发送的数据访问请求,并确定了目标租户对应的目标接入节点池后。接入服务器中的负载均衡模块可以获取目标接入节点池中每个接入节点的负载信息,接入节点的负载信息具体可以为每个接入节点接入的数据访问请求的请求数量,也可以为每个接入节点中的带宽资源占用量等。然后,基于负载均衡原则,可以将目标租户的数据访问请求分配到当前接入的数据访问请求的请求数量较少,或者带宽资源占用较少的接入节点中。当目标租户发送了多个数据访问请求,可以逐一对每一数据访问请求进行基于负载均衡的分配。
步骤905,接入节点检测目标租户当前消耗的请求资源量是否达到请求资源管控量。
负载均衡模块基于负载均衡原则将目标租户的数据访问请求分配到相应的接入节点中后,接入节点便开始对目标租户的数据访问请求进行处理,此处的接入节点可以为目标接入节点池中的任一接入节点。其中,可以理解的是,每一接入节点不仅处理目标租户的数据访问请求,还可以同时处理其他租户的数据访问请求。对于其他租户的数据访问请求的处理逻辑,可以与处理目标租户的数据访问请求的逻辑相同,因此本公开实施例以对目标租户的访问请求进行处理为例来说明接入节点对租户数据访问请求的处理过程。
具体地,接入节点接收到分配的目标租户的数据访问请求后,先将目标租户的数据访问请求安排在接入队列中进行排队。同时接入节点获取当前时刻目标租户的其他数据访问请求在接入节点中已经消耗的请求资源量,并检测目标租户当前消耗的请求资源量是否达到请求资源管控量。其中,此处请求资源管控量为当前时刻的请求资源管控量,如前述公开,每一接入节点对目标租户的请求资源管控量是以两秒每次的频率进行更新的。
步骤906,当检测到当前消耗的请求资源量未达到请求资源管控量时,接入节点向数据访问请求对应的存储节点发送数据访问请求。
其中,当接入节点检测到目标租户在该接入节点中当前消耗的请求资源量未达到请求资源管控量时,接入节点便可以对接入队列中的数据访问请求进行解析,以确定其对应的存储节点,然后将该数据访问请求发送给对应的存储节点。
步骤907,存储节点处理数据访问请求,并返回处理结果和请求资源消耗量给接入节点。
存储节点在接收到数据访问请求后,便可以对数据访问请求进行处理。其中数据访问请求可以为读请求也可以为写请求。存储节点对数据访问请求进行处理后,便可以将处理结果返回给对应的接入节点;同时,存储节点还可以将数据访问请求消耗的请求资源消耗量发送给对应的接入节点,以便接入节点累计当前目标租户在该接入节点中消耗的请求资源量。
步骤908,当检测到当前消耗的请求资源量达到请求资源管控量时,接入节点对目标租户的数据访问请求进行限流。
当检测到接入节点中目标租户当前消耗的请求资源量已经达到了请求资源管控量,则接入节点对租户的数据访问请求进行限流,即暂时不将租户的数据访问请求发送到对应的存储节点进行处理。如此可以避免租户使用过多请求资源量,从而产生不必要的费用,也可以避免过多数据访问请求发送到存储层导致存储层过载,影响数据库的访问效率的问题。
可以理解的是,虽然上述各个流程图中的各个步骤按照箭头的表征依次显示,但是这些步骤并不是必然按照箭头表征的顺序依次执行。除非本实施例中有明确的说明,这些步骤的执行并没有严格的顺序限制,这些步骤可以以其它的顺序执行。而且,上述流程图中的至少一部分步骤可以包括多个步骤或者多个阶段,这些步骤或者阶段并不必然是在同一时间执行完成,而是可以在不同的时间执行,这些步骤或者阶段的执行顺序也不必然是依次进行,而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
需要说明的是,在本公开的各个具体实施方式中,当涉及到需要根据目标对象属性信息或属性信息集合等与目标对象特性相关的数据进行相关处理时,都会先获得目标对象的许可或者同意,而且,对这些数据的收集、使用和处理等,都会遵守相关地区的相关法律法规和标准。此外,当本申请实施例需要获取目标对象属性信息时,会通过弹窗或者跳转到确认页面等方式获得目标对象的单独许可或者单独同意,在明确获得目标对象的单独许可或者单独同意之后,再获取用于使本申请实施例能够正常运行的必要的目标对象相关数据。
图10为本公开实施例提供的请求管理装置1000的结构示意图。该请求管理装置1000包括:
第一获取单元1010,用于获取第一请求管理时段内目标对象的数据访问请求在每一接入节点中消耗的第一请求资源量,接入节点为目标对象对应的接入节点集合中的接入节点;
第二获取单元1020,用于获取目标对象在第二请求管理时段内可支配的第二请求资源量;
计算单元1030,用于根据第一请求资源量与第二请求资源量计算第二请求管理时段内每一接入节点对应的请求资源管控量;
控制单元1040,用于在第二请求管理时段内,当检测到第一目标接入节点中目标对象的数据访问请求消耗的请求资源量大于对应的请求资源管控量时,禁止第一目标接入节点向存储节点发送目标对象的数据访问请求。
可选地,在一些实施例中,计算单元1030,包括:
第一计算子单元,用于根据第一请求资源量,计算第一请求管理时段内消耗的请求资源在接入节点中的分布信息;
第二计算子单元,用于根据分布信息与第二请求资源量,计算第二请求管理时段内每一接入节点对应的请求资源管控量。
可选地,在一些实施例中,第二计算子单元,包括:
分配模块,用于基于分布信息将第二请求资源量在多个接入节点中进行分配,得到第二请求管理时段内每一接入节点对应的第三请求资源量;
第一计算模块,用于根据第三请求资源量计算每一接入节点对应的第四请求资源量,第四请求资源量为备用的请求资源量;
第二计算模块,用于根据第三请求资源量与第四请求资源量,计算每一接入节点对应的请求资源管控量。
可选地,在一些实施例中,本公开提供的请求管理装置1000,还包括:
第一获取子单元,用于在第二请求管理时段内,获取每一接入节点对应的多个对象使用的备用请求资源量,备用请求资源量为对象在接入节点中的数据访问请求消耗的请求资源量与对应的请求资源分配量之间的差值;
第三计算子单元,用于计算多个对象使用的备用请求资源量的和,得到每一接入节点对应的备用请求资源使用总量;
第一控制子单元,用于当第二目标接入节点对应的备用请求资源使用总量达到预设请求资源量阈值时,禁止第二目标接入节点向存储节点发送使用了备用请求资源的对象对应的数据访问请求。
可选地,在一些实施例中,本公开提供的请求管理装置1000,还包括:
第二获取子单元,用于响应于目标对象的目标数据访问请求,获取第三请求管理时段内目标数据访问请求对应的第三目标接入节点对应的第一请求资源剩余量;
第二控制子单元,用于当第一请求资源剩余量小于目标数据访问请求所消耗的请求资源量时,禁止第三目标接入节点向存储节点发送目标对象的数据访问请求。
可选地,在一些实施例中,第三请求管理时段包括多个第二请求管理时段,第二获取子单元,包括:
第一获取模块,用于获取每一第二请求管理时段内,目标数据访问请求对应的第三目标接入节点的请求资源管控量与请求资源消耗量;
第三计算模块,用于计算每一第二请求管理时段内,请求资源管控量与请求资源消耗量之间的差值,得到多个第二请求资源剩余量;
第四计算模块,用于计算多个第二请求资源剩余量之和,得到第三请求管理时段对应的第一请求资源剩余量。
可选地,在一些实施例中,第二控制子单元,包括:
第二获取模块,用于当第一请求资源剩余量小于目标数据访问请求所消耗的请求资源量时,获取与目标对象对应的多个接入节点在第三请求管理时段内的请求资源剩余量之和,得到第三请求资源剩余量;
控制模块,用于当第三请求资源剩余量小于目标数据访问请求所消耗的请求资源量时,禁止第三目标接入节点向存储节点发送目标对象的数据访问请求。
可选地,在一些实施例中,本公开提供的请求管理装置1000,还包括:
第一发送子单元,用于当第一请求资源剩余量不小于目标数据访问请求所消耗的请求资源量时,向目标对象的客户端发送目标数据访问请求对应的处理结果;以及,
第二发送子单元,用于基于第三目标接入节点向存储节点发送目标对象的数据访问请求。
可选地,在一些实施例中,本公开提供的请求管理装置1000,还包括:
第一确定子单元,用于确定与目标对象对应的目标接入节点集合;
获取子单元,用于获取目标接入节点集合中每一接入节点接入的数据访问请求的数量;
第二确定子单元,用于根据数据访问请求的数量在目标接入节点集合中确定第三目标接入节点。
可选地,在一些实施例中,计算单元1030,包括:
第四计算子单元,用于根据第一请求资源量,计算第一请求管理时段内目标对象的数据访问请求消耗的请求资源总量;
第五计算子单元,用于计算第二请求资源量与请求资源总量之间的差值;
第六计算子单元,用于根据差值与第一请求资源量,计算第二请求管理时段内每一接入节点对应的请求资源管控量。
参照图11,图11为实现本公开实施例的请求管理方法的终端140的部分的结构框图,该终端140包括:射频(Radio Frequency,简称RF)电路1110、存储器1115、输入单元1130、显示单元1140、传感器1150、音频电路1160、无线保真(wireless fidelity,简称WiFi)模块1170、处理器1180、以及电源1190等部件。本领域技术人员可以理解,图11示出的终端140结构并不构成对手机或电脑的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。
RF电路1110可用于收发信息或通话过程中,信号的接收和发送,特别地,将基站的下行信息接收后,给处理器1180处理;另外,将设计上行的数据发送给基站。
存储器1115可用于存储软件程序以及模块,处理器1180通过运行存储在存储器1115的软件程序以及模块,从而执行终端的各种功能应用以及请求管理。
输入单元1130可用于接收输入的数字或字符信息,以及产生与终端的设置以及功能控制有关的键信号输入。具体地,输入单元1130可包括触控面板1131以及其他输入装置1132。
显示单元1140可用于显示输入的信息或提供的信息以及终端的各种菜单。显示单元1140可包括显示面板1141。
音频电路1160、扬声器1161,传声器1162可提供音频接口。
在本实施例中,当终端140可以作为接入层设备时,所包括的处理器1180可以执行前面实施例的请求管理方法。
本公开实施例的终端140包括但不限于手机、电脑、智能语音交互设备、智能家电、车载终端、飞行器等。本发明实施例可应用于各种场景,包括但不限于云技术、人工智能、智慧交通、辅助驾驶等。
图12为实施本公开实施例的请求管理方法的接入服务器120的部分的结构框图。接入服务器120可因配置或性能不同而产生比较大的差异,可以包括一个或一个以上中央处理器(Central Processing Units,简称CPU)1222(例如,一个或一个以上处理器)和存储装置1232,一个或一个以上存储应用程序1242或数据1244的存储介质1230(例如一个或一个以上海量存储装置)。其中,存储装置1232和存储介质1230可以是短暂存储或持久存储。存储在存储介质1230的程序可以包括一个或一个以上模块(图示没标出),每个模块可以包括对服务器110中的一系列指令操作。更进一步地,中央处理器1222可以设置为与存储介质1230通信,在接入服务器120上执行存储介质1230中的一系列指令操作。
接入服务器120还可以包括一个或一个以上电源1226,一个或一个以上有线或无线网络接口1250,一个或一个以上输入输出接口1258,和/或,一个或一个以上操作系统1241,例如Windows ServerTM,Mac OS XTM,UnixTM ,LinuxTM,FreeBSDTM等等。
接入服务器120中的中央处理器1222可以用于执行本公开实施例的请求管理方法。
本公开实施例还提供一种存储介质,存储介质用于存储程序代码,程序代码用于执行前述各个实施例的请求管理方法。
本公开实施例还提供了一种计算机程序产品,该计算机程序产品包括计算机程序。计算机设备的处理器读取该计算机程序并执行,使得该计算机设备执行实现上述的请求管理方法。
本公开的说明书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本公开的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“包含”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或装置不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或装置固有的其它步骤或单元。
应当理解,在本公开中,“至少一个(项)”是指一个或者多个,“多个”是指两个或两个以上。“和/或”,用于描述关联对象的关联关系,表示可以存在三种关系,例如,“A和/或B”可以表示:只存在A,只存在B以及同时存在A和B三种情况,其中A,B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达,是指这些项中的任意组合,包括单项(个)或复数项(个)的任意组合。例如,a,b或c中的至少一项(个),可以表示:a,b,c,“a和b”,“a和c”,“b和c”,或“a和b和c”,其中a,b,c可以是单个,也可以是多个。
应了解,在本公开实施例的描述中,多个(或多项)的含义是两个以上,大于、小于、超过等理解为不包括本数,以上、以下、以内等理解为包括本数。
在本公开所提供的几个实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本公开各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个取存储介质中。基于这样的理解,本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机装置(可以是个人计算机,服务器,或者网络装置等)执行本公开各个实施例方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,简称ROM)、随机存取存储器(Random Access Memory,简称RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
还应了解,本公开实施例提供的各种实施方式可以任意进行组合,以实现不同的技术效果。
以上是对本公开的实施方式的具体说明,但本公开并不局限于上述实施方式,熟悉本领域的技术人员在不违背本公开精神的条件下还可作出种种等同的变形或替换,这些等同的变形或替换均包括在本公开权利要求所限定的范围内。

Claims (11)

1.一种请求管理方法,其特征在于,所述方法包括:
获取第一请求管理时段内目标对象的数据访问请求在每一接入节点中消耗的第一请求资源量,所述接入节点为所述目标对象对应的接入节点集合中的接入节点;
获取所述目标对象在第二请求管理时段内可支配的第二请求资源量;
根据所述第一请求资源量与所述第二请求资源量,计算第二请求管理时段内每一接入节点对应的请求资源管控量;
在所述第二请求管理时段内,当检测到第一目标接入节点中所述目标对象的数据访问请求消耗的请求资源量大于对应的请求资源管控量时,禁止所述第一目标接入节点向存储节点发送所述目标对象的数据访问请求;
所述根据所述第一请求资源量与所述第二请求资源量,计算第二请求管理时段内每一接入节点对应的请求资源管控量,包括:
根据所述第一请求资源量,计算所述第一请求管理时段内消耗的请求资源在所述接入节点中的分布信息;
基于所述分布信息将所述第二请求资源量在多个所述接入节点中进行分配,得到所述第二请求管理时段内每一所述接入节点对应的第三请求资源量;
根据所述第三请求资源量计算每一所述接入节点对应的第四请求资源量,所述第四请求资源量为备用的请求资源量;
根据所述第三请求资源量与所述第四请求资源量,计算每一所述接入节点对应的请求资源管控量。
2.根据权利要求1所述的方法,其特征在于,所述根据所述第三请求资源量与所述第四请求资源量,计算每一所述接入节点对应的请求资源管控量之后,还包括:
在所述第二请求管理时段内,获取每一所述接入节点对应的多个对象使用的备用请求资源量,所述备用请求资源量为对象在所述接入节点中的数据访问请求消耗的请求资源量与对应的请求资源分配量之间的差值;
计算所述多个对象使用的所述备用请求资源量的和,得到每一接入节点对应的备用请求资源使用总量;
当第二目标接入节点对应的所述备用请求资源使用总量达到预设请求资源量阈值时,禁止所述第二目标接入节点向存储节点发送使用了备用请求资源的对象对应的数据访问请求。
3.根据权利要求1所述的方法,其特征在于,所述方法还包括:
响应于所述目标对象的目标数据访问请求,获取第三请求管理时段内所述目标数据访问请求对应的第三目标接入节点对应的第一请求资源剩余量;
当所述第一请求资源剩余量小于所述目标数据访问请求所消耗的请求资源量时,禁止所述第三目标接入节点向存储节点发送所述目标对象的数据访问请求。
4.根据权利要求3所述的方法,其特征在于,所述第三请求管理时段包括多个第二请求管理时段,所述获取第三请求管理时段内所述目标数据访问请求对应的第三目标接入节点对应的第一请求资源剩余量,包括:
获取每一第二请求管理时段内,所述目标数据访问请求对应的第三目标接入节点的请求资源管控量与请求资源消耗量;
计算每一第二请求管理时段内,所述请求资源管控量与所述请求资源消耗量之间的差值,得到多个第二请求资源剩余量;
计算所述多个第二请求资源剩余量之和,得到第三请求管理时段对应的第一请求资源剩余量。
5.根据权利要求3所述的方法,其特征在于,所述当所述第一请求资源剩余量小于所述目标数据访问请求所消耗的请求资源量时,禁止所述第三目标接入节点向存储节点发送所述目标对象的数据访问请求,包括:
当所述第一请求资源剩余量小于所述目标数据访问请求所消耗的请求资源量时,获取与所述目标对象对应的多个接入节点在所述第三请求管理时段内的请求资源剩余量之和,得到第三请求资源剩余量;
当所述第三请求资源剩余量小于所述目标数据访问请求所消耗的请求资源量时,禁止所述第三目标接入节点向存储节点发送所述目标对象的数据访问请求。
6.根据权利要求3所述的方法,其特征在于,所述响应于所述目标对象的目标数据访问请求,获取第三请求管理时段内所述目标数据访问请求对应的第三目标接入节点对应的第一请求资源剩余量之后,还包括:
当所述第一请求资源剩余量不小于所述目标数据访问请求所消耗的请求资源量时,向所述目标对象的客户端发送所述目标数据访问请求对应的处理结果;以及,
基于所述第三目标接入节点向存储节点发送所述目标对象的数据访问请求。
7.根据权利要求3所述的方法,其特征在于,所述获取第三请求管理时段内所述目标数据访问请求对应的第三目标接入节点对应的第一请求资源剩余量之前,还包括:
确定与所述目标对象对应的目标接入节点集合;
获取所述目标接入节点集合中每一接入节点接入的数据访问请求的数量;
根据所述数据访问请求的数量在所述目标接入节点集合中确定第三目标接入节点。
8.根据权利要求1所述的方法,其特征在于,所述根据所述第一请求资源量与所述第二请求资源量,计算第二请求管理时段内每一接入节点对应的请求资源管控量,包括:
根据所述第一请求资源量,计算所述第一请求管理时段内所述目标对象的数据访问请求消耗的请求资源总量;
计算所述第二请求资源量与所述请求资源总量之间的差值;
根据所述差值与所述第一请求资源量,计算第二请求管理时段内每一接入节点对应的请求资源管控量。
9.一种请求管理装置,其特征在于,所述装置包括:
第一获取单元,用于获取第一请求管理时段内目标对象的数据访问请求在每一接入节点中消耗的第一请求资源量,所述接入节点为所述目标对象对应的接入节点集合中的接入节点;
第二获取单元,用于获取所述目标对象在第二请求管理时段内可支配的第二请求资源量;
计算单元,用于根据所述第一请求资源量与所述第二请求资源量计算第二请求管理时段内每一接入节点对应的请求资源管控量;
控制单元,用于在所述第二请求管理时段内,当检测到第一目标接入节点中所述目标对象的数据访问请求消耗的请求资源量大于对应的请求资源管控量时,禁止所述第一目标接入节点向存储节点发送所述目标对象的数据访问请求;
所述根据所述第一请求资源量与所述第二请求资源量,计算第二请求管理时段内每一接入节点对应的请求资源管控量,包括:
根据所述第一请求资源量,计算所述第一请求管理时段内消耗的请求资源在所述接入节点中的分布信息;
基于所述分布信息将所述第二请求资源量在多个所述接入节点中进行分配,得到所述第二请求管理时段内每一所述接入节点对应的第三请求资源量;
根据所述第三请求资源量计算每一所述接入节点对应的第四请求资源量,所述第四请求资源量为备用的请求资源量;
根据所述第三请求资源量与所述第四请求资源量,计算每一所述接入节点对应的请求资源管控量。
10.一种存储介质,所述存储介质存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现根据权利要求1至8任意一项所述的请求管理方法。
11.一种计算机设备,包括存储器和处理器,所述存储器存储有计算机程序,其特征在于,所述处理器执行所述计算机程序时实现根据权利要求1至8任意一项所述的请求管理方法。
CN202311223206.6A 2023-09-21 2023-09-21 请求管理方法、装置、计算机可读存储介质及计算机设备 Active CN117076157B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311223206.6A CN117076157B (zh) 2023-09-21 2023-09-21 请求管理方法、装置、计算机可读存储介质及计算机设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311223206.6A CN117076157B (zh) 2023-09-21 2023-09-21 请求管理方法、装置、计算机可读存储介质及计算机设备

Publications (2)

Publication Number Publication Date
CN117076157A CN117076157A (zh) 2023-11-17
CN117076157B true CN117076157B (zh) 2024-01-12

Family

ID=88706143

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311223206.6A Active CN117076157B (zh) 2023-09-21 2023-09-21 请求管理方法、装置、计算机可读存储介质及计算机设备

Country Status (1)

Country Link
CN (1) CN117076157B (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111625859A (zh) * 2020-05-20 2020-09-04 北京百度网讯科技有限公司 一种资源的访问控制方法、装置、电子设备和存储介质
CN111786895A (zh) * 2020-03-16 2020-10-16 北京京东尚科信息技术有限公司 动态全局限流的方法和装置
CN112685169A (zh) * 2019-10-17 2021-04-20 腾讯科技(深圳)有限公司 一种负载控制方法、装置、服务器及可读存储介质
CN112887407A (zh) * 2021-01-26 2021-06-01 北京百度网讯科技有限公司 用于分布式集群的作业流量控制方法和装置
EP3905050A1 (en) * 2020-04-28 2021-11-03 Accenture Global Solutions Limited Prescriptive analytics based nosql database service optimization system for cloud computing
CN116192752A (zh) * 2023-02-27 2023-05-30 中国工商银行股份有限公司 业务流量控制方法、装置、电子设备及存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112685169A (zh) * 2019-10-17 2021-04-20 腾讯科技(深圳)有限公司 一种负载控制方法、装置、服务器及可读存储介质
CN111786895A (zh) * 2020-03-16 2020-10-16 北京京东尚科信息技术有限公司 动态全局限流的方法和装置
EP3905050A1 (en) * 2020-04-28 2021-11-03 Accenture Global Solutions Limited Prescriptive analytics based nosql database service optimization system for cloud computing
CN111625859A (zh) * 2020-05-20 2020-09-04 北京百度网讯科技有限公司 一种资源的访问控制方法、装置、电子设备和存储介质
CN112887407A (zh) * 2021-01-26 2021-06-01 北京百度网讯科技有限公司 用于分布式集群的作业流量控制方法和装置
CN116192752A (zh) * 2023-02-27 2023-05-30 中国工商银行股份有限公司 业务流量控制方法、装置、电子设备及存储介质

Also Published As

Publication number Publication date
CN117076157A (zh) 2023-11-17

Similar Documents

Publication Publication Date Title
CN102495857B (zh) 一种分布式数据库的负载均衡方法
CN102014169B (zh) 分布式服务系统、分布式服务系统的任务执行方法和装置
CN107430528B (zh) 机会性资源迁移以优化资源放置
CN100476742C (zh) 基于对象存储设备的负载平衡方法
US8751657B2 (en) Multi-client storage system and storage system management method
CN106802932B (zh) 一种数据库的路由方法、装置及数据库系统
US8060610B1 (en) Multiple server workload management using instant capacity processors
CN108900626B (zh) 一种云环境下数据存储方法、装置及系统
CN101226542B (zh) 一种报表缓存的方法
KR20170097132A (ko) 데이터베이스에서의 계좌와 관련된 거래 요청의 효율적인 처리를 위한 시스템
US10379834B2 (en) Tenant allocation in multi-tenant software applications
CN110636388A (zh) 一种业务请求分配方法、系统、电子设备及存储介质
US10616134B1 (en) Prioritizing resource hosts for resource placement
US11681447B2 (en) Method, device and computer program product of balance of storage space for file system
CN111737168A (zh) 一种缓存系统、缓存处理方法、装置、设备及介质
CN108874502A (zh) 云计算集群的资源管理方法、装置及设备
US20140351294A1 (en) Storage control device and storage control method
CN117076157B (zh) 请求管理方法、装置、计算机可读存储介质及计算机设备
CN115002187B (zh) 绑定关系处理方法及相关设备
CN110874344B (zh) 数据迁移方法、装置及电子设备
CN102542040B (zh) 分布式文件系统中的容量获取方法及容量获取系统
WO2019196595A1 (zh) 管理应用程序的方法与装置
CN108243228B (zh) 用于数据调度的方法和智能伺服集群
CN113297232B (zh) 一种基于数据库分区的数据更新方法、装置及系统
CN117891618B (zh) 人工智能模型训练平台的资源任务处理方法及装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant