Concurrent request processing method, apparatus, device, medium, and program product

Abstract

This application relates to the field of concurrent request processing technology, and provides a concurrent request processing method, apparatus, device, medium, and program product. The method includes: parsing received concurrent requests, determining the current count value of the Redis counter key corresponding to the concurrent request, and atomically comparing the current count value with a preset threshold; when the current count value is less than the preset threshold, incrementing the Redis counter key and determining the request to be executed; when the current count value is greater than or equal to the preset threshold, periodically polling the Redis counter key and the preset threshold, and when the current count value is detected to have decreased to below the preset threshold during the polling process, incrementing the Redis counter key and determining the request to be executed; executing a generation task according to the request to be executed, decrementing the Redis counter key, and releasing the concurrent slots occupied by the request to be executed. This invention enables the execution of requests, the release of counts, and the extraction of waiting queues to form a seamless processing chain on the same Redis counter key.

Description

Technical Field

[0001] This invention relates to the field of concurrent request processing technology, and in particular to a concurrent request processing method, apparatus, device, medium, and program product. Background Technology

[0002] In existing technologies, limiting and controlling the number of concurrent requests mainly relies on two types of solutions: message queue technology and thread pool technology.

[0003] Message queue solutions introduce middleware such as Kafka and RabbitMQ to buffer and distribute requests. However, they require additional deployment and maintenance of message storage, transmission, and consumption mechanisms. In scenarios with high concurrency, message backlog can easily occur, leading to increased processing latency. Furthermore, parameters such as message queue capacity are usually configured during system deployment, and adjusting them during runtime carries significant risks.

[0004] Thread pool solutions control concurrency by limiting the number of threads. When multiple threads read and write to shared counting resources, locking or synchronization mechanisms are required to ensure data consistency. This brings additional overhead to thread scheduling and context switching. Furthermore, the upper limit of the number of threads in the thread pool is difficult to adjust dynamically without restarting the service, resulting in a lack of flexibility in controlling the number of concurrency. Summary of the Invention

[0005] This invention provides a concurrent request processing method, apparatus, device, medium, and program product. This invention avoids the read and write gaps caused by multiple concurrent requests simultaneously reading the count value and then initiating auto-increment requests separately. It eliminates the need to introduce message queue middleware to maintain message storage and forwarding mechanisms, and also eliminates the need to rely on thread pool locking mechanisms to synchronize shared counting resources. This allows the execution of requests, the release of counts, and the retrieval of waiting queues to form a seamless processing chain on the same Redis counting key.

[0006] In a first aspect, embodiments of this application provide a concurrent request processing method, including: The received concurrent requests are parsed to determine the current count value of the Redis counter key corresponding to the concurrent request, and the current count value is atomically compared with a preset threshold. When the current count value is less than the preset threshold, the Redis counter key is incremented and the request to be executed is determined; When the current count value is greater than or equal to the preset threshold, the Redis counter key and the preset threshold are periodically polled. During the polling process, if the current count value is detected to decrease to below the preset threshold, the Redis counter key is incremented and a request to be executed is determined. The generation task is executed according to the pending request. After the generation task is completed, the Redis counter key is decremented and the concurrent slots occupied by the pending request are released.

[0007] Optionally, in a first implementation of the first aspect of the present invention, parsing the received concurrent requests, determining the current count value of the Redis counter key corresponding to the concurrent requests, and atomically comparing the current count value with a preset threshold includes: The received concurrent requests are parsed to obtain the business identifier corresponding to the concurrent request. The business identifier is used to identify the third-party interface to which the concurrent request belongs. If the counter key corresponding to the business identifier does not exist, create a Redis counter key with an initial value of zero; Obtain the current count value of the Redis counter key corresponding to the concurrent request, and perform an atomic comparison between the current count value and a preset threshold.

[0008] Optionally, in a second implementation of the first aspect of the present invention, the step of incrementing the Redis counter key and determining the request to be executed when the current count value is less than the preset threshold includes: When the current count value is less than the preset threshold, the Redis counter key is incremented to obtain an atomic comparison script; The atomic comparison script is input into Redis for single-threaded sequential execution. When the atomic comparison scripts corresponding to multiple concurrent requests arrive at Redis simultaneously, they are executed sequentially according to the order of arrival time to determine the requests to be executed.

[0009] Optionally, in a third implementation of the first aspect of the present invention, the step of inputting the atomic comparison script into Redis for single-threaded sequential execution, wherein when multiple atomic comparison scripts corresponding to concurrent requests arrive at Redis simultaneously, are executed sequentially according to the order of their arrival time in Redis, and the request to be executed is determined, includes: Multiplex the atomic comparison scripts sent by multiple clients to obtain a set of ready connections; The atomic comparison scripts in the ready connection set are queued in the order of their arrival time in Redis to obtain a command execution queue; The atomic alignment scripts are retrieved sequentially from the command execution queue by a single thread and executed to determine the requests to be executed.

[0010] Optionally, in a fourth implementation of the first aspect of the present invention, the step of periodically polling the Redis counter key and the preset threshold when the current count value is greater than or equal to the preset threshold, and when the current count value is detected to have decreased to below the preset threshold during the polling process, incrementing the Redis counter key and determining the request to be executed, includes: When the current count value is greater than or equal to the preset threshold, the concurrent requests are enqueued to obtain a waiting queue sorted by request timestamp; The Redis counter key is periodically polled. When the current count value decreases below the preset threshold, the waiting queue is extracted based on the current count value and the preset threshold, and the request to be executed is determined.

