Resource management method and apparatus, distributed cache system

Abstract

Embodiments of the present specification provide resource management methods and devices, and a distributed cache system. The resource management method is applied to the distributed cache system, and includes: obtaining registration information of a cache node, and constructing a first virtual node having a cache resource alignment relationship with the cache node according to the registration information; adding the first virtual node to a virtual node queue, and establishing a first mapping relationship between the first virtual node and the cache node; in response to a resource management request, screening a target first virtual node in the virtual node queue, establishing a second mapping relationship between the target first virtual node and a second virtual node, and a quota mapping relationship between the target first virtual node and a quota group corresponding to the resource management request; and storing the first mapping relationship, the second mapping relationship, and the quota mapping relationship to a distributed hash table, for allocating cache resources for a client corresponding to the resource management request.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of resource management technology, and in particular to resource management methods and apparatus, and distributed caching systems. Background Technology

[0002] With the development of computer and internet technologies, cloud computing services are being applied in an increasing number of scenarios. In cloud computing scenarios, data for some computing tasks is often stored in completely heterogeneous storage. Due to limitations such as bandwidth and network latency, accessing data in heterogeneous storage is usually costly. This problem can be addressed by using a distributed caching system. By caching frequently accessed hot data on various nodes of the corresponding cluster of the distributed caching system, the access speed of this hot data can be significantly improved. In existing technologies, distributed caching systems use distributed hash tables to record the mapping relationship between quota groups and cache nodes, so that cache requests can be directly initiated to the cache node when the cache node address is obtained. However, since the resources of cache nodes are limited, when there are no free cache resources, the cache node will follow a specified eviction policy to migrate old data with low expected access out of the cache, thereby reserving more space for new data. However, when there are multiple tenants in the system, this operation inevitably leads to resource congestion, resulting in insufficient guarantee of cache resources requested by tenants. Therefore, an effective solution is urgently needed to solve the above problems. Summary of the Invention

[0003] In view of this, embodiments of this specification provide a resource management method. One or more embodiments of this specification also relate to resource management devices, distributed caching systems, a computing device, a computer-readable storage medium, and a computer program product, to address technical deficiencies in the prior art.

[0004] According to a first aspect of the embodiments of this specification, a resource management method is provided, applied to a distributed caching system, comprising:

[0005] Obtain the registration information of the cache node, and construct a first-level virtual node with cache resource alignment relationship with the cache node based on the registration information;

[0006] Add the first-level virtual node to the virtual node queue, and establish a first-level mapping relationship between the first-level virtual node and the cache node;

[0007] In response to a resource management request, a target primary virtual node is selected from the virtual node queue, a secondary mapping relationship is established between the target primary virtual node and the secondary virtual node, and a quota mapping relationship is established between the target primary virtual node and the quota group corresponding to the resource management request.

[0008] The first-level mapping relationship, the second-level mapping relationship, and the quota mapping relationship are stored in a distributed hash table for allocating cache resources to the client corresponding to the resource management request.

[0009] According to a second aspect of the embodiments of this specification, another resource management method is provided, including:

[0010] In response to a cache request submitted by a client, a distributed hash table is queried, and the quota group field corresponding to the client is determined based on the query result;

[0011] The target secondary mapping relationship is read from the distributed hash table according to the quota group field, and the primary virtual node to be used is determined based on the target secondary mapping relationship;

[0012] The first-level virtual node to be used is read from the distributed hash table to determine the first-level mapping relationship, and the target cache node is determined based on the first-level mapping relationship.

[0013] The cache request is submitted to the target cache node, which allocates cache resources to the client to execute the target task corresponding to the cache request. The mapping relationship stored in the distributed hash table is constructed using the above method.

[0014] According to a third aspect of the embodiments of this specification, a distributed caching system is provided, including a management node, a cache node, and a client, comprising:

[0015] The management node is configured to: acquire the registration information of the cache node; construct a first-level virtual node with cache resource alignment with the cache node based on the registration information; add the first-level virtual node to the virtual node queue; and establish a first-level mapping relationship between the first-level virtual node and the cache node; in response to a resource management request, filter target first-level virtual nodes in the virtual node queue; establish a second-level mapping relationship between the target first-level virtual node and the second-level virtual node; and establish a quota mapping relationship between the target first-level virtual node and the quota group corresponding to the resource management request; and store the first-level mapping relationship, the second-level mapping relationship, and the quota mapping relationship in a distributed hash table.

[0016] The client is used to submit a cache request to the management node;

[0017] The management node is used to query the distributed hash table in response to the cache request, determine the target cache node based on the query result, and submit the cache request to the target cache node for allocating cache resources to the client to execute the target task corresponding to the cache request.

[0018] According to a fourth aspect of the embodiments of this specification, a resource management apparatus is provided, applied to a distributed caching system, comprising:

[0019] The acquisition module is configured to acquire the registration information of the cache node and construct a first-level virtual node with cache resource alignment relationship with the cache node based on the registration information;

[0020] The add module is configured to add the first-level virtual node to the virtual node queue and establish a first-level mapping relationship between the first-level virtual node and the cache node;

[0021] The filtering module is configured to filter target primary virtual nodes in the virtual node queue in response to a resource management request, establish a secondary mapping relationship between the target primary virtual nodes and secondary virtual nodes, and a quota mapping relationship between the target primary virtual nodes and the quota group corresponding to the resource management request.

[0022] The storage module is configured to store the first-level mapping relationship, the second-level mapping relationship, and the quota mapping relationship in a distributed hash table, which is used to allocate cache resources to the client corresponding to the resource management request.

[0023] According to a fifth aspect of the embodiments of this specification, another resource management apparatus is provided, comprising:

[0024] The query module is configured to query the distributed hash table in response to a cache request submitted by the client, and determine the quota group field corresponding to the client based on the query result;

[0025] The reading module is configured to read the target secondary mapping relationship in the distributed hash table according to the quota group field, and determine the primary virtual node to be used based on the target secondary mapping relationship;

[0026] The determination module is configured to read the first-level mapping relationship to be used in the distributed hash table based on the first-level virtual node to be used, and determine the target cache node based on the first-level mapping relationship to be used;

[0027] The submission module is configured to submit the cache request to the target cache node, and is used to allocate cache resources to the client to execute the target task corresponding to the cache request. The mapping relationship stored in the distributed hash table is constructed using the above method.

[0028] According to a sixth aspect of the embodiments of this specification, a computing device is provided, comprising:

[0029] Memory and processor;

[0030] The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the resource management method described above.

[0031] According to a seventh aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer-executable instructions that, when executed by a processor, implement the steps of the resource management method described above.

[0032] According to an eighth aspect of the embodiments of this specification, a computer program product is provided, including a computer program or instructions that, when executed by a processor, implement the steps of the resource management method described above.

[0033] The resource management method adopted in this embodiment aims to make multi-tenant cache resource quotas more efficient and reliable. It transforms tenant quota management into the management of virtual node mapping relationships by constructing a multi-layered mapping relationship, thereby flexibly utilizing various strategies to ensure system reliability. Specifically, after obtaining the registration information of cache nodes, a first-level virtual node with cache resource alignment is constructed based on the registration information. This first-level virtual node is then added to the virtual node queue, and a first-level mapping relationship is established between the first-level virtual node and the cache node. Furthermore, in response to resource management requests, target first-level virtual nodes are selected from the virtual node queue, establishing a second-level mapping relationship between the target first-level virtual node and second-level virtual nodes, as well as a quota mapping relationship between the target first-level virtual node and the quota group corresponding to the resource management request. This multi-layered mapping relationship manages the quota status of each tenant while avoiding cache resource usage squeeze issues. Finally, the first-level mapping relationship, second-level mapping relationship, and quota mapping relationship are stored in a distributed hash table for allocating cache resources to the client corresponding to the resource management request. A distributed caching system can flexibly and accurately allocate and manage cache resources. By combining a distributed hash table to store multi-layer mapping relationships, it can achieve multi-tenant isolation at the logical level in an efficient way. This ensures that each tenant can use cache resources within its corresponding quota during the application phase, thereby solving the problem of tenants squeezing each other's cache space. Attached Figure Description

[0034] Figure 1 This is a flowchart illustrating a resource management method provided in one embodiment of this specification;

[0035] Figure 2 This is a schematic diagram illustrating the mapping relationship between nodes in a resource management method provided in one embodiment of this specification;

[0036] Figure 3This is a flowchart of another resource management method provided in one embodiment of this specification;

[0037] Figure 4 This is a schematic diagram of the structure of a distributed caching system provided in one embodiment of this specification;

[0038] Figure 5 This is a flowchart illustrating the processing procedure of a resource management method provided in one embodiment of this specification;

[0039] Figure 6 This is a schematic diagram of the structure of a resource management device provided in one embodiment of this specification;

[0040] Figure 7 This is a schematic diagram of the structure of a resource management device provided in one embodiment of this specification;

