Resource invocation control method and apparatus, electronic device, and program product

Abstract

The present disclosure discloses a resource calling control method and device, electronic equipment and program product. The resource calling control method comprises: in response to a calling request of a target resource by a resource requester, obtaining a first real-time concurrency number of the target resource; increasing the first real-time concurrency number by a preset value to obtain a first updated concurrency number of the target resource; comparing the first updated concurrency number with a concurrency number threshold; in the case that the first updated concurrency number is greater than the concurrency number threshold, obtaining a second real-time concurrency number of the target resource and subtracting the preset value from the second real-time concurrency number to obtain a second updated concurrency number of the target resource, and rejecting the calling request; in the case that the first updated concurrency number is less than or equal to the concurrency number threshold, creating a calling session for the resource requester to call the target resource. The method, device, equipment and product of the present disclosure effectively solve the problem of concurrent calling control in a resource shortage scenario.

Description

Technical Field

[0001] This disclosure relates to the field of computer application technology, and in particular to resource access control methods and apparatus, electronic devices and program products. Background Technology

[0002] With the development of computer application technology, various services related to computer applications often need to call external resources to achieve their functions. These resources usually have a limit on the number of concurrent accesses; once the limit is exceeded, the resource call will fail.

[0003] Currently, in distributed high-concurrency scenarios, if resource and service calls are not subject to concurrency control, the actual number of concurrent requests may exceed the available capacity. However, if control is implemented by obtaining the current concurrency count in real time, multiple calls may compete for resources, impacting system performance.

[0004] In addition, existing concurrency control schemes have the problem of failing to accurately control the number of concurrent users under abnormal circumstances, thus affecting normal use.

[0005] Therefore, an improved solution is needed for concurrency control of resource calls.

[0006] The background description is provided for the purpose of understanding the relevant technologies in this field and is not intended as an admission of prior art. Summary of the Invention

[0007] The embodiments disclosed herein aim to provide a resource access control scheme that can mitigate or resolve at least one of the aforementioned technical problems.

[0008] In a first aspect, embodiments of this disclosure provide a resource access control method, comprising:

[0009] In response to a resource requester's request to invoke a target resource, obtain the first real-time concurrency count of the target resource;

[0010] The first real-time concurrency count is increased by a preset value to obtain the first update concurrency count of the target resource;

[0011] Compare the first update concurrency with the concurrency threshold;

[0012] If the first update concurrency is greater than the concurrency threshold, obtain the second real-time concurrency of the target resource and subtract the preset value from the second real-time concurrency to obtain the second update concurrency of the target resource, and reject the call request;

[0013] If the first update concurrency is less than or equal to the concurrency threshold, a call session for invoking the target resource is created for the resource requester.

[0014] Optionally, when creating the invocation session for the resource requester, the method includes:

[0015] Determine the creation status of the invocation session;

[0016] If the call session creation fails, obtain the third real-time concurrency of the target resource, subtract the preset value from the third real-time concurrency to obtain the third update concurrency of the target resource, and reject the call request.

[0017] Optionally, when creating the invocation session for the resource requester, the method further includes:

[0018] If the invocation session is successfully created, determine the usage status of the invocation session;

[0019] When the call session ends, the fourth real-time concurrency of the target resource is obtained, and the fourth update concurrency of the target resource is obtained by subtracting the preset value from the fourth real-time concurrency.

[0020] Optionally, when creating the invocation session for the resource requester, the method further includes:

[0021] If the call session is successfully created, a concurrent holding identifier is created for the call session, and the concurrent holding identifier is set to a first preset state;

[0022] When the call session ends, the state of the concurrent holding identifier is identified;

[0023] If the concurrent holding identifier is identified as being in the first preset state, the concurrent holding identifier is set to the second preset state.

[0024] Optionally, when creating the invocation session for the resource requester, the method further includes:

[0025] When the concurrent holding identifier is identified as being in the first preset state, the fourth real-time concurrent count of the target resource is obtained, and the preset value is subtracted from the fourth real-time concurrent count to obtain the fourth update concurrent count of the target resource.

[0026] Optionally, the method further includes:

[0027] Periodically check the usage duration of created call sessions;

[0028] If the usage duration of the created call session exceeds the preset duration, obtain the fifth real-time concurrency of the target resource, and subtract the preset value from the fifth real-time concurrency to obtain the fifth update concurrency of the target resource.

[0029] Optionally, the method further includes:

[0030] Create a concurrency information table to record resource information, concurrency information, and session information;

[0031] When a call session is successfully created, the session information of the created call session is recorded in the concurrency information table, wherein the session information includes resource information, a unique session identifier, and a session start time;

[0032] In response to a change in the state of the calling session, update the session information of the calling session recorded in the concurrency information table;

[0033] Periodically check the session information of the calling sessions recorded in the concurrency information table.

[0034] In a second aspect, embodiments of this disclosure provide a resource mobilization control device, which may include:

[0035] The acquisition unit is configured to acquire the first real-time concurrency of the target resource in response to a resource requester's call request for the target resource;

[0036] The update unit is configured to increase the first real-time concurrency count by a preset value to obtain the first update concurrency count of the target resource;

[0037] The comparison unit is configured to compare the first update concurrency with a concurrency threshold;

[0038] The first calling unit is configured to, when the first update concurrency is greater than the concurrency threshold, obtain the second real-time concurrency of the target resource, subtract the preset value from the second real-time concurrency to obtain the second update concurrency of the target resource, and reject the calling request;

[0039] The second invocation unit is configured to create an invocation session for the resource requester to invoke the target resource when the first update concurrency is less than or equal to the concurrency threshold.

[0040] In a third aspect, embodiments of this disclosure provide an electronic device that may include: a processor and a memory storing a computer program, the processor being configured to implement the method as described in the first aspect when executing the computer program.

[0041] In a fourth aspect, embodiments of this disclosure provide a computer program product including a computer program, wherein the computer program, when executed by a processor, implements the method described in the first aspect.

[0042] In a fifth aspect, embodiments of this disclosure provide a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the method described in the first aspect.

