A lock contention-based request aggregation and dynamic scheduling method, electronic device and program product

Abstract

The application provides a request aggregation and dynamic scheduling method based on lock competition, an electronic device and a program product. Requests are stored in a first waiting queue, and checked requests are extracted from a double queue according to a check period. Unprocessed requests are returned to a second queue, and the requests are orderly controlled. The number of aggregated batches in transit and the number of processable batches are determined by competition keys, processable requests are screened, non-batch resource requests are avoided from participating in lock competition, and invalid scheduling is reduced. Based on the processable requests, an execution queue is constructed in layers according to the competition keys, an aggregated event is generated by iteration, and the in-transit batch is incremented, so that the scattered requests are normalized and batch-converted. The aggregated event is processed by locking according to the competition keys, and the in-transit batch is decremented, so that the same competition key is processed in series, and the in-transit batch is updated in a closed loop, thereby providing an accurate basis for subsequent batch calculation. The overall lock competition is effectively alleviated, the orderliness and accuracy of request processing are ensured, and the efficiency of shared resource request processing is improved.

Description

Technical Field

[0001] This application relates to the field of high-concurrency business processing, and more specifically, to a method for request aggregation and dynamic scheduling based on lock contention, an electronic device, and a program product. Background Technology

[0002] For business scenarios that require serializing requests for shared resources, request aggregation is often used to improve system efficiency. Existing technologies often employ fixed time windows combined with maximum batch capacity implementations, such as request merging and message batch processing. Aggregation is triggered only based on time or quantity thresholds, resulting in coarse-grained differentiation of business processes, making it well-suited for stateless, lock-free event processing scenarios.

[0003] However, the above scheme has the following problems when handling requests for shared resources with locks: high-frequency contention keys cause multiple threads to compete for lock resources, which intensifies lock contention and leads to long lock waiting times; low-frequency contention keys are forced to merge prematurely due to the expiration of the time window, resulting in extremely low aggregation effect; high-frequency contention keys occupy most of the processing threads, while low-frequency contention keys cause thread starvation, resulting in low overall thread utilization of the system and limited throughput and resource utilization.

[0004] In conclusion, the industry urgently needs a more optimized and resource-efficient processing mechanism for handling requests for locked shared resources. Summary of the Invention

[0005] The purpose of this application is to provide a request aggregation and dynamic scheduling method, electronic device and program product based on lock contention, for improving the resource utilization efficiency of shared resources.

[0006] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: In a first aspect, embodiments of this application provide a request aggregation and dynamic scheduling method based on lock contention, comprising: Store the request event in the first waiting queue; In each inspection cycle, pending request events are obtained from the first waiting queue and the second waiting queue; wherein, the second waiting queue is configured to store unprocessed request events; Based on the competition key corresponding to each of the request events to be inspected, determine the number of aggregate batches in transit and the number of aggregate batches that can be processed for each competition key; wherein, the number of aggregate batches in transit represents the total number of aggregate batches that are currently being processed and have not yet been completed for the corresponding competition key; and the number of aggregate batches that can be processed represents the upper limit of the number of aggregate batches that are currently allowed to be added for the corresponding competition key. Based on the number of processable aggregate batches for each contested key, determine whether the request event to be inspected corresponding to the contested key is a processable request event; If not, the request event to be checked will be stored as the unprocessed request event in the second waiting queue; If so, based on all the processable request events, construct a hierarchical execution queue according to the corresponding contention key; each layer of the hierarchical execution queue contains all processable request events corresponding to the same aggregate batch. Traverse the hierarchical execution queue, generate an aggregate event from all processable request events of the same aggregate batch, and increment the number of aggregate batches in transit corresponding to the contention key; For each of the aggregate events, lock the corresponding aggregate event according to the target contention key, and decrement the number of aggregate batches in transit for the target contention key.

[0007] Secondly, embodiments of this application provide an electronic device, including: Memory, used to store one or more programs; processor; When the one or more programs are executed by the processor, the method as described in any one of the first aspects above is implemented.

[0008] Thirdly, embodiments of this application provide a program product that, when executed by a processor, implements the method as described in any one of the first aspects above.

[0009] Compared to existing technologies, the request aggregation and dynamic scheduling method, electronic device, and program product based on lock contention provided in this application stores requests in a first waiting queue, retrieves requests to be checked from a dual queue according to a check cycle, and returns unprocessed requests to a second queue, achieving orderly request management. It determines the number of in-transit and processable aggregate batches through contention keys, filters processable requests, avoids requests without batches participating in lock contention, and reduces ineffective scheduling. Based on processable requests, it constructs an execution queue hierarchically according to contention keys, iterates to generate aggregate events, and increments the in-transit batches, achieving the standardized batch transformation of scattered requests. It processes aggregate events by locking according to contention keys and decrements the in-transit batches, ensuring serial processing of the same contention key and simultaneously achieving closed-loop updates of in-transit batches, providing an accurate basis for subsequent batch calculations. Overall, it effectively alleviates lock contention, ensures the orderly processing and counting accuracy of requests, and improves the efficiency of shared resource request processing.

[0010] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A schematic diagram of a request aggregation and dynamic scheduling method based on lock contention provided in an embodiment of the present invention; Figure 2 A schematic diagram of another request aggregation and dynamic scheduling method based on lock contention provided in an embodiment of the present invention; Figure 3 A schematic diagram of another request aggregation and dynamic scheduling method based on lock contention provided in an embodiment of the present invention; Figure 4 A schematic diagram of another request aggregation and dynamic scheduling method based on lock contention provided in an embodiment of the present invention; Figure 5 A schematic diagram of another request aggregation and dynamic scheduling method based on lock contention provided in an embodiment of the present invention; Figure 6 A schematic diagram of another request aggregation and dynamic scheduling method based on lock contention provided in an embodiment of the present invention; Figure 7 A schematic diagram of another request aggregation and dynamic scheduling method based on lock contention provided in an embodiment of the present invention; Figure 8 A schematic diagram of another request aggregation and dynamic scheduling method based on lock contention provided in an embodiment of the present invention; Figure 9 A schematic diagram of another request aggregation and dynamic scheduling method based on lock contention provided in an embodiment of the present invention; Figure 10 A schematic diagram of another request aggregation and dynamic scheduling method based on lock contention provided in an embodiment of the present invention; Figure 11 A schematic diagram of another request aggregation and dynamic scheduling method based on lock contention provided in an embodiment of the present invention; Figure 12 A schematic diagram of the process for event fusion based on hierarchical execution queues provided in an embodiment of the present invention; Figure 13 A schematic diagram of a request aggregation and dynamic scheduling device based on lock contention provided in an embodiment of the present invention; Figure 14 A schematic diagram illustrating the implementation of a lock contention-based request aggregation and dynamic scheduling device provided in an embodiment of the present invention; Figure 15 The interaction signaling diagram of the request aggregation and dynamic scheduling device based on lock contention provided in the embodiments of the present invention; Figure 16(a) is a schematic diagram of the performance under extreme pressure scenario with a single competing bond provided by an embodiment of the present invention; Figure 16(b) is a schematic diagram of the performance of the conventional technical solution under extreme pressure scenario with a single competing key. Figure 17(a) is a performance diagram of a high-concurrency multi-competitive key random distribution scenario provided by an embodiment of the present invention; Figure 17(b) is a performance diagram of conventional technical solutions in a high-concurrency, multi-competitive key random distribution scenario; Figure 18 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0014] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0015] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0016] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0017] In the field of high-concurrency business processing, for scenarios that require serialized processing of shared resources (such as order status updates, user account operations, data consistency verification, etc.), the contested key, as the unique identifier of the shared resource (such as order ID, user ID), requires that all requests with the same contested key must be guaranteed to have atomicity through a mutual exclusion mechanism (such as exclusive lock). This is the core premise for avoiding data conflicts and ensuring the correctness of business operations.

[0018] However, in high-concurrency scenarios, the frequent independent processing of a large number of scattered requests can lead to frequent system context switching and increased lock operation overhead, significantly reducing overall processing efficiency. Therefore, request aggregation technology has become a key means to optimize the performance of such scenarios. Its core goal is to reduce repeated lock acquisition and release, data interaction and other operations by merging similar scattered requests into batch processing, thereby improving system throughput and resource utilization.

[0019] To achieve this goal, existing technologies have formed mature mainstream aggregation implementation approaches, specifically manifested as a static triggering method with "fixed time window and maximum batch capacity." The core is to start aggregation processing based on preset time or quantity thresholds. Common solutions include Hystrix's request merging scheme and KafkaProducer's batch sending scheme. These solutions are designed to adapt to stateless and lock-free event processing scenarios, and have a relatively coarse granularity in distinguishing business logic.

[0020] In practice, the system pre-configures a fixed aggregation time window (such as the batch sending interval of Kafka) and a maximum batch processing capacity (such as the maximum number of requests per batch). When any one of these conditions is met, the currently accumulated requests are merged into a single batch for processing. This type of solution does not recognize the lock resource contention relationship in the business scenario, nor does it distinguish the request characteristics of different contention keys. It only completes aggregation through uniform static rules, which is essentially a "mechanical merging" of scattered requests. It lacks the ability to perceive and adapt to dynamic factors such as lock contention and thread pool load.