[0041] Figure 8 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0042] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0043] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0044] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0045] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0046] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0047] Key-value distributed caching system: Stores accessed data in key-value pairs across multiple nodes in the cluster, improving data access efficiency.

[0048] Multi-tenant quota management: The system allocates and manages independent cache quotas for each tenant, ensuring that each tenant's cache usage does not affect other tenants.

[0049] DHT (Distributed Hash Table): A distributed hash table used to describe the mapping relationship between data and target nodes.

[0050] Decentralization: The ability to coordinate a system without relying on a single central node.

[0051] This specification provides a resource management method. One or more embodiments of this specification also relate to a resource management device, a distributed caching system, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0052] In practical applications, the working principle of a key-value distributed caching system generally adopts a master / slave architecture, consisting of a master and workers distributed across various machines in the cluster. The master is responsible for managing all workers in the cluster, collecting their working status in real time through a heartbeat mechanism; the workers are actually responsible for managing user cached data, including responding to user read and write requests, data persistence, and data recycling. The underlying logic of this system is a DHT (Distributed Hash Table), which records the mapping relationship between virtual nodes and workers. The master is responsible for updating and maintaining the DHT, and processes such as machine scaling are reflected in the DHT.

[0053] In existing technologies, the basic workflow of a distributed caching system is as follows: after the cache key is hashed, the address of the corresponding CacheWorker (cache node) is obtained according to the mapping relationship described in the DHT (Distributed Hash Table), and a cache request is sent to that CacheWorker. Since cache capacity is limited, when there is no free cache space, the CacheWorker will follow a specified eviction policy to remove older data with low expected access from the cache, freeing up enough space for new data. When there are multiple tenants in the system, mutual crowding inevitably occurs, resulting in insufficient guarantee of the cache capacity requested by each tenant. Therefore, an effective solution is urgently needed to address these issues.

[0054] The resource management method adopted in this embodiment aims to make multi-tenant cache resource quotas more efficient and reliable. It transforms tenant quota management into the management of virtual node mapping relationships by constructing a multi-layered mapping relationship, thereby flexibly utilizing various strategies to ensure system reliability. Specifically, after obtaining the registration information of cache nodes, a first-level virtual node with cache resource alignment is constructed based on the registration information. This first-level virtual node is then added to the virtual node queue, and a first-level mapping relationship is established between the first-level virtual node and the cache node. Furthermore, in response to resource management requests, target first-level virtual nodes are selected from the virtual node queue, establishing a second-level mapping relationship between the target first-level virtual node and second-level virtual nodes, as well as a quota mapping relationship between the target first-level virtual node and the quota group corresponding to the resource management request. This multi-layered mapping relationship manages the quota status of each tenant while avoiding cache resource usage squeeze issues. Finally, the first-level mapping relationship, second-level mapping relationship, and quota mapping relationship are stored in a distributed hash table for allocating cache resources to the client corresponding to the resource management request. A distributed caching system can flexibly and accurately allocate and manage cache resources. By combining a distributed hash table to store multi-layer mapping relationships, it can achieve multi-tenant isolation at the logical level in an efficient way. This ensures that each tenant can use cache resources within its corresponding quota during the application phase, thereby solving the problem of tenants squeezing each other's cache space.

[0055] See Figure 1 , Figure 1 A flowchart of a resource management method according to an embodiment of this specification is shown, applied to a distributed caching system, specifically including the following steps.

[0056] Step S102: Obtain the registration information of the cache node, and construct a first-level virtual node with cache resource alignment relationship with the cache node based on the registration information.

[0057] The resource management method provided in this embodiment is applied to a key-value distributed caching system. It maps the system's cache resources to several virtual nodes with fixed quotas. With the help of a distributed hash table (DHT), a multi-layer mapping structure is constructed to transform quota management for tenants into mapping management for virtual nodes, making the architecture simple and efficient. At the same time, based on the characteristics of DHT and the mapping structure, various strategies can be flexibly used to ensure the reliability of the system.

[0058] Specifically, a distributed caching system refers to a system composed of cache nodes providing different cache resources and a management phase. This system provides cache resources to tenants, enabling heterogeneous data to be pre-loaded into the cache, thereby improving data processing efficiency. Correspondingly, a cache node refers to the worker node corresponding to a device connected to the distributed caching system that provides cache resources; different cache nodes can provide different sizes of cache space. Registration information refers to the information submitted by a cache node when connecting to the distributed caching system. This information records the cache space size corresponding to the cache node, facilitating the subsequent allocation of virtual nodes to complete the mapping relationship. A first-level virtual node refers to a virtual node with a cache resource alignment relationship with a cache node. It can be represented by a Qnode and is used to change the direct mapping relationship between cache nodes and quota groups to one through virtual nodes, thus effectively isolating the cache resources of each tenant. Specifically, the cache resource alignment relationship means that the total cache space corresponding to the number of first-level virtual nodes created is the same as the cache space size provided by the cache node.

[0059] Therefore, to achieve more efficient and reliable caching resource quota management for multi-tenants, a multi-layered mapping system can be constructed. This transforms tenant quota management into the management of virtual node mapping relationships, allowing for flexible use of various strategies to ensure system reliability. Specifically, after obtaining the registration information of cache nodes, a first-level virtual node with cache resource alignment is constructed based on this information. This first-level virtual node is then added to the virtual node queue, establishing a first-level mapping between it and the cache node. Furthermore, in response to resource management requests, target first-level virtual nodes are selected from the virtual node queue, establishing a second-level mapping between these nodes and second-level virtual nodes, as well as a quota mapping between the target first-level virtual node and the quota group corresponding to the resource management request. This multi-layered mapping system manages each tenant's quota while avoiding cache resource overload. Finally, the first-level, second-level, and quota mapping relationships are stored in a distributed hash table for allocating cache resources to clients corresponding to resource management requests. A distributed caching system can flexibly and accurately allocate and manage cache resources. By combining a distributed hash table to store multi-layer mapping relationships, it can achieve multi-tenant isolation at the logical level in an efficient way. This ensures that each tenant can use cache resources within its corresponding quota during the application phase, thereby solving the problem of tenants squeezing each other's cache space.

[0060] Furthermore, when constructing the first-level virtual node corresponding to the cache node, in order to ensure that subsequent processing can fully utilize the cache resources provided by the cache node, the construction of the first-level virtual node can be completed according to the set cache resource allocation rules. In this embodiment, the specific implementation method is as follows:

[0061] Obtain the registration information of the cache nodes and determine the cache resource allocation rules of the distributed caching system; calculate the number of nodes to be allocated based on the registration information and the cache resource allocation rules; construct a first-level virtual node with cache resource alignment relationship with the cache node according to the number of nodes to be allocated.

[0062] Specifically, the cache resource allocation rule refers to the rules set for building first-level virtual nodes. This rule controls the cache space size corresponding to each first-level virtual node, as well as the number of first-level virtual nodes that need to be allocated for each cache node. Correspondingly, the node allocation number specifically refers to the number of first-level virtual nodes built for each cache node.

[0063] Based on this, in order to ensure that the first-level virtual nodes cover all the cache resources of the cache nodes, after obtaining the registration information of the cache nodes, the cache resource allocation rules of the distributed caching system can be determined first. At this time, the number of nodes to be allocated can be calculated based on the registration information and the cache resource allocation rules. Thus, it is possible to build first-level virtual nodes with cache resource alignment with the cache nodes according to the number of nodes allocated, so that they can be used later.

[0064] In other words, during the initialization phase of a distributed caching system, the management node Master can map the cache space size of the cache node Worker to a series of first-level virtual nodes Qnodes with the same quota size based on the information reported by the cache node Worker during registration. This allows for the allocation of cache resource quotas for different tenants by establishing continuous mapping relationships, thereby achieving the purpose of cache resource isolation.

[0065] For example, see Figure 2 The diagram shows a distributed caching system connected to three machines, corresponding to cache nodes Worker0, Worker1, and Worker2, each providing 300GB of cache space. Based on this, the distributed caching system allocates 100GB of cache space to each virtual node. Therefore, according to this configuration, a total of nine virtual nodes (Qnodes) can be constructed for Worker0, Worker1, and Worker2, namely Qnode0 to Qnode8. Specifically, Worker0 corresponds to Qnode0, Qnode1, and Qnode2; Worker1 corresponds to Qnode3, Qnode4, and Qnode5; and Worker2 corresponds to Qnode6, Qnode7, and Qnode8. Subsequent mapping relationships can be constructed based on this allocation.

[0066] In summary, by constructing a number of first-level virtual nodes that match the number of cache nodes according to the cache resource allocation rules, it can be ensured that all cache resources of the cache nodes can be used, thereby effectively improving resource utilization.

[0067] Step S104: Add the first-level virtual node to the virtual node queue and establish a first-level mapping relationship between the first-level virtual node and the cache node.