[0043] The resource invocation control method proposed in this embodiment responds to a resource requester's call request for a target resource by obtaining a first real-time concurrency of the target resource; increasing the first real-time concurrency by a preset value to obtain a first updated concurrency of the target resource; comparing the first updated concurrency with a concurrency threshold; and if the first updated concurrency is greater than the concurrency threshold, obtaining a second real-time concurrency of the target resource and subtracting the preset value from the second real-time concurrency to obtain a second updated concurrency of the target resource, and rejecting the call request; and if the first updated concurrency is less than or equal to the concurrency threshold, creating a call session for the resource requester to call the target resource. This effectively ensures that resource or service call requests do not exceed the maximum allowed concurrency while guaranteeing high availability and high performance when preempting computing concurrent resources, effectively improving the concurrency call control problem in resource-scarce scenarios, and improving the reliability and stability of distributed resource services.

[0044] Other optional features and technical effects of the embodiments of this disclosure are described in part below, and in part will be apparent from reading this document. Attached Figure Description

[0045] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings. The elements shown are not limited to the scale shown in the drawings, and the same or similar reference numerals in the drawings denote the same or similar elements, wherein:

[0046] Figure 1 This is a first flowchart of a resource access control method according to an embodiment of the present disclosure;

[0047] Figure 2 This is a second flowchart of a resource access control method according to an embodiment of the present disclosure;

[0048] Figure 3 This is a third flowchart of a resource access control method according to an embodiment of the present disclosure;

[0049] Figure 4 This is a fourth flowchart of a resource access control method according to an embodiment of the present disclosure;

[0050] Figure 5 This is the fifth flowchart of the resource access control method according to an embodiment of the present disclosure;

[0051] Figure 6 This is the sixth flowchart of the resource access control method according to an embodiment of the present disclosure;

[0052] Figure 7 This is a flowchart of a first specific example of a resource access control method according to an embodiment of the present disclosure;

[0053] Figure 8 This is a second specific example flowchart of a resource access control method according to an embodiment of the present disclosure;

[0054] Figure 9 An exemplary structural diagram of a resource retrieval control device according to an embodiment of the present disclosure is shown; and

[0055] Figure 10 An exemplary structural diagram of an electronic device capable of implementing the methods according to embodiments of the present disclosure is shown. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of this disclosure clearer, the disclosure will be further described in detail below with reference to specific embodiments and accompanying drawings. Here, the illustrative embodiments and descriptions of this disclosure are used to explain this disclosure, but are not intended to limit this disclosure.

[0057] The term "comprising" and its variations as used herein signify open inclusion, i.e., "including but not limited to". Unless otherwise stated, the term "or" means "and / or". The term "based on" means "at least partially based on". The terms "one example embodiment" and "one embodiment" mean "at least one example embodiment". The term "another embodiment" means "at least some embodiments". The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0058] With the development of computer application technology, various services often need to call external resources to achieve their functions. This is especially true in big data distributed resource calling scenarios, where massive numbers of calls occur constantly, and the called resources or services typically have limitations on the number of concurrent accesses. For example, in big data resource platforms, multiple data processing tasks often need to access limited computing resources, storage resources, or third-party data service interfaces simultaneously. Effectively controlling concurrent access becomes a key technology for ensuring service quality. In one example, for a big data-based intelligent voice service, third-party resources need to be procured and called to enhance system functionality, reduce costs, and solve data security issues. When the access to or calling of third-party resources exceeds their concurrent access limits, the service will malfunction. Therefore, properly controlling concurrency is crucial for the stability of data and resource calling systems in distributed scenarios.

[0059] One known concurrency control scheme determines resource availability by real-time acquisition of the current available concurrent connections. However, without concurrency control, this scheme may result in the actual number of concurrent connections used exceeding the available number. Furthermore, adding concurrency control can lead to contention among resource acquisition operations, impacting system performance.

[0060] Another known approach by the inventors uses a bidirectional flow valve to calculate the available and reuse quantities. However, this approach still suffers from the problem of not being able to effectively ensure that the number of calls does not exceed the maximum allowed concurrency, and it also cannot guarantee high availability and high performance when preempting computational concurrency resources. Furthermore, this approach can lead to inaccurate counting when the program malfunctions, thus affecting normal use.

[0061] This disclosure provides a resource access control method. This method achieves precise concurrency control through a pre-emption mechanism and state management, while ensuring high availability and high performance of the target resource access. In a further embodiment, multiple protection mechanisms are employed to handle abnormal access situations. Therefore, in distributed high-concurrency scenarios, the method provided by this disclosure can accurately control the concurrent use of resources to prevent exceeding limits, fully guarantee high system performance, and maintain accurate concurrency counts even in abnormal situations.

[0062] This resource invocation control method is applicable to distributed systems that require access to limited concurrent resources, such as big data resource platforms, distributed data processing platforms, and AI-based voice services, for controlling access to third-party resources and services. Therefore, in distributed high-concurrency scenarios, the resource invocation control method provided in this disclosure can accurately control the concurrent use of resources to prevent exceeding limits, while also ensuring high overall system performance. Furthermore, it can maintain accurate concurrency counts even under abnormal conditions.

[0063] In this embodiment, the resource invocation control method can be applied, for example, to a concurrent invocation control center. In some embodiments, when the target resource is an external resource located outside the distributed system, such as a third-party interface, the concurrent invocation control center can be located at the entry gateway of the distributed system. However, in other embodiments, the target resource may also include resources within the distributed system, such as resources stored in any computer node or database node within the distributed system. In this case, the concurrent invocation control center can be located in any suitable computer node or in other computers.

[0064] refer to Figures 1 to 6 The diagram illustrates a flowchart of a resource access control method provided in several embodiments of this disclosure.

[0065] like Figure 1As shown in the embodiments of this disclosure, a resource call control method may include at least S110-S150.

[0066] S110: In response to the resource requester's request to call the target resource, obtain the first real-time concurrency of the target resource.

[0067] In this embodiment, the first real-time concurrency count refers to the current concurrent access count of the target resource. The target resource can be an external resource of the distributed system, such as a voice resource provided by a third party. It can also be an internal resource of the distributed system, such as a resource stored in any computer node of the distributed system. Optionally, the method may further include step S110' (not shown): if the first real-time concurrency count is not obtained, set the first real-time concurrency count to a preset initial value, such as an initial value of 0.

[0068] In this embodiment of the disclosure, obtaining the first real-time concurrency count can be achieved through a distributed cache, preferably Redis. In this embodiment, the first real-time concurrency count or other concurrency counts can be stored using key-value pairs, such as Redis key-value pairs. For example, a resource's unique identifier can be used as the key to store its concurrency count. In a specific example, the accuracy of the count in high-concurrency scenarios can be ensured through Redis's atomic operation APIs (such as the INCR command).

