Resource calling method and device, computer device and storage medium

Abstract

The application relates to the computer technical field and discloses a resource calling method and device, a computer device and a storage medium. The resource calling comprises the following steps: performing quantitative processing on resources corresponding to a client to determine a plurality of target resources; controlling a target management module of the client to create a plurality of pessimistic locks according to the number of the target resources; associating the target resources and the pessimistic locks according to a preset configuration file of the target management module to form a distributed resource pool of the client; and loading target resources for any process or any thread according to the pessimistic locks of the distributed resource pool in response to a calling request of the any process or the any thread. According to the method, any resource is subjected to pool processing in a distributed and concurrent scenario of the client, so that the problem of exceeding the upper limit of resource load caused by concurrent maintenance of the same resource by different transactions is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a resource calling method and device, computer equipment and storage medium. BACKGROUND

[0002] A resource pool refers to an abstract collection of various public system resources, which is used to manage the use and recycling of resources. When a resource user obtains resources through a resource pool, he does not have to care about the specific provider of the resources.

[0003] In related technologies, the pooling processing of resources usually adopts a client maintenance method, that is, the client itself maintains a resource pool, and the client implements the related resource pool according to the needs to limit its own simultaneous access to resources. For example, the implementation of a database connection pool. Although this implementation method saves server resources, in a distributed scenario, multiple programs will maintain multiple resource pools for the same resources, which will break the resource load limit and cause server exceptions, thereby reducing security. SUMMARY

[0004] Therefore, the present application provides a resource calling method and device, computer equipment and storage medium, which can perform pooling processing on any resource based on the distributed and concurrent scenario of the client, thereby solving the problem of breaking the resource load limit caused by the concurrent maintenance of the same resource by different transactions.

[0005] In a first aspect, a resource calling method is provided, comprising:

[0006] quantizing the resources corresponding to the client to determine a plurality of target resources;

[0007] controlling a target management module of the client to create a plurality of pessimistic locks according to the number of the plurality of target resources;

[0008] associating the plurality of target resources and the plurality of pessimistic locks according to a preset configuration file of the target management module to form a distributed resource pool of the client;

[0009] loading target resources for any process or any thread according to the pessimistic locks of the distributed resource pool in response to a calling request of the any process or the any thread.

[0010] Further, loading target resources for any process or any thread according to the pessimistic locks of the distributed resource pool comprises:

[0011] detecting the enabled state of the plurality of pessimistic locks;

[0012] if any pessimistic lock is in an unoccupied state, controlling the target management module to allocate any pessimistic lock for the any process or the any thread.

[0013] loading the target resource associated with any pessimistic lock for any process or any thread.

[0014] Further, the resource calling method further comprises:

[0015] If the plurality of pessimistic locks are in the occupied state, the pessimistic lock is refused to be allocated to any process or any thread.

[0016] Further, the control target management module allocates any pessimistic lock for any process or any thread, comprising:

[0017] determining the calling priority of any process or any thread;

[0018] controlling any process or any thread to send a request for obtaining the pessimistic lock to the target management module according to the control parameter corresponding to the calling priority;

[0019] the target management module allocates any pessimistic lock to any process or any thread in response to the request for obtaining;

[0020] The control parameter comprises at least one of the following: polling frequency, request waiting time, and polling mode.

[0021] Further, after the target resource is loaded for any process or any thread according to the pessimistic lock of the distributed resource pool, the resource calling method further comprises:

[0022] If the use of the target resource by any process or any thread is ended, the target resource associated with the pessimistic lock is released by any process or any thread.

[0023] Further, the target resource comprises at least one of the following: an external service node, a memory resource, a session resource, and a queue width.

[0024] Further, the target management module comprises at least one of the following: a Zookeeper service module, a Redis cache module, and a database module.

[0025] In a second aspect, a resource calling device is provided, comprising:

[0026] The quantification module is configured to quantitatively process the resources corresponding to the client to determine a plurality of target resources.

[0027] The pooling module is configured to control the target management module of the client to create a plurality of pessimistic locks according to the number of the plurality of target resources; and

[0028] According to the preset configuration file of the target management module, the plurality of target resources and the plurality of pessimistic locks are associated to form a distributed resource pool of the client.