[0068] Specifically, after constructing the first-level virtual node for the cache node, considering that the cache resources corresponding to the cache node will be in a pending state before the quota is allocated, the first-level virtual node corresponding to the cache node will also be in a pending state. Therefore, the first-level virtual node can be added to the virtual node queue first, and a first-level mapping relationship between the first-level virtual node and the cache node can be established so that the target first-level virtual node can be read from the virtual node list and the quota operation can be completed by combining the first-level mapping relationship when allocating quotas.

[0069] Specifically, the virtual node queue refers to a queue that records each unassigned first-level virtual node, following a first-in-first-out (FIFO) rule. Correspondingly, the first-level mapping relationship refers to the mapping relationship established between first-level virtual nodes and cache nodes, used to characterize their matching relationship for subsequent use.

[0070] Furthermore, when constructing the mapping relationship, in order to ensure that the mapping relationship can be recorded in the distributed hash table, node identifiers can be used to complete the construction of the mapping relationship. In this embodiment, the specific implementation method is as follows:

[0071] The first-level node identifier of the first-level virtual node and the cache node identifier of the cache node are determined, and a first-level mapping relationship is constructed based on the first-level node identifier and the cache node identifier. Specifically, the cache node identifier refers to the unique identifier corresponding to the cache node, and the first-level node identifier refers to the unique identifier corresponding to the first-level virtual node.