[0069] In a further preferred embodiment, a concurrency information management mechanism can be introduced on the basis of concurrency control to ensure the accuracy of the above concurrency control in a distributed high-concurrency environment, especially its reliability under abnormal conditions.

[0070] like Figure 5 As shown, the resource call control method can provide multiple steps involving a session information management table, such as: S101: Create a concurrency information table.

[0071] In this embodiment, the concurrency information table can be used to record resource information and concurrency information. As described above, the concurrency information table can be used to store a first key-value pair with a unique resource identifier as the key and the concurrency number as the value. The concurrency information table can also be used to record session information, as further explained below. In a specific example, the first key-value pair can be in the form of "service_001:n". Accordingly, the first real-time concurrency number, such as n, can be obtained by reading the value of the first key-value pair. Optionally, when the first real-time concurrency number is not obtained, for example, when the first key-value pair does not yet exist in Redis, the first key-value pair can be created. In this case, step S101 above, i.e., creating the concurrency information table, can be executed as needed.

[0072] S120: Increase the first real-time concurrent number by a preset value to obtain the first update concurrent number.

[0073] In this embodiment, a first concurrency adjustment can be performed to attempt to pre-allocate resources, that is, the first real-time concurrency obtained in step S110 is increased by a preset value to obtain a first updated concurrency. In this embodiment, the preset value can be set to 1, indicating that a concurrency quota is pre-allocated. This pre-allocation mechanism can lock the concurrency quota before the resources are actually used, thereby avoiding the concurrency conflict problem in traditional schemes. Furthermore, in this embodiment of the disclosure, even if the resources are not actually used due to various reasons (such as exceeding the concurrency limit or session creation failure), the method of this embodiment of the disclosure can correctly restore the concurrency count through subsequent concurrency adjustment, as further described below. Here, it will be understood that the "pre-allocation of resources" does not actually mean that the resources are not actually used, but rather that the corresponding resource quota is pre-allocated.

[0074] In a specific example, the current concurrency count can be increased from n to n+1, ensuring accuracy in high-concurrency scenarios. In a specific embodiment, when using a concurrency information table, the first update concurrency count before pre-allocation can be stored in the value of the first key-value pair, replacing the previously stored value, such as replacing the previously obtained first real-time concurrency count. For example, if the current first key-value pair is "service_001:n", after adjusting the first concurrency count, it becomes "service_001:n+1", where "service_001" is the unique identifier of the target resource, and "n" and "n+1" are the concurrency counts before and after pre-allocation, respectively.

[0075] In this embodiment of the disclosure, when the first update concurrency is obtained, the comparison described in step S130 can be performed, and step S140 or S150 can be performed based on the comparison result.

[0076] S130: Compare the first update concurrency with the concurrency threshold.

[0077] S140: If the first update concurrency is greater than the concurrency threshold, obtain the second real-time concurrency of the target resource, subtract the preset value from the second real-time concurrency to obtain the second update concurrency, and reject the call request.

[0078] S150: If the first update concurrency is less than or equal to the concurrency threshold, create a call session for the resource requester to call the target resource.

[0079] In some embodiments, the concurrency threshold may include the maximum number of concurrent accesses allowed for the target resource. For example, this maximum number of concurrent accesses may be a limit based on the resource provider's restrictions or a limit set based on system performance. In other embodiments, the concurrency threshold may include a threshold based on the maximum number of concurrent accesses while taking into account a safety margin, which may be simply referred to as the safety threshold. In some examples, the safety threshold is greater than the maximum number of concurrent accesses, and the difference between the two is not greater than the safety margin. The safety margin can be set according to actual conditions, and this embodiment does not impose any restrictions. In some optional embodiments, the concurrency threshold may be a preset value. In other optional embodiments, the concurrency threshold may be a dynamically changing value, which is particularly suitable for scenarios where resources can be dynamically expanded.

[0080] In this embodiment, step S130 determines whether the first update concurrency n+1 obtained in step S120 is greater than the concurrency threshold. In a specific example, assuming the concurrency threshold for the target resource is k, it can be determined whether the first update concurrency n+1 is greater than k.

[0081] In this embodiment, in step S140, when the first update concurrency is greater than the concurrency threshold, a second concurrency adjustment can be performed, that is, the second real-time concurrency is subtracted from the preset value to obtain the second update concurrency. This second concurrency adjustment effectively releases the "pre-allocated" resource quota. In a specific embodiment, in step S140, the second real-time concurrency of the target resource can be obtained, denoted as m. In this embodiment, the value of the second real-time concurrency m may be equal to n+1 or may not be equal to n+1. As an explanation and not a limitation, the actual concurrency state may have changed when the second real-time concurrency is obtained, for example, other resource call sessions may end and release resources. In this embodiment, by obtaining the real-time concurrency twice at different times, the changes in concurrency in high-concurrency scenarios can be accurately known. For example, after obtaining the first real-time concurrency n, other requests may release resources, resulting in a decrease in the actual concurrency, or other requests may successfully pre-allocate, resulting in an increase in the actual concurrency. After obtaining the second real-time concurrency, the preset value can be subtracted from it to obtain the second update concurrency. In some embodiments, when using a concurrency information table, the first key-value pair can be updated to "service_001:m-1". This allows for the timely release of reserved concurrency limits and the rejection of the current call request.

[0082] In this embodiment, by acquiring the real-time concurrency count twice in steps S120 and S140 (if any), the mechanism can effectively ensure that the number of call requests does not exceed the maximum allowed concurrency while guaranteeing high availability and high performance when preempting computing concurrency resources, thus effectively improving the concurrency call control problem in resource-scarce scenarios. As an example, and not a limitation, when multiple resource requesters receive call requests for the target resource, for one call request, after acquiring its first real-time concurrency count and obtaining the first updated concurrency count, subsequent threshold judgments can continue. Simultaneously, for the next call request, its corresponding first real-time concurrency count can be acquired. In some embodiments, this mechanism can reduce the serial waiting time when performing concurrency control between multiple call requests. Furthermore, in this embodiment, the judgment is made based on the first update concurrency determined by the first real-time concurrency. This may be due to resource shortages when obtaining the first real-time concurrency, or the resources may have been expanded or other requests may have released resources when the threshold judgment is made. This may result in the resources being available, but the resources are still judged as unavailable and step S140 is executed. Although this may seem to reduce resource utilization efficiency in these situations, the inventors have noted that the solution of this embodiment can effectively control the number of call requests from not exceeding the maximum allowed concurrency, effectively ensuring high availability, and in fact improving resource utilization efficiency, especially in resource-scarce scenarios.