[0029] The calling module is configured to load a target resource for any process or any thread according to the pessimistic lock of the distributed resource pool in response to a calling request of any process or any thread of the client.

[0030] Further, the calling module is specifically configured to detect the enabling states of the plurality of pessimistic locks, and if any pessimistic lock is in an unoccupied state, the target management module is controlled to allocate any pessimistic lock for any process or any thread, and any process or any thread is loaded with a target resource associated with any pessimistic lock.

[0031] Further, the calling module is further configured to refuse to allocate any pessimistic lock for any process or any thread if the plurality of pessimistic locks are all in an occupied state.

[0032] Further, the calling module is specifically configured to determine a calling priority of any process or any thread, and according to a control parameter corresponding to the calling priority, the target management module is controlled to send a request for acquiring a pessimistic lock by any process or any thread, and the target management module allocates any pessimistic lock to any process or any thread in response to the request for acquiring the pessimistic lock, wherein the control parameter comprises at least one of a polling frequency, a request waiting time, and a polling mode.

[0033] Further, the calling module is specifically configured to control any process or any thread to release a pessimistic lock associated with a target resource if the use of the target resource by any process or any thread ends.

[0034] In a third aspect, a computer device is provided, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the steps of the resource calling method when executing the computer program.

[0035] In a fourth aspect, a computer readable storage medium is provided, which stores a computer program, and the computer program implements the steps of the resource calling method when executed by a processor.

[0036] The scheme implemented by the resource calling method, device, computer device and storage medium realizes the following. The client maintains a resource pool, and the resources are maintained in the resource pool. Specifically, the resources of the resource end corresponding to the client are quantitatively processed, and the number of resources is configured to obtain a plurality of target resources after quantification. Then, each target resource of the resource end is mapped to one pessimistic lock based on the resource configuration file related to the target management module of the client, so as to associate the plurality of target resources and the plurality of pessimistic locks to form a distributed resource pool. Therefore, by introducing the mechanism of the distributed pessimistic lock, the problem of resource pooling of any group of resources is mapped to the problem of resource pooling of a group of distributed pessimistic locks. Therefore, before any process or thread of the client needs to call the target resource, a distributed pessimistic lock needs to be acquired first, and the permission of calling the target resource is acquired through the pessimistic lock, so as to complete the pooling management of the group of resources. Therefore, without additional development of the resource end, the exclusive and exclusive characteristics of the distributed pessimistic lock are fully utilized to complete the resource pooling of any resource in a flexible, reliable and reusable manner, which can avoid the problem of breaking the upper limit of resource load caused by the concurrent maintenance of the same resource by different transactions. In particular, in the distributed, concurrent and resource-end-unable-to-pool resource scenario, the target resource is protected from being overused, and the utilization, reliability and stability of the resource are improved.

[0037] The above description is only a summary of the technical solutions of the present application. In order to more clearly understand the technical means of the present application, the content of the specification can be implemented, and in order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the following specific embodiments of the present application are described. BRIEF DESCRIPTION OF DRAWINGS

[0038] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the description of the embodiments of the present application. Obviously, the drawings in the following description are only some embodiments of the present application, and those skilled in the art can obtain other drawings according to these drawings without creating any creative labor.

[0039] Figure 1 is one of the flowcharts of the resource calling method in the present application;

[0040] Figure 2 is Figure 1 is a specific embodiment flowchart of step S40 in

[0041] Figure 3 is Figure 2 is a specific embodiment flowchart of step S42 in

[0042] Figure 4 This is the second flowchart illustrating the resource access method in this application;

[0043] Figure 5 This is a schematic diagram illustrating the application logic of the resource retrieval method in this application;

[0044] Figure 6 This is a schematic diagram of the resource retrieval device in this application;

[0045] Figure 7 This is a schematic diagram of the computer device in this application. Detailed Implementation

[0046] 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, 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.

[0047] Please see Figure 1 As shown, Figure 1 A flowchart illustrating a resource retrieval method provided in this application embodiment includes the following steps:

[0048] S10: Quantify the resources corresponding to the client and determine multiple target resources;