[0072] Following the previous example, after obtaining the allocation relationship between cache nodes and virtual nodes, a mapping relationship between them can be established by combining the identifiers corresponding to the cache nodes and virtual nodes respectively. At this point, the Master node, the management node of the distributed caching system, will record the following first-level mapping relationship between cache nodes and virtual nodes: {<Qnode0,Worker0><Qnode1,Worker0><Qnode2,Worker0>}、{<Qnode3,Worker1><Qnode4,Worker1><Qnode5,Worker1>}and{<Qnode6,Worker2><Qnode7,Worker2><Qnode8,Worker2> This mapping is used to complete the quota allocation later.

[0073] Step S106: In response to the resource management request, select target primary virtual nodes in the virtual node queue, establish a secondary mapping relationship between the target primary virtual nodes and secondary virtual nodes, and a quota mapping relationship between the target primary virtual nodes and the quota group corresponding to the resource management request.

[0074] Specifically, upon receiving a resource management request submitted to the distributed caching system, it indicates that a cache resource allocation operation for the quota group needs to be completed in response to the resource management request. At this point, the system can first filter the target primary virtual node in the virtual node queue to determine the primary virtual node matching the quota group. Then, a secondary mapping relationship can be established between the target primary virtual node and the secondary virtual node, as well as a quota mapping relationship between the target primary virtual node and the quota group corresponding to the resource management request. This mapping relationship is then recorded in a distributed hash table. When a tenant corresponding to a quota group uses cache resources, the cache node is determined according to the mapping relationship recorded in the distributed hash table. This allows cache requests to be submitted to the cache node for loading heterogeneous storage data, thereby improving data processing efficiency while avoiding cache resource crowding caused by multiple tenants using cache resources simultaneously.

[0075] Specifically, a resource management request refers to a request triggered or submitted when cache resources need to be allocated to a tenant. This request records quota group information and the required cache resource size. Correspondingly, the target primary virtual node refers to a primary virtual node extracted from the virtual node queue that meets the resource management request's requirements. A secondary virtual node refers to a smaller-granularity virtual node, which can be understood as the basic unit of cache resource management, ensuring that tenants' cache resource usage needs can be flexibly met in a distributed architecture. A quota group refers to one or more tenants that currently need to be allocated cache resources. The secondary mapping relationship refers to the matching relationship established between primary and secondary virtual nodes, and the quota mapping relationship refers to the mapping relationship established between primary virtual nodes and quota groups.

[0076] Furthermore, the step of responding to a resource management request by filtering target primary virtual nodes in the virtual node queue, establishing a two-level mapping relationship between the target primary virtual nodes and secondary virtual nodes, and a quota mapping relationship between the target primary virtual nodes and the quota group corresponding to the resource management request, includes:

[0077] In response to a resource management request, quota information is determined. At least one primary virtual node matching the quota information is selected as a target primary virtual node from the virtual node queue. Secondary virtual nodes are filtered in the virtual node cluster of the distributed caching system according to the quota information, and the quota group corresponding to the resource management request is determined, wherein the number of secondary virtual nodes is greater than the number of target primary virtual nodes. Based on the target primary virtual nodes, the secondary virtual nodes, and the quota group, the steps of establishing a secondary mapping relationship between the target primary virtual nodes and the secondary virtual nodes, and a quota mapping relationship between the target primary virtual nodes and the quota group corresponding to the resource management request are performed.

[0078] The step of establishing a secondary mapping relationship between the target primary virtual node and the secondary virtual node includes: determining the target primary node identifier of the target primary virtual node and the secondary node identifier of the secondary virtual node, and constructing a secondary mapping relationship based on the target primary node identifier and the secondary node identifier; the step of establishing a quota mapping relationship between the target primary virtual node and the quota group corresponding to the resource management request includes: determining the quota group identifier of the quota group corresponding to the resource management request, and constructing a quota mapping relationship based on the target primary node identifier and the quota group identifier.

[0079] Specifically, quota information refers to the size of cached resources requested by the resource management request. Virtual node cluster refers to a cluster that records all secondary virtual nodes. Correspondingly, the target primary node identifier is the unique identifier corresponding to the target primary virtual node; the secondary node identifier is the unique identifier corresponding to the secondary virtual node; and the quota group identifier is the unique identifier corresponding to the quota group.

[0080] Based on this, when a resource management request is received for the distributed caching system, it indicates that cache resources need to be requested from tenants in the quota group. To ensure reasonable resource allocation, the quota information can be determined in response to the resource management request. The required cache resource size can be determined based on the quota information. Since the cache resource size corresponding to each primary virtual node is fixed, at least one primary virtual node matching the quota information can be selected as the target primary virtual node from the virtual node queue. On this basis, secondary virtual nodes can be selected from the virtual node cluster of the distributed caching system according to the quota information, and the quota group corresponding to the resource management request can be determined. The number of secondary virtual nodes is greater than the number of target primary virtual nodes.

[0081] Furthermore, the target first-level node identifier of the target first-level virtual node and the second-level node identifier of the second-level virtual node can be determined. At this time, a second-level mapping relationship can be constructed based on the target first-level node identifier and the second-level node identifier. Similarly, the quota group identifier corresponding to the quota group of the resource management request can also be determined. At this time, a quota mapping relationship can be constructed based on the target first-level node identifier and the quota group identifier, so that the quota operation can be completed in combination with the above mapping relationship.

[0082] In practical applications, when a request to create a QuotaGroup is received, the management node Master can randomly select the corresponding quota of Qnodes from the virtual node queue and allocate them to the QuotaGroup, while also maintaining...<QuotaGroup,Qnode> The mapping relationship. Furthermore, to construct a complete mapping chain, the Master node also needs to build...<Vnode,Qnode> The mapping relationship evenly distributes a preset number of Vnodes (such as the default 1 million) to all Qnodes within the QuotaGroup, facilitating appropriate combinations. In practice, because the number of Vnodes is large enough, the requests from the QuotaGroup can be evenly distributed across the Qnodes, thereby reducing the risk of single points of failure.

[0083] It's important to note that introducing secondary virtual nodes on top of the primary virtual nodes stabilizes the relationship between cache nodes and quota groups, aiming to maintain the stability of hash mapping. This can be understood as follows: if only a mapping relationship is established between virtual nodes (Qnodes) and cache nodes (Workers), to achieve tenant quota management, each Qnode needs to have a quota attribute, such as each Qnode corresponding to a 1GB cache quota. Therefore, the total number of Qnodes will inevitably change with the cluster capacity, leading to an unstable mapping relationship. Taking modulo operation as the hash mapping algorithm as an example, 10 machines correspond to x%10, and 11 machines correspond to x%11. If putting the cache occurs on 10 machines, it maps to virtual node Qnode2; if getting the cache occurs on 11 machines, it maps to virtual node Qnode1. However, virtual nodes Qnode1 and Qnode2 happen to be on different machines, resulting in a cache not being found. Therefore, to solve this problem, this embodiment introduces secondary virtual nodes (Vnodes), with the number of Vnodes far exceeding the number of machines, to ensure the stability of hash mapping.

[0084] Furthermore, the primary purpose of building virtual nodes (Qnodes) is to achieve flexible multi-tenant quota management. The virtual node (Qnode) layer can essentially be understood as a more fine-grained cache node (Worker). If virtual nodes (Vnodes) are directly mapped to cache nodes (Workers), the capacity allocation unit is too heavy, inflexible, and uneven, making it more prone to hotspot issues.

[0085] Continuing with the previous example, after completing the first-level mapping, if it is determined from the received resource management request that QuotaGroupA has requested a quota of 200GB, then the distributed caching system can allocate two virtual nodes (Qnodes) to QuotaGroupA. Therefore, Qnode1 and Qnode5, which are in an unallocated state, can be selected from the virtual node queue and allocated to QuotaGroupA. Simultaneously, the distributed caching system contains n virtual nodes (Vnodes), which can then be evenly distributed among virtual nodes Qnode1 and Qnode5. Based on the allocation results, a mapping can be constructed as follows: Figure 3 The mapping relationships shown are, respectively, second-level mapping relationships {<A,Qnode1><A,Qnode5>}, quota mapping relationship {<Vnode0,Qnode1><Vnode2,Qnode1> …}{<Vnode1,Qnode5><Vnode3,Qnode5> …} After obtaining the above mapping relationship, it can be stored in a distributed hash table so that when tenants in the quota group use cache resources, they can complete the process according to the above mapping relationship.

[0086] In summary, by constructing the mapping relationship using the above method, not only can the orderliness of the mapping relationship be guaranteed, but it can also support the rapid reuse of cache resources, thereby effectively improving the cache resource management efficiency of the distributed caching system.

[0087] Step S108: Store the first-level mapping relationship, the second-level mapping relationship, and the quota mapping relationship in a distributed hash table for allocating cache resources to the client corresponding to the resource management request.

[0088] Specifically, after constructing the first-level mapping relationship, the second-level mapping relationship, and the quota mapping relationship, these relationships can be stored in a distributed hash table. This table is used to allocate cache resources to the client corresponding to the resource management request, so that the client can load heterogeneous data and improve data processing efficiency.

[0089] Furthermore, considering that the first-level mapping relationship includes all mapping relationships between cache nodes and first-level virtual nodes, and resource management requests may only use some first-level virtual nodes, the target first-level mapping relationship can be filtered out from the first-level mapping relationship and stored in a distributed hash table for subsequent use. In this embodiment, the specific implementation is as follows:

[0090] Extract the target first-level mapping relationship corresponding to the target first-level virtual node from the first-level mapping relationship; construct the relationship link between the target first-level mapping relationship, the second-level mapping relationship and the quota mapping relationship; and store the target first-level mapping relationship, the second-level mapping relationship and the quota mapping relationship into a distributed hash table based on the relationship link.

[0091] Specifically, the target-level mapping relationship refers to the first-level mapping relationship between the target-level virtual nodes and the cache nodes. Correspondingly, the relationship link refers to the link that reflects the association between the three mapping relationships, ensuring that the data stored in the distributed hash table can be reused during the usage phase.

[0092] Based on this, after obtaining the first-level mapping relationship, the second-level mapping relationship, and the quota group mapping relationship, the target first-level mapping relationship corresponding to the target first-level virtual node can be extracted from the first-level mapping relationship. At this time, the relationship link between the target first-level mapping relationship, the second-level mapping relationship, and the quota mapping relationship can be constructed. This enables the three mapping relationships to be related, and then the target first-level mapping relationship, the second-level mapping relationship, and the quota mapping relationship can be stored in a distributed hash table based on the relationship link for subsequent use in allocating cache resources to the client corresponding to the resource management request.

[0093] In practical applications, the first-level mapping relationship, second-level mapping relationship, and quota group mapping relationship constructed above can represent the indirect mapping between quota group and cache node. Therefore, a complete mapping link can be constructed through the above mapping relationship, namely cache key → Vnode → Qnode → Worker. The mapping from cache key to Vnode can be completed by simple hash operation.

[0094] Following the previous example, after obtaining the first-level mapping relationship between cache node Worker0 and virtual node Qnode, the quota mapping relationship between quota group and virtual node Qnode, and the second-level mapping relationship between virtual node Qnode and virtual node Vnode, the above mapping relationship can be stored in the distributed hash table DHT of the distributed caching system through the management node Master. This allows the application to read the mapping relationship from the table and send the request to the corresponding cache node to complete the data processing operation.

[0095] In summary, by selecting target-level mapping relationships and storing them in a distributed hash table, the mapping relationships of associated quota groups can be recorded, thereby supporting reuse during the application phase and improving resource management efficiency.

[0096] Furthermore, when expanding cache resources in a distributed caching system, the mapping relationship of the distributed hash table needs to be updated based on the expansion result. In this embodiment, the specific implementation is as follows:

[0097] Upon receiving a resource expansion request, the system determines the expansion cache node and obtains its expansion registration information. It then designates the expansion cache node as the cache node and the expansion registration information as the registration information, and executes a step of constructing a first-level virtual node with cache resource alignment with the cache node based on the registration information. If the expansion first-level mapping relationship corresponding to the expansion cache node is obtained, the system updates the first-level mapping relationship stored in the distributed hash table based on the expansion first-level mapping relationship.

[0098] Specifically, a resource expansion request refers to a request submitted to the distributed caching system to expand cache resources. This request indicates that the distributed caching system will connect new cache nodes, i.e., expand the cache nodes. Correspondingly, the expansion registration information is the registration information corresponding to the expand cache nodes. Furthermore, the expansion first-level mapping relationship specifically refers to the first-level mapping relationship established between the expand cache nodes and the first-level virtual nodes constructed for them.

[0099] Based on this, upon receiving a resource expansion request, it indicates that a new cache node has been connected to the distributed caching system. Therefore, the expansion cache node can be identified first, and its expansion registration information can be obtained. Subsequently, the expansion cache node can be used as the cache node, and the expansion registration information can be used as the registration information. The step of constructing a first-level virtual node with cache resource alignment with the cache node based on the registration information can be executed. After establishing the expansion first-level mapping relationship between the expansion cache node and the constructed first-level virtual node, in order to enable the cache node to be used later, the first-level mapping relationship stored in the distributed hash table can be updated according to the expansion first-level mapping relationship to insert the expansion first-level mapping relationship for subsequent use.

[0100] For example, when a new cache node Worker with 100GB of cache space is added to a distributed caching system, a virtual node Qnode can be built for this cache node Worker. This virtual node Qnode corresponds to 100GB. Then, a mapping relationship between the cache node Worker and the virtual node Qnode can be established, and the mapping relationship between Worker and Qnode already stored in the distributed hash table DHT can be updated. This ensures that the existing quota in the system will not be affected, thereby providing a stable cache resource usage service.

[0101] In summary, for cache resource expansion scenarios, updating the first-level mapping relationship allows the distributed cache system to understand the status of idle resources, thus facilitating the direct selection and use of resources when there are resource management requests, thereby reducing the waiting time for temporary construction.

[0102] When scaling down cache resources, a compensation strategy can be used to reduce the magnitude of mapping updates. However, for cases where compensation is not possible, updates to the mapping relationships involved in certain links are required. In this embodiment, the specific implementation is as follows:

[0103] Upon receiving a resource scaling-down request, determine the scaling-down cache resource corresponding to the scaling-down cache node; check whether there is a first-level virtual node in the virtual node queue that matches the scaling-down cache resource;

[0104] If so, select a scaled-down first-level virtual node in the virtual node queue and remove the scaled-down first-level virtual node from the virtual node queue; determine the scaled-down first-level mapping relationship corresponding to the scaled-down first-level virtual node, and update the first-level mapping relationship stored in the distributed hash table according to the scaled-down first-level mapping relationship.

[0105] If not, determine the failed first-level virtual node associated with the shrinking cache node, and determine the failed first-level mapping relationship between the shrinking cache node and the failed first-level virtual node; determine the quota group to be updated based on the failed first-level virtual node, and select a valid first-level virtual node matching the quota group to be updated in the virtual node queue, and establish the quota mapping relationship between the valid first-level virtual node and the quota group to be updated; update the first-level mapping relationship and the failed quota mapping relationship corresponding to the quota group to be updated stored in the distributed hash table according to the failed first-level mapping relationship and the quota mapping relationship to be updated.

[0106] Specifically, a resource scaling-down request refers to a request submitted to the distributed caching system to reduce cache resources. Correspondingly, the scaling-down cache node is the cache node that needs to be deleted. Similarly, a scaling-down first-level virtual node refers to the first-level virtual node in the virtual node list that matches the scaling-down cache node and the corresponding scaling-down cache resource. The scaling-down first-level mapping relationship is the first-level mapping relationship associated with the scaling-down first-level virtual nodes. Similarly, an invalidated first-level virtual node refers to a first-level virtual node that has a mapping relationship with the scaling-down cache node. The invalidated first-level mapping relationship is the first-level mapping relationship between the scaling-down cache node and the invalidated first-level virtual node. The quota group to be updated refers to the quota group associated with the invalidated first-level virtual node. The valid first-level virtual node refers to the new first-level virtual node selected for the quota group to be updated; the quota mapping relationship to be updated is the quota mapping relationship between the two.

[0107] Based on this, when a resource scaling-down request is received, it indicates that the distributed caching system needs to delete some cache resources. Therefore, we can first determine the scaling-down cache resources corresponding to the scaling-down cache nodes; at the same time, we can check whether there is a first-level virtual node in the virtual node queue that matches the scaling-down cache resources.

[0108] If so, it means that the first-level virtual node established by the shrinking cache node that needs to be deleted has not yet been assigned to the tenant. Therefore, the corresponding shrinking first-level virtual node can be selected in the virtual node queue, and then the shrinking first-level virtual node can be removed from the virtual node queue. At the same time, the shrinking first-level mapping relationship corresponding to the shrinking first-level virtual node can be determined, and the first-level mapping relationship stored in the distributed hash table can be updated according to the shrinking first-level mapping relationship. This update can be understood as deleting the shrinking first-level mapping relationship.

[0109] If not, it means that the first-level virtual node created for the shrinking cache node that needs to be deleted has already been used. This can be understood as the first-level virtual node corresponding to the shrinking cache node being allocated and used for a quota group. The cache's invalidation causes the quota group to be unable to request resources. Therefore, a new first-level virtual node needs to be selected from the queue and allocated to the quota group. Similarly, the mapping relationship in the hash table needs to be rebuilt to ensure the relationship functions correctly. Specifically, we can first determine the invalidated first-level virtual node associated with the shrinking cache node, and simultaneously determine the invalidated first-level mapping relationship between the shrinking cache node and the invalidated first-level virtual node. Then, we can determine the quota group to be updated based on the invalidated first-level virtual node, and select a valid first-level virtual node matching the quota group to be updated from the virtual node queue. This allows us to establish the quota mapping relationship between the valid first-level virtual node and the quota group to be updated. Finally, based on the invalidated first-level mapping relationship and the quota mapping relationship to be updated, we can update the first-level mapping relationship and the invalidated quota mapping relationship corresponding to the quota group to be updated stored in the distributed hash table.

[0110] In practical applications, when a distributed caching system needs to reduce cache resources, the criterion for judgment can be whether the resources can be compensated by virtual nodes in the virtual node queue. If the idle virtual node Qnode in the virtual node queue can compensate, then only the idle virtual node Qnode corresponding to the reduced cache node is needed. At the same time, the mapping relationship between cache nodes and virtual nodes in the distributed hash table DHT can be updated, thereby avoiding impact on the existing quota.

[0111] In cases where compensation is not possible, such as when a shrinking cache node worker is removed from the cluster, all caches within the scope of the shrinking cache node worker will become invalid. Therefore, the distributed caching system needs to reallocate new virtual nodes (Qnodes) from the virtual node queue for the affected quota groups. At the same time, it will update the mapping relationship stored in the distributed hash table (DHT) based on the removal and reallocation results to ensure that the distributed caching system can continue to provide services.

[0112] In summary, for cache resource scaling-up scenarios, combining compensation strategies with resource scaling-up can avoid large-scale updates to mapping relationships, thereby effectively reducing the system's processing complexity.

[0113] Furthermore, to mitigate the impact of a distributed caching system restart on the mapping relationship, the distributed hash table can be persisted, allowing resource management information to be read from disk and reconstructed upon restart. In this embodiment, the specific implementation is as follows:

[0114] The distributed hash table is stored on the target disk of the distributed cache system; in the event of a restart of the distributed cache system, the distributed hash table is read from the target disk, and the resource management information is reconstructed in the memory of the distributed cache system according to the distributed hash table.

[0115] Specifically, the target disk refers to the disk where the distributed caching system can persist the distributed hash table. Therefore, to avoid data loss, the distributed caching system can store the distributed hash table on its target disk. In the event of a system restart, the distributed hash table can be read from the target disk, and resource management information can be reconstructed in the distributed caching system's memory according to the hash table, so that cache resource management services can continue to be provided subsequently.

[0116] In practical applications, for the restart of distributed caching systems, such as when the management node Master process fails and crashes, the Master process can load the persistent distributed hash table (DHT) from the disk after restarting and restore the virtual node (Qnode) management information in memory before the crash. Specifically, this can include which QuotaGroups exist, which Qnodes they correspond to, and the mapping relationships between Workers, Qnodes, and Vnodes, etc., achieving a lossless restart effect and improving system reliability.

[0117] The resource management method adopted in this embodiment aims to make multi-tenant cache resource quotas more efficient and reliable. It transforms tenant quota management into the management of virtual node mapping relationships by constructing a multi-layered mapping relationship, thereby flexibly utilizing various strategies to ensure system reliability. Specifically, after obtaining the registration information of cache nodes, a first-level virtual node with cache resource alignment is constructed based on the registration information. This first-level virtual node is then added to the virtual node queue, and a first-level mapping relationship is established between the first-level virtual node and the cache node. Furthermore, in response to resource management requests, target first-level virtual nodes are selected from the virtual node queue, establishing a second-level mapping relationship between the target first-level virtual node and second-level virtual nodes, as well as a quota mapping relationship between the target first-level virtual node and the quota group corresponding to the resource management request. This multi-layered mapping relationship manages the quota status of each tenant while avoiding cache resource usage squeeze issues. Finally, the first-level mapping relationship, second-level mapping relationship, and quota mapping relationship are stored in a distributed hash table for allocating cache resources to the client corresponding to the resource management request. A distributed caching system can flexibly and accurately allocate and manage cache resources. By combining a distributed hash table to store multi-layer mapping relationships, it can achieve multi-tenant isolation at the logical level in an efficient way. This ensures that each tenant can use cache resources within its corresponding quota during the application phase, thereby solving the problem of tenants squeezing each other's cache space.

[0118] See Figure 3 , Figure 3 A flowchart of another resource management method provided according to an embodiment of this specification is shown, which specifically includes the following steps.

[0119] Step S302: In response to the cache request submitted by the client, query the distributed hash table and determine the quota group field corresponding to the client based on the query result.

[0120] Step S304: Read the target secondary mapping relationship in the distributed hash table according to the quota group field, and determine the primary virtual node to be used based on the target secondary mapping relationship.

[0121] Step S306: Read the first-level mapping relationship to be used from the distributed hash table according to the first-level virtual node to be used, and determine the target cache node according to the first-level mapping relationship to be used.

[0122] Step S308: Submit the cache request to the target cache node for allocating cache resources to the client to execute the target task corresponding to the cache request, wherein the mapping relationship stored in the distributed hash table is constructed using the above method.

[0123] This embodiment provides another resource management method. For any content not described in detail, please refer to the description in the above embodiments. This embodiment will not elaborate further here.

[0124] Specifically, the client refers to the terminal device operated by a tenant with caching needs. Correspondingly, the quota group field refers to the field that records quota group information. And correspondingly, the target task refers to the data loading task that the cache node needs to execute according to the cache request.

[0125] Based on this, when a client submits a cache request, the system can first query the distributed hash table in response to the client's cache request, and determine the quota group field corresponding to the client based on the query result. Furthermore, considering that the distributed hash table stores multiple levels of mapping relationships, the target secondary mapping relationship can be read from the distributed hash table according to the quota group field, and the first-level virtual node to be used can be determined based on the target secondary mapping relationship. Subsequently, the first-level mapping relationship to be used can be read from the distributed hash table based on the first-level virtual node to be used, and the target cache node can be determined based on the first-level mapping relationship to be used. Based on this, the cache request can be submitted to the target cache node, which is used to allocate cache resources to the client and execute the target task corresponding to the cache request. The first-level mapping relationship, secondary mapping relationship, and quota mapping relationship stored in the distributed hash table can all be constructed using the above method.

[0126] In practical applications, when a client initiates a cache request, relevant information can first be obtained from the Distributed Hash Table (DHT). The client calculates the corresponding secondary virtual node (Vnode) based on the requested key, and then looks up the corresponding Vnode in the DHT using the QuotaGroup field recorded in the key. <qnode-vnode>The mapping table is used to determine the virtual node (Qnode) corresponding to the request. Furthermore, the client can utilize the data recorded in the distributed hash table (DHT). <qnode-worker>The mapping relationship locates the specific cache node worker address that handles the request. When the cache node worker receives the cache request, it can centrally manage the request and update the cache usage of the relevant QuotaGroup.

[0127] Furthermore, when the cache usage of a QuotaGroup reaches its set limit, the cache node worker can automatically initiate a data eviction mechanism to remove less active data entries within that QuotaGroup. This mechanism ensures that each tenant can only use cache resources within its quota, thus avoiding impacting the data storage of other tenants. In other words, each cache node, knowing the cache capacity corresponding to the tenant it is responsible for, can trigger the data eviction mechanism if the cache capacity limit is exceeded.

[0128] The resource management method adopted in this embodiment enables the distributed caching system to flexibly and accurately complete the allocation and management of cache resources. In addition, by combining the distributed hash table to store multi-level mapping relationships, it can achieve multi-tenant isolation at the logical level in an efficient manner, thereby ensuring that each tenant can use cache resources within its corresponding quota during the application phase, thus solving the problem of mutual squeezing of cache space between tenants.

[0129] Corresponding to the above method embodiments, this specification also provides embodiments of a distributed caching system. Figure 4 A schematic diagram of the structure of a distributed caching system provided in one embodiment of this specification is shown. Figure 4 As shown, the distributed caching system 400 includes a management node 410, a cache node 420, and a client 430, comprising:

[0130] The management node 410 is configured to obtain the registration information of the cache node 420, and construct a first-level virtual node with cache resource alignment with the cache node based on the registration information; add the first-level virtual node to the virtual node queue, and establish a first-level mapping relationship between the first-level virtual node and the cache node; in response to a resource management request, filter target first-level virtual nodes in the virtual node queue, establish a second-level mapping relationship between the target first-level virtual node and the second-level virtual node, and a quota mapping relationship between the target first-level virtual node and the quota group corresponding to the resource management request; and store the first-level mapping relationship, the second-level mapping relationship, and the quota mapping relationship in a distributed hash table.

[0131] The client 430 is used to submit a cache request to the management node;

[0132] The management node 410 is used to query the distributed hash table in response to the cache request, determine the target cache node based on the query result, and submit the cache request to the target cache node for allocating cache resources to the client to execute the target task corresponding to the cache request.

[0133] In other words, through a decentralized distributed quota management architecture, the core of the management node is to update the mapping relationship in the distributed hash table in real time based on the information reported by the cache nodes and the user's application and management operations for cache quotas. This method allows the management node to avoid intervening in the user's actual cache usage process, thereby avoiding the problem of the management node being a single point of failure in the centralized quota management mechanism.

[0134] The above is an illustrative scheme of a distributed caching system according to this embodiment. It should be noted that the technical solution of this distributed caching system and the technical solution of the resource management method described above belong to the same concept. For details not described in detail in the technical solution of the distributed caching system, please refer to the description of the technical solution of the resource management method described above.

[0135] The following is in conjunction with the appendix Figure 5 Taking the application of the resource management method provided in this specification in a cached resource usage scenario as an example, the resource management method will be further explained. Figure 5 The present specification illustrates a process flowchart of a resource management method according to an embodiment, which specifically includes the following steps.

[0136] Step S502: Obtain the registration information of the cache nodes and determine the cache resource allocation rules of the distributed cache system. Calculate the number of nodes to be allocated based on the registration information and the cache resource allocation rules.

[0137] Step S504: Construct first-level virtual nodes that have cache resource alignment with cache nodes according to the number of nodes allocated, and construct first-level virtual nodes that have cache resource alignment with cache nodes according to the registration information.

[0138] Step S506: Add the first-level virtual node to the virtual node queue and establish the first-level mapping relationship between the first-level virtual node and the cache node.

[0139] Step S508: In response to the resource management request, determine the quota information and select at least one primary virtual node that matches the quota information from the virtual node queue as the target primary virtual node.

[0140] Step S510: Based on the quota information, select secondary virtual nodes in the virtual node cluster of the distributed caching system and determine the quota group corresponding to the resource management request, wherein the number of secondary virtual nodes is greater than the number of target primary virtual nodes.

[0141] Step S512: Establish the secondary mapping relationship between the target primary virtual node and the secondary virtual node, as well as the quota mapping relationship between the target primary virtual node and the quota group corresponding to the resource management request.

[0142] Step S514: Extract the target first-level mapping relationship corresponding to the target first-level virtual node from the first-level mapping relationship, and construct the relationship link between the target first-level mapping relationship, the second-level mapping relationship and the quota mapping relationship.

[0143] Step S516: Based on the relationship chain, store the target first-level mapping relationship, second-level mapping relationship and quota mapping relationship into a distributed hash table, which is used to allocate cache resources to the client corresponding to the resource management request.

[0144] Upon receiving a resource expansion request, the system determines the expansion cache node and obtains its expansion registration information. It then uses the expansion cache node as the cache node and the expansion registration information as registration information, and executes the step of constructing a first-level virtual node with cache resource alignment with the cache node based on the registration information. Finally, upon obtaining the expansion first-level mapping relationship corresponding to the expansion cache node, it updates the first-level mapping relationship stored in the distributed hash table based on the expansion first-level mapping relationship.

[0145] Upon receiving a resource scaling-down request, determine the scaling-down cache resource corresponding to the scaling-down cache node; check if there is a first-level virtual node in the virtual node queue that matches the scaling-down cache resource;

[0146] If so, select a scaled-down first-level virtual node from the virtual node queue and remove the scaled-down first-level virtual node from the virtual node queue; determine the scaled-down first-level mapping relationship corresponding to the scaled-down first-level virtual node, and update the first-level mapping relationship stored in the distributed hash table according to the scaled-down first-level mapping relationship.

[0147] If not, determine the failed first-level virtual node associated with the shrinking cache node, and determine the failed first-level mapping relationship between the shrinking cache node and the failed first-level virtual node; determine the quota group to be updated based on the failed first-level virtual node, and select the valid first-level virtual node that matches the quota group to be updated in the virtual node queue, and establish the quota mapping relationship between the valid first-level virtual node and the quota group to be updated; update the first-level mapping relationship and the failed quota mapping relationship corresponding to the quota group to be updated stored in the distributed hash table based on the failed first-level mapping relationship and the quota mapping relationship to be updated.

[0148] In addition, the distributed hash table can be stored on the target disk of the distributed cache system; in the event of a restart of the distributed cache system, the distributed hash table can be read from the target disk, and the resource management information can be reconstructed in the memory of the distributed cache system according to the distributed hash table.

[0149] Step S518: Upon receiving a cache request submitted by the client, query the distributed hash table in response to the cache request submitted by the client, and determine the quota group field corresponding to the client based on the query result.

[0150] Step S520: Read the target secondary mapping relationship in the distributed hash table according to the quota group field, and determine the primary virtual node to be used based on the target secondary mapping relationship.

[0151] Step S522: Read the mapping relationship of the first-level virtual node to be used from the distributed hash table, and determine the target cache node based on the mapping relationship of the first-level virtual node to be used.

[0152] Step S524: Submit the cache request to the target cache node, which is used to allocate cache resources to the client and execute the target task corresponding to the cache request.

[0153] In summary, to achieve more efficient and reliable caching resource quota management for multi-tenants, a multi-layered mapping approach can be adopted. This transforms tenant quota management into the management of virtual node mapping relationships, allowing for flexible use of various strategies to ensure system reliability. Specifically, after obtaining the registration information of cache nodes, a first-level virtual node with cache resource alignment can be constructed based on this information. This first-level virtual node can then be added to the virtual node queue, establishing a first-level mapping relationship between it and the cache node. Furthermore, in response to resource management requests, target first-level virtual nodes can be selected from the virtual node queue, establishing a second-level mapping relationship between the target first-level virtual node and second-level virtual nodes, as well as a quota mapping relationship between the target first-level virtual node and the quota group corresponding to the resource management request. This multi-layered mapping approach manages the quota status of each tenant while avoiding cache resource overcrowding issues. Finally, the first-level, second-level, and quota mapping relationships can be stored in a distributed hash table for allocating cache resources to clients corresponding to resource management requests. A distributed caching system can flexibly and accurately allocate and manage cache resources. By combining a distributed hash table to store multi-layer mapping relationships, it can achieve multi-tenant isolation at the logical level in an efficient way. This ensures that each tenant can use cache resources within its corresponding quota during the application phase, thereby solving the problem of tenants squeezing each other's cache space.

[0154] Corresponding to the above method embodiments, this specification also provides embodiments of a resource management device. Figure 6 A schematic diagram of a resource management device according to one embodiment of this specification is shown. Figure 6 As shown, this device is applied to a distributed caching system and includes:

[0155] The acquisition module 602 is configured to acquire the registration information of the cache node and construct a first-level virtual node with cache resource alignment relationship with the cache node based on the registration information;

[0156] The addition module 604 is configured to add the first-level virtual node to the virtual node queue and establish a first-level mapping relationship between the first-level virtual node and the cache node;

[0157] The filtering module 606 is configured to filter target primary virtual nodes in the virtual node queue in response to a resource management request, establish a secondary mapping relationship between the target primary virtual nodes and secondary virtual nodes, and a quota mapping relationship between the target primary virtual nodes and the quota group corresponding to the resource management request.

[0158] Storage module 608 is configured to store the first-level mapping relationship, the second-level mapping relationship and the quota mapping relationship in a distributed hash table, for allocating cache resources to the client corresponding to the resource management request.

[0159] In an optional embodiment, obtaining the registration information of the cache node and constructing a first-level virtual node with cache resource alignment with the cache node based on the registration information includes:

[0160] Obtain the registration information of the cache nodes and determine the cache resource allocation rules of the distributed caching system; calculate the number of nodes to be allocated based on the registration information and the cache resource allocation rules; construct a first-level virtual node with cache resource alignment relationship with the cache node according to the number of nodes to be allocated.

[0161] In an optional embodiment, establishing the first-level mapping relationship between the first-level virtual node and the cache node includes:

[0162] The process involves determining the primary node identifier of the primary virtual node and the cache node identifier of the cache node, and constructing a primary mapping relationship based on the primary node identifier and the cache node identifier. Establishing a secondary mapping relationship between the target primary virtual node and the secondary virtual node includes: determining the target primary node identifier of the target primary virtual node and the secondary node identifier of the secondary virtual node, and constructing a secondary mapping relationship based on the target primary node identifier and the secondary node identifier. Establishing a quota mapping relationship between the target primary virtual node and the quota group corresponding to the resource management request includes: determining the quota group identifier of the quota group corresponding to the resource management request, and constructing a quota mapping relationship based on the target primary node identifier and the quota group identifier.

[0163] In an optional embodiment, the step of responding to a resource management request by filtering target primary virtual nodes in the virtual node queue, establishing a two-level mapping relationship between the target primary virtual nodes and secondary virtual nodes, and a quota mapping relationship between the target primary virtual nodes and the quota group corresponding to the resource management request, includes:

[0164] In response to a resource management request, quota information is determined. At least one primary virtual node matching the quota information is selected as a target primary virtual node from the virtual node queue. Secondary virtual nodes are filtered in the virtual node cluster of the distributed caching system according to the quota information, and the quota group corresponding to the resource management request is determined, wherein the number of secondary virtual nodes is greater than the number of target primary virtual nodes. Based on the target primary virtual nodes, the secondary virtual nodes, and the quota group, the steps of establishing a secondary mapping relationship between the target primary virtual nodes and the secondary virtual nodes, and a quota mapping relationship between the target primary virtual nodes and the quota group corresponding to the resource management request are performed.

[0165] In an optional embodiment, after the step of storing the first-level mapping relationship, the second-level mapping relationship, and the quota mapping relationship into a distributed hash table is performed, the method further includes:

[0166] Upon receiving a resource expansion request, the system determines the expansion cache node and obtains its expansion registration information. It then designates the expansion cache node as the cache node and the expansion registration information as the registration information, and executes a step of constructing a first-level virtual node with cache resource alignment with the cache node based on the registration information. If the expansion first-level mapping relationship corresponding to the expansion cache node is obtained, the system updates the first-level mapping relationship stored in the distributed hash table based on the expansion first-level mapping relationship.

[0167] In an optional embodiment, after the step of storing the first-level mapping relationship, the second-level mapping relationship, and the quota mapping relationship into a distributed hash table is performed, the method further includes:

[0168] Upon receiving a resource scaling-down request, the scaling-down cache resource corresponding to the scaling-down cache node is determined; it is checked whether there is a first-level virtual node in the virtual node queue that matches the scaling-down cache resource; if so, a first-level virtual node is selected from the virtual node queue and removed from the virtual node queue; the scaling-down first-level mapping relationship corresponding to the scaling-down first-level virtual node is determined, and the first-level mapping relationship stored in the distributed hash table is updated according to the scaling-down first-level mapping relationship.

[0169] In an optional embodiment, if the determination result of whether there is a first-level virtual node in the virtual node queue that matches the scaling-down cache resource is negative, it includes:

[0170] The process involves: determining the failed first-level virtual nodes associated with the scaled-down cache nodes and establishing a first-level failure mapping relationship between them; determining quota groups to be updated based on the failed first-level virtual nodes and selecting valid first-level virtual nodes matching the quota groups to be updated from the virtual node queue; establishing a quota mapping relationship between the valid first-level virtual nodes and the quota groups to be updated; and updating the first-level mapping relationship and the failed quota mapping relationship corresponding to the quota groups to be updated stored in the distributed hash table based on the failed first-level mapping relationship and the quota mapping relationship to be updated.

[0171] In an optional embodiment, after the step of storing the first-level mapping relationship, the second-level mapping relationship, and the quota mapping relationship into a distributed hash table is performed, the method further includes:

[0172] The distributed hash table is stored on the target disk of the distributed cache system; in the event of a restart of the distributed cache system, the distributed hash table is read from the target disk, and the resource management information is reconstructed in the memory of the distributed cache system according to the distributed hash table.

[0173] In an optional embodiment, storing the first-level mapping relationship, the second-level mapping relationship, and the quota mapping relationship into a distributed hash table includes:

[0174] Extract the target first-level mapping relationship corresponding to the target first-level virtual node from the first-level mapping relationship; construct the relationship link between the target first-level mapping relationship, the second-level mapping relationship and the quota mapping relationship; and store the target first-level mapping relationship, the second-level mapping relationship and the quota mapping relationship into a distributed hash table based on the relationship link.

[0175] The resource management device in this embodiment, in order to make multi-tenant cache resource quotas more efficient and secure, can transform tenant quota management into the management of virtual node mapping relationships by constructing a multi-layer mapping relationship. This allows for flexible use of various strategies to ensure system reliability. Specifically, after obtaining the registration information of cache nodes, a first-level virtual node with cache resource alignment with the cache node can be constructed based on the registration information. This first-level virtual node can then be added to the virtual node queue, and a first-level mapping relationship can be established between the first-level virtual node and the cache node. Based on this, in response to resource management requests, target first-level virtual nodes can be selected from the virtual node queue, establishing a second-level mapping relationship between the target first-level virtual node and second-level virtual nodes, as well as a quota mapping relationship between the target first-level virtual node and the quota group corresponding to the resource management request. This achieves multi-layer mapping relationship management of each tenant's quota while avoiding cache resource usage squeeze issues. Finally, the first-level mapping relationship, second-level mapping relationship, and quota mapping relationship can be stored in a distributed hash table for allocating cache resources to the client corresponding to the resource management request. A distributed caching system can flexibly and accurately allocate and manage cache resources. By combining a distributed hash table to store multi-layer mapping relationships, it can achieve multi-tenant isolation at the logical level in an efficient way. This ensures that each tenant can use cache resources within its corresponding quota during the application phase, thereby solving the problem of tenants squeezing each other's cache space.

[0176] The above is an illustrative scheme of a resource management device according to this embodiment. It should be noted that the technical solution of this resource management device and the technical solution of the resource management method described above belong to the same concept. For details not described in detail in the technical solution of the resource management device, please refer to the description of the technical solution of the resource management method described above.

[0177] Corresponding to the above method embodiments, this specification also provides another embodiment of a resource management device. Figure 7 A schematic diagram of another resource management device provided in one embodiment of this specification is shown. Figure 7 As shown, the device includes:

[0178] The query module 702 is configured to query a distributed hash table in response to a cache request submitted by a client, and determine the quota group field corresponding to the client based on the query result;

[0179] The reading module 704 is configured to read the target secondary mapping relationship in the distributed hash table according to the quota group field, and determine the primary virtual node to be used based on the target secondary mapping relationship;

[0180] The determination module 706 is configured to read the first-level mapping relationship to be used in the distributed hash table based on the first-level virtual node to be used, and determine the target cache node based on the first-level mapping relationship to be used;

[0181] The submission module 708 is configured to submit the cache request to the target cache node, and is used to allocate cache resources to the client to execute the target task corresponding to the cache request. The mapping relationship stored in the distributed hash table is constructed by the above method.

[0182] The resource management device used in this embodiment enables the distributed caching system to flexibly and accurately complete the allocation and management of cache resources. In addition, by combining the distributed hash table to store multi-layer mapping relationships, it can achieve multi-tenant isolation at the logical level in an efficient manner, thereby ensuring that each tenant can use cache resources within its corresponding quota during the application phase, thus solving the problem of tenants squeezing each other's cache space.

[0183] The above is an illustrative scheme of another resource management device in this embodiment. It should be noted that the technical solution of this other resource management device and the technical solution of the other resource management method described above belong to the same concept. For details not described in detail in the technical solution of the other resource management device, please refer to the description of the technical solution of the other resource management method described above.

[0184] Figure 8 A structural block diagram of a computing device 800 according to one embodiment of this specification is shown. The components of the computing device 800 include, but are not limited to, a memory 810 and a processor 820. The processor 820 is connected to the memory 810 via a bus 830, and a database 850 is used to store data.

[0185] The computing device 800 also includes an access device 840, which enables the computing device 800 to communicate via one or more networks 860. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 840 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0186] In one embodiment of this specification, the above-described components of the computing device 800 and Figure 8 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 8 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0187] The computing device 800 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 800 can also be a mobile or stationary server.