[0083] In this embodiment, in step S150, when it is confirmed that the first update concurrency does not exceed the concurrency threshold, it can be determined that the target resource has sufficient concurrency quota for the corresponding resource requester. At this time, the call session creation process can be initiated to create a call session for the resource requester, enabling it to actually use the target resource.

[0084] Continue to refer to Figure 2 In a further embodiment, when a call session for the target resource is created for the resource requester (i.e., when step S150 is executed), the resource call control method may further include at least S210-S220.

[0085] S210: Determine the creation status of the calling session.

[0086] In this embodiment, it can be determined in step S210 whether the calling session was created successfully. In some embodiments, the creation of the calling session may fail due to network anomalies, system failures, or other reasons.

[0087] S220: If the session creation fails, obtain the third real-time concurrency of the target resource, subtract the preset value from the third real-time concurrency to obtain the third update concurrency, and reject the call request.

[0088] In this embodiment, in step S220, a third concurrency adjustment can be performed, that is, releasing the reserved concurrency quota when session creation fails. Specifically, the third real-time concurrency of the target resource can be obtained, and a preset value can be subtracted from it to obtain the third updated concurrency. Through this mechanism, even if session creation fails, the reserved concurrency quota can be released in a timely manner, allowing other call requests to use the quota. In some embodiments, this mechanism can improve resource utilization efficiency.

[0089] In some embodiments, when using a concurrency information table, the first key-value pair can be updated based on a third update concurrency count. In a specific example, if the third real-time concurrency count is p, the first key-value pair can be updated to "service_001:p-1", where "service_001" is the unique identifier of the target resource, and "p-1" is the third update concurrency count after subtracting a preset value. In this embodiment, the mechanism of adjusting the third real-time concurrency count to obtain the third update concurrency count ensures that the system, such as the value of the first key-value pair in the concurrency information table, is always updated based on the real-time state of the resource (in this case, a rollback). This mechanism, combined with the aforementioned first and second concurrency adjustment mechanisms, can maintain accurate control over the concurrency count at each stage of the call request, thereby improving the concurrency call control problem in resource-constrained scenarios.

[0090] In this embodiment of the disclosure, after successfully creating a call session for the resource requester, a session state management mechanism can be used to control the adjustment of the concurrency level. This session state management mechanism can effectively prevent the problem of repeatedly releasing concurrency quotas in a distributed environment. For example, if a session triggers both timeout cleanup and abnormal termination due to network anomalies, without a state management mechanism, the concurrency quota may be released repeatedly.

[0091] like Figure 3 As shown, the resource access control method may include at least S310-S320.

[0092] S310: If the call session is successfully created, determine the usage status of the call session.

[0093] In this embodiment of the disclosure, a call session involves a complete resource call process between a resource requester and a target resource. This process begins with the successful creation of the call session and ends with the end of resource usage. Specifically, the resource requester can only begin to actually use the target resource after the system successfully creates a call session for the resource requester, and the call session ends when resource usage ends (including normal completion or abnormal completion). For example, in an intelligent voice scenario, after an application successfully obtains permission to call a third-party voice resource and creates a session, the call session involves starting to process the voice task until processing is completed or an exception occurs.

[0094] In this embodiment, in step S310, it can be determined whether the calling session is in use. In one specific embodiment, its use status can be determined by detecting whether the calling session is making a resource call.

[0095] S320: When the call session ends, obtain the fourth real-time concurrency of the target resource, and subtract the preset value from the fourth real-time concurrency to obtain the fourth update concurrency.

[0096] In this embodiment of the disclosure, the circumstances under which a session ends are not limited, and may include, but are not limited to: normal termination (e.g., resource call completion, resource user actively ending the session); and abnormal termination (e.g., session execution timeout, network connection interruption, etc.).

[0097] In this embodiment, when executing step S320, a fourth concurrency adjustment can be performed, that is, the concurrency quota is released when the session ends. Specifically, the fourth real-time concurrency of the target resource can be obtained, and a preset value can be subtracted from it to obtain the fourth updated concurrency. This mechanism ensures that the system can release the occupied concurrency quota in a timely manner when the session ends, so that other call requests can use the quota, thereby improving resource utilization efficiency.

[0098] In some embodiments, when using a concurrency information table, the first key-value pair can be updated based on the fourth update concurrency. In a specific example, if the fourth real-time concurrency is q, the first key-value pair can be updated to "service_001:q-1", where "service_001" is the unique identifier of the target resource, and "q-1" is the fourth update concurrency after subtracting a preset value.

[0099] In this embodiment, by adjusting the fourth real-time concurrency count, it can be ensured that the system, such as the value of the first key-value pair in the concurrency information table, can update the concurrency count based on the real-time status of the resources. This mechanism, combined with the aforementioned first, second, and optional third concurrency adjustment mechanisms, enables the system to control the concurrency count at various stages, including pre-allocation, usage, and release, thereby further alleviating the concurrency call control problem in resource-constrained scenarios.

[0100] In the foregoing Figure 3 In the illustrated embodiment, a session state management mechanism that directly determines the session state can be used to control the adjustment of the concurrency level. In another embodiment, a session state management mechanism based on state identifiers can be used to control the adjustment of the concurrency level, which can, for example, further avoid the situation where the concurrency quota is repeatedly released during the end of the call session.

[0101] like Figure 4 As shown, the resource access control method may include:

[0102] S310': If the call session is successfully created, create a concurrent holding identifier for the call session and set the concurrent holding identifier to the first preset state.

[0103] In this embodiment, a concurrent holding identifier can be created for the calling session. In some embodiments of this application, the concurrent holding identifier can be used to identify whether the corresponding session is allowed to hold concurrent resources, thereby preventing the repeated release of the concurrent quota of the corresponding session by recording whether it is in a first preset state or a second preset state. The concurrent holding identifier is preferably session-level, and each session information, including the concurrent holding identifier, can be recorded and managed in a global concurrent information table, as further described below. In some embodiments of this application, the concurrent holding identifier can be initially set to a first preset state. For example, the first preset state can be set to a state indicating "in use". In a specific example, when the calling session is successfully created, for example, after obtaining permission to call third-party voice resources in a smart voice scenario, a concurrent holding identifier can be created for the calling session, and the calling session state can be marked as the first preset state indicating "in use".