[0049] In this context, the resources corresponding to the client are quantifiable system resources on the resource side. These are objects that the system program needs to occupy, use, and consume during operation, and are usually restored after use, rather than physical file data. For example, target resources include external service nodes, memory resources, session resources, and queue width.

[0050] In this embodiment, by quantizing the resources, all resources are divided into multiple target resources according to the quantization level to form distributed resources, which facilitates simultaneous calls by multiple processes or threads of the client. Moreover, the quantization process can identify usable target resources from all resources, which helps prevent the problem of resource overload in processes or threads.

[0051] Specifically, quantization can be either uniform quantization or non-uniform quantization.

[0052] S20: Control the client's target management module to create multiple pessimistic locks based on the number of target resources;

[0053] Among them, the pessimistic lock is also called pessimistic concurrency control (Pessimistic Concurrency Control, PCC), which is a very typical and very strict concurrency control strategy in a database. The pessimistic lock has strong exclusivity and exclusivity, and holds a conservative attitude towards the use of resources by the outside world, so that the resource is in a locked state during use. During this period, other transactions will not be able to operate on this resource, and the lock will be released only after the resource is used up. After releasing the corresponding lock, other transactions can execute operations conflicting with the lock. By making transactions wait for locks, parallel operations are executed serially.

[0054] In actual application scenarios, the target management module can be a Zookeeper service module, a Redis cache module, a database module, or other third-party media capable of implementing a distributed lock.

[0055] In this embodiment, a target management module is added in the client to create a pessimistic lock through the target management module, and then the problem of resource pooling of any group of resources is mapped to the resource pooling problem of a group of distributed pessimistic locks by introducing the mechanism of distributed pessimistic locks, so as to construct a distributed resource pool.

[0056] S30: According to the preset configuration file of the target management module, a plurality of target resources and a plurality of pessimistic locks are associated to form a distributed resource pool of the client;

[0057] Among them, the preset configuration file is used to indicate the basic information that the resource pool should have, for example, the acquisition address of the resource, the corresponding strategy of the target resource and the pessimistic lock, the name of the resource pool, the size of the resource pool and other information.

[0058] In actual application scenarios, in the resource pooling scheme taking the Zookeeper service module as an example, the name of the resource pool can be equivalent to a specific node of Zookeeper. At this time, the size of the resource pool can be equivalent to how many child nodes can exist under this node, each child node corresponds to a distributed pessimistic lock, and one distributed pessimistic lock corresponds to a call right of a resource, so as to complete the pooling management of a group of resources. Alternatively, the name of the resource pool can not be equivalent to a specific node of Zookeeper. The developer can maintain a group of arbitrary nodes in other ways and manage and use the group of nodes as a specific resource pool.

[0059] In this embodiment, each target resource at the resource end is mapped to one pessimistic lock based on the resource configuration file related to the target management module of the client, thereby associating multiple target resources and multiple pessimistic locks to form a distributed resource pool. Thus, before any process or any thread of the client needs to call a target resource, it needs to first attempt to acquire one distributed pessimistic lock to obtain the right to call the target resource through the pessimistic lock, thereby completing the pooling management of a group of resources. Thus, by maintaining consistency in the configuration on the client, it is ensured that multiple clients take a group of resources within a reasonable range, thereby achieving the purpose of resource pooling.

[0060] S40: In response to the calling request of any process or any thread of the client, loading the target resource for any process or any thread according to the pessimistic lock of the distributed resource pool.

[0061] In this embodiment, when the target resource needs to be used by any process or any thread of the client corresponding to a transaction, it is necessary to first attempt to acquire one distributed pessimistic lock to obtain the right to call the target resource through the pessimistic lock. After any process or any thread obtains the pessimistic lock, the corresponding target resource can be loaded. Thus, from the perspective of the client, the centralized resource group is managed in a pooled manner, and in the case that no additional development is needed at the resource end, the exclusive and exclusive features of the distributed pessimistic lock are fully utilized to complete the resource pooling of any resource in a flexible, reliable, and reusable manner, which can avoid the problem of exceeding the upper limit of resource load caused by the concurrent maintenance of the same resource by different transactions. In particular, in the distributed, concurrent, and resource-end-unable-to-pool-resource scenarios, the target resource is protected from being overused, and the utilization, reliability, and stability of the resource are improved. In addition, since the maintenance of the resource pool occurs at the client, by maintaining consistency in the configuration on the client, it is ensured that multiple clients take a group of resources within a reasonable range, thereby achieving the purpose of resource pooling. Therefore, the resource end itself can not need to be aware of or changed, thereby greatly saving the labor cost.