[0188] The processor 820 is configured to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the resource management method described above.

[0189] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the resource management method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the resource management method described above.

[0190] An embodiment of this specification also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the resource management method described above.

[0191] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the resource management method described above belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the resource management method described above.

[0192] An embodiment of this specification also provides a computer program, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described resource management method.

[0193] The above is an illustrative example of a computer program according to this embodiment. It should be noted that the technical solution of this computer program and the technical solution of the resource management method described above belong to the same concept. Details not described in detail in the technical solution of the computer program can be found in the description of the technical solution of the resource management method described above.

[0194] An embodiment of this specification also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the resource management method described above.

[0195] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the resource management method described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the resource management method described above.

[0196] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0197] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0198] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0199] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0200] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A resource management method applied to a distributed caching system, comprising: Obtain the registration information of the cache node, and construct a first-level virtual node with cache resource alignment relationship with the cache node based on the registration information; Add the first-level virtual node to the virtual node queue, and establish a first-level mapping relationship between the first-level virtual node and the cache node; In response to a resource management request, a target primary virtual node is selected from the virtual node queue, a secondary mapping relationship is established between the target primary virtual node and the secondary virtual node, and a quota mapping relationship is established between the target primary virtual node and the quota group corresponding to the resource management request. The first-level mapping relationship, the second-level mapping relationship, and the quota mapping relationship are stored in a distributed hash table for allocating cache resources to the client corresponding to the resource management request.