[0104] In this embodiment of the disclosure, a concurrency information table can be used to record and manage session information. For example... Figure 5 As shown, the resource call control method further includes step S102: when the call session is successfully created, the session information of the created call session is recorded in the concurrency information table. Specifically, in step S102, relevant session information can be recorded in the concurrency information table. In some embodiments, the session information may include a unique session identifier; and the session information may also include a session start time, as further described below, wherein the unique session identifier can be used to uniquely identify this session, and the session start time can be used for subsequent timeout determination, as further described below.

[0105] As previously described, the concurrency information table can be used to store a first key-value pair, with the resource unique identifier as the key and the concurrency count as the value. In a further embodiment, the concurrency information table can also use a key-value structure to record session information. In one specific embodiment, the concurrency information table can also use a second key-value pair to record the concurrent holding identifier. In a further optional embodiment, the concurrency information table can also use a third key-value pair to record the session start time, as further explained below.

[0106] In some embodiments, the second key-value pair can be used to store a concurrent holding identifier, i.e., whether the corresponding session is allowed to hold concurrent resources, and optionally store a session unique identifier. For example, the second key-value pair can use a combination of a resource identifier and a session unique identifier as the key, such as in the form of "resource identifier:session unique identifier", and can use the concurrent holding identifier as the value. For example, when the resource unique identifier is "service_001" and the session unique identifier is "session_123", a key-value pair of the form "service_001:session_123:1" or "service_001:session_123:0" can be formed, where "service_001:session_123" is the key, and the value represents the state indicated by the concurrent holding identifier. For example, setting the value to "1" indicates a first preset state (such as "in use"), or setting it to "0" indicates a second preset state ("not in use"). In a specific embodiment, the second key-value pair is stored using a hash structure. In some embodiments, the above storage scheme can also be implemented using a distributed cache (such as Redis) hash data structure. Accordingly, resource information, concurrency information, and session information can be managed uniformly in a single global concurrency information table.

[0107] S320': Identify the state of concurrent holding identifiers when the calling session ends.

[0108] In this embodiment, in step S320', it can be identified whether the concurrent holding identifier is currently in a first preset state, such as "in use". Specifically, when a call session ends due to normal completion, abnormal interruption, or other reasons, the concurrent holding identifier state of the session can be checked first to ensure that it can be accurately determined whether the session has released the concurrent quota. As an explanation and not a limitation, checking the concurrent holding identifier state can prevent the concurrency number from being repeatedly adjusted. In embodiments using a concurrency information table, the system can identify the current state of the session by querying a second key-value pair (where the key is a combination of the resource identifier and the session unique identifier, and the value is a numerical value representing the state).

[0109] S330': If the concurrent holding identifier is identified as being in the first preset state, the concurrent holding identifier is set to the second preset state.

[0110] In this embodiment, in step S330', if the concurrent holding identifier is identified as being in a first preset state, the concurrent holding identifier can be updated from the first preset state to a second preset state. For example, the second preset state can represent a "non-reuse" state.

[0111] In embodiments employing concurrent information tables, the transition of concurrent holding identifier states can be achieved by updating the second key-value pair. In some embodiments, it can be combined with... Figure 5 The illustrated embodiments are combined. More specifically, step S330' can be combined with... Figure 5 The step S103 shown can be combined with or used as a sub-step. For example... Figure 5 As shown, the resource call control method further includes step S103: in response to a change in the concurrent holding identifier state of the calling session, updating the session information of the calling session recorded in the concurrency information table. Specifically, the transition of the concurrent holding identifier state can be achieved by updating the second key-value pair. For example, updating the value corresponding to "service_001:session_123" from "1" to "0" indicates that the session has changed from the "in use" state to the "not in use" state. It should be noted that... Figure 5 Step S103 shown is not only applicable to the concurrent holding identifier state transition scenario described in this step, but can also be applied to other session state change scenarios, and is not limited to recording session state changes, but can also optionally record changes to other session information. This unified information update mechanism ensures the timeliness and accuracy of session information in the concurrent information table.

[0112] S340': When the concurrent holding identifier is identified as the first preset state, the fourth real-time concurrent count of the target resource is obtained, and the preset value is subtracted from the fourth real-time concurrent count to obtain the fourth update concurrent count.

[0113] In this embodiment, in step S340', a fourth concurrency adjustment can be performed when the concurrent holding identifier is confirmed to be in a first preset state. Specifically, the fourth real-time concurrency of the target resource can be obtained, and a preset value can be subtracted from it to obtain the fourth updated concurrency. In an embodiment using a concurrency information table, if the fourth real-time concurrency is q, the first key-value pair can be updated to "service_001:q-1", indicating the release of one concurrency quota. Simultaneously, relevant information for the session in the concurrency information table can be cleared, including updating or clearing the session state information in the second key-value pair as needed, and clearing the session start time information recorded in the third key-value pair as needed. By way of explanation and not limitation, by associating the concurrency adjustment with the session state, it can be ensured that each session will release a concurrency quota at most once.

[0114] In this embodiment, by introducing a concurrent holding identifier for a session and its state transition mechanism, and associating the fourth concurrency adjustment with the concurrent holding identifier state, the repeated release of concurrency quotas can be effectively avoided. This mechanism, combined with the aforementioned first, second, and optional third concurrency adjustment mechanisms, can better ensure the accuracy of concurrency counting, thus effectively solving the concurrency call control problem in resource-constrained scenarios. In particular, in distributed systems, when the same session may trigger an end event simultaneously due to multiple reasons such as timeouts and exceptions, this mechanism can ensure that concurrency quotas are not erroneously released multiple times. As an explanation, although the above... Figure 3 The illustrated embodiments describe a method for concurrency control that directly determines session usage status; however, in some embodiments, Figure 3 The embodiments shown can also use a concurrency information table to assist in managing session information; for example, the usage status and start time information of a session can be recorded in the concurrency information table to support the determination of the session usage status and the detection of session duration; this disclosure is not limited thereto.

[0115] In this embodiment of the disclosure, a periodic detection mechanism can be used to ensure the reliability of concurrency control, so as to optimize the handling of timeout exceptions that may occur in the call session.

[0116] like Figure 6 As shown, the resource access control method may include:

[0117] S510: Periodically check the usage duration of created call sessions.

[0118] In this embodiment, in step S510, the created call sessions can be periodically monitored. For example, the duration of each call session from its inception to the present can be monitored. In some embodiments, the preset duration can be set to a value greater than the normal business processing time, for example, the preset duration can be set to 7 minutes.