[0062] In an embodiment of the present specification, the client can be a desktop computer, a tablet computer, a notebook computer, a smart phone, a digital assistant, a smart wearable device, etc. The smart wearable device can include a smart bracelet, a smart watch, smart glasses, a smart helmet, etc. Of course, the client is not limited to the above computer devices with certain entities, and it can also be a software running in the above computer devices.

[0063] In some embodiments of the present application, as shown in Figure 2 In some embodiments of the present application, as shown in

[0064] S41: detecting the enabling state of the plurality of pessimistic locks;

[0065] S42: if any pessimistic lock is in the unoccupied state, controlling the target management module to allocate any pessimistic lock to any process or any thread;

[0066] S43: loading the target resource associated with any pessimistic lock for any process or any thread;

[0067] S44: if the plurality of pessimistic locks are all in the occupied state, refusing to allocate any pessimistic lock to any process or any thread.

[0068] For steps S41-S44, considering the exclusive and exclusion characteristics of the pessimistic lock, if the pessimistic lock has been occupied by a process or a thread, at this time, other processes or threads will not be able to obtain the occupied pessimistic lock. Therefore, the enabling state of the plurality of pessimistic locks is detected first, and if the pessimistic lock is not occupied, it will be detected by the system. Then, the detected unoccupied pessimistic lock is allocated to the process or thread in need, so that the process or thread loads the associated target resource by using the pessimistic lock, and realizes the transaction corresponding to the process or thread. If the plurality of pessimistic locks are all in the occupied state, that is, there is no unoccupied pessimistic lock at present, then continue to wait until other processes or threads release the pessimistic lock, at which time the target management module is controlled to allocate the released pessimistic lock to any process or any thread. Thus, by using the feature that the distributed pessimistic lock has only one holder in the distributed scenario, based on the same configuration item, it can be ensured that the use of resources by multiple processes or multiple threads in the distributed scenario is within the configuration allowed range in the global scope, effectively avoiding excessive load on the resource end.

[0069] It can be understood that the pessimistic lock in the unoccupied state can be one or more, and when there are a plurality of unoccupied pessimistic locks, any unoccupied pessimistic lock can be selected and allocated to the process or thread in need. Thus, without needing to pay attention to the state of the client, the access times of the required resources, etc., random allocation of system resources is realized, and on the premise of ensuring the running of the client, any target resource is protected from being excessively used in the distributed scenario.

[0070] In some embodiments of the present application, as shown in Figure 3 a specific entity alignment scheme is provided, and the display size information includes display width and display height; in S42, that is, the target management module allocates any pessimistic lock to any process or any thread, which specifically includes the following steps:

[0071] S421: determining the call priority of any process or any thread;

[0072] The call priority of a process or thread can be reasonably set according to the transaction corresponding to the process or thread and the performance of the client. This application embodiment does not make specific limitations.

[0073] S422: According to the control parameters corresponding to the call priority, control any process or thread to send a pessimistic lock acquisition request to the target management module;

[0074] S423: In response to an acquisition request, the target management module assigns any pessimistic lock to any process or any thread;

[0075] The control parameters include at least one of the following: polling frequency, request waiting time, and polling method. For example, the higher the call priority, the greater the polling frequency of sending pessimistic lock acquisition requests and the shorter the period of sending pessimistic lock acquisition requests. In other words, the more frequently a process or thread sends pessimistic lock acquisition requests, the faster the process or thread can obtain the pessimistic lock, and thus the higher the probability of obtaining the pessimistic lock.

