Resource management method, device, equipment, system, storage medium and program product

Abstract

The embodiment of the invention discloses a resource management method, device, equipment and system, a storage medium and a program product. In the embodiment of the invention, lock distribution requests sent by at least two threads are acquired; according to the lock distribution request, obtaining a service function realized by the thread in the service instance; determining a lock distribution priority of the thread according to a service function realized by the thread; according to the lock allocation priority, resource locks are allocated for the threads, so that the threads can grab the locks orderly, and the phenomenon that lock grabbing of a certain thread fails all the time is avoided.

Description

Technical Field

[0001] This application relates to the field of electronic equipment technology, specifically to a resource management method, apparatus, device, system, storage medium, and program product. Background Technology

[0002] An application service is a software program that runs on a computer system to provide specific functions. To improve the stability and fault tolerance of application services, multiple instances of the application service can be deployed, and each instance can have multiple parallel threads.

[0003] When multiple threads access shared resources simultaneously, contention may occur. Therefore, locks can be used to restrict access to shared resources. Each thread must acquire the lock before accessing the shared resource; threads that fail to acquire the lock cannot access the shared resource, ensuring that only one thread can access the shared resource at any given time. However, current lock-acquiring methods may cause a particular thread to continuously fail to acquire the lock, thus affecting the use of application services. Summary of the Invention

[0004] This application provides a resource management method, apparatus, device, system, storage medium, and program product that can solve the technical problem of a certain thread failing to acquire a lock.

[0005] This application provides a resource management method applied to an electronic device. The resource management system of the electronic device includes threads of at least two service instances. The method includes: obtaining lock allocation requests sent by at least two of the threads; obtaining the service functions implemented by the threads in the service instances based on the lock allocation requests; determining the lock allocation priority of the threads based on the service functions implemented by the threads; and allocating resource locks to the threads based on the lock allocation priority.

[0006] Accordingly, this application provides a resource management device applied to an electronic device. The resource management system of the electronic device includes threads of at least two service instances, comprising: a request acquisition module for acquiring lock allocation requests sent by at least two of the threads; a function acquisition module for acquiring service functions implemented by the threads in the service instances based on the lock allocation requests; a determination module for determining the lock allocation priority of the threads based on the service functions implemented by the threads; and an allocation module for allocating resource locks to the threads based on the lock allocation priority.

[0007] Furthermore, this application also provides an electronic device, including a processor and a memory, wherein the memory stores a computer program, and the processor is used to run the computer program in the memory to implement the resource management method provided in this application.

[0008] Furthermore, embodiments of this application also provide a computer-readable storage medium storing a computer program adapted for loading by a processor to execute any of the resource management methods provided in embodiments of this application.

[0009] Furthermore, this application also provides a computer program product, including a computer program, which, when executed by a processor, implements any of the resource management methods provided in this application.

[0010] Furthermore, this application embodiment also provides a resource management system, which includes at least two service instances and a lock allocation instance. The at least two service instances are used to send lock allocation requests to the lock allocation instance through their threads. The lock allocation instance is used to execute any of the resource management methods provided in this application embodiment.

[0011] In this embodiment, lock allocation requests sent by at least two threads are obtained. Based on the lock allocation requests, the service functions implemented by the threads in the service instance are obtained. Based on the service functions implemented by the threads, the lock allocation priority of the threads is determined. Based on the lock allocation priority, resource locks are allocated to the threads, so that the threads compete for locks in an orderly manner, avoiding the phenomenon that a certain thread keeps failing to compete for locks, and ensuring the use of the application services corresponding to the service instance. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a schematic diagram of a resource management process provided in an embodiment of this application.

[0014] Figure 2 This is a schematic diagram of the resource management system provided in an embodiment of this application.

[0015] Figure 3 This is a flowchart illustrating the resource management method provided in the embodiments of this application.

[0016] Figure 4 This is a schematic diagram illustrating the process of determining the target hash value of the lock identifier provided in an embodiment of this application.

[0017] Figure 5 This is a schematic diagram of the hash ring and hash range provided in the embodiments of this application.

[0018] Figure 6This is a flowchart illustrating another resource management method provided in an embodiment of this application.

[0019] Figure 7 This is a schematic diagram of the thread, service instance, and first server provided in the embodiments of this application.

[0020] Figure 8 This is a schematic diagram of thread preemption of resource locks provided in an embodiment of this application.

[0021] Figure 9 This is another schematic diagram of the resource management method provided in the embodiments of this application.

[0022] Figure 10 This is a schematic diagram illustrating the process of adding a thread to a target queue and determining whether the target thread retrieved from the target queue meets the lock allocation conditions, as provided in the embodiments of this application.

[0023] Figure 11 This is a schematic diagram of the structure of the resource management device provided in the embodiments of this application.

[0024] Figure 12 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0025] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] This application provides a resource management method, apparatus, device, system, storage medium, and program product. The device can be an electronic device, the storage medium can be a computer storage medium, and the program product can be a computer program product. The resource management apparatus can be integrated into an electronic device, which can be a server or a terminal, etc.

[0027] The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery network (CDN) acceleration services, and big data and artificial intelligence platforms. Multiple servers can form a blockchain, and the server is a node on the blockchain.

[0028] The terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, etc., but is not limited to these. The terminal and the server can be connected directly or indirectly through wired or wireless communication, which is not limited herein.

[0029] For example, such as Figure 1 As shown, the terminal sends a service request to the server through at least one client of the application service. The server, through threads of at least two service instances of the application service, sends a lock allocation request to the lock allocation instance based on the service request. The lock allocation instance obtains the service functions implemented by the thread in the service instance according to the lock allocation request, determines the lock allocation priority of the thread according to the service functions implemented by the thread, allocates a resource lock to the thread according to the lock allocation priority, and responds to the service request through threads of at least two service instances according to the resource lock, and returns the response result to at least one client.

[0030] The type of application service can be set according to the actual situation. For example, the application service can be intelligent manufacturing service, manufacturing execution service or robot control service, etc. This application embodiment does not limit it.

[0031] The following is based on Figure 2 The resource management system provided in the embodiments of this application will be described.

[0032] The resource management system of this application embodiment includes at least two service instances and a lock allocation instance. The at least two service instances are used to send lock allocation requests to the lock allocation instance through threads of the at least two service instances. The lock allocation instance is used to obtain the service functions implemented by the threads in the service instances according to the lock allocation requests; determine the lock allocation priority of the threads according to the service functions implemented by the threads; and allocate resource locks to the threads according to the lock allocation priority.

[0033] In this configuration, at least two service instances and the lock allocation instance can reside on the same node. In this case, the resource management system provided in this embodiment can function as follows: Figure 2 As shown in Figure 201, or, at least two service instances and a lock allocation instance can reside on different nodes. The node where the lock allocation instance resides can be called the first node, and the nodes where the at least two service instances reside can be called the second node. The first node can include at least one instance, and the second node can include at least one instance. In this case, the resource management system can be configured as follows: Figure 2 As shown in Figure 202.

[0034] A node can be an electronic device, a virtual machine, or a container. When the node is a virtual machine or a container, the resource management method provided in this application embodiment can be executed by the electronic device where the virtual machine resides or by the electronic device where the container resides. When the node is an electronic device and the electronic device is a server, if at least two service instances and lock allocation instances are located on the same node, the resource management system is located on one server; if at least two service instances and lock allocation instances are located on different nodes, the resource management system is located on different servers.