[0011] Optionally, in a fifth implementation of the first aspect of the present invention, the step of enqueuing the concurrent requests to obtain a waiting queue sorted by request timestamps when the current count value is greater than or equal to the preset threshold includes: When the current count value is greater than or equal to the preset threshold, the generation status field of the concurrent request is updated to obtain a request record with a status of waiting; The request records in the waiting state are sorted according to their request timestamps to obtain a waiting queue sorted by request timestamp.

[0012] Optionally, in a sixth implementation of the first aspect of the present invention, the step of periodically polling the Redis counter key, and when the current count value decreases below the preset threshold, extracting the waiting queue and determining the request to be executed based on the current count value and the preset threshold, includes: The Redis counter key is queried according to a preset polling cycle to obtain the current counter value at the time of query. The number of available slots is calculated based on the preset threshold and the current counter value at the time of query. Based on the number of available slots, requests are extracted from the head of the waiting queue in the order of their request timestamps to determine the requests to be executed.

[0013] Optionally, in the seventh implementation of the first aspect of the present invention, the step of executing a generation task according to the request to be executed, and after the generation task is completed, decrementing the Redis counter key and releasing the concurrent slots occupied by the request to be executed, includes: Based on the business identifier corresponding to the request to be executed, a generation task is executed on the third-party interface corresponding to the request to be executed, and the storage address of the generation result is obtained. After obtaining the storage address of the generated result, the Redis counter key is decremented and the concurrent slots occupied by the pending request are released.

[0014] Optionally, in the eighth implementation of the first aspect of the present invention, the step of decrementing the Redis counter key and releasing the concurrent slots occupied by the pending request after obtaining the storage address of the generated result includes: After obtaining the storage address of the generated result, the decrement operation of the Redis counter key is encapsulated in a script to obtain an atomic release script; The atomic release script is input into Redis to obtain the current count value after decrementing. The current count value after decrementing is used for periodic polling to determine the number of available release slots.

[0015] Secondly, embodiments of this application provide a concurrent request processing apparatus, including: The request parsing module is used to parse the received concurrent requests, determine the current count value of the Redis counter key corresponding to the concurrent request, and perform an atomic comparison between the current count value and a preset threshold. The first request processing module is used to increment the Redis counter key and determine the request to be executed when the current count value is less than the preset threshold. The second request processing module is used to periodically poll the Redis counter key and the preset threshold when the current count value is greater than or equal to the preset threshold. During the polling process, when the current count value is detected to have decreased to below the preset threshold, the Redis counter key is incremented and a request to be executed is determined. The request release module is used to execute a generation task according to the pending request, and after the generation task is completed, decrement the Redis counter key and release the concurrent slots occupied by the pending request.

[0016] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described concurrent request processing method.

[0017] Fourthly, embodiments of this application provide a readable storage medium storing a computer program that, when executed by a processor, implements the steps of the aforementioned concurrent request processing method.

[0018] Fifthly, embodiments of this application provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the above-described concurrent request processing method.

[0019] In one solution provided by the aforementioned concurrent request processing methods, devices, equipment, media, and program products, the comparison and counting operations of concurrent requests are encapsulated into a script and executed sequentially by a single thread in Redis. This allows the judgment and increment process for the same Redis counter key to be completed in a single execution, avoiding the read and write gaps caused by multiple concurrent requests simultaneously reading the counter value and then initiating separate increment requests. It eliminates the need for message queue middleware to maintain message storage and forwarding mechanisms, and also eliminates the need to rely on thread pool locking mechanisms for synchronous control of shared counting resources. For requests that fail the comparison because the current counter value has reached a preset threshold, their status fields are marked and updated according to the request time. A waiting queue is formed by sorting by a stylus. A scheduled task queries the Redis counter key at a preset polling period. The difference between the query count and a preset threshold determines the number of available slots. Based on this, the corresponding number of requests are retrieved from the waiting queue and re-executed for comparison. This allows waiting requests to be reintroduced into the processing flow without relying on event notifications or callback mechanisms. After the generation task is completed, the count value obtained by decrementing the Redis counter key is used as the basis for the scheduled polling to determine the number of available slots. This creates a seamless processing chain on the same Redis counter key, connecting request execution, count release, and waiting queue retrieval. Attached Figure Description

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

[0021] Figure 1 This is a schematic diagram of the structure of a concurrent request processing system according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the first process of a concurrent request processing method in one embodiment of the present invention; Figure 3 yes Figure 2 A schematic diagram of the implementation process of step S10; Figure 4 yes Figure 2 A schematic diagram of the implementation process of step S20; Figure 5 yes Figure 2 A schematic diagram of the implementation process of step S30; Figure 6 yes Figure 2 A schematic diagram of the implementation process of step S40; Figure 7 This is a second flowchart illustrating the concurrent request processing method in one embodiment of the present invention; Figure 8 This is a schematic diagram of a concurrent request processing device according to an embodiment of the present invention; Figure 9 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention. Detailed Implementation

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