[0119] like Figure 5 As shown, the resource call control method further includes step S104: periodically detecting the session information of the call sessions recorded in the concurrency information table. In embodiments using a concurrency information table, step S510 can be combined with step S104 or used as a sub-step. Specifically, the session usage duration can be detected by checking the session start time recorded in the third key-value pair as described above. In some embodiments, the third key-value pair can use a combination of resource identifier and session unique identifier as the key, for example, in the form of "resource identifier:session unique identifier", and can use the session start timestamp as the value. For example, when the resource unique identifier is "service_001" and the session unique identifier is "session_123", a key-value pair of the form "service_001:session_123:1698765432" can be formed, where 1698765432 represents the session start timestamp. It should be noted that... Figure 5 Step S104, as shown, is not only applicable to the session duration detection scenario described in this step, but can also be used to detect other session information. This unified detection mechanism ensures the validity of session information in the concurrency information table. In one specific embodiment, the third key-value pair is stored using a hash structure. In some embodiments, the hash data structure of a distributed cache (such as Redis) can also be used to implement the above storage scheme. Accordingly, resource information, concurrency information, and session information can be uniformly managed in the same concurrency information table.

[0120] S520: If the usage time of an already created call session exceeds the preset duration, obtain the fifth real-time concurrency of the target resource, and subtract the preset value from the fifth real-time concurrency to obtain the fifth update concurrency.

[0121] In this embodiment, in step S520, a fifth concurrency adjustment can be performed, i.e., releasing the concurrency quota when the session times out. Specifically, the fifth real-time concurrency of the target resource can be obtained, and a preset value can be subtracted from it to obtain the fifth updated concurrency. In an embodiment using a concurrency information table, if the fifth real-time concurrency is r, the first key-value pair can be updated to "service_001:r-1", indicating the release of one concurrency quota. At the same time, the relevant information of the session in the concurrency information table can be cleared, including the session status information in the second key-value pair and the session start time information in the third key-value pair.

[0122] In this embodiment, by periodically detecting and promptly releasing the concurrency quota occupied by timed-out sessions, the prolonged occupation of concurrency quota under abnormal circumstances can be avoided. This mechanism, combined with the aforementioned session state management mechanism, can maintain effective control over concurrency in both normal and abnormal scenarios. Specifically, in distributed systems, even if a node malfunctions and fails to release concurrency quota normally, this mechanism can automatically correct this through timeout detection, thereby ensuring the reliability of concurrency control. Furthermore, by integrating concurrency control and session information management into the same concurrency information table, unified management of target resource calls can be achieved, supporting full lifecycle management from session creation and state transition to timeout handling.

[0123] As described above, in some embodiments, the resource invocation control method of this disclosure can still achieve improved concurrent invocation control for multiple resource requesters' invocation requests to a target resource. For example, the resource invocation control method may include: receiving multiple resource requesters' invocation requests to a target resource; in response to a first resource requester's first invocation request to the target resource among multiple resource requesters, obtaining a first real-time concurrency of the target resource; increasing the first real-time concurrency by a preset value to obtain a first updated concurrency of the target resource; comparing the first updated concurrency with a concurrency threshold; if the first updated concurrency is greater than the concurrency threshold, obtaining a second real-time concurrency of the target resource and subtracting a preset value from the second real-time concurrency to obtain a second updated concurrency of the target resource, and rejecting the first invocation request; if the first updated concurrency is less than or equal to the concurrency threshold, creating a first invocation session for the first resource requester; in response to a second resource requester's second invocation request to the target resource among multiple resource requesters, obtaining the target resource's first real-time concurrency; and in response to a second resource requester's second invocation request to the target resource, obtaining the first real-time concurrency of the target resource. The process involves: determining the sixth real-time concurrency of the source resource; increasing the sixth real-time concurrency by a preset value to obtain the sixth updated concurrency of the target resource; comparing the sixth updated concurrency with a concurrency threshold; if the sixth updated concurrency is greater than the concurrency threshold, obtaining the seventh real-time concurrency of the target resource and subtracting the preset value from the seventh real-time concurrency to obtain the seventh updated concurrency of the target resource, and rejecting the second call request; if the sixth updated concurrency is less than or equal to the concurrency threshold, creating a second call session for the second resource requester; wherein, the sixth real-time concurrency for the second resource requester can be obtained after obtaining the first real-time concurrency for the first resource requester. Preferably, the comparison process between the first updated concurrency for the first resource requester and the concurrency threshold can be executed in parallel with the process of obtaining the sixth real-time concurrency for the second resource requester. Preferably, in the multiple call request sequences of multiple resource requesters, the second call request of the second resource requester is directly located within the first call request of the first resource requester. Such a solution can, for example, reduce the serial waiting time when performing concurrency control between multiple call requests, thereby achieving high-performance concurrent call control while maintaining high availability, based on preemptive acquisition of concurrent resources. It will also be understood that, in embodiments involving receiving call requests for a target resource from multiple resource requesters, this resource call control method can be combined with other embodiments and examples herein, such as with... Figures 1 to 8 The features and steps of the resource call control method shown in the embodiments and examples are combined to obtain new embodiments or examples.

[0124] The following text combines Figure 7 and Figure 8 A preferred specific example of the resource access control method of the present invention will be described in detail. This embodiment takes the concurrent access control of third-party voice resources in an intelligent voice scenario as an example.

[0125] This embodiment uses a distributed cache (Redis) to store and manage concurrency information. Specifically, key-value pairs are set up in Redis for management. The key-value pairs include: a first key-value pair for recording resource concurrency information, in the form of "service_001:n", indicating that the current concurrency is n; a second key-value pair for recording session status information, using "resource identifier:session unique identifier" as the key and 1 or 0 as the value, where 1 represents the first preset state ("in use") and 0 represents the second preset state ("not in use"); and a third key-value pair for recording session time information, also using "resource identifier:session unique identifier" as the key and a timestamp as the value. In this specific example, all key-value pairs are stored using a hash structure.

[0126] like Figure 7 As shown, when a resource user requests a target resource, such as when a smart voice application requests to call a third-party voice resource, the system first obtains the first real-time concurrency count for that resource. If it is the first time the resource is used, the system initializes the first real-time concurrency count to 0 (n=0) and creates a corresponding first key-value pair in the concurrency information table, such as "service_001:0". Then, the first real-time concurrency count is incremented by a preset value (+1) to obtain the first updated concurrency count. At this time, the first key-value pair is updated to "service_001:1" (n+1=1), and compared with the concurrency threshold (e.g., k=100). If the first updated concurrency count exceeds the threshold, the system obtains the second real-time concurrency count and subtracts the preset value (e.g., updating "service_001:101" to "service_001:100"), and then rejects the request.