[0035] Furthermore, in the embodiments of this application, "multiple" refers to two or more. The terms "first" and "second," etc., in the embodiments of this application are used for distinguishing descriptions and should not be construed as implying relative importance. The order of description of the following embodiments is not intended to limit the preferred order of the embodiments.

[0036] In this embodiment, the electronic device that executes the resource management method provided in this application embodiment is referred to as the electronic device. The description will be from the perspective of the electronic device. The resource management system in which the electronic device is located includes threads of at least two service instances. The electronic device can be a server or a terminal. In order to facilitate the description of the resource management method of this application, the following will take the server as the electronic device as an example for detailed description, that is, take the server as the execution subject for detailed description.

[0037] Please see Figure 3 , Figure 3 This is a flowchart illustrating a resource management method provided in an embodiment of this application. The resource management method may include: S301. Obtain lock allocation requests from at least two threads.

[0038] At least two threads can be threads from different service instances. Different service instances can be service instances targeting the same application service. An application service refers to a software program running on a computer system, used to provide specific functions. The type of application service can be set according to actual needs; for example, an application service can be a social service, a video interaction service, an item trading service, or a Manufacturing Execution System (MES), and is not limited here.

[0039] A service instance refers to a specific, runnable entity created within an application service. It represents a copy of the application service and can independently handle user requests and provide the functionality of the application service. A service instance may include at least one thread; a thread is the smallest unit of execution in an electronic device.

[0040] Service instances can reside on a server, or they can reside on other devices.

[0041] When a service instance is located on another device, when that device obtains a service request through the service instance, it can generate a lock allocation request based on the service request and send the lock allocation request to the server through the thread of the service instance.

[0042] A lock allocation request is used to request the allocation of a resource lock, which controls access to the target resource. When a thread acquires the resource lock, it can access the target resource; when a thread does not acquire the resource lock, it cannot access the target resource.

[0043] A target resource refers to a resource that affects the execution of multiple threads and is accessible to all threads. The type of target resource can be set according to the actual situation; for example, a target resource can be at least one of hardware resources, software resources, and data. Hardware resources can refer to computer resources, such as memory or a central processing unit (CPU). Software resources can be, for example, code or variables.

[0044] It is understandable that different threads can have different identifiers. The thread identifier can be set according to the actual situation, and there are no restrictions here.

[0045] In some embodiments, to ensure that different threads have different identifiers, the thread identifier can be generated based on the server address where the thread's service instance resides, the identifier of the thread's service instance, and the thread's thread identifier (TID). The server address can be the server's IP address or a proxy address.

[0046] S302. Based on the lock allocation request, obtain the service functions implemented by the thread in the service instance.

[0047] In this context, the service function implemented by a thread within a service instance can be a sub-function of the functions implemented by the service instance itself, which is the same as the function implemented by the application service. For example, if the service instance is a manufacturing execution service instance, the functions it can implement include inventory management, quality management, and procurement management. The inventory management function includes inbound management and outbound management. The service function implemented by a thread within the service instance could be the inbound management function.

[0048] After receiving a lock allocation request, the server retrieves the service functionality implemented by the thread in the service instance based on the lock allocation request. For example, if the server receives a lock allocation request from thread t1 and a lock allocation request from thread t2, it retrieves the service functionality implemented by thread t1 in the service instance based on the lock allocation request from thread t1, and retrieves the service functionality implemented by thread t2 in the service instance based on the lock allocation request from thread t2.

[0049] S303. Determine the lock allocation priority of the thread based on the service functions implemented by the thread.

[0050] Among them, the higher the lock allocation priority of a thread, the earlier the lock is allocated to that thread, that is, the earlier it is determined whether the thread meets the lock allocation conditions. The lower the lock allocation priority of a thread, the later the lock is allocated to that thread, that is, the later it is determined whether the thread meets the lock allocation conditions.

[0051] In some embodiments, the process of determining the lock allocation priority of a thread based on the service function implemented by the thread can be as follows: obtaining the priority of the service function implemented by the thread; and determining the priority of the service function as the lock allocation priority of the thread.

[0052] The priority of service functions can be pre-set. The server can determine the importance of the service functions implemented by threads based on the functions implemented by the service instances, and then pre-set the priority of the service functions according to their importance. The higher the importance of the service function, the higher its priority, and the higher the lock allocation priority of the thread; the lower the importance of the service function, the lower its priority, and the lower the lock allocation priority of the thread.

[0053] For example, if the service instance is a manufacturing execution service instance, the service function implemented by thread t1 is the inbound management function, and the service function implemented by thread t2 is the outbound management function, the outbound management function is more important than the inbound management function, and the outbound management function has a higher priority than the inbound management function. Therefore, the lock allocation priority of thread t1 is lower than the lock allocation priority of thread t2.

[0054] In this embodiment, the priority of the service function implemented by the thread is obtained, and the priority of the service function is determined as the lock allocation priority of the thread. This ensures that the lock allocation priority of the thread is determined according to the priority of the service function, thereby guaranteeing that the threads acquire locks in an orderly manner.

[0055] In some embodiments, the process of determining the lock allocation priority of a thread based on the service functions implemented by the thread can be as follows: determine the importance of the thread based on the service functions implemented by the thread; and determine the lock allocation priority of the thread based on the importance.

[0056] The higher the importance of a thread, the higher its lock allocation priority; conversely, the lower the importance of a thread, the lower its lock allocation priority.

[0057] For example, if the service instance is a manufacturing execution service instance, the service function implemented by thread t1 is the inbound management function, and the service function implemented by thread t2 is the outbound management function, the importance of thread t1 is lower than that of thread t2. Therefore, the lock allocation priority of thread t1 is lower than that of thread t2.

[0058] In this embodiment, the importance of a thread is determined based on the service function it implements, and the lock allocation priority of the thread is determined based on the importance. This ensures that not only can threads compete for locks in an orderly manner, but also that threads with higher importance are given priority in execution.

[0059] In some embodiments, the server can obtain the importance of a service function and then determine the importance of a thread based on that importance. The higher the importance of a service function, the higher the importance of the thread. The importance of the service function can be a pre-set level.

[0060] In some embodiments, a resource lock is used to control access to a target resource. Determining the importance of a thread based on the service functions implemented by the thread includes: determining the importance of the thread based on the service functions implemented by the thread and the target resource.

[0061] In this context, the target resource refers to a resource that affects the execution of multiple threads and is accessible to all threads. The type of target resource can be set according to the actual situation; for example, the target resource can be at least one of hardware resources, software resources, and data. Hardware resources can refer to computer resources, such as memory resources or central processing unit (CPU) resources. Software resources can be, for example, code or variables.

[0062] Since the importance of a thread may vary depending on the target resource, in this embodiment, the importance of a thread can be determined based on the service function implemented by the thread and the target resource, making the determined importance of the thread more accurate.

[0063] In some embodiments, the process of determining the importance of a thread based on the service functions implemented by the thread and the target resource can be as follows: determining the importance of the service functions implemented by the thread based on the target resource; and determining the importance of the thread based on the importance of the service functions implemented by the thread.

[0064] This allows us to determine the importance of the service functions implemented by the thread based on the current resource information of the target resource. The current resource information refers to the specific state of the target resource. For example, if the target resource is data and the data is inventory, and the inventory is 1000, then the current resource information is 1000.

[0065] The method for determining the importance of the service functions implemented by the thread based on the current resource information can be set according to the actual situation. For example, the current resource information can be mapped through a mapping table to obtain the importance of the service functions implemented by the thread. Alternatively, the current resource information can be input into a trained recognition neural network model for recognition to obtain the importance of the service functions. This application embodiment does not limit this.