[0023] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. It should also be understood that, as used in this specification and the appended claims, the term "and / or" refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0024] Furthermore, in the description of this invention and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0025] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of the invention include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0026] It should be understood that the sequence number of each step in the following embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0027] To illustrate the technical solution of the present invention, specific embodiments are described below.

[0028] To address the problems mentioned above in the background art, embodiments of this application propose a concurrent request processing method, apparatus, device, medium, and program product. The concurrent request processing method provided by the embodiments of this invention can be applied to, for example... Figure 1 The concurrent request processing system shown includes a client and a server.

[0029] In one embodiment, such as Figure 2 As shown, a concurrent request processing method is provided, which is applied to... Figure 1 Taking a concurrent request processing system as an example, the following steps are included: S10: Parse the received concurrent requests, determine the current count value of the Redis counter key corresponding to the concurrent request, and atomically compare the current count value with the preset threshold; S20: When the current count value is less than the preset threshold, increment the Redis counter key and determine the request to be executed; S30: When the current count value is greater than or equal to the preset threshold, the Redis counter key and the preset threshold are periodically polled. During the polling process, if the current count value is detected to have decreased to below the preset threshold, the Redis counter key is incremented and the request to be executed is determined. S40: Execute the generation task according to the pending request. After the generation task is completed, decrement the Redis counter key and release the concurrent slots occupied by the pending request.

[0030] In this embodiment, the comparison and counting operations for concurrent requests are encapsulated into a script and executed sequentially by a single thread in Redis. This allows the judgment and increment process for the same Redis counter key to be completed in a single execution, avoiding the read and write gaps caused by multiple concurrent requests simultaneously reading the counter value and then initiating separate increment requests. It eliminates the need for message queue middleware to maintain message storage and forwarding mechanisms, and also eliminates the need to rely on thread pool locking mechanisms for synchronous control of shared counting resources. For requests that fail the comparison because the current counter value has reached a preset threshold, their generated status fields are marked and sorted by request timestamps to form a waiting queue, which is then processed by a timer. The system queries the Redis counter key according to a preset polling cycle. Based on the difference between the obtained count value and a preset threshold, it determines the number of available slots. Accordingly, it retrieves the corresponding number of requests from the waiting queue and re-executes the comparison, allowing waiting requests to be reintroduced into the processing flow without relying on event notifications or callback mechanisms. After the task is generated, the count value obtained by decrementing the Redis counter key is used as the basis for determining the number of available slots in the timed polling phase. This ensures that the execution of requests, the release of the count, and the retrieval from the waiting queue form a seamless processing chain on the same Redis counter key.

[0031] In one embodiment, such as Figure 3 As shown, step S10 specifically includes the following steps: S11: Parse the received concurrent requests to obtain the business identifier corresponding to the concurrent request. The business identifier is used to identify the third-party interface to which the concurrent request belongs. S12: If the counter key corresponding to the business identifier does not exist, create a Redis counter key with an initial value of zero; S13: Obtain the current count value of the Redis counter key corresponding to the concurrent request, and perform an atomic comparison between the current count value and the preset threshold.

[0032] In this embodiment, after receiving concurrent requests for image generation, video generation, or other requests that require calling third-party interfaces, the server performs unified parsing of the request message at the gateway layer or business service layer. It extracts the user identifier, request identifier, request timestamp, request type, and third-party interface channel identifier from the request header, request body, or routing parameters. The third-party interface channel identifier can serve as a business identifier. For example, the image generation interface is identified as img_gen_api, and the video generation interface is identified as video_gen_api. Since the third-party interface limits the number of concurrent requests per interface channel rather than per individual user, the business identifier is a core component of the Redis counter key. After parsing the business identifier, the server concatenates the Redis counter key according to a unified naming convention. For example, the counter key corresponding to the business identifier `img_gen_api` is set to `concurrent:count:img_gen_api`, and the preset threshold configuration key corresponding to the business identifier is set to `concurrent:limit:img_gen_api`. The default concurrency threshold for this third-party image generation interface is set to 5, meaning that a maximum of 5 requests are allowed to be in execution at the same time. If the counter key corresponding to the business identifier does not yet exist in Redis, the server creates a Redis counter key with an initial value of zero through SETNX or the built-in initialization logic of the Lua script. A long expiration time can be set for the counter key, or no expiration time can be set, to avoid the counter structure being accidentally deleted during long-term use of the interface. In addition, to prevent the counter value from remaining due to service failure, the request status can be synchronously saved in the request record table. The server reads the preset threshold corresponding to the business identifier and encapsulates the actions of obtaining the current count value, comparing the current count value with the preset threshold, and performing an increment when the condition is met into a single Lua script, which is then submitted to Redis for execution. This is different from the application service reading the current count value and sending an increment command separately. This is because when multiple requests arrive simultaneously, the distributed execution will cause multiple requests to read the same old count value, resulting in the problem of allowing requests to pass even when the threshold is exceeded. By executing the Lua script sequentially in a single thread in Redis, it can be ensured that the reading, comparison, and increment of the same counter key are completed in a single, uninterrupted atomic execution process. After receiving parameters such as the counter key, threshold, and request identifier, the script reads the current value of the counter key. If the read result is empty, it treats it as zero and completes the initialization. Then, it checks whether the current count value is less than the preset threshold of 5. If it is less than 5, it increments the counter key and returns a "pass" flag and the incremented count value. The server uses this to determine the request as a pending request and updates the request status to "in execution". If the current count value is greater than or equal to 5, the script does not change the value of the counter key and returns a "fail" flag. The server uses this to update the request status to "waiting" and initiates the subsequent timed polling process.To ensure that the same request does not repeatedly occupy concurrency slots due to client retries, the idempotent record corresponding to the request identifier can be checked before performing atomic comparison. If the request identifier is already in execution or waiting, the existing state is returned directly and it will not participate in the counting again. At the same time, to ensure that the threshold can be dynamically adjusted, the preset threshold is stored in the Redis configuration key or configuration center. The operation and maintenance personnel can adjust the concurrency threshold of img_gen_api from 5 to other values ​​without stopping the system. The new threshold can be read and taken effect the next time the Lua script is executed.