[0076] For steps S421-S423, control parameters corresponding to the call priority of any process or thread are determined through a preset correspondence. Based on these control parameters, any process or thread sends a pessimistic lock acquisition request to the target management module, causing the target management module to respond to the acquisition request and allocate any unoccupied pessimistic locks to that process or thread. Therefore, in high-concurrency scenarios, if the number of unoccupied pessimistic locks is less than the number of acquisition requests sent by multiple processes or threads (i.e., when multiple processes or threads are vying for the right to call the same resource at the same time), the priority order of any process or thread in acquiring the distributed lock increases the probability of higher-priority processes or threads acquiring the distributed lock and thus the right to call the resource. This avoids vicious competition and an excessive number of competing threads, which would place a heavy burden on the CPU. This facilitates meeting the needs of different processes and threads, thereby enhancing the flexibility of managing the distributed resource pool and reducing resource waste.

[0077] In an actual application scenario, based on the basic principle of the zookeeper distributed lock, the process of obtaining the zookeeper distributed pessimistic lock is actually the process of creating a sequential sub-node under a specific node on the zookeeper by the client. Since the creation of the node is atomic, the number of each sub-node is different. Based on this, the sub-node of the zookeeper is interacted with the thread or process to determine whether the sub-node created by the current client is the smallest sub-node. If so, the sub-node with the smallest number is considered to have obtained the pessimistic lock, otherwise, the zookeeper listens to the previous sub-node of the sub-node adjacent to the current thread or process and blocks the current thread or process until there is a sub-node with the smallest number. Deleting the sub-node means releasing the lock. The next thread or process can obtain the distributed lock only after the current thread or process that obtains the distributed lock releases the distributed lock.

[0078] In some embodiments of the present application, as shown in Figure 4 , a specific entity alignment scheme S40 is provided, that is, after loading the target resource for any process or any thread according to the pessimistic lock of the distributed resource pool, the following steps are further included:

[0079] S50: If the use of the target resource by any process or any thread is completed, control any process or any thread to release the pessimistic lock associated with the target resource.

[0080] For step S50, when any process or any thread completes the use of the target resource, the pessimistic lock associated with the target resource is immediately released to return the pessimistic lock to the target management module. So that other processes or threads can continue to call the target resource by obtaining the pessimistic lock, thereby effectively improving the business processing performance of the client.

[0081] In a specific embodiment, as shown in Figure 5 , based on the zookeeper distributed pessimistic lock, the memory resources of the client are resource-pooled, and the resource calling method includes the following steps:

[0082] 1. Quantize the memory resources of the specified node, configure the number of resources, for example, provide a maximum of 8 units of memory resources, and the memory resource size of each unit is the same. The memory resource size of each unit can be set as needed, which can be 100KB, 24MB, 5GB or 1TB, etc.

[0083] 2. The client process maps 1 unit of memory resources of the specified node to 1 zookeeper pessimistic lock based on the resource configuration file, and 8 units of memory resources correspond to 8 lock nodes.

[0084] 3. When the client needs to occupy 1 unit of memory resources of the specified node, the process needs to first try to obtain any one of the 8 lock nodes of the zookeeper before using 1 unit of memory resources of the specified node. Only after successfully obtaining 1 lock node, the 1 unit of memory resources of the specified node can be occupied. Since at any time, at most 8 lock nodes are occupied, the specified node is at most occupied 8 units.

[0085] 4. When the client finishes using, the lock node is released, and the resource recycling is completed.

[0086] Through the above embodiment, on the one hand, by reasonably introducing the mechanism of distributed pessimistic lock, without the need for additional development of the resource end, the distributed pessimistic lock is used to complete the resource pooling of any resource in a flexible, reliable and reusable manner, which greatly improves the utilization, reliability and stability of the resource. Moreover, in any scenario that requires resource pooling of a specific resource, especially in distributed, concurrent scenarios, and scenarios where the resource end cannot be pooled, there is ample room for play. On the other hand, by maintaining the consistency of the configuration on the client side, multiple clients can take a set of resources within a reasonable range, achieving the purpose of resource pooling. From the perspective of the client, the centralized resource group is managed in a pooled manner, and the resource end itself can not be aware of or changed, greatly saving the cost of manpower.