[0127] When the number of concurrent updates is within the threshold range (e.g., n+1≤100), the system creates a call session for the request and sets the concurrency holding flag to the first preset state ("in use") upon successful session creation. Simultaneously, relevant information is recorded in the concurrency information table.

[0128] The second key-value pair is: "service_001:session_123" as the key and "1" as the value.

[0129] Update the third key-value pair: use "service_001:session_123" as the key and "1698765432" (current timestamp) as the value.

[0130] If session creation fails, obtain the third real-time concurrency count (e.g., p=98) and subtract the preset value (-1) (e.g., update "service_001:98" to "service_001:97"), and then reject the current call request.

[0131] Continue to refer to Figure 7 When a voice resource call is completed or an error occurs, the system first checks the status of the concurrent holding identifier. If the concurrent holding identifier is in the first preset state (when the value of the second key-value pair is "1"), the system obtains the fourth real-time concurrent count (e.g., q = 5) and subtracts the preset value (-1) (e.g., updating "service_001:5" to "service_001:4"). Simultaneously, the concurrent holding identifier is updated to the second preset state (the value of the second key-value pair is updated to "0", indicating a non-reuse state), and the session time information in the third key-value pair is cleared. If the value of the second key-value pair is "0", it means the session has already been processed, and the system exits directly.

[0132] like Figure 8 As shown, a timed check mechanism is also implemented to handle abnormal situations. The timer determines the session usage duration by checking the third key-value pair in the concurrency information table. For each session, the current time is subtracted from the recorded start timestamp. If the duration exceeds a preset time (7 minutes in this embodiment, for example, determined by adding a 2-minute margin to the maximum call time of 5 minutes in a normal business scenario), the system will obtain the fifth real-time concurrency count (e.g., r = 6) and subtract a preset value (-1) (e.g., updating "service_001:6" to "service_001:5"), while simultaneously clearing the second and third key-value pairs for that session. This check process can be continuously performed periodically.

[0133] In this embodiment, reliable control over concurrent calls to target resources, such as third-party voice resources, is achieved through a dual guarantee of concurrent session holding (state) identification and periodic detection. Even if node anomalies or network interruptions occur in the distributed system, the correct concurrency level can be automatically restored through the periodic check mechanism, ensuring stable system operation. For example, when a voice processing task is abnormally interrupted, the system can automatically release the occupied concurrency quota within a maximum of 7 minutes.

[0134] Furthermore, this embodiment fully utilizes the characteristics of distributed caching, and through Redis's atomic operations and hash structure, ensures the accuracy of state management and concurrency control in high-concurrency scenarios.

[0135] The specific parameters and implementation methods in this embodiment can be adjusted according to actual needs. For example, different preset durations can be set according to different voice processing task types, or an early warning mechanism can be added to notify in advance when the session is about to time out. This disclosure does not limit this.

[0136] In some embodiments of this disclosure, such as Figure 9As shown, a resource request control device 900 is also provided, which may include: an acquisition unit 910, an update unit 920, a comparison unit 930, a first call unit 940, and a second call unit 950. Wherein,

[0137] The acquisition unit 910 is configured to acquire the first real-time concurrency of the target resource in response to the resource requester's call request for the target resource.

[0138] The update unit 920 is configured to increase the first real-time concurrency count by a preset value to obtain the first update concurrency count of the target resource.

[0139] The comparison unit 930 is configured to compare the first update concurrency with a concurrency threshold.

[0140] The first calling unit 940 is configured to, when the first update concurrency is greater than the concurrency threshold, obtain the second real-time concurrency of the target resource and subtract a preset value from the second real-time concurrency to obtain the second update concurrency of the target resource, and reject the calling request.

[0141] The second calling unit 950 is configured to create a calling session for the resource requester to call the target resource when the first update concurrency is less than or equal to the concurrency threshold.

[0142] Figure 9 The diagram only schematically shows some components of device 900 and does not imply that device 900 only includes [specific components]. Figure 9 The unit shown.

[0143] In this embodiment of the disclosure, the resource request control device 900 and its unit are executable. Figures 1 to 8 The method features in the present application and the features of the device components in the embodiments of the present application can be referred to the features of the method and steps in the embodiments of the present application, and the device embodiments can be combined with the features of the method embodiments to obtain new embodiments, and vice versa, and will not be repeated here.

[0144] In some embodiments of this disclosure, such as Figure 10 The diagram illustrates an electronic device 1000 capable of implementing the methods of embodiments of the present disclosure. In some embodiments, it may include more or fewer electronic devices than illustrated. In some embodiments, it may be implemented using a single or multiple electronic devices. In some embodiments, it may be implemented using cloud-based or distributed electronic devices.

[0145] like Figure 10As shown, the electronic device 1000 includes a processor 1001, which can perform various appropriate operations and processes based on programs and / or data stored in read-only memory (ROM) 1002 or programs and / or data loaded from storage portion 1008 into random access memory (RAM) 1003. The CPU 1001 can be a multi-core processor or may contain multiple processors. In some embodiments, the processor 1001 may include a general-purpose main processor and one or more special coprocessors, such as a graphics processing unit (GPU), a neural network processor (NPU), a digital signal processor (DSP), etc. Various programs and data required for the operation of the electronic device 1000 are also stored in RAM 1003. The CPU 1001, ROM 1002, and RAM 1003 are interconnected via bus 1004. An input / output (I / O) interface 1005 is also connected to bus 1004.

[0146] The processor and memory described above are used together to execute a program stored in the memory. When the program is executed by a computer, it can implement the steps or functions of the file transfer method described in the above embodiments.

[0147] The following components are connected to I / O interface 1005: an input section 1006 including a keyboard, mouse, touchscreen, etc.; an output section 1007 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1008 including a hard disk, etc.; and a communication section 1009 including a network interface card such as a LAN card, modem, etc. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to I / O interface 1005 as needed. A removable medium 1011, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 1010 as needed so that computer programs read from it can be installed into storage section 1008 as needed. Figure 10 The diagram only shows a portion of the components and does not imply that the computer system 1000 only includes... Figure 10 The components shown.