[0033] In one embodiment, such as Figure 4 As shown, step S20 specifically includes the following steps: S21: When the current count value is less than the preset threshold, increment the Redis counter key to obtain the atomic comparison script; S22: Input the atomic comparison script into Redis for single-threaded sequential execution. When the atomic comparison scripts corresponding to multiple concurrent requests arrive in Redis at the same time, they are executed sequentially according to the order of arrival time in Redis to determine the requests to be executed.

[0034] In this embodiment, the preset threshold configuration corresponding to the business identifier is read. For example, the concurrent threshold of the third-party image generation interface is preset to 5, and the count value corresponding to the current Redis counter key is obtained. If the current count value is less than 5, it means that there are still available concurrent slots in the interface channel. At this time, "reading the count value, comparing the preset threshold, incrementing when the condition is met, and returning the execution result" are encapsulated into the same Lua atomic comparison script. The Redis counter key is passed in as KEYS[1], the preset threshold is passed in as ARGV[1], and the parameters required for request identifier, business identifier or status write-back are passed in as other input parameters, so that the script can complete the judgment and slot occupation at the Redis server at one time. That is, when the business rule judges that the current count value meets the conditions for release, an atomic comparison script for executing the auto-increment is constructed, and the auto-increment operation is actually completed in Redis by the script, instead of auto-incrementing outside the script and then generating the script, thereby avoiding the problem that multiple requests read the same old count value at the same time and then auto-increment separately, which leads to the problem that the number of requests exceeds the threshold during execution. When the script executes, if the counter key does not exist, it is first processed with an initial value of 0 and the counter key is created. Then, the current counter value is read. If the current counter value is less than the preset threshold of 5, the counter key is incremented during the same script execution, and an "execution allowed" flag and the incremented counter value are returned. For example, if the current counter value is 3, the script increments and returns 4, indicating that the request has occupied a concurrent slot and can be identified as a pending request. If the current counter value has reached 5, the script does not increment the counter, but only returns an "execution not allowed" flag, which is then processed by the subsequent waiting queue. After the server submits the atomic comparison script to Redis through the Redis client, Redis processes the received script commands sequentially according to a single-threaded event loop. Even if multiple clients send multiple concurrent requests at the same time, the atomic comparison scripts corresponding to these requests will not be executed in parallel on the same counter key. Instead, they will enter the command execution queue in the order they arrive at Redis, and Redis will retrieve and execute them one by one by a single thread. Suppose at a certain moment there are already 4 requests in execution under the same business identifier, with a preset threshold of 5. Simultaneously, 3 new requests arrive in Redis. The first arriving script reads the current count value as 4, determines it's less than 5, increments the count, and returns "allowed." The incremented count becomes 5, and this request is identified as a pending request. The second script, upon execution, already reads 5, so it doesn't increment and returns "disallowed." The third script similarly returns "disallowed." The determination of pending requests is not based on the application server's local judgment, but on the return result of the atomic comparison script in Redis. Only requests whose scripts return "allowed" and have completed the count increment are updated to the "in execution" status and enter the image generation, video generation, or other third-party API call process. Requests that fail to increment do not occupy concurrency slots, avoiding discrepancies between the count value and the actual number of executed requests.

[0035] In one embodiment, step S22 specifically includes the following steps: Multiplex the atomic comparison scripts sent by multiple clients and listen for them to obtain a set of ready connections; The atomic comparison scripts in the ready connection set are queued in the order of their arrival time in Redis to obtain the command execution queue; A single thread retrieves atomic comparison scripts from the command execution queue in sequence and executes them to determine the requests to be executed.