[0021] To address the problems of static aggregation using fixed time windows and maximum batch size in existing technologies, which lack lock contention and system load awareness, leading to intensified lock contention, low aggregation efficiency, and insufficient thread utilization, this application provides a mechanism for dynamic batch calculation of contested keys. This mechanism dynamically determines the number of processable aggregation batches for a single contested key by combining global system load and the number of aggregated batches in transit. This alleviates lock contention, avoids thread starvation, optimizes resource allocation, and ultimately improves aggregation efficiency and overall system performance in high-concurrency scenarios. Furthermore, a "dual waiting queue mechanism" is introduced to prioritize processing backlogged requests in the second waiting queue, preventing new requests from consuming resources. Differential scheduling adapts to the dynamic batch allocation results, ensuring fairness in processing each contested key request and maintaining system stability.

[0022] Optionally, the following provides a possible implementation of a request aggregation and dynamic scheduling method based on lock contention. Specifically, Figure 1 A schematic diagram of a request aggregation and dynamic scheduling method based on lock contention provided in an embodiment of the present invention is shown below. Figure 1 The method includes: Step 100: Store the request event in the first waiting queue.

[0023] Step 101: In each inspection cycle, obtain the inspection request event from the first waiting queue and the second waiting queue.

[0024] The second waiting queue is configured to store unprocessed request events.

[0025] Step 102: Based on the contention key corresponding to each request event to be inspected, determine the number of aggregate batches in transit and the number of aggregate batches that can be processed for each contention key.

[0026] The number of aggregate batches in transit represents the total number of aggregate batches currently being processed and not yet completed for the corresponding competing key; the number of aggregate batches that can be processed represents the upper limit of the number of aggregate batches that can be added for the corresponding competing key.

[0027] Step 103: Based on the number of aggregate batches that can be processed for each contest key, determine whether the request event to be inspected corresponding to the contest key is a processable request event.

[0028] If not, proceed to step 104; if yes, proceed to step 105.

[0029] Step 104: Store the pending request event as an unprocessed request event in the second waiting queue.

[0030] Step 105: Based on all processable request events, construct a hierarchical execution queue according to the corresponding contention key.

[0031] The hierarchical execution queue contains all processable request events corresponding to the same aggregate batch at each level.

[0032] Step 106: Traverse the hierarchical execution queue, generate an aggregate event from all processable request events of each same aggregate batch, and increment the number of in-transit aggregate batches for the corresponding contention key.

[0033] Step 107: Lock the corresponding aggregation event according to the target contention key of each aggregation event, and decrement the number of aggregation batches in transit for the target contention key.

[0034] The request aggregation and dynamic scheduling method based on lock contention provided in this invention stores requests in a first waiting queue, retrieves requests to be checked from a dual queue according to a check cycle, and returns unprocessed requests to a second queue, thus achieving orderly request management. It determines the number of in-transit and processable aggregate batches through a contention key, filters processable requests, avoids requests without batches participating in lock contention, and reduces ineffective scheduling. Based on processable requests, it constructs an execution queue hierarchically according to the contention key, iterates to generate aggregate events, and increments the in-transit batches, achieving the standardized batch transformation of scattered requests. It processes aggregate events by locking according to the contention key and decrements the in-transit batches, ensuring serial processing of the same contention key and simultaneously achieving closed-loop updates of in-transit batches, providing an accurate basis for subsequent batch calculations. Overall, it effectively alleviates lock contention, ensures the orderly processing and counting accuracy of requests, and improves the efficiency of shared resource request processing.

[0035] Optionally, for step 102 above, in order to control the total number of concurrent aggregate batches at the global level and avoid system overload, this application provides a load-adaptive mechanism for determining the number of processable aggregate batches: by comprehensively considering the current load state of the processing thread pool and the intensity of the pending requests, the minimum value under the constraints of the two is taken as the upper limit of the number of processable aggregate batches, so that the system will not reduce throughput due to too few batches or exhaust thread pool resources due to too many batches in high-concurrency scenarios.

[0036] Specifically, in Figure 1 On this basis, Figure 2 A schematic diagram of another request aggregation and dynamic scheduling method based on lock contention provided in this embodiment of the invention is shown below. Figure 2 Step 102 includes: Step 102-1: Determine the current load status of the processing thread pool.

[0037] The current load status represents the busyness of the processing thread pool at the current moment, and is used to measure the remaining aggregate batch capacity that the thread pool can handle. The higher the load status, the busier the thread pool is, and the fewer aggregate batches can be added.

[0038] Step 102-2: Determine the estimated batch value for each competing bond.

[0039] The estimated aggregate batch value reflects the theoretical batch demand corresponding to the current pending request intensity.

[0040] Step 102-3: Take the minimum value between the current load status and the estimated aggregation batch value of each competing key as the number of aggregate batches that can be processed for the corresponding competing key.

[0041] The maximum number of aggregate batches that can be processed is the minimum of the current load state and the estimated aggregate batch value, which serves as the upper limit for the number of new aggregate batches allowed by the contention key. This constrains both the number of requests and the system load.

[0042] Optionally, for example, in the current inspection cycle, the total number of pending request events in the first and second waiting queues is 6000, and the default value of the aggregate batch size is 1000. Therefore, the estimated aggregate batch value is 6000 / 1000 = 6. The processing thread pool has a pending queue length of 23, a core thread count of 10, and a thread pool processing count of 23 / 10 = 2.3. After rounding, the current load is 2. Therefore, in step 102-3, min(2,6) = 2 is taken as the number of processable aggregate batches for this contention key. At this point, even if the theoretical number of pending requests requires 6 batches, the current thread pool load only allows for 2 additional batches. The system thus limits the concurrent aggregation intensity to avoid thread pool overload.

[0043] Optionally, regarding the current load status involved in step 102-1 above, the following is a possible method for obtaining it. Specifically, in Figure 2 On this basis, Figure 3 A schematic diagram of another request aggregation and dynamic scheduling method based on lock contention provided in this embodiment of the invention is shown below. Figure 3 Step 102-1 includes: Step 102-1a: Determine the number of times the thread pool will process based on the length of the queue to be processed and the number of core threads in the processing thread pool.

[0044] Optionally, the number of times the thread pool processes tasks can be the ratio of the length of the processing thread pool's pending queue to the number of core threads, representing the average amount of pending tasks currently handled by each core thread. A larger value indicates a busier thread pool. The length of the pending queue represents the number of tasks submitted but not yet completed in the processing thread pool, directly reflecting the backlog level. The number of core threads is the minimum number of threads that the processing thread pool must maintain resident, serving as the baseline for the thread pool's basic processing capacity.

[0045] Step 102-1b: Use the number of times the thread pool processes data as the current load status of the processing thread pool.

[0046] Optionally, for example, if the processing thread pool is configured with 10 core threads and a maximum of 20 threads, and the number of aggregate events submitted but not yet completed in the current queue is 23, then the thread pool processing count = 23 / 10 = 2.3, which rounds up to the nearest integer, indicating a current load of 2. This value suggests that each core thread handles an average of approximately 2 pending tasks, and the thread pool is under moderate load. If the queue length increases to 50, the thread pool processing count = 50 / 10 = 5, reaching the load threshold. Based on this, the system determines that the thread pool is fully loaded and should limit the addition of new aggregate batches.

[0047] Optionally, regarding the estimated aggregation batch value involved in step 102-2 above, a possible method for obtaining it is provided below. Specifically, in Figure 3 On this basis, Figure 4 A schematic diagram of another request aggregation and dynamic scheduling method based on lock contention provided in this embodiment of the invention is shown below. Figure 4 Step 102-2 includes: Step 102-2a: Count the total number of pending request events in the first waiting queue and the second waiting queue, and use this as the total number of pending requests.

[0048] The total number of pending requests represents the overall request processing pressure currently faced by the system.

[0049] Step 102-2b: Determine the estimated aggregate batch size by rounding down the ratio of the total number of pending requests to the aggregate batch size.

[0050] The aggregate batch size represents the maximum number of request events allowed in a single aggregate batch and serves as the baseline unit for batch splitting. The estimated aggregate batch value is the integer result of dividing the total number of pending requests by the aggregate batch size, reflecting the theoretical batch demand corresponding to the current request intensity.

[0051] Optionally, for example, in the current inspection cycle, 900 request events are extracted from the first waiting queue and 5100 unprocessed request events are extracted from the second waiting queue. After merging, the total number of request events to be inspected is 6000. The default value for the aggregate batch size is 1000. Therefore, the total number of requests to be processed is 6000, and the estimated aggregate batch size is 6000 / 1000 = 6. This value indicates that if the thread pool resources are sufficient, theoretically, 6 aggregate batches are needed to process all the requests to be inspected. If the total number of requests to be processed is 1500, then the estimated aggregate batch size is 1500 / 1000 = 1 (rounded down), indicating that the intensity of the requests to be processed is low, and only 1 batch is needed to complete the processing.