[0087] It should be understood that the size of the serial number of each step in the above embodiment does not mean the order of execution, and the execution order of each process should be determined according to its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0088] In an embodiment, a resource calling device is provided, which corresponds to the resource calling method in the above embodiment. As shown in the figure, the resource calling device includes a quantization module 601, a pooling module 602, and a calling module 603. The functions of each functional module are described in detail as follows: Figure 6

[0089] The quantization module is configured to quantize the resources corresponding to the client and determine a plurality of target resources.

[0090] The pooling module is configured to control the target management module of the client to create a plurality of pessimistic locks according to the number of target resources; and

[0091] According to the preset configuration file of the target management module, the plurality of target resources and the plurality of pessimistic locks are associated to form a distributed resource pool of the client.

[0092] ​The calling module is configured to load a target resource for any process or any thread according to the pessimistic lock of the distributed resource pool in response to a calling request of any process or any thread of the client.

[0093] In an embodiment, the calling module 603 is specifically configured to detect the enabling states of the plurality of pessimistic locks, and if any pessimistic lock is in an unoccupied state, control the target management module to allocate any pessimistic lock for any process or any thread, and load a target resource associated with any pessimistic lock for any process or any thread.

[0094] In an embodiment, the calling module 603 is further configured to, if all the plurality of pessimistic locks are in an occupied state, refuse to allocate any pessimistic lock for any process or any thread.

[0095] In an embodiment, the calling module 603 is specifically configured to determine a calling priority of any process or any thread, and control any process or any thread to send a request for acquiring a pessimistic lock to the target management module according to a control parameter corresponding to the calling priority, so as to allocate any pessimistic lock to any process or any thread, wherein the control parameter comprises at least one of the following: a polling frequency, a request waiting time, and a polling mode.

[0096] In an embodiment, the calling module 603 is specifically configured to, if use of a target resource by any process or any thread ends, control any process or any thread to release a pessimistic lock associated with the target resource.

[0097] In an embodiment, the target resource comprises at least one of the following: an external service node, a memory resource, a session resource, and a queue width.

[0098] In an embodiment, the target management module comprises at least one of the following: a Zookeeper service module, a Redis cache module, and a database module.

[0099] The application provides a resource calling device. The resource is maintained in a resource pool by adopting a client to maintain a resource pool mode. Specifically, the resources of the resource end corresponding to the client are quantitatively processed, and the number of resources is configured to obtain a plurality of target resources after quantification. Then, each target resource of the resource end is mapped to one pessimistic lock based on a resource configuration file related to the target management module of the client, so as to associate the plurality of target resources and the plurality of pessimistic locks to form a distributed resource pool. Therefore, by introducing the mechanism of the distributed pessimistic lock, the problem of resource pooling of any group of resources is mapped to the problem of resource pooling of a group of distributed pessimistic locks. Therefore, before any process or any thread of the client needs to call the target resource, one distributed pessimistic lock needs to be acquired first, and the permission of calling the target resource is acquired through the pessimistic lock, so as to complete the pooling management of the group of resources. Therefore, without additional development of the resource end, the exclusive and exclusive characteristics of the distributed pessimistic lock are fully utilized, so that the resource pooling of any resource is completed in a flexible, reliable and reusable manner, and the problem of breaking the upper limit of resource load caused by the concurrent maintenance of the same resource by different transactions can be avoided. Especially in the scene of distributed, concurrent and resource end unable to perform resource pooling, the target resource is protected from being overused, and the utilization rate, reliability and stability of the resource are improved.

[0100] The specific limitation of the resource calling device can be referred to the limitation of the resource calling method in the above, which will not be repeated here. Each module in the above resource calling device can be realized by software, hardware and their combination in whole or in part. The above modules can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0101] In one embodiment, a computer device is provided, including a memory, a processor and a computer program stored in the memory and executable on the processor, and the processor implements the following steps when executing the computer program: quantitatively processing the resources corresponding to the client to determine a plurality of target resources; controlling the target management module of the client to create a plurality of pessimistic locks according to the number of target resources; according to the preset configuration file of the target management module, associating the plurality of target resources and the plurality of pessimistic locks to form a distributed resource pool of the client; and in response to the calling request of any process or any thread of the client, loading the target resource for any process or any thread according to the pessimistic lock of the distributed resource pool.