[0036] In this embodiment, the Redis server receives connection requests from multiple clients through a network event handling mechanism. When multiple business servers submit atomic comparison scripts simultaneously, each script is sent to the Redis port along with its corresponding Redis counter key, preset threshold, request identifier, and business identifier. Redis listens for the readable events of these client connections simultaneously through a multiplexing mechanism. When a connection has completed sending the script command and is ready to be read, it is added to the ready connection set. The ready connection set indicates that the command data from these client connections has arrived in Redis, and Redis can read and parse the complete script execution command from the connection buffer. Redis converts the atomic comparison scripts in the ready connection set into commands to be executed according to the order of event arrival and command parsing completion, and places them in the command execution queue. Each command in the queue carries a corresponding counter key and threshold parameter. For example, if the counter key for the same third-party interface channel is concurrent:count:img_gen_api and the preset threshold is 5, then although the scripts corresponding to multiple requests may arrive almost simultaneously, they will form a definite order after entering the command execution queue. Redis uses a single thread to retrieve and execute atomic comparison scripts one by one from the head of the command execution queue. No other scripts are executed while a script is running. Therefore, the process of a script reading the current counter value, checking if the current counter value is less than a preset threshold, incrementing the counter key when the condition is met, and returning the result is uninterrupted. If the first script reads a current counter value of 4 and the preset threshold is 5, the script will increment the counter value to 5 during the same execution, and return an execution permission flag. The server uses this to determine that the request is pending execution. When a subsequent script is retrieved and executed, it reads the updated counter value of 5. Therefore, the condition of being less than the threshold is no longer met, and the script will not continue to increment the counter, but will return a flag indicating whether to wait or refuse execution. By using queuing and single-threaded sequential execution, there are no parallel read / write conflicts between multiple clients sharing the same counter value, nor are there any counting gaps caused by the application layer reading before writing. The pending requests are determined entirely by the return results of the Redis atomic comparison script. Only requests that have completed auto-incrementing and successfully occupied the concurrent quota will enter the subsequent task generation process. Requests that have not successfully occupied the quota will remain in a waiting state and be handled by the subsequent timed polling mechanism, thus ensuring that the number of requests under the same business identifier is always constrained by the Redis counter key and the preset threshold.

[0037] In one embodiment, such as Figure 5 As shown, step S30 specifically includes the following steps: S31: When the current count value is greater than or equal to the preset threshold, concurrent requests will be enqueued to obtain a waiting queue sorted by request timestamp; S32: Periodically poll the Redis counter key. When the current counter value decreases below the preset threshold, extract the waiting queue based on the current counter value and the preset threshold and determine the request to be executed.

[0038] In this embodiment, after the atomic comparison script returns a "fail" flag, it indicates that the current count value of the Redis counter key corresponding to the business identifier is greater than or equal to a preset threshold. For example, the preset threshold for the third-party image generation interface is 5, and the current count value has reached 5. Therefore, the request cannot continue to occupy the execution slot, nor can it directly call the third-party interface, otherwise it will exceed the concurrency limit allowed by the third-party interface. At this time, the server needs to transfer the concurrent request to the waiting process and query its persistent record in the MySQL request record table according to the request identifier, update the generation status field from "pending judgment" to "waiting", and retain information such as user identifier, request content, request type, business identifier, and request timestamp. Furthermore, since multiple requests may be judged as waiting within the same time period, the waiting queue is not only determined according to the default database write order, but also sorted by the request timestamp. Request records with the status of "waiting" under the same business identifier are arranged from earliest to latest time, thus forming a first-come, first-served waiting queue to avoid later requests repeatedly occupying the concurrent slots of earlier requests. In this embodiment, the scheduled task runs according to a preset polling cycle, for example, a poll every 5 seconds. In each round of processing, it reads the current count value of the corresponding Redis counter key according to the business identifier, and at the same time reads the preset threshold configuration corresponding to the business identifier. If the current count value is still greater than or equal to the preset threshold, it means that there are no idle execution slots for the interface channel. The scheduled task does not extract from the waiting queue, but only ends the current round of processing for the business identifier and waits for the next round. If the current count value has decreased to below the preset threshold, for example, a concurrent slot is released after a generating task is completed, causing the current count value to drop from 5 to 3, it means that there are still requests that can be allowed under the business identifier. The scheduled task can determine the maximum number of waiting requests that can be extracted in this round based on the difference between the current count value and the preset threshold, and extract the corresponding number of request records from the head of the waiting queue in the order of request timestamps. To avoid competition between the scheduled task and newly arrived requests when retrieving pending requests, the scheduled task resubmits the same Redis atomic comparison script before actually determining the request to be executed. The script rereads the current value of the counter key and increments it when it is less than a preset threshold. Only when the script returns a request that is allowed to be executed and successfully occupies the quota will its status be updated from "waiting" to "executing" and it will be determined as a request to be executed. If the script returns a failure during the polling process because other requests occupy the quota first, the request will remain in the "waiting" state and continue to be processed in subsequent polling cycles.

[0039] In one embodiment, step S31 specifically includes the following steps: When the current count value is greater than or equal to the preset threshold, update the generation status field of the concurrent request to obtain the request record with the status of waiting; The request records in the waiting state are sorted according to their request timestamps to obtain a waiting queue sorted by request timestamp.