[0052] Optionally, regarding the calculation of the estimated aggregate batch value in step 102-2b above, in order to avoid excessive compression of system batch resources due to the estimated aggregate batch value being too low when the number of pending requests is small, this application provides a lightweight request scenario protection mechanism based on the first batch threshold: when the estimated aggregate batch value is less than the first batch threshold, the first batch threshold is directly used as the number of aggregate batches that can be processed, ensuring that the system maintains basic batch processing capabilities even in low-load scenarios, and avoiding frequent triggering of the check cycle and reduction of overall throughput due to too few batches.

[0053] Specifically, in Figure 4 On this basis, Figure 5 A schematic diagram of another request aggregation and dynamic scheduling method based on lock contention provided in this embodiment of the invention is shown below. Figure 5 Following step 102-2b, the following is also included: Step 102-2c: Determine whether the estimated aggregation batch value is less than the first batch threshold.

[0054] The first batch threshold can be used to distinguish between lightweight request scenarios and batch request scenarios. When the estimated aggregate batch value is lower than this threshold, the system determines that it is currently in a lightweight request scenario.

[0055] Optionally, in lightweight request scenarios, instead of using the estimated aggregate batch value (which may be 0 or 1), the number of aggregate batches that can be processed is fixed at the first batch threshold to ensure that the system maintains the minimum batch processing capacity.

[0056] Furthermore, if the value is less than the threshold, proceed to step 102-2d; if it is greater than or equal to the threshold, return to step 102-1a. When the estimated aggregate batch value is greater than or equal to the first batch threshold, it indicates that the strength of the requests to be processed is sufficient, and the dynamic batch calculation process based on thread pool load is entered.

[0057] Step 102-2d: Use the value of the first batch threshold as the number of aggregate batches that can be processed for the corresponding competing key.

[0058] Optionally, for example, the first batch threshold is preset to 1. If the current total number of requests to be processed is 600 and the aggregate batch size is 1000, then the estimated aggregate batch value = 600 / 1000 = 0 (rounded down). At this time, step 102-2c determines that 0 << 1, proceeds to step 102-2d, and directly determines the number of aggregate batches that can be processed as 1 (i.e., the first batch threshold), instead of 0. This means that even if the number of requests to be processed is less than a complete batch, the system still retains the processing capacity of one batch, avoiding the indefinite stagnation of a small number of requests in the second waiting queue. If the total number of requests to be processed is 6000 and the estimated aggregate batch value = 6, then 6 ≥ 1, proceeds to step 102-2e, and continues to execute the thread pool load state calculation and minimum value comparison process.

[0059] Optionally, to prevent the thread pool from being allocated a large number of aggregate batches when it is close to or reaches full load, leading to task backlog, response delay, or even system crash, this application provides an overload scenario degradation protection mechanism based on a load threshold: the number of thread pool processing times is compared with the load threshold. If the thread pool is already in a high load or overload state, the number of aggregate batches that can be processed is directly limited to the first batch threshold, dynamic expansion is stopped, and the system self-protection is achieved.

[0060] Specifically, in Figure 3 On this basis, Figure 6 A schematic diagram of another request aggregation and dynamic scheduling method based on lock contention provided in this embodiment of the invention is shown below. Figure 6 Following step 102-1b, the following is also included: Step 102-1c: Compare the number of times the thread pool processes data with the load threshold.

[0061] The load threshold is used to determine whether the thread pool is overloaded. When the number of times the thread pool processes data reaches or exceeds this value, the system determines that the thread pool is fully loaded or overloaded.

[0062] If the load threshold is greater than or equal to the load threshold, then step 102-1d is executed; if it is less than the load threshold, then step 102-3 is executed.

[0063] Step 102-1d: Use the value of the first batch threshold as the number of aggregate batches that can be processed for the corresponding competing key.

[0064] In this example, when the thread pool is overloaded, the estimated size of the aggregate batch value is ignored, and the number of aggregate batches that can be processed is directly downgraded to the first batch threshold, forcibly limiting the addition of new aggregate batches and prioritizing the processing of submitted tasks.

[0065] Optionally, for example, the load threshold is preset to 5. If the processing thread pool queue length is 50 and the core thread count is 10, then the thread pool processing count = 50 / 10 = 5. Step 102-1c checks if 5 ≥ 5, proceeds to step 102-1d, and directly limits the number of aggregated batches that can be processed to the first batch threshold (e.g., 1). At this time, even if the estimated aggregated batch value is 6 (6000 requests to be processed), the system will not allocate 6 batches, but only allow 1 batch to prevent the thread pool from continuing to receive a large number of new tasks when it is already fully loaded. If the processing queue length is 23 and the thread pool processing count = 2.3 << 5, then the degradation protection is not triggered, and the normal min(load status, estimated aggregated batch value) calculation process continues.

[0066] Step 101 above is the core process of the two-level waiting queue divide-and-conquer architecture. It provides an accurate and controllable data source for subsequent calculation of estimated aggregate batch values ​​and request determination. For the same contention key in both waiting queues, backlogs are prioritized by processing them sequentially. Simultaneously, for multiple contention keys, a mechanism for rationally managing thread resources is constructed to more flexibly handle currently processable backlog requests. This solves the backlog and thread starvation problems of traditional solutions and avoids system overload. A possible implementation method is provided below; specifically... Figure 1 On this basis, Figure 7 A schematic diagram of another request aggregation and dynamic scheduling method based on lock contention provided in this embodiment of the invention is shown below. Figure 7 Step 101 includes: Step 101-1: Trigger the inspection cycle at fixed time intervals to start the process of extracting the request events to be inspected.

[0067] Step 101-2: Count the remaining number of request events in the first waiting queue and the number of request events stored in the second waiting queue, and sum them to get the total number of request events to be processed.

[0068] Optionally, the total number of pending requests = SUM(length of the first waiting queue and length of the second waiting queue) to provide a basis for subsequent extraction quantity calculation.

[0069] Step 101-3: If the total number of pending request events is 0, then the extraction process for this inspection cycle will be terminated.

[0070] Step 101-4: If the total number of pending request events is greater than 0, then according to the single extraction limit of the second waiting queue, extract the corresponding number of unprocessed request events from the second waiting queue in the order of enqueueing as pending request events. The unprocessed request events that are not extracted continue to remain in the second waiting queue.

[0071] Optionally, the second waiting queue can be a linked list queue that supports repeated processing. Unretrieved requests continue to be stored in the queue. In this example, the single extraction limit parameter of the second waiting queue is configurable. At the same time, for a single contention key, the order of its requests in the second waiting queue can always remain unchanged. For example, requests A4~A6 of contention key A are always stored in the second queue in the order of A4, A5, A6.

[0072] Step 101-5: If the preset request processing conditions are met, the request events are extracted from the first waiting queue in the order of enqueueing as the request events to be checked, and merged with the request events to be checked extracted from the second waiting queue.

[0073] Step 101-6: If the preset request processing conditions are not met, the request events to be checked extracted from the second waiting queue will be used as all request events to be checked in this inspection cycle.

[0074] Optionally, one possible implementation of the preset request processing condition is: the total number of pending request events is less than or equal to the default value of the preset waiting queue capacity.

[0075] The total number of pending request events is: the sum of the number of remaining request events in the first waiting queue and the number of unprocessed request events stored in the second waiting queue, which is a quantitative indicator of the overall pending request scale of the system at present, obtained through real-time statistics during the current inspection cycle.

[0076] The default value for the waiting queue capacity is: a global request capacity threshold preset to manage the overall request load of the system and avoid request backlog overload. This default value can be "100_000". It is also the key basis for determining whether to extract new requests from the first waiting queue. This value is a configurable parameter that can be adapted to the high concurrency scenario requirements of different businesses. Its core function is to determine whether the system is currently facing request load pressure, thereby guiding the selection of extraction strategies for the dual waiting queues.

[0077] For example, the preset request processing condition for the first waiting queue is "the total number of pending requests ≤ the default waiting queue capacity (100_000)". If this condition is met, the number of requests retrieved from the first waiting queue = the total number of pending requests - the length of the second waiting queue, and the enqueueing and dequeueing of the first waiting queue is a one-time operation, with the corresponding request being removed immediately after retrieval; if this condition is not met (the number of requests exceeds the queue capacity), no requests are retrieved from the first waiting queue, and only requests from the second waiting queue are processed.

[0078] Optionally, for the time sequence example of waiting queue processing: at time T1, the second waiting queue contains A1, B1, A2, A3, A4, C1, B2, B3, A5, B4, B5, A6, B6, and C2. Therefore, at time T2, request events in the second waiting queue are processed first, and new requests in the first waiting queue are directly inserted into the tail of the second queue, consistent with the extraction rules in this example.