2. The resource management method according to claim 1, wherein obtaining the registration information of the cache node and constructing a first-level virtual node with a cache resource alignment relationship with the cache node based on the registration information includes: Obtain the registration information of the cache nodes and determine the cache resource allocation rules of the distributed caching system; The number of nodes to be allocated is calculated based on the registration information and the cache resource allocation rules. Construct first-level virtual nodes that have cache resource alignment with the cache nodes according to the number of nodes allocated.

3. The resource management method according to claim 1, wherein establishing the first-level mapping relationship between the first-level virtual node and the cache node includes: Determine the first-level node identifier of the first-level virtual node and the cache node identifier of the cache node, and construct a first-level mapping relationship based on the first-level node identifier and the cache node identifier; The step of establishing a two-level mapping relationship between the target first-level virtual node and the second-level virtual node includes: Determine the target first-level node identifier of the target first-level virtual node and the second-level node identifier of the second-level virtual node, and construct a second-level mapping relationship based on the target first-level node identifier and the second-level node identifier; The step of establishing the quota mapping relationship between the target primary virtual node and the quota group corresponding to the resource management request includes: Determine the quota group identifier corresponding to the quota group of the resource management request, and construct a quota mapping relationship based on the target primary node identifier and the quota group identifier.

4. The resource management method according to claim 1, wherein the step of responding to a resource management request by filtering target primary virtual nodes in the virtual node queue, establishing a secondary mapping relationship between the target primary virtual nodes and secondary virtual nodes, and a quota mapping relationship between the target primary virtual nodes and the quota group corresponding to the resource management request, comprises: In response to a resource management request, quota information is determined, and at least one primary virtual node matching the quota information is selected from the virtual node queue as the target primary virtual node. Based on the quota information, secondary virtual nodes are selected in the virtual node cluster of the distributed caching system, and the quota group corresponding to the resource management request is determined, wherein the number of secondary virtual nodes is greater than the number of target primary virtual nodes; Based on the target primary virtual node, the secondary virtual node, and the quota group, the steps of establishing a secondary mapping relationship between the target primary virtual node and the secondary virtual node, and a quota mapping relationship between the target primary virtual node and the quota group corresponding to the resource management request are performed.