[0040] In this embodiment, when the atomic comparison script reads that the current count value of the Redis counter key corresponding to the business identifier is greater than or equal to a preset threshold (e.g., the preset concurrency threshold for a third-party image generation interface is 5, and the current count value is already 5), it indicates that the execution quota of the interface channel has been fully occupied. The concurrent request cannot immediately enter the generation task, nor can it directly call the third-party interface. Therefore, the server needs to locate the record of the request in the MySQL request record table based on the request identifier, and update the generation status field from "pending judgment" to "waiting" in the same business processing transaction. Simultaneously, it writes the waiting start time, business identifier, request timestamp, request type, and necessary request content index, so that the request is persistently retained without occupying Redis concurrency quotas. To avoid the same request entering the waiting queue multiple times due to repeated client submissions or network retries, the server can perform an idempotent check based on the request identifier before updating the status. If the request is already in "waiting" or "executing," it will not be repeatedly inserted or updated, but will directly return the current status. If the request is still in "pending judgment," the status update will be performed, and the corresponding request cache record in Redis will be synchronously marked as waiting. The waiting queue can be implemented without relying on a separate message queue middleware. Instead, it can be represented by a set of request records in the database that share the same business identifier and have a "waiting" status field. When the server or scheduled task queries waiting requests, it sorts them in ascending order by request timestamp. If the timestamps are the same, it further sorts them by request identifier or auto-incrementing number stored in the database, thus obtaining a stable order. Requests submitted earlier are placed at the head of the queue, and requests submitted later are placed at the tail. This prevents later requests from overtaking earlier requests when quotas are released, and also facilitates the restoration of the waiting queue based on persistent records after a system restart. For example, if the preset polling period is 5 seconds, the scheduled task queries request records with a "waiting" status every 5 seconds and checks the current Redis counter value to determine if there are any available quotas. Before a quota is released, the request remains in a waiting state without changing the Redis counter value. After a quota is released, the request is retrieved from the head of the waiting queue (sorted by request timestamp) and the atomic comparison script is re-executed. Only requests that pass the re-comparison and complete the Redis counter increment will be updated from "waiting" to "in execution."

[0041] In one embodiment, step S32 specifically includes the following steps: The Redis counter key is queried according to a preset polling cycle to obtain the current counter value at the time of query. The number of available slots is calculated based on the preset threshold and the current counter value at the time of query. Based on the number of available slots, requests are extracted from the head of the waiting queue in the order of their request timestamps to determine the requests to be executed.

[0042] In this embodiment, a fixed polling period is configured in the scheduled task module, for example, the preset polling period is 5 seconds, and the scheduled task traverses the concurrency count key in Redis according to the business identifier dimension. For example, for the third-party image generation interface, it reads the current count value of concurrent:count:img_gen_api, and at the same time reads the concurrency threshold configuration corresponding to the business identifier, for example, the preset threshold is 5. At each polling interval, the scheduled task retrieves the current count value of the Redis counter key at that moment. The count value is derived from the atomic increment at the start of the previous request execution and the atomic decrement after the task is completed, thus reflecting the number of requests still in execution under that business identifier. If the current count value obtained is greater than or equal to the preset threshold, it means that the third-party interface channel is still fully loaded. The scheduled task does not extract requests from the waiting queue, nor does it change the status of the waiting requests. Instead, it ends the current round of processing and waits for the next polling. If the current count value obtained is less than the preset threshold, it means that some executing requests have completed and released the concurrency quota. At this time, the scheduled task determines the number of quotas that can be released in this round based on the difference between the preset threshold and the current count value at the time of query. For example, if the preset threshold is 5 and the current count value is 3, a maximum of 2 waiting requests can be extracted in this round. The scheduled task queries and generates a set of request records with a status field of "Waiting" based on the business identifier. These records are then sorted by request timestamp from earliest to latest, placing the earliest submitted and unexecuted request at the head of the queue. The task then retrieves the corresponding number of request records from the head of the queue according to the number of available slots. For requests with the same timestamp, a secondary sorting can be performed based on the request identifier or the order of data entry to ensure a stable retrieval order. To prevent new requests from entering and preempting slots during the polling process, the scheduled task resubmits the Redis atomic comparison script for each request before classifying it as a pending request. This causes the script to read the current value of the counter key again and increment it if the current count is still less than a preset threshold. Only requests that successfully occupy concurrent slots and are allowed to execute are updated to "Executing" and designated as pending requests, subsequently entering the image or video generation task process. If the script returns a failure, it indicates that the slot has been occupied by another request, and the request remains in the "Waiting" state until the next round of polling.

[0043] In one embodiment, such asFigure 6 As shown, step S40 specifically includes the following steps: S41: Based on the business identifier corresponding to the request to be executed, execute the generation task on the third-party interface corresponding to the request to be executed, and obtain the storage address of the generation result; S42: After obtaining the storage address of the generated results, decrement the Redis counter key and release the concurrent slots occupied by the pending requests.

[0044] In this embodiment, after a concurrent request is atomically compared through Redis and successfully occupies the concurrent quota, the server determines the request as a pending request and locates the corresponding third-party interface configuration based on the business identifier stored in the request record. For example, when the business identifier is img_gen_api, the server reads the image generation interface address, authentication credentials, request parameter template, timeout time, and result callback rules bound to the business identifier. Then, the server assembles the user identifier, request identifier, request content, request type, and necessary generation parameters in the pending request into a call message that the third-party interface can recognize, and initiates the generation task call only after the request status has been updated to "in execution". If the request to be executed is an image generation request, the server can encapsulate the prompt, size parameters, style parameters, etc., and submit them to the image generation interface. If the request to be executed is a video generation request, the server can encapsulate the script content, target duration, aspect ratio, etc., and submit them to the video generation interface. In order to ensure that the same request will not be generated repeatedly after network retries or interface timeouts, the server writes the request identifier as an idempotent identifier into the call context, so that the result returned by the third-party interface or the platform-side compensation retries can all correspond to the same request record. During the generation task execution, the current count value of the Redis counter key remains unchanged. For example, if the preset threshold is 5 and the count value is 5 after the request occupies the quota, then before the third-party interface returns the generation result, the quota will always be considered occupied. Subsequent new requests can only enter the waiting queue or wait for the quota to be released by periodic polling. When the third-party interface returns the generation success result, the server obtains the temporary download address or binary result of the generated file, and then uploads the generation result to object storage, file storage or platform resource service to generate a stable and accessible generation result storage address, such as oss: / / bucket / result / requestId.png or the corresponding video file address. This address is then written back to the MySQL request record table, and the generation status is updated from "Executing" to "Completed". Only after confirming that the storage address for the generated results has been obtained and the status write-back is complete, does the server enter the concurrent quota release process. This involves relocating the Redis counter key based on the request's business identifier and performing a decrement operation on the counter key, releasing one concurrent quota occupied by the request. To avoid the release action interfering with the atomic comparison actions of other requests and causing counting anomalies, the decrement operation is executed using a Redis script or atomic command. Before decrementing, the count value is checked to be greater than zero to prevent the count value from becoming negative due to repeated callbacks, repeated releases, or anomaly compensation. The current count value obtained after decrementing will continue to be used as the basis for periodically polling to determine the number of available quotas. For example, if the preset threshold is 5 and the count value drops from 5 to 4 after a task is completed, the next round of periodic tasks can determine that there is an available quota and retrieve the oldest waiting request from the head of the waiting queue to re-execute the atomic comparison.