[0079] Optionally, step 103 in the above example is the core step of the precise screening of requests in this application. It follows the calculation result of the number of processable aggregated batches in step 102, serving as a crucial link between batch calculation and queue scheduling. It clarifies the data source division for subsequent non-processable request backflow and the construction of hierarchical queues for processable requests, enabling batch judgment of contention key dimensions, filtering of invalid requests, and ensuring fairness in the judgment. A possible implementation method is provided below; specifically, in... Figure 1 On this basis, Figure 8A schematic diagram of another request aggregation and dynamic scheduling method based on lock contention provided in this embodiment of the invention is shown below. Figure 8 Step 103 includes: Step 103-1: Group all the request events to be checked according to their corresponding competition keys to obtain the set of request events to be checked associated with each competition key.

[0080] Optionally, before determining the eligibility of a request for processing, the requests to be inspected should be aggregated by competition key. This is because the number of aggregated batches that can be processed is a global indicator at the competition key level, and it is not possible to determine the eligibility of a single request individually. For example, if the number of aggregated batches that can be processed for competition key A is 2, then all A-type requests associated with it have the same eligibility for processing.

[0081] Step 103-2: For each competing key, determine whether the corresponding number of aggregated batches that can be processed is greater than 0.

[0082] If yes, then proceed to step 103-3; if the number of processable aggregation batches for the competing key is 0, then proceed to step 103-4.

[0083] Step 103-3: Determine all the request events to be checked in the set of request events to be checked associated with the competition key as processable request events.

[0084] Step 103-4: Determine all unprocessed request events in the associated set of unprocessed request events. Optionally, for multiple competing keys, the order in which they are placed in the second waiting queue may change. However, for a single competing key, the order will not change. Competing keys: A1, B1, A2, A3, A4, C1, B2, B3, A5, B4, B5, A6, B6, C2; Determine that 3 processable request events of A and 2 processable request events of B can be executed; then the remaining request events in the second waiting queue are: A4, C1, B3, A5, B4, B5, A6, B6, C2.

[0085] If a contested key is not processed, it will not be processed in the second waiting queue.

[0086] It should be noted that the above example of contested keys is a simplified explanation based on the number of contested keys. When execution is performed according to the number of processable aggregate batches, the number of request events that can be processed for each contested key is: number of processable aggregate batches * aggregate batch size. For example, the number of processable aggregate batches for contested key A is 2, and the aggregate batch size is 1000. Therefore, for contested key A, the number of request events that can be processed in this instance is 2000. Then, as the request events enter the two-level waiting queues one by one, for example, the second waiting queue is: A1, B1, A2, A3, C1, ..., A2000, B1700, A2001, C400. After processing the 2000 processable request events for contested key A, the remaining items in the second waiting queue are: B1, C1, B2, ..., A2001, B1700, C400.

[0087] This example demonstrates that when there is a competing key with a processable number of aggregate batches (A can execute 2 batches), its associated request is determined to be processable and added to the execution list; when there is no competing key with a processable number of aggregate batches, its associated request is not processed in the second waiting queue and is retained for a subsequent cycle. This is a scenario-based evidence of the judgment rule.

[0088] Based on the above example, it can be seen that for contested keys, this example provides the following possible handling mechanisms: 1) The overall order in which requests for multiple competing keys are placed into the second waiting queue may change, but the order of requests for a single competing key remains constant.

[0089] 2) If the number of aggregate batches that can be processed for a contested key is 0, then the requests for that contested key in the second waiting queue will not participate in any processing in this cycle until the number of aggregate batches that can be processed is >0 in a subsequent cycle.

[0090] 3) The system only "extracts a portion of the contended key requests that can be processed" from the requests to be checked each time, instead of processing all contended keys, to ensure the reasonable allocation of system resources.

[0091] Additionally, this application provides a reflow rule for unprocessed request events, such as appending them to a second waiting queue.

[0092] Optionally, step 105 in the above example, as a step in the batch parallel processing of this application, follows the processable request event filtering results from step 103, providing a structured, batched request carrier for the aggregation event generation in step 106. This solves the problems of traditional solutions involving aggregation without hierarchy and multiple batches preempting resources with a single contention key, achieving hierarchical mapping between the global and contention key batches, dedicated resource allocation, and ensuring the orderly processing of aggregation. A possible implementation method is provided below; specifically, in... Figure 1 On this basis, Figure 9A schematic diagram of another request aggregation and dynamic scheduling method based on lock contention provided in this embodiment of the invention is shown below. Figure 9 Step 105 includes: Step 105-1: Based on the global maximum executable aggregate batch value, create the corresponding number of queue levels and construct a hierarchical execution queue.

[0093] Optionally, the number of levels in the hierarchical execution queue is equal to the global maximum executable aggregate batch value. For example, if the global maximum executable aggregate batch value is 3, then 3 queue levels are created.

[0094] Step 105-2: For each competing key, allocate the corresponding number of queue levels based on the number of aggregate batches that can be processed.

[0095] Optionally, the number of allocation levels for each contested key is equal to the number of aggregate batches it can handle. For example, if contested key A has 2 aggregate batches it can handle, then it is allocated 2 queue levels; if contested key I has 3 aggregate batches it can handle, then it is allocated 3 queue levels.

[0096] Step 105-3: Divide the processable request events of each competing key into batches, with the number of batches matching the number of allocation levels.

[0097] Step 105-4: Place the processable request events of a single batch into the corresponding level.

[0098] Each level can accommodate only one batch of requests for the same contention key, while different contention keys can coexist in the same level.

[0099] Optionally, step 106 in the above example is the step for implementing request event aggregation in this application. It follows the hierarchical execution queue construction result of step 105, provides standardized aggregated events for the locking business processing in step 107, and is a key step in transforming scattered requests into batched processing units. It can also realize the atomic dynamic update of the number of aggregated batches with contention keys in transit, ensuring standardized aggregation generation, accurate counting, orderly processing, and timely interception of anomalies. A possible implementation method is provided below. Specifically, in... Figure 1 On this basis, Figure 10 A schematic diagram of another request aggregation and dynamic scheduling method based on lock contention provided in this embodiment of the invention is shown below. Figure 10 Step 106 includes: Step 106-1: Traverse the layered execution queue in hierarchical order.

[0100] Optionally, for traversing the hierarchical execution queue: if the execution queue of a certain level is not empty, then execute the current execution queue. For example, follow the order of level 1, level 2, level 3, ... to ensure the ordered nature of batch processing.

[0101] Step 106-2: Group the requests at the current level according to each contention key.

[0102] In this context, the same contention key can be understood as a request group. That is, the same contention key belongs to one request group, and different contention keys are not mixed into groups. For example, the first level of A-1000 and C-1000 are divided into request group A and request group C, respectively.

[0103] Step 106-3: Determine whether the number of request groups exceeds the maximum processing capacity of a single batch. If it does not exceed the maximum processing capacity of a single batch, generate an aggregate event; otherwise, split the batch and generate multiple aggregate events.

[0104] Optionally, for example, if the contested key A has 1300 processable request events and the aggregate batch size is configured to 1000, then request group A is split into two sub-request groups of "1000" and "300", generating two independent aggregate events respectively, i.e. "faster merging processing, configurable threshold"; if a preprocessing exception occurs during the group aggregation process, then the batch of requests is updated to an exception, the generation of aggregate events is terminated, and no subsequent count increment operation is performed.

[0105] Step 106-4: Increment the number of aggregation batches in transit for each competing key.

[0106] Optionally, if the processing result is successful, an aggregation processing event is assembled and sent, and the number of aggregation batches in transit is incremented based on the contention key, i.e., the number of aggregation batches in transit is increased by 1. For example, in one possible implementation, it can be based on the addNum method of ContentionKeyAggregateNumCache, and each aggregation event corresponds to one count increment. For example, if contention key A generates 2 aggregation events, then its number of aggregation batches in transit is increased by 2.

[0107] Optionally, if the number of groups is greater than 1, asynchronous preprocessing can be performed by a preprocessing thread pool. The preprocessing thread pool is decoupled from the processing thread pool. For example, the preprocessing thread pool can be set to 10 threads by default to improve the efficiency of aggregate event generation.

[0108] Optionally, in the above example, step 107 is the final step in the implementation of the application business and lock contention control. It follows the aggregation event generation result from step 106 and is the final implementation step for all scheduling and aggregation actions. It also enables closed-loop updates of the number of aggregation batches in transit, providing accurate status information for subsequent periodic batch calculations. The core implementation includes exclusive lock control for contention keys, reliable processing of aggregation events, and elastic thread pool processing. A possible implementation method is provided below. Specifically, in... Figure 1 On this basis, Figure 11 A schematic diagram of another request aggregation and dynamic scheduling method based on lock contention provided in this embodiment of the invention is shown below. Figure 11Step 107 includes: Step 107-1: Perform exclusive locking based on the target contention key of each aggregation event.

[0109] Optionally, the locking operation is an exclusive locking based on a contention key, where the contention key is a shared resource identifier (such as order ID or user ID) that needs to be processed serially in the business logic. Aggregated events with the same contention key need to be locked and processed sequentially.