[0066] The importance of service functions varies depending on the current resource information. For example, if the target resource is inventory quantity and the service function is inbound management, the importance of inbound management is higher when the inventory quantity is low and lower when the inventory quantity is high.

[0067] In this embodiment, since the importance of service functions may differ depending on the current resource information of the target resource, the importance of the service functions implemented by the thread can be determined based on the target resource, and the importance of the thread can be determined based on the importance of the service functions implemented by the thread, so that the importance of the service functions changes dynamically and the accuracy of the determined importance of the thread is improved.

[0068] In some embodiments, determining the importance of a thread based on the service functions implemented by the thread and the target resource includes: determining the dependencies between the service functions implemented by the thread based on the target resource; and determining the importance of the threads corresponding to the service functions that have dependencies based on the dependencies, wherein the threads of the dependent service functions are of higher importance.

[0069] In this context, dependency refers to a relationship where one thread must complete its execution before another thread can successfully execute. For example, consider a target resource that is data, specifically inventory quantity, with an initial inventory quantity of 0. The threads include thread t1 and thread t2. Thread t1 implements an outbound inventory management function, while thread t2 implements an inbound inventory management function. If thread t1 executes before thread t2, the 0 inventory quantity will cause thread t1 to fail. Therefore, thread t2 can be executed first, followed by thread t1. Thread t1 depends on the execution of thread t2, and a dependency relationship exists between them. Thread t2 is the thread that provides the dependent service function, and its importance is higher than that of thread t1.

[0070] Understandably, if there are service functions that have no dependencies, the importance of the threads of those service functions can be determined based on the pre-set importance of those service functions.

[0071] In this embodiment, the dependencies between service functions implemented by threads are determined based on the target resource. Based on the dependencies, the importance of the threads corresponding to the service functions with dependencies is determined. Among them, the threads of the dependent service functions have higher importance. This realizes the determination of thread importance based on dependencies and improves the accuracy of the determined thread importance.

[0072] In some embodiments, determining the importance of a thread based on the service functions implemented by the thread and the target resource includes: if it is determined that all threads can be executed based on the target resource, then determining the importance of the thread based on the importance of the service functions of the thread.

[0073] The importance of a thread's service function is pre-defined. The server can pre-determine the importance of the service functions implemented by threads based on the functions implemented by the service instances. When it is determined that all threads can execute based on the target resource, it means that there is no dependency between the threads. In this case, the importance of a thread can be determined based on the importance of its service function: the higher the importance of its service function, the higher the importance of the thread; the lower the importance of its service function, the lower the importance of the thread.

[0074] For example, if the target resource is data and the data is inventory, and the service functions implemented by the thread include material issuance and inventory management, then when the inventory is sufficient, the importance of the thread can be determined based on the pre-set importance of the material issuance and inventory management functions.

[0075] In this embodiment, if it is determined that all threads can be executed based on the target resource, then the importance of the threads is determined based on the importance of their service functions, thereby improving the accuracy of determining the importance of threads.

[0076] In some embodiments, determining the lock allocation priority of a thread based on the service function implemented by the thread includes: if the thread includes multiple first threads targeting the same client, then based on the request time of the multiple first threads, deduplicating the first threads in the thread to obtain a deduplicated thread, wherein the multiple first threads are threads implementing the same service function under at least two service instances; and determining the lock allocation priority of the deduplicated thread based on the service function implemented by the deduplicated thread.

[0077] In this context, multiple first threads for the same client can be understood as multiple first threads responding to service requests sent by the same client. When multiple threads respond to the same client's service requests, it indicates that the same client has initiated multiple service requests. Since multiple service requests from the same client, and the threads responding to these requests, may contain identical service requests, only one of these identical requests needs to be responded to. Therefore, when a thread includes multiple first threads for the same client with identical service functions, deduplication can be performed on the first threads based on their request times, resulting in a deduplicated thread.

[0078] Specifically, when the difference between request times is within a preset range, it indicates that there is a high probability that multiple first threads are responding to the same service request. Therefore, only one second thread can be retained to achieve deduplication of the first threads. The second thread refers to the first thread whose request time is within the preset range.

[0079] For example, if a client initiates two submission requests for the same order within a short period of time, service instance e1 sends a lock allocation request through thread t1 based on one submission request, and service instance e2 sends a lock allocation request through thread t2 based on the other submission request. Since threads t1 and t2 implement the same service functions, in this case, only thread t1 or thread t2 can be retained.

[0080] In this embodiment of the application, if a thread includes multiple first threads targeting the same client, then based on the request time of the multiple first threads, the first threads are deduplicated in the thread to obtain a deduplicated thread. The multiple first threads are threads that implement the same service function under at least two service instances, thereby reducing the number of threads that perform lock allocation, and thus reducing the computer resources consumed when performing lock allocation.

[0081] S304. Allocate resource locks to threads according to lock allocation priority.

[0082] The process of allocating a resource lock to a thread based on the lock allocation priority can be as follows: select a target thread from the threads according to the lock allocation priority; determine whether the target thread meets the lock allocation conditions; if the target thread meets the lock allocation conditions, then allocate a resource lock to the target thread.

[0083] In this process, the thread with the highest priority can be selected first, and this thread becomes the target thread. A lock allocation instance can be used to determine whether the target thread meets the lock allocation conditions. The implementation of the lock allocation instance can be set according to the actual situation; for example, it can be implemented using Redis or Zookeeper. This embodiment of the application does not limit this approach.

[0084] The following describes the process of implementing a lock allocation instance using Redis, and determining whether a target thread meets the lock allocation conditions using the lock allocation instance. The process is as follows: a resource lock acquisition command is sent to the lock allocation instance; the lock allocation instance, based on the acquisition command, checks if a key identifier corresponding to the resource lock exists; if a key identifier corresponding to the resource lock exists, the target thread is determined not to meet the lock allocation conditions; if a key identifier corresponding to the resource lock does not exist, the target thread is determined to meet the lock allocation conditions, and the key identifier corresponding to the resource lock is created.

[0085] The command to acquire a resource lock is called the `SETNX` command, and the key identifier is also called the key in a key-value pair. The `SETNX` command is used to create key-value pairs in Redis. The `SETNX` command can only execute successfully if there is no key corresponding to the resource lock in Redis. Therefore, if a key identifier for a resource lock exists, it means that the resource lock is being held by another thread, and the `SETNX` command will fail because the target thread does not meet the lock allocation conditions. If no key identifier exists, it means that the resource lock is not being held by another thread, and the `SETNX` command will execute successfully because the target thread meets the lock allocation conditions.

[0086] The following describes an example of lock allocation using ZooKeeper, and how to determine if a target thread meets the lock allocation conditions. The process is as follows: Using the lock allocation instance, a sequence node corresponding to the target thread is created under the root node in ZooKeeper. The root node is the node corresponding to the resource lock in ZooKeeper. The lock allocation instance then checks if the sequence node corresponding to the target thread is the smallest sequence node under the root node. If it is, the target thread meets the lock allocation conditions; otherwise, it does not.

[0087] In ZooKeeper, sequential nodes are assigned numbers based on their creation time. Smaller numbers indicate earlier creation. When a sequential node has the smallest number, it means it was created earliest, and in this case, the thread corresponding to that node is deemed to meet the lock allocation conditions.

[0088] In some embodiments, selecting a target thread from the threads according to the lock allocation priority includes: adding the thread to a target sequence that matches the lock allocation priority; and retrieving the target thread from the target sequence with a higher lock allocation priority.