[0045] In one embodiment, step S42 specifically includes the following steps: After obtaining the storage address of the generated results, the decrement operation of the Redis counter key is encapsulated in a script to obtain an atomic release script; Input the atomic release script into Redis to get the current count value after decrementing. The current count value after decrementing is used for periodic polling to determine the number of available release slots.

[0046] In this embodiment, after the third-party generation task is completed and the storage address of the generation result is obtained, the server relocates the Redis counter key occupied by the request based on the business identifier in the request record. For example, when the business identifier is img_gen_api, the corresponding counter key is concurrent:count:img_gen_api. Then, instead of directly executing the ordinary DECR command at the application layer, the counter value reading, validity verification, decrement release, and return of the release result are encapsulated in the same RedisLua script to obtain the atomic release script. The generation task may have repeated callbacks from third-party interfaces, server retries, and repeated execution of exception compensation tasks. If the counter key is directly decremented, it may cause the same request to release concurrent quotas repeatedly, making the counter value lower than the actual number of requests executed, or even negative. Therefore, the atomic release script first reads the current value of the counter key inside Redis. If the counter key does not exist or the current value is less than or equal to zero, the decrement is not performed, and a release failure or no release is returned. If the current value is greater than zero, the counter key is decremented during the same script execution, and the current count value after decrement is returned. After the server inputs the atomic release script into Redis, Redis executes the script commands sequentially in a single thread. This ensures that the release action does not overlap with atomic comparisons or incrementing actions of other requests, thus guaranteeing the continuity and consistency of count changes under the same business identifier. For example, with a preset threshold of 5, before a certain image generation request is completed, the current count value of `concurrent:count:img_gen_api` is 5. After the server has obtained the storage address of the generated result and updated the request status to "completed", the atomic release script reads the current count value of 5, determines that it is greater than zero, and then decrements the count value to 4, returning 4 to the server. This decremented current count value is then read by the timed polling module. If the preset polling period is 5 seconds, the timed task will find that the current count value of 4 is less than the preset threshold of 5 in the next round of querying. It can then determine that there is a release slot under this business identifier and extract the first request from the request record set with the status of "waiting" in order of request timestamp to re-execute the atomic comparison. To further ensure a closed-loop release process, the server can write the release result, release time, pre-release count value, and post-release count value into the request record or log record. When the script returns an exception, the server can trigger a count correction process by querying the number of requests that are still "in execution" and comparing them with the Redis count value to prevent count residues caused by service downtime or network anomalies.

[0047] In this embodiment, as Figure 7As shown in the diagram, the second flowchart of the concurrent request processing method in one embodiment of the present invention illustrates the process of a user submitting a request, which is stored in a MySQL table on the server, a Redis counter key is queried and compared with a preset threshold. If the comparison fails, the process switches to waiting and a timed task polls the remaining number of counter keys. If the condition is met, the comparison is repeated. If the comparison passes, the generation task is executed until the process ends.

[0048] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0049] In one embodiment, a concurrent request processing apparatus is provided, which corresponds one-to-one with the concurrent request processing methods in the above embodiments. For example... Figure 8 As shown, the concurrent request processing device includes: The request parsing module 801 is used to parse the received concurrent requests, determine the current count value of the Redis counter key corresponding to the concurrent request, and atomically compare the current count value with a preset threshold. The first request processing module 802 is used to increment the Redis counter key and determine the request to be executed when the current count value is less than a preset threshold. The second request processing module 803 is used to periodically poll the Redis counter key and the preset threshold when the current count value is greater than or equal to the preset threshold. During the polling process, when the current count value is detected to have decreased to below the preset threshold, the Redis counter key is incremented and the request to be executed is determined. The request release module 804 is used to execute a generation task based on the pending request. After the generation task is completed, the Redis counter key is decremented and the concurrent slots occupied by the pending request are released.

[0050] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0051] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0052] This application also provides a computer device, such as... Figure 9 As shown, the computer device includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor. When the processor executes the computer program, it implements the steps in any of the above method embodiments, or when the processor executes the computer program, it implements the functions of each module / unit in the above device embodiments.