[0110] Step 107-2: If the lock is successfully acquired, execute the business processing corresponding to the aggregate event.

[0111] Step 107-3: If the lock is not released, the target contention key of the aggregation event will be in a waiting state until the lock is released.

[0112] For example, if another aggregate event is being processed, causing the lock not to be released, then the target contention key of the aggregate event in step 107-3 will be in a waiting state, waiting for the lock to be released after the other aggregate event is processed. If the lock is released, then return to step 107-2; if an exception occurs in the waiting state, then proceed to step 107-4. Step 107-4: If an abnormality occurs in the waiting state, record the abnormality.

[0113] Optionally, for log exceptions, an output can be provided allowing for a manual decision on whether to resend the request for processing.

[0114] Optionally, step 107-5 can be executed upon completion of business processing or in the event of an exception.

[0115] Step 107-5: After processing is complete, release the lock and decrement the number of aggregation batches in transit.

[0116] Optionally, the decrement can be achieved by decreasing the number of aggregate batches in transit for the contested key by 1. In one possible implementation, this can be done using the removeNum method of ContentionKeyAggregateNumCache, with each aggregation event corresponding to a decrement of the count. The released batch resources can be used for processing new requests in subsequent cycles. For example, if the number of aggregate batches in transit for contested key A is 2, it can be decremented to 1 after processing one aggregation event.

[0117] Optionally, Figure 11 One possible implementation for exception handling, not shown, involves rolling back the transaction, releasing the lock, decrementing the counter, and storing the request in the exception queue.

[0118] Optionally, if a transaction rollback is triggered to restore the original business data, the lock on the contested key is released, thereby decrementing the number of aggregate batches in transit. All request events corresponding to the aggregate event are marked as abnormal request events and ultimately stored in a preset abnormal queue. Abnormal request events will not flow back to the first or second waiting queues in the example above, avoiding duplicate exception handling. Then, after manual confirmation, it is determined whether to perform replay processing based on the abnormal request event.

[0119] Optionally, this application also provides a mechanism for elastic scaling of the thread pool: 10 core threads and 20 maximum threads. The process of the thread pool consuming aggregated events is asynchronous and decoupled from the preprocessing thread pool, forming a dynamic feedback loop of "lock contention awareness, aggregated event generation, and elastic thread pool processing".

[0120] Optionally, to better illustrate the above examples of this application, the following example, using a specific value example, provides an illustrative explanation of how to perform event fusion based on a hierarchical execution queue. Specifically, Figure 12 This is a schematic diagram of the process for event fusion based on hierarchical execution queues provided in an embodiment of the present invention. See also... Figure 12 The process is as follows: Based on the aforementioned request event extraction rules for the dual waiting queues, and because the preset request processing conditions are met (total number of pending requests ≤ default waiting queue capacity 100_000), the following steps 1 and 2 are executed.

[0121] Step 1: Extract 900 request events from the first waiting queue.

[0122] Step 2: Extract 5100 unprocessed request events from the second waiting queue, and combine them as the request events to be checked in this inspection cycle.

[0123] Among them, the above-mentioned requests to be inspected are grouped by competition key, and the number of requests associated with each competition key is as follows: competition key A - 3300, competition key B - 800, competition key C - 1200, competition keys D / E / F / G / H / I / J each 100, and the total number of requests to be processed is 6000.

[0124] Step 3: Calculate the global maximum executable aggregate batch value.

[0125] The maximum executable aggregate batch value can be understood as the queue level of the hierarchical execution queue in this calculation. The specific calculation is as follows: The default aggregate batch size is 1000; the estimated aggregate batch value = total pending requests / aggregate batch size = 6000 / 1000 = 6; the thread pool load = length of the pending queue in the processing thread pool / number of core threads in the processing thread pool = 23 / 10 = 2.3, which ≤ the load threshold of 5; the thread pool can support a maximum batch value = load threshold - thread pool load = 5 - 2.3 = 3; the maximum executable aggregate batch value = min(thread pool can support a maximum batch value, estimated aggregate batch value) = min(3,6) = 3.

[0126] Furthermore, based on the aforementioned example, the processable request events are evenly divided according to the aggregate batch size (1000). The number of batches after the division is consistent with the number of allocation levels. For example, if contested key A has 2000 processable request events and is allocated to 2 levels, then each level is allocated 1000 processable request events. If the number of requests is less than the aggregate batch size, then it is divided according to the actual number. For example, if contested key I has 100 processable request events and is allocated to 3 levels, then only the first level is allocated 100 processable request events, and the remaining levels are 0.

[0127] Step 4: Retrieve the number of aggregated batches in transit for each competing key from the preset concurrent safe key-value pair storage structure.

[0128] Specifically, based on the previous example, the number of batches in transit for A is 1, for B it is 5, for C it is 1, for D it is 5, for E it is 5, for F it is 5, for G it is 5, for H it is 4, for I it is 0, and for J it is 2.

[0129] Step 5: Calculate the number of aggregate batches that can be processed and the number of executable requests for each contested key.

[0130] Optionally, in conjunction with the previous example, the number of aggregate batches that can be processed = the global maximum executable aggregate batch value - the number of aggregate batches in transit, and the number of executable requests = the number of aggregate batches that can be processed × the aggregate batch size.

[0131] The number of aggregate batches that can be processed for competition keys A and C is 3-1=2 each, and the number of request events that can be processed is 2×1000=2000 each; the number of aggregate batches that can be processed for competition keys B / D / E / F / G / H is 0, and the number of request events that can be processed is 0; the number of aggregate batches that can be processed for competition key I is 3-0=3, and the number of request events that can be processed is 3×1000=3000; the number of aggregate batches that can be processed for competition key J is 3-2=1, and the number of request events that can be processed is 1×1000=1000.

[0132] Step 6: Construct a hierarchical execution queue.

[0133] Optionally, based on the previous example, three queue levels are created according to the global maximum executable aggregate batch value "3". The processable request events of each contention key are split into batches and placed into the corresponding levels. The final request distribution of the hierarchical execution queues is as follows: the first level contains A-1000, C-1000, I-100, and J-100; the second level contains A-1000 and C-200; the third level has no request events; and each level can only accommodate one batch of requests for the same contention key, while batches of different contention keys coexist in the same level.

[0134] Step 7: Traverse the hierarchical execution queue in hierarchical order, group the current level requests by contention key, and generate aggregate events.

[0135] Optionally, based on the previous example, the final number of aggregated events generated is 6: the first level corresponds to A-1, C-1, I-1, and J-1; the second level corresponds to A-1 and C-1; and no aggregated events are generated in the third level.

[0136] It should be noted that in this example, the contested key can be a shared resource identifier (such as order ID, user ID, etc.) that needs to be processed serially in the business logic. All requests with the same contested key must be locked exclusively to ensure the atomicity of the operation. For example, 1,000 transaction requests under the same order ID must all use that order ID as the contested key and be locked to complete the order data update operation to ensure the consistency of business data.

[0137] To illustrate the steps and corresponding technical effects of the above examples, this application also provides a request aggregation and dynamic scheduling device based on lock contention. Specifically, Figure 13 A schematic diagram of a request aggregation and dynamic scheduling device based on lock contention provided in an embodiment of the present invention is shown below. Figure 13 The lock contention-based request aggregation and dynamic scheduling device 20 includes: a preprocessing controller 201, a scheduling controller 202, and a processing controller 203.

[0138] The preprocessing controller 201 is used to store request events to a first waiting queue; and in each inspection cycle, to obtain request events to be inspected from the first waiting queue and a second waiting queue; wherein the second waiting queue is configured to store unprocessed request events. The scheduling controller 202 is used to determine the number of aggregate batches in transit and the number of aggregate batches that can be processed for each competition key based on the competition key corresponding to each request event to be inspected; wherein, the number of aggregate batches in transit represents the total number of aggregate batches that are currently being processed and have not yet been completed for the corresponding competition key; and the number of aggregate batches that can be processed represents the upper limit of the number of aggregate batches that are currently allowed to be added for the corresponding competition key. The preprocessing controller 201 is further configured to determine whether the request event to be checked corresponding to each competition key is a processable request event based on the number of processable aggregate batches for each competition key; if not, the request event to be checked is stored as an unprocessed request event in the second waiting queue; if so, based on all processable request events, a hierarchical execution queue is constructed according to the corresponding competition key; the hierarchical execution queue contains all processable request events corresponding to the same aggregate batch in each layer; the hierarchical execution queue is traversed, and all processable request events of the same aggregate batch are generated into an aggregate event, and the number of aggregate batches in transit corresponding to the competition key is incremented. The processing controller 203 is used to lock the corresponding aggregation event according to the target contention key of each aggregation event and decrement the number of aggregation batches in transit for the target contention key.

[0139] Optionally, the scheduling controller 202 is specifically used to determine the current load state of the processing thread pool; determine the estimated aggregate batch value of each contention key; and take the minimum value between the current load state and the estimated aggregate batch value of each contention key as the number of aggregate batches that can be processed for the corresponding contention key.