[0102] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, it performs the following steps: quantifying the resources corresponding to the client to determine multiple target resources; controlling the client's target management module to create multiple pessimistic locks according to the number of multiple target resources; associating multiple target resources and multiple pessimistic locks according to a preset configuration file of the target management module to form a distributed resource pool for the client; and loading target resources for any process or thread in response to a call request from any process or thread of the client, based on the pessimistic locks of the distributed resource pool.

[0103] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram is shown below. Figure 7 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the function or steps of a resource retrieval method.

[0104] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions of the resource call methods in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0105] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer readable storage medium, and when executed, can include the processes of the above-mentioned embodiment methods. Any reference to memory, storage, database or other medium used in the embodiments provided by the present application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration but not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0106] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is exemplified, and in actual application, the above-mentioned functions can be completed by different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above.

[0107] The above-mentioned embodiments are only used to illustrate the technical solutions of the present application, and not to limit it. Although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A resource invocation method, characterized in that, include: The resources corresponding to the client are quantified to determine multiple target resources; Based on the number of multiple target resources, the target management module of the client is controlled to create multiple pessimistic locks, wherein each resource unit among the multiple target resources is mapped to a pessimistic lock; According to the preset configuration file of the target management module, the multiple target resources and the multiple pessimistic locks are associated to form a distributed resource pool for the client. The name of the resource pool is equivalent to a specific node of the target management module, the size of the resource pool is equivalent to how many child nodes can exist under that node, each child node corresponds to a distributed pessimistic lock, and a distributed pessimistic lock corresponds to the right to call a resource. In response to a call request from any process or thread of the client, the target resource is loaded for the process or thread according to the pessimistic locking of the distributed resource pool.

2. The resource retrieval method according to claim 1, characterized in that, The step of loading the target resource for any process or any thread based on the pessimistic lock of the distributed resource pool includes: Detect the enabled status of the multiple pessimistic locks; If any pessimistic lock is in an unoccupied state, allocate the pessimistic lock to any process or any thread; Load the target resource associated with any pessimistic lock for any process or any thread.

3. The resource retrieval method according to claim 2, characterized in that, The method further includes: If all of the pessimistic locks are in a occupied state, refuse to allocate a pessimistic lock to any of the processes or threads.

4. The resource retrieval method according to claim 2, characterized in that, Assigning any pessimistic lock to any process or any thread includes: Determine the call priority of any of the processes or threads; According to the control parameters corresponding to the call priority, control any process or any thread to send a pessimistic lock acquisition request to the target management module; In response to the acquisition request, the target management module assigns any pessimistic lock to any process or any thread. The control parameters include at least one of the following: polling frequency, request waiting time, and polling method.

5. The resource retrieval method according to claim 1, characterized in that, After loading the target resource for any process or thread based on the pessimistic lock of the distributed resource pool, the method further includes: If any process or thread finishes using the target resource, control the process or thread to release the pessimistic lock associated with the target resource.

6. The resource retrieval method according to any one of claims 1 to 5, characterized in that, The target resources include at least one of the following: external service nodes, memory resources, session resources, and queue width.

7. The resource retrieval method according to any one of claims 1 to 5, characterized in that, The target management module includes at least one of the following: Zookeeper service module, Redis cache module, and database module.

8. A resource allocation device, characterized in that, include: The quantization module is used to quantify the resources corresponding to the client and determine multiple target resources; A pooling module is used to control the client's target management module to create multiple pessimistic locks based on the number of target resources, wherein each resource unit among the multiple target resources is mapped to a pessimistic lock; and, According to the preset configuration file of the target management module, the multiple target resources and the multiple pessimistic locks are associated to form a distributed resource pool for the client. The name of the resource pool is equivalent to a specific node of the target management module, the size of the resource pool is equivalent to how many child nodes can exist under that node, each child node corresponds to a distributed pessimistic lock, and a distributed pessimistic lock corresponds to the right to call a resource. The calling module is used to respond to a call request from any process or thread of the client and load the target resource for any process or thread according to the pessimistic lock of the distributed resource pool.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the resource access method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the resource retrieval method as described in any one of claims 1 to 7.

Images