[0053] For example, the computer program may be divided into one or more modules / units, which are stored in the memory and executed by the processor to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the computer device.

[0054] Those skilled in the art will understand that Figure 9 The computer device described is merely an example and does not constitute a limitation on the computer device. It may include more or fewer components than shown, or combine certain components, or different components. For example, the computer device may also include input / output devices, network access devices, buses, etc.

[0055] The aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), or field-programmable gate arrays (FPGAs). Programmable Gate Array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0056] The memory can be an internal storage unit of the computer device, such as a hard drive or RAM. The memory can also be an external storage device of the computer device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory can include both internal and external storage units of the computer device.

[0057] This application also provides a readable storage medium storing a computer program, which, when executed by a processor, can implement the steps in the above-described method embodiments.

[0058] This application provides a computer program product that, when run on an electronic device, enables the electronic device to implement the steps described in the various method embodiments above.

[0059] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

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

[0061] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0062] In the embodiments provided in this application, it should be understood that the disclosed apparatus / devices and methods can be implemented in other ways. For example, the apparatus / device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0063] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0064] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for handling concurrent requests, characterized in that, include: The received concurrent requests are parsed to determine the current count value of the Redis counter key corresponding to the concurrent request, and the current count value is atomically compared with a preset threshold. When the current count value is less than the preset threshold, the Redis counter key is incremented and a request to be executed is determined. Specifically, this includes: when the current count value is less than the preset threshold, the Redis counter key is incremented to obtain an atomic comparison script; the atomic comparison scripts sent by multiple clients are multiplexed and monitored to obtain a ready connection set; the atomic comparison scripts in the ready connection set are queued in the order of arrival time in Redis to obtain a command execution queue; a single thread retrieves the atomic comparison scripts from the command execution queue in sequence for execution to determine the request to be executed; wherein reading the count value, comparing the preset threshold, incrementing when the condition is met, and returning the execution result are encapsulated into the same atomic comparison script. When the current count value is greater than or equal to the preset threshold, the Redis counter key and the preset threshold are periodically polled. During the polling process, if the current count value is detected to have decreased to below the preset threshold, the Redis counter key is incremented and a request to be executed is determined. Specifically, this includes: when the current count value is greater than or equal to the preset threshold, updating the generation status field of the concurrent request to obtain a request record with a status of "waiting"; sorting the request records with a status of "waiting" according to the request timestamp to obtain a waiting queue sorted by request timestamp; querying the Redis counter key according to a preset polling period to obtain the current count value at the time of query; calculating the number of release slots based on the preset threshold and the current count value at the time of query; and extracting the release slots from the head of the waiting queue according to the order of the request timestamps to determine the requests to be executed. The generation task is executed according to the pending request. After the generation task is completed, the Redis counter key is decremented and the concurrent slots occupied by the pending request are released.

2. The concurrent request processing method as described in claim 1, characterized in that, The step of parsing the received concurrent requests, determining the current count value of the Redis counter key corresponding to the concurrent request, and atomically comparing the current count value with a preset threshold includes: The received concurrent requests are parsed to obtain the business identifier corresponding to the concurrent request. The business identifier is used to identify the third-party interface to which the concurrent request belongs. If the counter key corresponding to the business identifier does not exist, create a Redis counter key with an initial value of zero; Obtain the current count value of the Redis counter key corresponding to the concurrent request, and perform an atomic comparison between the current count value and a preset threshold.

3. The concurrent request processing method as described in claim 1, characterized in that, The step of executing a generation task based on the pending request, and decrementing the Redis counter key and releasing the concurrent slots occupied by the pending request after the generation task is completed, includes: Based on the business identifier corresponding to the request to be executed, a generation task is executed on the third-party interface corresponding to the request to be executed, and the storage address of the generation result is obtained. After obtaining the storage address of the generated result, the Redis counter key is decremented and the concurrent slots occupied by the pending request are released.

4. The concurrent request processing method as described in claim 3, characterized in that, After obtaining the storage address of the generated result, decrementing the Redis counter key and releasing the concurrent slots occupied by the pending request includes: After obtaining the storage address of the generated result, the decrement operation of the Redis counter key is encapsulated in a script to obtain an atomic release script; The atomic release script is input into Redis to obtain the current count value after decrementing. The current count value after decrementing is used for periodic polling to determine the number of available release slots.

5. A concurrent request processing apparatus, characterized in that, The steps for implementing the concurrent request processing method as described in any one of claims 1 to 4 include: The request parsing module is used to parse the received concurrent requests, determine the current count value of the Redis counter key corresponding to the concurrent request, and perform an atomic comparison between the current count value and a preset threshold. The first request processing module is used to increment the Redis counter key and determine the request to be executed when the current count value is less than the preset threshold. The second request processing module is used to periodically poll the Redis counter key and the preset threshold when the current count value is greater than or equal to the preset threshold. During the polling process, when the current count value is detected to have decreased to below the preset threshold, the Redis counter key is incremented and a request to be executed is determined. The request release module is used to execute a generation task according to the pending request, and after the generation task is completed, decrement the Redis counter key and release the concurrent slots occupied by the pending request.

6. 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 concurrent request processing method as described in any one of claims 1 to 4.

7. A 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 concurrent request processing method as described in any one of claims 1 to 4.

8. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the concurrent request processing method as described in any one of claims 1 to 4.

Images