[0140] Optionally, the scheduling controller 202 is specifically used to determine the number of times the thread pool will process based on the length of the queue to be processed and the number of core threads in the processing thread pool; and to use the number of times the thread pool will process as the current load state of the processing thread pool.

[0141] Optionally, the scheduling controller 202 is specifically used to count the total number of pending request events in the first waiting queue and the second waiting queue as the total number of pending requests; and to determine the estimated aggregate batch value by rounding down the ratio of the total number of pending requests to the aggregate batch size.

[0142] Optionally, the scheduling controller 202 is specifically used to determine whether the estimated aggregate batch value is less than the first batch threshold; if it is less, the value of the first batch threshold is used as the number of aggregate batches that can be processed for the corresponding contention key; if it is greater than or equal to, the step of determining the number of times the thread pool processes based on the length of the processing thread pool queue and the number of core threads of the processing thread pool is executed.

[0143] Optionally, the scheduling controller 202 is specifically used to compare the number of times the thread pool processes with the load threshold. If it is greater than or equal to the load threshold, the value of the first batch threshold is used as the number of aggregate batches that can be processed for the corresponding contested key.

[0144] Optionally, the preprocessing controller 201 is specifically used to trigger an inspection cycle at fixed time intervals and initiate the extraction process of request events to be inspected; to count the remaining number of request events in the first waiting queue and the number of request events stored in the second waiting queue, and sum them to obtain the total number of request events to be processed; if the total number of request events to be processed is 0, the extraction process of this inspection cycle is terminated; if the total number of request events to be processed is greater than 0, according to the single extraction limit of the second waiting queue, the corresponding number of unprocessed request events are extracted from the second waiting queue in the order of enqueueing as request events to be inspected, and the unprocessed request events are retained in the second waiting queue; if the preset request processing conditions are met, request events are extracted from the first waiting queue in the order of enqueueing as request events to be inspected, and merged with the request events to be inspected extracted from the second waiting queue; if the preset request processing conditions are not met, the request events to be inspected extracted from the second waiting queue are taken as all request events to be inspected in this inspection cycle.

[0145] Optionally, the preprocessing controller 201 is specifically configured to aggregate all pending request events according to their corresponding competition keys to obtain a set of pending request events associated with each competition key; for each competition key, it determines whether the corresponding number of processable aggregate batches is greater than 0. If so, all pending request events in the set of pending request events associated with the competition key are determined as processable request events; if the number of processable aggregate batches of the competition key is equal to 0, all pending request events in the associated set of pending request events are determined as unprocessed request events.

[0146] Optionally, the preprocessing controller 201 is specifically used to create a corresponding number of queue levels and construct a hierarchical execution queue based on the global maximum executable aggregate batch value; allocate a corresponding number of queue levels for each contest key based on the corresponding number of processable aggregate batches; evenly split the processable request events of each contest key into batches, with the number of splits being consistent with the number of allocated levels; and place the processable request events of a single batch into the corresponding level; wherein a single level can only accommodate one batch of requests for the same contest key, and different contest keys can coexist in the same level.

[0147] Optionally, the preprocessing controller 201 is specifically used to traverse the hierarchical execution queue in hierarchical order; group the requests of the current level according to each contention key; wherein, the same contention key is a request group; determine whether the number of request groups exceeds the maximum processing volume of a single batch, if not, generate an aggregation event, if exceeding, split and generate multiple aggregation events; and perform an increment operation on the number of in-transit aggregation batches for each contention key.

[0148] Optionally, the processing controller 203 is specifically used to perform exclusive locking based on the target contention key of each aggregation event; if the locking is successful, the business processing corresponding to the aggregation event is executed; if the lock is not released, the target contention key of the aggregation event is in a waiting state until the lock is released; if an exception occurs in the waiting state, the exception is recorded; after processing is completed, the lock is released and the number of aggregation batches in transit is decremented.

[0149] Regarding the aforementioned request aggregation and dynamic scheduling mechanism based on lock contention, the following provides an implementation method running on the JVM platform, based on the Java language and the Spring Boot framework. Specifically... Figure 14 This is a schematic diagram illustrating the implementation of the lock contention-based request aggregation and dynamic scheduling device provided in an embodiment of the present invention. (See also...) Figure 14 The functions of the preprocessing controller 201 (PreBusinEventHandler), the scheduling controller 202 (ContentionKeyAggregateNumCache), and the processing controller 203 (AggregateBusinEventHandler) are illustrated by example.

[0150] Among them, the preprocessing controller 201 (PreBusinEventHandler) is the entry point and core executor of the entire scheduling process, responsible for request enqueuing, periodic checks, batch calculations, hierarchical queue construction, and aggregate event generation.

[0151] The core attributes are as follows: batchSize:int: corresponds to "aggregate batch size" (e.g., default 1000), which is the core parameter for batch splitting and aggregation.

[0152] waitHandleEventList:ArrayBlockingQueue <prebusinevent>: Corresponds to the first waiting queue, storing newly enqueued request events.

[0153] secondWaitHandleEventList:LinkedList <prebusinevent>: Corresponds to the second waiting queue, which stores unprocessed / reflowed request events and supports FIFO retention and duplicate processing.

[0154] scheduledService:ScheduledExecutorService: Corresponds to "fixed time interval trigger check cycle", used to execute checkTaskProcess() at regular intervals to achieve periodic scheduling.

[0155] The core method is as follows: onEvent(event:PreBusinEvent): This corresponds to step 100 in the example above, where the business request is received and written to the first waiting queue.

[0156] checkTaskProcess():void: This corresponds to step 101 in the example above, a timed check task that performs dual-queue request extraction and total pending quantity statistics.

[0157] getCurProcessEvents(): This function corresponds to steps 102 and 103 in the example above. It can query batches of competing key batches in transit, calculate the number of batches that can be processed, and filter the requests that can be processed.

[0158] calcKeyBatchProcessCount(): This corresponds to step 102 in the example above, calculating the global maximum executable batch size and the hierarchical queue level.

[0159] processBatch(List <prebusinevent>events): void: For the filtered processable request events, execute the complete batch processing task of "hierarchical execution queue construction and aggregated event generation", which can correspond to steps 105 and 106 in the example above.

[0160] Among them, the scheduling controller 202 (ContentionKeyAggregateNumCache) is the state center of the entire dynamic scheduling, responsible for the concurrent and safe counting of batches with competing keys in transit, providing an accurate basis for batch calculation.

[0161] The core attributes are as follows: contentionKeyNumCache:Cache<Long,AtomicInteger> : Concurrency-safe key-value pair cache, where the key is the contested key ID and the value is the number of in-transit aggregation batches of type AtomicInteger. It ensures accurate counting under high concurrency through atomic operations, corresponding to the "concurrency-safe key-value pair storage structure" example above.

[0162] The core method is as follows: addNum(Stringkey):void: This corresponds to step 106 in the example above, incrementing the number of aggregate batches in transit for the competing key, and is called when the aggregate event is generated.

[0163] removeNum(Stringkey):void: This corresponds to step 107 in the example above, decrementing the number of aggregate batches in transit for the competing key. It is called when the aggregate event is completed (regardless of success or failure), thus achieving a counting loop.

[0164] getContentionKeyNumMap(Set <string>keys): This corresponds to step 102 in the example above, which is to batch obtain the in-transit batch mapping of competing keys and use it to calculate the number of aggregate batches that can be processed.

[0165] The processing controller 203 (AggregateBusinEventHandler) is the final executor of business processing, responsible for locking the aggregated events and scheduling the thread pool.

[0166] The core attributes are as follows: commonThreadPoolExecutor:ThreadPoolTaskExecutor: Corresponds to the "processing thread pool" in the above example, such as 10 core threads by default and a maximum of 20, to realize elastic parallel processing of aggregated events and improve system throughput.

[0167] The core method is as follows: onEvent(DoBusinEventevent):void: Receives the aggregated event submitted by PreBusinEventHandler, performs exclusive locking according to the target contention key, and after completing the business logic processing, calls the removalNum() method of ContentionKeyAggregateNumCache to decrement the batch in transit, completing the entire process loop.

[0168] The following provides a possible interaction implementation for the preprocessing controller 201 (PreBusinEventHandler), the scheduling controller 202 (ContentionKeyAggregateNumCache), and the processing controller 203 (AggregateBusinEventHandler). Specifically, Figure 15 The interaction signaling diagram of the lock contention-based request aggregation and dynamic scheduling device provided in this embodiment of the invention is shown below. Figure 15 The interaction signaling between request aggregation and dynamic scheduling devices based on lock contention includes the following process: Step 01: Submit a request event to the preprocessing controller 201.

[0169] Step 02: The preprocessing controller 201 stores the request event in the first waiting queue.

[0170] This then enters a loop [timed task scheduling].

[0171] Step 03: Preprocessing controller 201 checks the trigger conditions.