5. The resource management method according to any one of claims 1 to 4, further comprising, after the step of storing the first-level mapping relationship, the second-level mapping relationship, and the quota mapping relationship into a distributed hash table: Upon receiving a resource expansion request, determine the expansion cache node and obtain the expansion registration information of the expansion cache node; The expansion cache node is used as the cache node and the expansion registration information is used as the registration information. The step of constructing a first-level virtual node with cache resource alignment relationship with the cache node according to the registration information is executed. Once the expansion level-one mapping relationship corresponding to the expansion cache node is obtained, the level-one mapping relationship stored in the distributed hash table is updated according to the expansion level-one mapping relationship.

6. The resource management method according to any one of claims 1 to 4, after the step of storing the first-level mapping relationship, the second-level mapping relationship, and the quota mapping relationship into a distributed hash table, further comprising: Upon receiving a resource scaling-down request, determine the scaling-down cache resource corresponding to the scaling-down cache node; Detect whether there is a first-level virtual node in the virtual node queue that matches the scaled-down cache resource; If so, select a scaled-down virtual node from the virtual node queue and remove the scaled-down virtual node from the virtual node queue; Determine the scaling-down first-level mapping relationship corresponding to the scaling-down first-level virtual node, and update the first-level mapping relationship stored in the distributed hash table according to the scaling-down first-level mapping relationship.