[0089] In this context, the target sequence that matches the lock allocation priority can be understood as having a priority equal to that lock allocation priority. For example, if the lock allocation priorities include p1, p2, and p3, and the target sequences include sequences q1, q2, and q3, with sequence q1 having a lock allocation priority of p1, sequence q2 having a lock allocation priority of p2, and sequence q3 having a lock allocation priority of p3, then if a thread's lock allocation priority is p1, the target sequence that matches the lock allocation priority is sequence q1, and the thread is added to sequence q1.

[0090] The target sequence may include at least one, and the number of target sequences may be set according to the actual situation. For example, the target sequences may include two or three, but this embodiment of the application does not limit this.

[0091] The target sequence can be a first-in, first-out (FIFO) sequence, or it can be a last-in, first-out (LIFO) sequence. When the target sequence is FIFO, it can be, for example, a queue. When the target sequence is LIFO, it can be, for example, a stack.

[0092] Understandably, if the target sequence that matches the lock allocation priority has reached its limit, then the thread can be added to the target sequence containing a lock allocation priority that is lower than the lock allocation priority but adjacent to it.

[0093] For example, the target sequence includes sequence q1 and sequence q2. The lock allocation priority of sequence q1 is p1, and the lock allocation priority of sequence q2 is p2. p1 is greater than p2 and adjacent to p2. If the lock allocation priority of a thread is p1 and the number of threads stored in sequence q1 has reached the limit, then the thread is added to sequence q2.

[0094] In this embodiment, the thread is added to the target sequence that matches the lock allocation priority according to the lock allocation priority of the thread, and the target thread is taken out from the target sequence with higher lock allocation priority. This realizes that the lock allocation priority of the thread is represented by different target sequences, so that the thread with higher lock allocation priority has priority to preempt the resource lock.

[0095] In some embodiments, retrieving a target thread from a target sequence with high lock allocation priority can be understood as retrieving target threads sequentially from the target sequence according to their lock allocation priority. Specifically, it can be done by querying whether a thread exists in the first target sequence. If a thread exists, the target thread is retrieved from the first target sequence. If no thread exists, the third target sequence is used as the first target sequence, and the step of querying whether a thread exists in the first target sequence is returned. The lock allocation priority of the third target sequence is adjacent to and lower than that of the first target sequence.

[0096] For example, the target sequence includes sequence q1, sequence q2, and sequence q3. The lock allocation priority of sequence q1 is higher than that of sequence q2, and the lock allocation priority of sequence q2 is higher than that of sequence q3. Sequence q1 is the first target sequence. First, it is checked whether a thread exists in sequence q1. If a thread exists in sequence q1, the target thread is taken from sequence q1. If no thread exists in sequence q1, then sequence q2 is the third target sequence. It is checked whether a thread exists in sequence q2. If a thread exists in sequence q2, the target thread is taken from sequence q2. If no thread exists in sequence q2, then sequence q3 is the third target sequence. It is checked whether a thread exists in sequence q3. If a thread exists in sequence q3, the target thread is taken from sequence q3.

[0097] Alternatively, retrieving the target thread from the target sequence with high lock allocation priority can be understood as querying each target sequence separately to retrieve candidate threads. Then, based on the lock allocation priority of the target sequence containing the candidate thread, the target thread is determined from the candidate threads. In this case, retrieving the target thread from the target sequence with high lock allocation priority includes: querying each target sequence; if a candidate thread is found in the first target sequence, then it is determined whether the number of threads in the second target sequence is equal to zero, and the lock allocation priority of the second target sequence is higher than that of the first target sequence; if the number of threads in the second target sequence is equal to zero, then the candidate thread is determined as the target thread.

[0098] Here, the first target sequence refers to the target sequence from which candidate threads can be extracted. When the number of threads in the second target sequence is zero, it means that the target thread cannot be extracted from the second target sequence, indicating that there is no thread with a higher lock allocation priority than the candidate thread. Therefore, the candidate thread can be identified as the target thread, ensuring that the thread with the higher lock allocation priority is allocated the lock first. When the number of threads in the second target sequence is greater than zero, it means that the target thread can be extracted from the second target sequence, indicating that there is a thread with a higher lock allocation priority than the candidate thread. Therefore, the candidate thread is not identified as the target thread. In this case, the candidate thread is controlled to be in a waiting state. After the duration of the waiting state reaches the target duration, the step of judging whether the number of threads in the second target sequence is equal to zero is returned.

[0099] For example, the target sequence includes sequence q1, sequence q2, and sequence q3. The lock allocation priority of sequence q1 is higher than that of sequence q2, and the lock allocation priority of sequence q2 is higher than that of sequence q3. When querying sequences q1, q2, and q3, if a candidate thread is found in sequence q2, then sequence q2 becomes the first target sequence, and sequence q1 becomes the second target sequence. Since the number of threads in sequence q1 is zero, it means that no thread can be retrieved from sequence q1. Therefore, the lock allocation priority of the candidate thread found in sequence q2 is the highest priority, and the candidate thread is determined as the target thread.

[0100] Understandably, a target sequence can be either a first target sequence or a second target sequence. For example, the target sequence includes sequences q1, q2, and q3. The lock allocation priority of sequence q1 is higher than that of sequence q2, and the lock allocation priority of sequence q2 is higher than that of sequence q3. When querying sequences q1, q2, and q3, if a candidate thread is found from sequence q2, then sequence q2 is the first target sequence and sequence q1 is the second target sequence. If a candidate thread is found from sequence q3, then sequence q3 is the first target sequence, and sequences q1 and q2 are the second target sequences. When candidate threads are found from both sequences q2 and q3, for sequence q2, sequence q2 is the first target sequence and sequence q1 is the second target sequence; for sequence q3, sequence q3 is the first target sequence, and sequences q1 and q2 are the second target sequences.

[0101] In this embodiment of the application, each target sequence is queried. If a candidate thread is found in the first target sequence, it is determined whether the number of threads in the second target sequence is equal to zero. The lock allocation priority of the second target sequence is higher than the lock allocation priority of the first target sequence. If the number of threads in the second target sequence is equal to zero, the candidate thread is determined as the target thread, so that the target thread can be guaranteed to be the thread with the highest lock allocation priority, thereby ensuring that the thread with the highest lock allocation priority has priority to preempt the resource lock.

[0102] In some embodiments, after determining whether the target thread meets the lock allocation conditions, this application embodiment further includes: if the target thread does not meet the lock allocation conditions, controlling the target thread to be in a waiting state; after the duration of the waiting state reaches the target duration, returning to the step of determining whether the target thread meets the lock allocation conditions.

[0103] The target duration is a preset duration, which can be set according to actual conditions; this embodiment does not limit it. The waiting state refers to the state in which the target thread is suspended from execution, such as a blocked state or a sleeping state.

[0104] After the waiting time reaches the target duration, the target thread can be kept in a running state so that the execution can return to the step of determining whether the target thread meets the lock allocation conditions.

[0105] In this embodiment, if the target thread does not meet the lock allocation conditions, the target thread is controlled to be in a waiting state. After the duration of the waiting state reaches the target duration, the step of judging whether the target thread meets the lock allocation conditions is returned, thereby saving the central processing unit.

[0106] In some embodiments, the present application further includes: obtaining the cumulative duration of the target thread in a waiting state; if the cumulative duration is equal to or greater than a preset waiting time, reducing the lock allocation priority of the target thread, and returning to the step of selecting the target thread from the threads according to the lock allocation priority.