[0172] In the timed scheduling triggering stage (such as the timed triggering of ScheduledExecutorService), it checks whether the conditions for "starting request processing" are met (such as reaching the check cycle or the queue request volume reaching the target). If they are met, it proceeds to the next step of processing; otherwise, it continues to wait.

[0173] This leads to a branch.

[0174] Step 04: The preprocessing controller 201 calculates the number of request events that need to be consumed from the first waiting queue and extracts the tail data.

[0175] Step 05: The preprocessing controller 201 calculates the maximum global executable aggregate batch value for this operation and constructs a hierarchical execution queue.

[0176] Step 06: The preprocessing controller 201 obtains all the contested keys from the extracted queue request event data and the request event data in the second waiting queue.

[0177] Specifically, it integrates "request events extracted from the first waiting queue" and "unprocessed request events from the second waiting queue" (such as requests from the last scheduled return), extracts a unique set of competition keys from all requests, and prepares for subsequent batch queries of the number of aggregated batches in transit.

[0178] Step 07: The preprocessing controller 201 obtains the number of in-transit aggregated batches associated with the contention key from the scheduling controller 202.

[0179] Step 08: The scheduling controller 202 returns the correspondence between the contention key and the number of aggregated batches in transit.

[0180] Step 09: Preprocessing controller 201 calculates the number of processable aggregate batches for each competing key.

[0181] Then, the loop continues [traversing the second waiting queue].

[0182] Step 10: When the request event for the contested key is processable, the preprocessing controller 201 removes the request event and adds it to the corresponding level of the hierarchical execution queue.

[0183] Then, the loop iterates through the extracted queue data.

[0184] Step 11: When the request event for the contention key is processable, the preprocessing controller 201 removes the request event and adds it to the corresponding level of the hierarchical execution queue; when no processing is required, it is added to the tail of the second waiting queue.

[0185] Then, the loop [traverses the hierarchical execution queue] is entered.

[0186] Step 12: The preprocessing controller 201 groups the requests at the current level according to each contention key and generates aggregate events.

[0187] Then, the loop [traverses the competition keys after grouping] is entered.

[0188] Then proceed to the branch [Aggregation processing successful].

[0189] Step 13: The preprocessing controller 201 publishes an aggregation event to the processing controller 203.

[0190] Step 14: Preprocessing controller 201 instructs scheduling controller 202 to increment the number of aggregated batches in transit for each competing key.

[0191] Step 15: If an aggregation exception exists, the preprocessing controller 201 performs aggregation exception handling.

[0192] Step 16: Process controller 203 performs aggregate event locking processing.

[0193] The controller receives the aggregation event, performs exclusive locking based on the competing key (aggregation events with the same competing key are processed serially), and executes the actual business logic (such as order transaction data updates and inventory deductions).

[0194] Step 17: Processing controller 203 instructs scheduling controller 202 to perform a decrement operation on the number of aggregated batches in transit.

[0195] In this process, the processing controller sends an atomic decrement instruction to the scheduling controller to reduce the number of in-transit aggregated batches for the corresponding contested key by 1, thereby achieving a closed-loop update of the number of in-transit aggregated batches and providing an accurate status for batch calculation in the next inspection cycle.

[0196] Based on the above embodiments, this application also provides a test example based on specific data. Specifically, in this test example, the basic environment is as follows: software: Java 17, Spring Boot 3.5.4, MyBatis 3.5.19, MySQL 8.0; hardware: 8-core CPU with 16 threads and 32GB of memory.

[0197] Simulated transaction request aggregation processing business scenario: order preprocessing (2ms pause, database query for order information), aggregated transaction processing (locking based on order, 20ms pause, database update of order, database batch transaction saving, lock release). The calling platform is JMeter, and the request time-per-second (TPS) is limited to 30,000 requests per second (due to local machine hardware resource limitations).

[0198] Metrics Explanation: 1) TPS (Core Metric): Transactions per second (TPS) of P90. Throughput is the core performance target of this verification. 2) Aggregation Effect (Auxiliary Metric): Number of transactions processed by P90 in a merged manner. The larger the number, the better the batch processing effect. 3) Processing Latency (s): The time difference between the end of the load test and the end of the server processing. The smaller the latency, the less backlog there is.

[0199] Other notes: Fixed pause is used to simulate the time consumed by other business operations in real-world scenarios. The batch merge is set to 1000, the timed task interval is set to 2ms, the waiting queue capacity is set to 100,000, the preprocessing thread pool is set to 10, and the processing threads are set to 10 cores with a maximum of 20.

[0200] The test data table (comparing the proposed solution and the conventional solution) is shown in Table 1 below: Table 1

[0201] It should be noted that the main difference between scenarios one through five in the table above lies in the number of contested keys. Scenario one has one contested key and a sample size of 6 million, meaning scenario one contains data from 6 million request events; scenario two has five contested keys, meaning each contested key has 1.2 million samples; scenario three has ten contested keys, meaning each contested key has 600,000 samples; and scenarios four and five involve a random number of contested keys.

[0202] In addition, scenarios one through three simulate hot data scenarios, while scenarios four and five simulate concurrent scenarios with multiple resource contention keys.

[0203] In a load test of 6 million requests across five scenarios—single contention key, 5 / 10 fixed contention keys, and 1-100 / 1-500 random contention keys—this solution achieved significant performance optimizations compared to ordinary solutions. In the single contention key scenario, this solution significantly improved processing throughput, reduced processing latency and lock waiting time, and only experienced moderate backlog, resolving the severe request backlog and thread idleness issues of ordinary solutions. In the 5 / 10 fixed contention key scenario, this solution achieved zero request backlog and no lock waiting, significantly improving processing efficiency, greatly reducing latency, and completely eliminating lock contention and request accumulation problems of ordinary solutions. In the 1-100 and 1-500 random contention key scenarios, this solution achieved zero backlog, significantly improving processing throughput and aggregation effects, eliminating lock waiting, reducing processing latency, and resolving the thread starvation and system throughput drop issues of ordinary solutions, overcoming the industry pain point of near-paralysis of processing capacity in complex contention scenarios.

[0204] To better illustrate the performance difference between this application and conventional technical solutions, a performance comparison test example under extreme pressure scenarios with a single contention key is provided below. Specifically, Figure 16(a) is a performance diagram under extreme pressure scenarios with a single contention key provided by the embodiment of the present invention. Referring to the lower half of Figure 16(a), during the stress test startup phase (approximately 20:42:00), the request-side TPS (type="Request") and the server-side processing TPS (type="DoHandle") climb synchronously, stabilizing at around 17,000 TPS after approximately 30 seconds, with the two curves essentially overlapping. Referring to the upper half of Figure 16(a), the merging effect curve (aggregated batch size) stabilizes at approximately 1,000 from the start of the stress test, indicating that the system continuously aggregates approximately 1,000 request events into one aggregated event for batch processing. Throughout the monitoring period, the throughput capabilities of the calling end and the server end are matched, with no request stalling or server-side throughput drop, and the system is in a stable operating state.

[0205] Accordingly, Figure 16(b) is a performance diagram of the single-competition key extreme stress scenario provided by the conventional technical solution. Referring to the lower half of Figure 16(b), at the initial stage of the stress test (around 20:25:00), the request-side TPS (type="Request") rapidly climbed from about 15,000 to 30,000 and maintained this sending rate; however, the server-side processing TPS (type="DoHandle") could only slowly climb from about 4,000 to about 10,000, and could never break through this limit. Around 20:30:00, the request-side TPS experienced a precipitous drop, plummeting from 30,000 to almost 0, while the server-side processing TPS remained at around 10,000, and subsequently also dropped back to 0 around 20:35:00. Referring to the upper part of Figure 16(b), the combined effect curve shows that the P90 polymerization batch size of the ordinary scheme is only about 600 in the early stage of the stress test, and rises briefly to about 950 in the middle of the stress test before becoming unstable again.

[0206] Based on the quantitative data in Table 1, in scenario one with a single competing key (6 million samples): This solution has the following TPS: client-side TPS 17,678, server-side TPS 17,422, moderate backlog, processing delay of 5.042 seconds, aggregation ratio of 1000:1, and lock wait time P90 of 285ms.

[0207] Standard solution: Client-side TPS 29,916, server-side TPS only 9,965 (less than 1 / 3 of client-side TPS), severe backlog, processing delay 401.572 seconds, aggregation effect 407:1, lock wait P90 800ms.

[0208] Optionally, a performance comparison test example is provided below for a high-concurrency scenario with multiple contention keys randomly distributed. Specifically, the test environment is configured as follows: the number of contention keys is randomly distributed between 1 and 500, the calling end continuously applies pressure to the server at a fixed TPS, and the total sample size is 6 million.

[0209] Figure 17(a) is a performance diagram of a high-concurrency, multi-competitive key random distribution scenario provided by an embodiment of the present invention. Referring to the lower half of Figure 17(a), the TPS of the request end and the processing TPS of the server end simultaneously climb from about 11,000, and after about 30 seconds, they both stabilize at around 30,000 TPS. The two curves basically overlap and remain stable until the end of the load test. Referring to the upper half of Figure 17(a), the merged effect curve (P90 aggregated batch size) stabilizes between 142 and 144 with slight fluctuations. Throughout the entire monitoring period, the throughput of the calling end and the server end are perfectly matched, with no backlog, no jitter, and no sudden drops in speed.