[0148] The systems, devices, modules, or units described in the above embodiments can be implemented by a computer or its associated components. The computer may be, for example, a mobile terminal, smartphone, personal computer, laptop computer, in-vehicle human-machine interface device, personal digital assistant, media player, navigation device, game console, tablet computer, wearable device, smart TV, Internet of Things system, smart home, industrial computer, server, or a combination thereof.

[0149] Although not shown, in embodiments of this disclosure, a program product is provided, including a computer program that, when executed by a processor, implements the methods of any of the embodiments of this disclosure.

[0150] Although not shown, in embodiments of this disclosure, a storage medium is provided that stores a computer program configured to be executed to implement the methods of any of the embodiments of this disclosure.

[0151] The storage media in embodiments of this disclosure include articles that are permanent and non-permanent, removable and non-removable, capable of storing information by any method or technology. Examples of storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0152] The methods, programs, systems, apparatuses, etc., of the embodiments of this disclosure can be executed or implemented in a single or multiple networked computers, or practiced in a distributed computing environment. In the embodiments of this specification, in these distributed computing environments, tasks can be performed by remote processing devices connected via a communication network.

[0153] Those skilled in the art will understand that the embodiments described in this specification can be provided as methods, systems, or computer program products. Therefore, those skilled in the art will realize that the functional modules / units or controllers and related method steps described in the above embodiments can be implemented in software, hardware, or a combination of both.

[0154] Unless explicitly stated otherwise, the actions or steps of the methods or procedures described in the embodiments of this disclosure do not necessarily have to be performed in a specific order and can still achieve the desired results. In some implementations, multitasking and parallel processing are also possible or may be advantageous.

[0155] This document describes several embodiments of the present disclosure; however, for the sake of brevity, the descriptions of the embodiments are not exhaustive, and identical or similar features or portions between the embodiments may be omitted. In this document, "one embodiment," "some embodiments," "example," "specific example," or "some examples" refers to at least one embodiment or example applicable to the present disclosure, but not all embodiments. The above terms do not necessarily refer to the same embodiment or example. Without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of the different embodiments or examples.

[0156] The exemplary systems and methods of this disclosure have been specifically shown and described with reference to the foregoing embodiments, and are merely examples of the best mode for implementing the systems and methods. Those skilled in the art will understand that various changes can be made to the embodiments of the systems and methods described herein without departing from the spirit and scope of this disclosure as defined in the appended claims when implementing the systems and / or methods.

Claims

1. A resource access control method, characterized in that, include: In response to a resource requester's request to invoke a target resource, obtain the first real-time concurrency count of the target resource; The first real-time concurrency count is increased by a preset value to obtain the first updated concurrency count of the target resource. The first updated concurrency count is used to reserve the concurrency quota of the corresponding target resource. Compare the first update concurrency with the concurrency threshold; If the first update concurrency is greater than the concurrency threshold, obtain the second real-time concurrency of the target resource and subtract the preset value from the second real-time concurrency to obtain the second update concurrency of the target resource, and reject the call request; If the first update concurrency is less than or equal to the concurrency threshold, a call session for invoking the target resource is created for the resource requester. If the call session is successfully created, a concurrency holding identifier is created for the call session and set to a first preset state. When the call session ends, the state of the concurrency holding identifier is identified. If the concurrency holding identifier is identified as being in the first preset state, the concurrency holding identifier is set to a second preset state. The fourth real-time concurrency of the target resource is obtained, and the fourth update concurrency of the target resource is obtained by subtracting the preset value from the fourth real-time concurrency. The concurrency holding identifier is session-level and is recorded and managed in a global concurrency information table.

2. The resource access control method according to claim 1, characterized in that, When creating the invocation session for the resource requester, the method includes: Determine the creation status of the invocation session; If the call session creation fails, obtain the third real-time concurrency of the target resource, subtract the preset value from the third real-time concurrency to obtain the third update concurrency of the target resource, and reject the call request.

3. The resource access control method according to claim 2, characterized in that, When creating the invocation session for the resource requester, the method further includes: If the invocation session is successfully created, determine the usage status of the invocation session; When the call session ends, the fourth real-time concurrency of the target resource is obtained, and the fourth update concurrency of the target resource is obtained by subtracting the preset value from the fourth real-time concurrency.

4. The resource access control method according to any one of claims 1 to 3, characterized in that, The method further includes: Periodically check the usage duration of created call sessions; If the usage duration of the created call session exceeds the preset duration, obtain the fifth real-time concurrency of the target resource, and subtract the preset value from the fifth real-time concurrency to obtain the fifth update concurrency of the target resource.

5. The resource access control method according to any one of claims 1 to 3, characterized in that, The method further includes: Create a concurrency information table to record resource information, concurrency information, and session information; When a call session is successfully created, the session information of the created call session is recorded in the concurrency information table, wherein the session information includes a unique session identifier and a session start time; In response to a change in the state of the calling session, update the session information of the calling session recorded in the concurrency information table; Periodically check the session information recorded in the concurrency information table.

6. A resource allocation control device, characterized in that, include: The acquisition unit is configured to acquire the first real-time concurrency of the target resource in response to a resource requester's call request for the target resource; The update unit is configured to increase the first real-time concurrency count by a preset value to obtain the first update concurrency count of the target resource, wherein the first update concurrency count is used to reserve the concurrency quota of the corresponding target resource; The comparison unit is configured to compare the first update concurrency with a concurrency threshold; The first calling unit is configured to, when the first update concurrency is greater than the concurrency threshold, obtain the second real-time concurrency of the target resource and subtract the preset value from the second real-time concurrency to obtain the second update concurrency of the target resource, and reject the calling request. Specifically, when the calling session is successfully created, a concurrency holding identifier is created for the calling session and set to a first preset state; when the calling session ends, the state of the concurrency holding identifier is identified; if the concurrency holding identifier is identified as being in the first preset state, the concurrency holding identifier is set to a second preset state, a fourth real-time concurrency of the target resource is obtained, and the fourth update concurrency of the target resource is subtracted from the preset value from the fourth real-time concurrency. The concurrency holding identifier is session-level and is recorded and managed in a global concurrency information table. The second invocation unit is configured to create an invocation session for the resource requester to invoke the target resource when the first update concurrency is less than or equal to the concurrency threshold.

7. An electronic device, characterized in that, include: A processor and a memory storing a computer program, the processor being configured to implement the method of any one of claims 1-5 when executing the computer program.

8. A program product comprising a computer program, wherein, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-5.

Images