[0107] The cumulative duration refers to the total duration during which the target thread is in a waiting state. In other words, the cumulative duration is the duration obtained by summing the target duration, or, if the target thread is in a waiting state only once, the cumulative duration is the target duration.

[0108] For example, if the target duration is T1, the target thread is retrieved from the threads. It is determined whether the target thread meets the lock allocation condition. If the target thread does not meet the lock allocation condition, it is put into a waiting state. After the waiting state lasts for T1 hours, the target thread is put into a running state, and it is determined whether the target thread meets the lock allocation condition again. If the target thread does not meet the lock allocation condition, it is put into a waiting state. After the waiting state lasts for T1 hours, the target thread is put into a running state, and it is determined whether the target thread meets the lock allocation condition again. If the target thread does not meet the lock allocation condition, the cumulative duration is 2T1.

[0109] The preset waiting time is a pre-set time, which can be set according to the actual situation. This application embodiment does not limit it here.

[0110] If the cumulative duration is equal to or greater than the preset waiting time, the lock allocation priority of the target thread is reduced, and the process of selecting the target thread from the threads based on the lock allocation priority is returned, causing the target thread to exit the lock allocation process.

[0111] Lowering the lock allocation priority of the target thread can be understood as lowering the lock allocation priority by at least one level. For example, the lock allocation priorities include p1, p2, and p3, where p1 is greater than p2 and adjacent to p2, and p2 is greater than p3 and adjacent to p3. If the lock allocation priority of the target thread is p1, then after lowering the lock allocation priority of the target thread, the lock allocation priority of the target thread can be p2 or p3.

[0112] It is understandable that when a target thread is removed from a target sequence, lowering the lock allocation priority of the target thread can add the target thread to a target sequence with a lock allocation priority lower than that of the target sequence in which the target thread is located.

[0113] For example, the target sequence includes sequence q1 and sequence q2. The lock allocation priority of sequence q1 is p1, and the lock allocation priority of sequence q2 is p2. p1 is greater than p2 and adjacent to p2. The target thread is taken out from sequence q1. If the cumulative waiting time of the target thread is equal to or greater than the preset waiting time, the target thread is added to sequence q2.

[0114] In this embodiment, the cumulative duration of the target thread in the waiting state is obtained. If the cumulative duration is equal to or greater than the preset waiting time, the lock allocation priority of the target thread is reduced, and the process of selecting the target thread from the threads according to the lock allocation priority is returned. This realizes the process of reducing the lock allocation priority of the thread and exiting the lock allocation process, avoiding the target thread from being blocked or sleeping for a long time, and alleviating the thread congestion situation.

[0115] In some embodiments, the resource management system includes at least two lock allocation instances, which are used to determine whether a target thread meets the lock allocation conditions. Both lock allocation instances may include relevant data about the resource lock.

[0116] In some embodiments, the resource management system includes at least two lock allocation instances, and the lock allocation request also includes a lock identifier of the resource lock. Determining whether the target thread meets the lock allocation conditions includes: determining the hash value corresponding to the lock identifier; determining the target lock allocation instance to allocate the resource lock based on the hash value and the hash value of the lock allocation instance; and determining whether the target thread meets the lock allocation conditions through the target lock allocation instance.

[0117] Here, a lock allocation instance refers to an entity used for lock allocation, which can include multiple instances. First, the hash value of the lock allocation instance can be calculated. Then, after determining the hash value corresponding to the lock identifier, the target lock allocation instance for allocating the resource lock is determined based on the hash value corresponding to the lock identifier and the hash value of the lock allocation instance. This allows the determination of whether the target thread meets the lock allocation conditions.

[0118] In this embodiment, the hash value corresponding to the lock identifier is determined. Based on the hash value and the hash value of the lock allocation instance, the target lock allocation instance for allocating the resource lock is determined. Through the target lock allocation instance, it is determined whether the target thread meets the lock allocation conditions. This ensures that only the target lock allocation instance needs to store the relevant data of the resource lock. The relevant data of the resource lock includes the lock identifier of the resource lock and the status of the resource lock, etc., avoiding the need for all lock allocation instances to store the relevant data of the resource lock, thus saving memory.

[0119] In some embodiments, determining the target lock allocation instance for allocating the resource lock based on the hash value and the hash value of the lock allocation instance includes: determining the hash value ring in which the lock allocation instance is located; taking the modulo of the hash value of the lock identifier with the maximum hash value of the hash value ring to obtain the target hash value; and determining the target lock allocation instance for allocating the resource lock based on the target hash value and the hash value range of each lock allocation instance in the hash value ring.

[0120] The lock allocation instance corresponding to the hash value range where the target hash value is located is the target lock allocation instance.

[0121] For example, lock allocation instances include lock allocation instance s1, lock allocation instance s2, and lock allocation instance s3. The hash value of a lock allocation instance can be obtained by mapping the server address where the lock allocation instance resides. If the server address is ABCD, after hash mapping ABCD, the hash value of the lock allocation instance can be obtained as 0~2. 32 The value is between -1 and 2, therefore, the maximum hash value of the hash ring where the lock allocation instance resides is 2. 32-1, the hash value pair corresponding to the lock identifier (2 32 -1) Take the modulo to get the target hash value, such as Figure 4 As shown ( Figure 4 In this context, `hashcode` is the target hash value, and `hash(key1)` is the hash value. If the hash value of lock allocation instance s1 is 3232249857, the hash value of lock allocation instance s2 is 2130706433, and the hash value of lock allocation instance s3 is 4394967041, then the hash value range for lock allocation instance s2 is 4394967041-2130706433, the hash value range for lock allocation instance s1 is 2130706433-3232249857, and the hash value range for lock allocation instance s3 is 3232249857-4394967041. If the hash value pair of the lock identifier (2...) is... 32 -1) Taking the modulo, the target hash value is 370451254. Therefore, the hash value range of the target hash value is 4394967041-2130706433. For example... Figure 5 As shown, lock allocation instance s2 is the target lock allocation instance.

[0122] In some embodiments, the lock allocation instance is located in the lock allocation component. In this case, the lock allocation instance can be called through the interface of the lock allocation component, thereby modularizing the lock allocation instance and enabling any service instance to call the lock allocation instance, thus improving the call flexibility of the lock allocation instance.

[0123] In some embodiments, the lock allocation instance resides in the distributed platform of the resource management system. In this case, the lock allocation instance is implemented through the distributed platform, and the resource lock can also be called a distributed lock. The type of distributed platform can be set according to the actual situation. For example, the distributed platform can be Redis or Zookeeper, and this embodiment of the application does not limit it.

[0124] When the resource lock is a distributed lock, the distributed lock is a non-fair lock. The resource management method provided in this application embodiment can transform the non-fair lock into a fair lock.

[0125] In this embodiment, lock allocation instances are implemented through a distributed platform, which is not limited to a single platform, improves the flexibility of lock allocation, and thus improves the availability of the resource management system.

[0126] In some embodiments, when the lock allocation instance is located in the lock allocation component, the lock allocation component may be located in a distributed platform.

[0127] In some embodiments, at least two lock allocation requests sent by threads can be obtained through any lock allocation instance. Based on the lock allocation requests, the service functions implemented by the threads in the service instance can be obtained, and the lock allocation priority of the threads can be determined based on the service functions implemented by the threads.