[0210] Figure 17(b) is a performance diagram of a high-concurrency scenario with multiple contention keys and random distribution provided by conventional technical solutions. Referring to the lower half of Figure 17(b), the TPS of the request end and the processing TPS of the server end exhibit violent sawtooth fluctuations from startup. The request end fluctuates greatly between approximately 1,000 and 3,500, while the server end fluctuates synchronously between approximately 500 and 2,500. Moreover, there are multiple instances where the phase difference between the request end and the server end is higher, indicating that the system is continuously in an alternating state of request accumulation and processing lag. The merging effect curve shows that the P90 aggregation batch size is only about 3 to 4, and it drops rapidly from about 6 to about 3 immediately after startup and remains at a low level for a long time. This indicates that when the number of contention keys is large and randomly distributed, the ordinary solution almost loses its request aggregation capability and degenerates into a single-request processing mode.

[0211] This invention also provides an electronic device that can execute all the steps of the examples described above to achieve the corresponding technical effects. Specifically, Figure 18 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. See also: Figure 18 The electronic device 30 includes: a memory 301 and a processor 300; Memory 301 is used to store one or more programs; Processor 300; When one or more programs are executed by a processor, the electronic device 30 can achieve the steps and corresponding technical effects when it performs the steps shown in the above-described method examples.

[0212] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0213] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0214] If a function is implemented as a software module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a program product. This program product is stored in a computer-readable storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0215] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

[0216] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within this application. No reference numerals in the claims should be construed as limiting the scope of the claims.< / string> < / prebusinevent> < / prebusinevent> < / prebusinevent>

Claims

1. A request aggregation and dynamic scheduling method based on lock contention, characterized in that, include: Store the request event in the first waiting queue; In each inspection cycle, pending request events are obtained from the first waiting queue and the second waiting queue; wherein, the second waiting queue is configured to store unprocessed request events; Based on the competition key corresponding to each of the request events to be inspected, determine the number of aggregate batches in transit and the number of aggregate batches that can be processed for each competition key; wherein, the number of aggregate batches in transit represents the total number of aggregate batches that are currently being processed and have not yet been completed for the corresponding competition key; and the number of aggregate batches that can be processed represents the upper limit of the number of aggregate batches that are currently allowed to be added for the corresponding competition key. Based on the number of processable aggregate batches for each contested key, determine whether the request event to be inspected corresponding to the contested key is a processable request event; If not, the request event to be checked is stored as the unprocessed request event in the second waiting queue; If so, based on all the processable request events, a hierarchical execution queue is constructed according to the corresponding contention key; each layer of the hierarchical execution queue contains all processable request events corresponding to the same aggregate batch; for processable request events with different contention keys in the same layer, they correspond to aggregate batches with the same sequence number; processable request events with the same contention key in the same layer constitute a request group. Traverse the hierarchical execution queue, generate an aggregate event for each request group, and increment the number of in-transit aggregate batches corresponding to the contention key; For each of the aggregate events, lock the corresponding aggregate event according to the target contention key, and decrement the number of aggregate batches in transit for the target contention key.

2. The method according to claim 1, characterized in that, The step of determining the number of in-transit aggregate batches and the number of processable aggregate batches for each competition key based on the competition key corresponding to each request event to be inspected includes: Determine the current load status of the processing thread pool; Determine the estimated aggregation batch value for each of the competing keys; The minimum value between the current load state and the estimated aggregation batch value for each competing key is taken as the number of aggregate batches that can be processed for the corresponding competing key.

3. The method according to claim 2, characterized in that, The step of determining the current load state of the processing thread pool includes: The number of times the thread pool processes data is determined based on the length of the queue to be processed in the processing thread pool and the core number of threads in the processing thread pool. The number of times the thread pool processes data is taken as the current load state of the processing thread pool.

4. The method according to claim 3, characterized in that, After the step of using the number of times the thread pool processes data as the current load state of the processing thread pool, the method further includes: The number of times the thread pool processes is compared with the load threshold. If it is greater than or equal to the load threshold, the value of the first batch threshold is used as the number of aggregate batches that can be processed for the corresponding contested key. If not, then the step of taking the minimum value between the current load state and the estimated aggregate batch value of each competing key as the number of aggregate batches that can be processed for the corresponding competing key is executed.

5. The method according to claim 3, characterized in that, The step of determining the estimated aggregate batch value for each of the competing keys includes: The total number of pending request events in the first waiting queue and the second waiting queue is counted as the total number of pending requests. The estimated aggregate batch size is determined by rounding down the ratio of the total number of requests to the aggregate batch size.

6. The method according to claim 5, characterized in that, After the step of determining the estimated aggregate batch size by rounding down the ratio of the total number of requests to be processed to the aggregate batch size, the method further includes: Determine whether the estimated aggregation batch value is less than the first batch threshold; If it is less than, then the value of the first batch threshold is taken as the number of aggregate batches that can be processed for the corresponding competing key; If it is greater than or equal to, then execute the step of determining the number of times the thread pool will process based on the length of the queue to be processed and the number of core threads in the processing thread pool.

7. The method according to claim 1, characterized in that, The specific steps for obtaining the request event to be inspected from the first waiting queue and the second waiting queue in each inspection cycle include: The inspection cycle is triggered at fixed time intervals to initiate the extraction process of the request event to be inspected. The remaining number of request events in the first waiting queue and the number of request events stored in the second waiting queue are counted respectively, and the sum is obtained to obtain the total number of request events to be processed; If the total number of pending request events is 0, the extraction process for this inspection cycle is terminated; if the total number of pending request events is greater than 0, according to the single extraction limit of the second waiting queue, the corresponding number of unprocessed request events are extracted from the second waiting queue in the order of enqueueing as the pending request events, and the unprocessed request events that are not extracted continue to remain in the second waiting queue. If the preset request processing conditions are met, the request events are extracted from the first waiting queue in the order of enqueueing as the request events to be checked, and merged with the request events to be checked extracted from the second waiting queue; if the preset request processing conditions are not met, the request events to be checked extracted from the second waiting queue are taken as all the request events to be checked in this inspection cycle.

8. The method according to claim 1, characterized in that, The specific steps for determining whether the request event to be inspected corresponding to each competition key is a processable request event based on the number of processable aggregate batches for each competition key include: All the request events to be inspected are grouped according to their corresponding competition keys to obtain a set of request events to be inspected associated with each competition key; For each of the competition keys, determine whether the corresponding number of processable aggregate batches is greater than 0. If so, determine all the request events to be checked in the set of request events to be checked associated with the competition key as the processable request events. If the number of processable aggregate batches of the competing key is equal to 0, then all the request events to be inspected in the associated set of request events to be inspected are determined as the unprocessed request events.

9. The method according to claim 1, characterized in that, The specific steps for constructing a hierarchical execution queue based on all processable request events and their corresponding contention keys include: Based on the global maximum executable aggregate batch value, create a corresponding number of queue levels to construct the hierarchical execution queue; For each of the competing keys, allocate a corresponding number of queue levels based on the number of aggregate batches that can be processed. The processable request events for each of the aforementioned competing keys are evenly divided into batches, with the number of batches matching the number of allocation levels; A single batch of processable request events is placed into the corresponding level; wherein, a single level can only accommodate one batch of requests with the same contention key, and different contention keys can coexist in the same level.

10. The method according to claim 1, characterized in that, The step of traversing the hierarchical execution queue, generating an aggregate event for each request group, and incrementing the number of in-transit aggregate batches corresponding to the contention key includes: Traverse the hierarchical execution queue in hierarchical order; The requests at the current level are grouped according to each of the competition keys; wherein, the same competition key constitutes one request group; Determine whether the number of request groups exceeds the maximum processing capacity of a single batch. If it does not exceed the maximum processing capacity of a single batch, generate the aggregated event; otherwise, split the batch and generate multiple aggregated events. An increment operation is performed on the number of aggregation batches in transit for each of the competing keys.

11. The method according to claim 1, characterized in that, The specific steps for locking and processing aggregation events and decrementing the number of aggregation batches in transit include: Perform exclusive locking based on the target contention key for each of the aggregate events; If the lock is successfully acquired, the business processing corresponding to the aggregated event is executed; if the lock is not released, the target contention key of the aggregated event is in a waiting state until the lock is released; if an exception occurs in the waiting state, the exception is recorded. After processing is complete, release the lock and decrement the number of aggregated batches in transit.

12. An electronic device, characterized in that, include: Memory, used to store one or more programs; processor; When the one or more programs are executed by the processor, the method as described in any one of claims 1-11 is implemented.

13. A program product, characterized in that, When the program product is executed by the processor, it implements the method as described in any one of claims 1-11.

Images