7. The resource management method according to claim 6, wherein if the determination result of detecting whether there is a first-level virtual node in the virtual node queue that matches the shrinkage cache resource is negative, it includes: Determine the failed first-level virtual node associated with the shrinking cache node, and determine the first-level failure mapping relationship between the shrinking cache node and the failed first-level virtual node; Based on the failed first-level virtual nodes, determine the quota group to be updated, and select a valid first-level virtual node that matches the quota group to be updated from the virtual node queue, and establish a mapping relationship between the valid first-level virtual node and the quota group to be updated. Based on the failed first-level mapping relationship and the quota mapping relationship to be updated, the first-level mapping relationship and the failed quota mapping relationship corresponding to the quota group to be updated stored in the distributed hash table are updated.

8. The resource management method according to claim 1, after the step of storing the first-level mapping relationship, the second-level mapping relationship, and the quota mapping relationship into a distributed hash table, further includes: Store the distributed hash table to the target disk of the distributed cache system; In the event of a restart of the distributed cache system, the distributed hash table is read from the target disk, and the resource management information is reconstructed in the memory of the distributed cache system according to the distributed hash table.

9. The resource management method according to claim 1, wherein storing the first-level mapping relationship, the second-level mapping relationship, and the quota mapping relationship into a distributed hash table comprises: Extract the target first-level mapping relationship corresponding to the target first-level virtual node from the first-level mapping relationship; Construct the relationship links between the target first-level mapping relationship, the second-level mapping relationship, and the quota mapping relationship; Based on the relationship chain, the target first-level mapping relationship, the second-level mapping relationship, and the quota mapping relationship are stored in a distributed hash table.

10. A resource management method, comprising: In response to a cache request submitted by a client, a distributed hash table is queried, and the quota group field corresponding to the client is determined based on the query result; The target secondary mapping relationship is read from the distributed hash table according to the quota group field, and the primary virtual node to be used is determined based on the target secondary mapping relationship; The first-level virtual node to be used is read from the distributed hash table to determine the first-level mapping relationship, and the target cache node is determined based on the first-level mapping relationship. The cache request is submitted to the target cache node for allocating cache resources to the client to execute the target task corresponding to the cache request, wherein the mapping relationship stored in the distributed hash table is constructed by any one of claims 1 to 9.

11. A distributed caching system, comprising a management node, cache nodes, and clients, including: The management node is used to obtain the registration information of the cache node and construct a first-level virtual node with cache resource alignment relationship with the cache node based on the registration information; The first-level virtual node is added to the virtual node queue, and a first-level mapping relationship is established between the first-level virtual node and the cache node; in response to a resource management request, a target first-level virtual node is selected from the virtual node queue, a second-level mapping relationship is established between the target first-level virtual node and the second-level virtual node, and a quota mapping relationship is established between the target first-level virtual node and the quota group corresponding to the resource management request; Store the first-level mapping relationship, the second-level mapping relationship, and the quota mapping relationship in a distributed hash table; The client is used to submit a cache request to the management node; The management node is used to query the distributed hash table in response to the cache request and determine the target cache node based on the query result; The cache request is submitted to the target cache node, which allocates cache resources to the client to execute the target task corresponding to the cache request.

12. A resource management device applied to a distributed caching system, comprising: The acquisition module is configured to acquire the registration information of the cache node and construct a first-level virtual node with cache resource alignment relationship with the cache node based on the registration information; The add module is configured to add the first-level virtual node to the virtual node queue and establish a first-level mapping relationship between the first-level virtual node and the cache node; The filtering module is configured to filter target primary virtual nodes in the virtual node queue in response to a resource management request, establish a secondary mapping relationship between the target primary virtual nodes and secondary virtual nodes, and a quota mapping relationship between the target primary virtual nodes and the quota group corresponding to the resource management request. The storage module is configured to store the first-level mapping relationship, the second-level mapping relationship, and the quota mapping relationship in a distributed hash table, which is used to allocate cache resources to the client corresponding to the resource management request.

13. A resource management device, comprising: The query module is configured to query the distributed hash table in response to a cache request submitted by the client, and determine the quota group field corresponding to the client based on the query result; The reading module is configured to read the target secondary mapping relationship in the distributed hash table according to the quota group field, and determine the primary virtual node to be used based on the target secondary mapping relationship; The determination module is configured to read the first-level mapping relationship to be used in the distributed hash table based on the first-level virtual node to be used, and determine the target cache node based on the first-level mapping relationship to be used; The submission module is configured to submit the cache request to the target cache node, and is used to allocate cache resources to the client to execute the target task corresponding to the cache request, wherein the mapping relationship stored in the distributed hash table is constructed by any one of claims 1 to 9.

14. A computing device, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the method according to any one of claims 1 to 10.

15. A computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 10.

16. A computer program product comprising a computer program or instructions which, when executed by a processor, implement the steps of the method according to any one of claims 1 to 10.

Images