[0128] As can be seen from the above, in this embodiment of the application, at least two lock allocation requests sent by threads are obtained. Based on the lock allocation requests, the service functions implemented by the threads in the service instance are obtained. Based on the service functions implemented by the threads, the lock allocation priority of the threads is determined. Based on the lock allocation priority, resource locks are allocated to the threads, so that the threads compete for locks in an orderly manner, avoiding the phenomenon that a certain thread fails to compete for locks all the time, and ensuring the use of the application services corresponding to the service instance.

[0129] Based on the method described in the above embodiments, the following will provide further detailed examples. In this embodiment, the resource management system includes a first node and a second node. The first node is a node where at least two service instances reside, and the second node is a node where a lock service instance resides. The first node can be a first server, the second node can be a second server, and the target sequence is a target queue.

[0130] Please see Figure 6 , Figure 6 This is a flowchart illustrating a resource management method provided in an embodiment of this application. The resource management method may include: S601, The first server receives at least two service requests sent by the client.

[0131] S602. The first server sends a lock allocation request to the second server based on at least two service requests through threads of at least two service instances.

[0132] The first server may include at least one, and at least two service instances may reside on the same first server or on different first servers. A service instance may include at least one thread, such as... Figure 7 As shown.

[0133] Since at least two service instances' threads need to acquire resource locks before they can continue running, the first server can send a lock allocation request to the second server.

[0134] S603. When the second server receives a lock allocation request, it obtains the service functions implemented by the thread in the service instance according to the lock allocation request through the lock allocation instance.

[0135] After receiving a lock allocation request, the second server can obtain the service functions implemented by the thread in the service instance through the lock allocation instance, so as to determine whether the thread meets the lock allocation conditions based on the service functions implemented by the thread.

[0136] For example, such as Figure 8 As shown, the threads include thread t1, thread t2, and thread t3. Threads t1, t2, and t3 need to acquire resource lock 1 to continue running. It can be determined whether the threads meet the lock allocation conditions by checking the lock allocation instance. Alternatively, the threads include thread t4, thread t5, and thread t6. Threads t4, t5, and t6 need to acquire resource lock 2 to continue running. It can also be determined whether the threads meet the lock allocation conditions by checking the lock allocation instance.

[0137] S604. If a thread includes multiple first threads targeting the same client, the second server allocates instances through locks, and based on the request time of the multiple first threads, performs deduplication on the first threads in the thread to obtain the deduplicated thread. Among them, the multiple first threads are threads that implement the same service function under at least two service instances.

[0138] S605. The second server determines the importance of a thread by allocating lock instances based on the service functions implemented by the deduplicated threads, and determines the lock allocation priority of the threads based on their importance.

[0139] S606. The second server, through the lock allocation instance, adds threads to the target queue that matches the lock allocation priority, based on the lock allocation priority.

[0140] For example, there can be three target queues, which can be queue q1, queue q2, and queue q3 respectively. Figure 9 As shown.

[0141] It is understandable that adding a thread to a target queue that matches the lock allocation priority can be understood as adding the thread's identifier to the target queue that matches the lock allocation priority.

[0142] Optionally, the capacity of a target queue with a higher lock allocation priority can be lower, and the capacity of a target queue with a lower lock allocation priority can be higher. For example, there can be three target queues: queue q1, queue q2, and queue q3. The lock allocation priority of queue q1 is higher than that of queue q2, and the lock allocation priority of queue q2 is higher than that of queue q3. The capacity of queue q1 is 1000, the capacity of queue q2 is 2000, and the capacity of queue q3 is unlimited. Figure 9 As shown.

[0143] S607. The second server retrieves the target thread from the target queue with high lock allocation priority through the lock allocation instance.

[0144] The second server can determine whether the target queue matching the lock allocation priority can still store threads based on the lock allocation priority. If the target queue matching the lock allocation priority is not full, it means that the target queue matching the lock allocation priority can still store threads, and the thread is added to the target queue matching the lock allocation priority. If the target queue matching the lock allocation priority is full, it means that the target queue matching the lock allocation priority cannot store threads, and the thread is added to the target queue with a lock allocation priority lower than that of the target queue.

[0145] After the second server adds the thread to the target queue, it can query each target queue. If a candidate thread is found in the first target sequence, it determines whether the number of threads in the second target sequence is equal to zero. The lock allocation priority of the second target sequence is higher than that of the first target sequence. If the number of threads in the second target sequence is equal to zero, the candidate thread is determined as the target thread.

[0146] For example, such as Figure 10 As shown, the target queues include queues q1, q2, and q3. The lock allocation priority p1 of queue q1 is higher than that of queue q2, and the lock allocation priority p2 of queue q2 is higher than that of queue q3. If a thread's lock allocation priority is p1 and queue q1 is not full, the thread is added to queue q1. If a thread's lock allocation priority is p1 and queue q1 is full, the thread is added to queue q2. If a thread's lock allocation priority is p2 and queue q2 is not full, the thread is added to queue q2. If a thread's lock allocation priority is p2 and queue q2 is full, the thread is added to queue q3. If a thread's lock allocation priority is p3, the thread is added to queue q3. Queues q1, q2, and q3 are queried to find candidate threads from them.

[0147] After retrieving the candidate thread from queue q1, since queue q1 has the highest lock allocation priority, the candidate thread retrieved from queue q1 is the target thread. The target thread preempts the resource lock, and the lock allocation process is completed.

[0148] After retrieving candidate threads from queue q2, it checks whether the number of threads in queue q1 is zero. If the number of threads in queue q1 is zero, the candidate thread retrieved from queue q2 is determined as the target thread. If the number of threads in queue q1 is greater than zero, it checks whether the cumulative waiting time of the candidate thread is greater than the preset waiting time. If it is greater than the preset waiting time, the candidate thread retrieved from queue q2 is added to queue q3. If it is less than the preset waiting time, the candidate thread retrieved from queue q2 is kept in a waiting state. After the duration of the waiting state reaches the target duration, the process returns to the step of checking whether the number of threads in queue q1 is zero.

[0149] After retrieving a candidate thread from queue q3, it checks whether the number of threads in queue q1 and queue q2 is zero. If both queue q1 and queue q2 are zero, the candidate thread retrieved from queue q3 is identified as the target thread. If the number of threads in queue q1 is greater than zero and / or the number of threads in queue q2 is greater than zero, it checks whether the cumulative waiting time of the candidate thread is greater than a preset waiting time. If it is greater than the preset waiting time, the candidate thread retrieved from queue q3 exits the lock allocation process. If it is less than the preset waiting time, the candidate thread retrieved from queue q3 is kept in a waiting state. After the duration of the waiting state reaches the target duration, the process returns to check whether the number of threads in queue q1 and queue q2 is zero.

[0150] S608. The second server determines the target lock allocation instance from the lock allocation instances to allocate the resource lock.

[0151] S609. The second server determines whether the target thread meets the lock allocation conditions by using the target lock allocation instance.

[0152] S6010. If the target thread meets the lock allocation conditions, the second server will send the resource lock to the target thread of the first server.

[0153] If the target thread meets the lock allocation conditions, it means that the target thread has successfully acquired the resource lock; if the target thread does not meet the allocation conditions, it means that the target thread has failed to acquire the resource lock.

[0154] S6011. The first server controls the target thread and accesses the target resource based on the resource lock in response to service requests.

[0155] S6012. If the target thread does not meet the lock allocation conditions, the second server notifies the first server so that the first server controls the target thread to be in a waiting state. After the duration of the waiting state reaches the target duration, the second server returns to the execution step S609. When the cumulative duration of the waiting state is equal to or greater than the preset waiting time, the second server reduces the lock allocation priority of the target thread and returns to the execution step S607.

[0156] The resource management method provided in this embodiment may include two parts: a hierarchical part and a lock allocation part, such as... Figure 9 As shown, the hierarchical part is executed through the lock allocation instance, and the lock allocation part is executed through the target lock allocation instance.

[0157] During the hierarchical process, based on the lock allocation request, the resource lock identifier is initialized, threads are deduplicated, the importance of the thread is determined according to the service function implemented by the deduplicated thread, and the lock allocation priority of the thread is determined according to the importance. According to the lock allocation priority, the thread is added to the target queue that matches the lock allocation priority, and each target queue is queried in order to retrieve the target thread.

[0158] In the lock allocation section, it is determined whether the target thread meets the lock allocation conditions. If the target thread meets the lock allocation conditions, the resource lock is returned to the first server. The first server controls the target thread to access the target resource based on the resource lock to respond to the service request. If the target thread does not meet the lock allocation conditions, it is determined whether the cumulative duration of the target thread in the waiting state is equal to or greater than the preset waiting time. If the cumulative duration is less than the preset waiting time, the second server is notified to control the target thread to be in a waiting state so that after the duration of the current waiting state reaches the target duration, the second server returns to execute step S609. If the cumulative duration is equal to or greater than the preset waiting time, the target thread is controlled to exit the lock allocation process.

[0159] The tiered section also includes: when the cumulative waiting time is equal to or greater than the preset waiting time, the second server reduces the lock allocation priority of the target thread and returns to execution step S607.

[0160] That is, the hierarchical part includes deduplication, determining lock allocation priority, lowering lock allocation priority, and queuing threads. The lock allocation part includes determining the target lock allocation instance, determining the lock identifier of the resource lock, the thread waiting process, cyclic allocation of resource locks, and the thread execution process.

[0161] Understandably, a thread can release the resource lock after execution so that it can be used by other threads.

[0162] For the explanation of terms, specific implementation methods, and corresponding beneficial effects of this embodiment, please refer to the above resource management embodiment. This embodiment is not limited here.

[0163] To facilitate better implementation of the resource management method provided in the embodiments of this application, the embodiments of this application also provide an apparatus based on the above-described resource management method. The meanings of the terms used are the same as in the resource management method described above, and specific implementation details can be found in the descriptions in the method embodiments.

[0164] For example, such as Figure 11 As shown, this is applied to an electronic device, where the resource management system of the electronic device includes threads for at least two service instances. The resource management device may include: The request acquisition module 1101 is used to acquire lock allocation requests sent by at least two threads.

[0165] The function acquisition module 1102 is used to acquire the service functions implemented by the thread in the service instance based on the lock allocation request.

[0166] The determination module 1103 is used to determine the lock allocation priority of a thread based on the service functions implemented by the thread.

[0167] The allocation module 1104 is used to allocate resource locks to threads based on lock allocation priority.

[0168] Optionally, the determining module 1103 is specifically used to perform the following: determining the importance of a thread based on the service functions implemented by the thread; and determining the lock allocation priority of the thread based on its importance. Optionally, the resource lock is used to control access to the target resource, and the determining module 1103 is specifically used to perform the following: determining the importance of a thread based on the service functions implemented by the thread and the target resource. Optionally, the determining module 1103 is specifically used to perform the following: determining the dependencies between the service functions implemented by the thread based on the target resource; and determining the importance of the threads corresponding to the dependent service functions based on the dependencies, wherein the threads of the dependent service functions have higher importance. Optionally, the determining module 1103 is specifically used to perform the following: if it is determined that all threads can execute based on the target resource, then the importance of the thread is determined based on the importance of its service functions. Optionally, the determining module 1103 is specifically used to perform the following: if the thread includes multiple first threads targeting the same client, then based on the request time of the multiple first threads, deduplicating the first threads in the thread to obtain deduplicated threads, wherein the multiple first threads are threads implementing the same service function under at least two service instances; and determining the lock allocation priority of the deduplicated threads according to the service function implemented by the deduplicated threads. Optionally, the allocating module 1104 is specifically used to perform the following: select a target thread from the threads according to the lock allocation priority; determine whether the target thread meets the lock allocation conditions; if the target thread meets the lock allocation conditions, allocate a resource lock to the target thread. Optionally, the allocating module 1104 is specifically used to perform the following: add the thread to the target sequence matching the lock allocation priority according to the thread's lock allocation priority; and retrieve the target thread from the target sequence with higher lock allocation priority. Optionally, the allocation module 1104 is specifically used to perform: querying each target sequence; if a candidate thread is found in the first target sequence, then determining whether the number of threads in the second target sequence is equal to zero, and the lock allocation priority of the second target sequence is higher than the lock allocation priority of the first target sequence; if the number of threads in the second target sequence is equal to zero, then the candidate thread is determined as the target thread. Optionally, the allocation module 1104 is also used to perform: if the target thread does not meet the lock allocation conditions, controlling the target thread to be in a waiting state; after the duration of the waiting state reaches the target duration, returning to the step of determining whether the target thread meets the lock allocation conditions. Optionally, the allocation module 1104 is also used to perform: obtaining the cumulative duration of the target thread in the waiting state; if the cumulative duration is equal to or greater than the preset waiting time, then reducing the lock allocation priority of the target thread, and returning to the step of selecting the target thread from the threads according to the lock allocation priority.Optionally, the resource management system includes at least two lock allocation instances. The lock allocation request also includes the lock identifier of the resource lock. The allocation module 1104 is specifically used to perform the following: determine the hash value corresponding to the lock identifier; determine the target lock allocation instance for allocating the resource lock based on the hash value and the hash value of the lock allocation instance; and determine whether the target thread meets the lock allocation conditions through the target lock allocation instance. Optionally, the allocation module 1104 is specifically used to perform the following: determine the hash value ring in which the lock allocation instance is located; take the modulo of the hash value of the lock identifier with the maximum hash value of the hash value ring to obtain the target hash value; and determine the target lock allocation instance for allocating the resource lock based on the target hash value and the hash value range of each lock allocation instance in the hash value ring. Optionally, the lock allocation instance is located in the lock allocation component. Optionally, the lock allocation instance is located in the distributed platform of the resource management system.

[0169] In practice, each of the above modules can be implemented as an independent entity or can be combined arbitrarily to be implemented as the same or several entities. For the specific implementation methods and corresponding beneficial effects of each of the above modules, please refer to the previous method embodiments, which will not be repeated here.

[0170] This application also provides an electronic device, which may be a server or a terminal, etc. Figure 12 As shown, it illustrates a structural schematic diagram of the electronic device involved in the embodiments of this application, specifically: The electronic device may include components such as a processor 1201 with one or more processing cores, a memory 1202 with one or more computer-readable storage media, a power supply 1203, and an input unit 1204. Those skilled in the art will understand that... Figure 12 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0171] The processor 1201 is the control center of the electronic device, connecting various parts of the device via various interfaces and lines. It executes computer programs and / or modules stored in the memory 1202, and calls data stored in the memory 1202 to perform various functions and process data. Optionally, the processor 1201 may include one or more processing cores; preferably, the processor 1201 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 1201.

[0172] The memory 1202 can be used to store computer programs and modules. The processor 1201 executes various functional applications and data processing by running the computer programs and modules stored in the memory 1202. The memory 1202 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, computer programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 1202 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 1202 may also include a memory controller to provide the processor 1201 with access to the memory 1202.

[0173] The electronic device also includes a power supply 1203 that supplies power to various components. Preferably, the power supply 1203 can be logically connected to the processor 1201 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 1203 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0174] The electronic device may also include an input unit 1204, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0175] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 1201 in the electronic device loads the executable files corresponding to the processes of one or more computer programs into the memory 1202 according to the following instructions, and the processor 1201 runs the computer programs stored in the memory 1202 to realize various functions, such as: obtaining lock allocation requests sent by at least two threads; obtaining the service functions implemented by the threads in the service instance according to the lock allocation requests; determining the lock allocation priority of the threads according to the service functions implemented by the threads; and allocating resource locks to the threads according to the lock allocation priority.

[0176] For details on the specific implementation methods and corresponding beneficial effects of the above operations, please refer to the detailed description of the resource management method above, which will not be repeated here.

[0177] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by a computer program, or by a computer program controlling related hardware. The computer program can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0178] To this end, embodiments of this application provide a computer-readable storage medium storing a computer program that can be loaded by a processor to execute the steps of any of the resource management methods provided in embodiments of this application. For example, the computer program can execute the following steps: obtaining lock allocation requests sent by at least two threads; obtaining the service functions implemented by the threads in the service instance based on the lock allocation requests; determining the lock allocation priority of the threads based on the service functions implemented by the threads; and allocating resource locks to the threads based on the lock allocation priority.

[0179] For details on the specific implementation methods and corresponding beneficial effects of the above operations, please refer to the previous embodiments, which will not be repeated here.

[0180] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0181] Since the computer program stored in the computer-readable storage medium can execute the steps of any of the resource management methods provided in the embodiments of this application, the beneficial effects that any of the resource management methods provided in the embodiments of this application can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0182] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the resource management method described above.

[0183] The resource management method, apparatus, device, system, storage medium, and program product provided in the embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A resource management method, characterized in that, Applied to electronic devices, wherein the resource management system in which the electronic device resides includes threads of at least two service instances, including: Obtain lock allocation requests from at least two of the aforementioned threads; Based on the lock allocation request, obtain the service functions implemented by the thread in the service instance; Determine the lock allocation priority of the thread based on the service functions implemented by the thread; Resource locks are allocated to the thread according to the lock allocation priority.

2. The resource management method according to claim 1, characterized in that, The step of determining the lock allocation priority of the thread based on the service functions implemented by the thread includes: The importance of a thread is determined based on the service functions it implements. The lock allocation priority of the thread is determined based on the importance mentioned.

3. The resource management method according to claim 2, characterized in that, The resource lock is used to control access to the target resource. Determining the importance of the thread based on the service functions implemented by the thread includes: The importance of the thread is determined based on the service functions implemented by the thread and the target resource.

4. The resource management method according to claim 3, characterized in that, Determining the importance of a thread based on the service functions implemented by the thread and the target resource includes: Based on the target resource, determine the dependencies between the service functions implemented by the thread; Based on the dependencies, the importance of the threads corresponding to the service functions that have the dependencies is determined, wherein the threads of the service functions that are depended upon are of higher importance.

5. The resource management method according to claim 3, characterized in that, Determining the importance of a thread based on the service functions implemented by the thread and the target resource includes: If it is determined that all threads can be executed based on the target resource, then the importance of each thread is determined based on the importance of its service function.

6. The resource management method according to claim 1, characterized in that, The step of determining the lock allocation priority of the thread based on the service functions implemented by the thread includes: If the thread includes multiple first threads targeting the same client, then based on the request time of the multiple first threads, the first threads are deduplicated in the thread to obtain the deduplicated thread, wherein the multiple first threads are threads that implement the same service function under the at least two service instances; Based on the service functions implemented by the deduplicated threads, the lock allocation priority of the deduplicated threads is determined.

7. The resource management method according to any one of claims 1-6, characterized in that, The step of allocating resource locks to the thread according to the lock allocation priority includes: Based on the lock allocation priority, the target thread is selected from the threads; Determine whether the target thread meets the lock allocation conditions; If the target thread meets the lock allocation condition, then a resource lock is allocated to the target thread.

8. The resource management method according to claim 7, characterized in that, The step of selecting a target thread from the threads based on the lock allocation priority includes: Based on the lock allocation priority of the thread, add the thread to the target sequence that matches the lock allocation priority; The target thread is retrieved from the target sequence with high lock allocation priority.

9. The resource management method according to claim 8, characterized in that, The step of retrieving the target thread from the target sequence with high lock allocation priority includes: Query each of the target sequences; If a candidate thread is found from the first target sequence in the target sequence, then it is determined whether the number of threads in the second target sequence is equal to zero, and the lock allocation priority of the second target sequence is higher than the lock allocation priority of the first target sequence. If the number of threads in the second target sequence is zero, then the candidate thread is determined as the target thread.

10. The resource management method according to claim 7, characterized in that, After determining whether the target thread meets the lock allocation condition, the method further includes: If the target thread does not meet the lock allocation condition, the target thread is controlled to be in a waiting state; After the duration of the waiting state reaches the target duration, the process returns to the step of determining whether the target thread meets the lock allocation conditions.

11. The resource management method according to claim 10, characterized in that, The method further includes: Obtain the cumulative duration of the target thread in the waiting state; If the cumulative duration is equal to or greater than the preset waiting time, then the lock allocation priority of the target thread is reduced, and the process returns to the step of selecting the target thread from the threads according to the lock allocation priority.

12. The resource management method according to claim 7, characterized in that, The resource management system includes at least two lock allocation instances, and the lock allocation request further includes the lock identifier of the resource lock. The step of determining whether the target thread meets the lock allocation conditions includes: Determine the hash value corresponding to the lock identifier; Based on the hash value and the hash value of the lock allocation instance, determine the target lock allocation instance to which the resource lock is allocated; Based on the target lock allocation instance, determine whether the target thread meets the lock allocation conditions.

13. The resource management method according to claim 12, characterized in that, Determining the target lock allocation instance for allocating the resource lock based on the hash value and the hash value of the lock allocation instance includes: Determine the hash ring in which the lock allocation instance resides; The target hash value is obtained by taking the modulo of the hash value of the lock identifier with the maximum hash value of the hash value ring; Based on the target hash value and the hash value range of each lock allocation instance in the hash ring, the target lock allocation instance for allocating the resource lock is determined.

14. A resource management device, characterized in that, Applied to electronic devices, wherein the resource management system in which the electronic device resides includes threads of at least two service instances, including: The request acquisition module is used to acquire lock allocation requests sent by at least two of the threads; The function acquisition module is used to acquire the service functions implemented by the thread in the service instance based on the lock allocation request; The determining module is used to determine the lock allocation priority of the thread based on the service functions implemented by the thread; The allocation module is used to allocate resource locks to the thread according to the lock allocation priority.

15. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a computer program, and the processor running the computer program in the memory to perform the resource management method according to any one of claims 1 to 13.

16. A resource management system, characterized in that, include: At least two service instances and a lock allocation instance, wherein the at least two service instances are used for: A lock allocation request is sent to the lock allocation instance through the threads of the at least two service instances; The lock allocation instance is used for: Based on the lock allocation request, obtain the service functions implemented by the thread in the service instance; Determine the lock allocation priority of the thread based on the service functions implemented by the thread; Resource locks are allocated to the thread according to the lock allocation priority.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted for loading by a processor to perform the resource management method according to any one of claims 1 to 13.

18. A computer program product, characterized in that, The computer program product stores a computer program adapted for loading by a processor to execute the resource management method according to any one of claims 1 to 13.

Images