A method and system for batch request peak shaping based on dynamic sleep and partitioned polling

Abstract

This invention provides a batch request peak-shaving processing method and system based on dynamic hibernation and partitioned polling, relating to the field of server-side task scheduling and load control technology. The method first divides batch requests into multiple request partitions based on resource identifiers and updates the queue length, request arrival rate, and queue growth rate of each partition in real time. Then, a reinforcement learning model predicts the load trend of each partition in the next cycle, and calculates the dynamic hibernation time window accordingly. Within the hibernation window, content feature extraction and similarity clustering are performed on the requests to be processed. Combined with content hashing, deduplication and consistency checks are performed on requests within the same cluster, forming the final deduplicated request set. Based on processing feedback and global peak-shaving indicators, the reinforcement learning strategy parameters are adaptively updated to achieve cross-partition cyclic peak-shaving control. This invention can reduce instantaneous load and improve server resource utilization and system stability in high-concurrency scenarios.

Description

Technical Field

[0001] This invention relates to the field of server-side task scheduling and load control technology, and in particular to a batch request peak-shaving processing method and system based on dynamic hibernation and partitioned polling. Background Technology

[0002] As the scale of online services continues to expand, servers in high-concurrency scenarios generally face a "structural peak pressure" that cannot be solved by conventional rate limiting and caching: a large number of requests arrive at the same type of resource in a very short period of time, making it difficult for traditional peak-shaving methods based on thread sleep, queue discarding or fixed-frequency polling to maintain a stable processing rhythm under micro-minute fluctuations.

[0003] These peaks are characterized by high unpredictability, cross-resource partition asynchrony, and high content repetition, making it difficult to avoid the problem of "peak-shaving windows being repeatedly broken" simply by increasing queue size, extending sleep time, or using fixed threshold scheduling. At the same time, a large number of requests with highly similar or even identical semantics accumulate exponentially during peak periods, causing the actual operations performed by the server to far exceed the "necessary processing volume," resulting in serious resource waste.

[0004] Therefore, we propose a batch request peak-shaving processing method and system based on dynamic sleep and partitioned polling. The information disclosed in the background section is only for enhancing understanding of the background of this disclosure and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by providing a batch request peak-shaving processing method and system based on dynamic sleep and partitioned polling, thereby solving the technical problems mentioned in the background section.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] The batch request peak shaping method based on dynamic sleep and partitioned polling includes the following steps:

[0008] S1. Construct multiple independent request partitions based on resource identifiers, and write the arriving batch requests into the corresponding pending queues according to the mapping rules;

[0009] S2. Poll each request partition to obtain the queue status and change rate, use the reinforcement learning model to predict the load trend based on historical data, and calculate the dynamic sleep time window of the target partition accordingly.

[0010] S3. Collect pending requests within the dynamic sleep time window, perform content feature-based similarity clustering, content-level deduplication, and consistency verification, and generate a deduplicated request set.

[0011] S4. Perform unified processing on the deduplication request set: perform a single read and broadcast the result for read requests of the same type, perform a single write after aggregation for write requests of the same type that are idempotent, and fill the result back into the original request;

[0012] S5. Resource consumption and deduplication feedback during the data acquisition and processing process are addressed by adaptively optimizing the dynamic sleep time window of subsequent polling through updating the reinforcement learning model.

[0013] S6. Apply the optimized dynamic sleep time window to the polling process of the next partition, and achieve global collaborative peak shaving through cross-partition cyclic execution.

[0014] S1 specifically includes:

[0015] In the server node, according to the preset resource identifier mapping rules, the range of resources accessible by batch requests is divided into multiple independent request partitions to form a set of request partitions for partitioned management.

[0016] Initialize the corresponding queue to be processed in any request partition, and record initial state parameters such as the maximum capacity of the queue, the current queue length, and the historical arrival rate for that request partition.

[0017] When a new request arrives at the server node, it is written into the pending queue of the corresponding target request partition according to the resource identifier mapping rule, so as to maintain the consistency between the request access and the partition structure.

[0018] The queue length, queue growth rate, and arrival rate per unit time of each request partition are continuously updated as input parameters for subsequent dynamic sleep time window calculations.

[0019] Establish a partition status table containing all requested partition status information, so that the partition status table can be continuously queried in subsequent steps for scheduling partition polling and dynamic sleep time window calculation.

[0020] S2 specifically includes:

[0021] The request partition set is accessed sequentially according to a preset polling order, and when any target request partition is polled, its latest queue length, queue growth rate and arrival rate per unit time are read.

[0022] The aforementioned state parameters of the target request partition and its corresponding historical state sequence are input into the reinforcement learning model, which then predicts the load trend of the target request partition in the next time period based on the online update strategy.

[0023] Based on the trend of the unprocessed load output by the reinforcement learning model, and combined with the current state parameters of the target request partition, calculate the dynamic sleep time window for the target request partition.

[0024] Determine the difference between the dynamic sleep time window and the dynamic sleep time window of the target request partition in the previous round of polling to determine whether the sleep parameters of the target request partition need to be adaptively adjusted.

[0025] Record the calculated dynamic dormancy time window and use this dynamic dormancy time window as the effective time range for subsequent content clustering steps, so that content clustering is only performed within this dormancy time window.

[0026] S3 specifically includes:

[0027] When the target request partition enters the dynamic hibernation time window, the immediate processing operation on the target request partition is paused, and the collection of all pending requests within the hibernation window begins.

[0028] For pending requests within the same dormant window, content clustering is performed based on resource identifier, idempotent features, or parameter similarity to form multiple request clusters with high content consistency.

[0029] Within each request cluster, the request content is compared item by item, and requests with completely duplicate content are removed to obtain an initial version of the deduplicated request set.

[0030] Perform a consistency check on the initial version of the deduplication request set to ensure that requests in the same request cluster meet the merging conditions in terms of format, number of parameters, and access path.

[0031] The set of deduplication requests that has passed the consistency check is recorded as the final set of deduplication requests, and this set is used as the sole input set for subsequent merging processing steps.

[0032] S4 specifically includes:

[0033] For the final deduplication request set, determine whether the request type of each request cluster is a read operation request or an idempotent write operation request, so as to select the appropriate merging processing method;

[0034] For read operation requests belonging to the same request cluster, perform a unified resource read operation and cache the read result as the corresponding read operation result cache;

[0035] The read operation result is cached and broadcast back to all original read operation requests in the request cluster to achieve unified processing of read operation requests in the final deduplicated request set;

[0036] For idempotent write operation requests belonging to the same request cluster, a single final write operation is performed according to the preset write merging strategy, and the execution result of the final write operation is recorded as a write result cache.

[0037] The write result is cached and returned to all original idempotent write operation requests corresponding to the request cluster, so that all original requests obtain the same write processing result.

[0038] S5 specifically includes:

[0039] After completing the merging process of the final deduplication request set, the actual response time, resource consumption, and deduplication ratio of the target request partition in this round of processing are collected.

[0040] The actual response time, resource consumption, and deduplication ratio are compared with similar parameters in the previous round of polling to evaluate the effectiveness of the current dynamic sleep time window and content clustering strategy.

[0041] The above evaluation parameters are input into the reinforcement learning model, which then adjusts the sleep policy parameters corresponding to the target request partition based on the policy update rules.

[0042] Based on the updated sleep policy parameters of the reinforcement learning model, the dynamic sleep time window of the target request partition in the next round of polling is adaptively adjusted.

[0043] Record the revised dynamic sleep time window to make it the latest sleep parameter when performing subsequent polling and content clustering on the target requested partition.

[0044] S6 specifically includes:

[0045] After processing the current target request partition, the revised dynamic sleep time window and content clustering rules are applied to the next request partition to maintain the consistency of the partition polling logic.

[0046] The remaining requested partitions are sequentially processed by obtaining partition status, calculating dynamic sleep time windows, and performing content clustering and merging, ensuring that the partition polling process remains continuous globally.

[0047] During the cross-partition polling process, the processing results and deduplication ratio of each requested partition are recorded in the global processing status table for evaluation of the overall peak shaving effect.

[0048] Based on the peak-shaving effect, request load balancing degree and resource consumption in the global processing status table, the reinforcement learning model is updated in an overall manner to improve the peak-shaving efficiency in the next round of global polling.

[0049] By repeatedly executing the above steps, the server nodes can continuously perform cross-partition peak shaving under peak traffic scenarios, so as to maintain a balance between system stability and resource utilization.

[0050] A batch request peak-shaving system based on dynamic sleep and partitioned polling includes:

[0051] The request partitioning module is used to divide batch requests into multiple request partitions according to resource identifier mapping rules, and to establish a queue to be processed for each request partition.

[0052] The partition polling and dynamic hibernation calculation module is used to poll each request partition in a preset order. When polling to any target request partition, it reads its current queue length, request arrival rate, queue growth rate and historical state sequence.

[0053] The request clustering and content deduplication module within the hibernation window is used to collect pending requests from the target request partition within a dynamic hibernation time window, perform content feature extraction on each request, and cluster the content based on similarity.

[0054] The request merging processing module is used to perform unified processing on each request cluster in the final deduplicated request set: for request clusters of read operation type, a single unified resource read is performed and the read result is broadcast to all requests in that cluster;

[0055] The feedback collection and rhythm optimization module is used to collect the actual response time, resource consumption and deduplication ratio of the target request partition after the merging process is completed, and to construct a comprehensive performance evaluation value.

[0056] The global peak shaping control module is used to record the processing results of each request partition during cross-partition polling and to build global peak shaping metrics.

[0057] The global status management module is used to record the status parameters, dynamic sleep time windows, clustering results, merge processing results, feedback parameters, and global peak shaving indicators for all requested partitions.

[0058] The beneficial effects of this invention are as follows:

[0059] This invention utilizes a reinforcement learning model to predict the load trend of the request partition in the next cycle and dynamically calculates the sleep time window accordingly, enabling the system to enter peak shaving mode in advance before sudden peaks arrive. Unlike existing methods that rely on instantaneous queue length or CPU utilization for passive rate limiting, this invention has a forward-looking peak shaving capability, which can significantly reduce processing rhythm oscillations in short-cycle continuous peaks and "textured fluctuating load" scenarios, thereby improving system load capacity and stability.

[0060] This invention performs content feature extraction, similarity clustering, and content hash comparison on requests to be processed within a dynamic sleep window, generating a final deduplicated request set. This merges a large number of similar read requests into a single unified read and a large number of idempotent write requests into a single final write. This "content-dimensional peak shaving" not only reduces the number of instantaneous requests but also directly reduces the actual number of executions, achieving a non-linear reduction of peak load and significantly surpassing the effect of traditional time-delay-based peak shaving solutions.

[0061] The request merging processing module of this invention can execute read operation requests within the same request cluster in a single operation and broadcast the read results to all original requests; it also aggregates similar idempotent write operations into a single final write. Compared with existing line-by-line processing mechanisms, this invention significantly reduces I / O impact and disk write amplification effect under peak traffic, effectively reducing peak pressure on the backend storage system and improving server resource utilization.

[0062] This invention inputs multi-dimensional feedback parameters such as response time, resource consumption, and deduplication ratio into a reinforcement learning model. Through reward and loss functions, it achieves adaptive updates of policy parameters, allowing the dynamic sleep window to automatically evolve with traffic patterns. Compared to traditional static rate limiting strategies, this invention can continuously improve peak shaving performance, maintaining optimal rhythm control when business changes, load fluctuations, or changes in request composition, demonstrating significant intelligent optimization advantages.

[0063] This invention constructs a global peak-shaving metric that includes multiple indicators such as peak load after peak shaving, average deduplication ratio, and resource consumption after peak shaving. Based on this metric, a global policy update is performed on the reinforcement learning model, enabling unified optimization of peak-shaving strategies across multiple request partitions. This mechanism avoids the problem of chaotic policy interaction caused by independent adjustments in each partition in traditional technologies, achieving optimization at the overall system level and significantly improving global stability and processing capacity. Attached Figure Description

[0064] Figure 1 This is a schematic diagram comparing system resource consumption in an embodiment of the present invention;

[0065] Figure 2 This is a trend analysis chart of the peak shaving effect during the operating cycle of an embodiment of the present invention;

[0066] Figure 3 This is a schematic diagram of feature similarity clustering distribution in an embodiment of the present invention;

[0067] Figure 4 This is a schematic diagram of the predicted output of the load trend within the sampling period in an embodiment of the present invention.

[0068] Figure 5 This is a schematic diagram of the batch request peak-shaving processing method based on dynamic sleep and partitioned polling of the present invention;

[0069] Figure 6 This is a schematic diagram of the batch request peak-shaving processing system framework based on dynamic sleep and partitioned polling of the present invention. Detailed Implementation

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

[0071] Example 1: As Figure 5 As shown, this embodiment provides a batch request peak shaping method based on dynamic sleep and partitioned polling, including the following steps:

[0072] S1. Construct multiple independent request partitions based on resource identifiers, and write the arriving batch requests into the corresponding pending queues according to the mapping rules;

[0073] S2. Poll each request partition to obtain the queue status and change rate, use the reinforcement learning model to predict the load trend based on historical data, and calculate the dynamic sleep time window of the target partition accordingly.

[0074] S3. Collect pending requests within the dynamic sleep time window, perform content feature-based similarity clustering, content-level deduplication, and consistency verification, and generate a deduplicated request set.

[0075] S4. Perform unified processing on the deduplication request set: perform a single read and broadcast the result for read requests of the same type, perform a single write after aggregation for write requests of the same type that are idempotent, and fill the result back into the original request;

[0076] S5. Resource consumption and deduplication feedback during the data acquisition and processing process are addressed by adaptively optimizing the dynamic sleep time window of subsequent polling through updating the reinforcement learning model.

[0077] S6. Apply the optimized dynamic sleep time window to the polling process of the next partition, and achieve global collaborative peak shaving through cross-partition cyclic execution.

[0078] S1 specifically includes the following sub-steps:

[0079] S110. Establishment of request partitioning rules: In the server node, the range of resources accessible by batch requests is divided into multiple independent request partitions according to the resource identifier mapping rules.

[0080] To improve transparency, a resource identifier mapping formula can be defined as follows:

[0081]

[0082] Where: rid is the resource ID, used to uniquely identify the target resource that the request needs to access; Here, is a hash function used to map resource identifiers to integer values; mod is the modulo operator used to calculate the remainder after division. This embodiment does not limit the specific hash function and can be any available function such as CRC32, MD5, or MurmurHash; N is the number of request partitions used to limit the total number of available request partitions; and p is the partition index, indicating the target request partition to which the resource identifier is mapped.

[0083] The partition number p, calculated by the server according to the formula, provides the basis for subsequent requests to write to the corresponding partition.

[0084] S120. Request Partition Initialization and Status Parameter Establishment: For each request partition, initialize its corresponding pending queue and establish the following status parameters:

[0085] Queue maximum capacity : This indicates the maximum number of requests that the pending queue for this request partition can hold;

[0086] Current queue length : Used to represent the actual number of pending requests for this request partition at the current sampling time t, where i is the partition number (where the value range of i is consistent with p);

[0087] Request arrival rate This indicates the change in the number of write requests to this partition per unit of time. It can be calculated using a sliding time window, with the following formula:

[0088]

[0089] in The sampling period is used to represent the length of the time window used when calculating the arrival rate; This indicates the previous sampling time. All of the above state parameters are stored in the state record of the corresponding requested partition for subsequent calculation and updating of the dynamic sleep time window.

[0090] S130, New Request Writing and Queue Overflow Handling: When a new request arrives at the server node, the target partition number p corresponding to the request is obtained according to the mapping rule in S110, and the new request is written into the pending queue of the request partition with the number p.

[0091] When the current queue length of the queue to be processed Reaching the maximum queue capacity In such cases, the server may perform queue overflow processing based on a preset strategy; exemplary strategies include:

[0092] Refuse the new request;

[0093] Write the overflowing request into the handover buffer;

[0094] This triggers a partition expansion or dynamic scaling strategy. Specific overflow strategies are not limited to the examples above; those skilled in the art can configure them according to actual needs.

[0095] S140. Real-time update of request partition status parameters: During operation, the status parameters of each request partition are updated in real time, including:

[0096] Current queue length Request arrival rate (Calculated according to the formula in S120);

[0097] Queue growth rate : Used to represent the magnitude of change in the growth trend of the queue, which can be calculated using the following formula as an example:

[0098]

[0099] in To prevent division by zero of small constants, the example value can be 10. -6 However, this value is not the only one; the meanings of all symbols remain consistent with those above. The above three parameters constitute the real-time operating status of the target partition, which is used for the accurate calculation of the subsequent dynamic hibernation time window.

[0100] S150. Construction and Recording of the Global Partition Status Table: To achieve unified scheduling and querying of all requested partitions, a global partition status table is established to store the status information of each requested partition. This status table includes at least the following fields:

[0101] PartitionID (Partition Number): Corresponds to the aforementioned symbol i;

[0102] QueueLength (current queue length): Corresponding to... ;

[0103] ArrivalRate (Request Delivery Rate): Corresponding to ;

[0104] GrowthRate (Queue Growth Rate): Corresponding to ;

[0105] HistoryStates: This is used to record the state values ​​of the requested partition in the most recent sampling periods, which are used as input for subsequent reinforcement learning models. The global partition state table can be stored in the form of a structure, table or JSON, without limiting the specific format, as long as the aforementioned state parameters can be read from it in subsequent steps.

[0106] S2 specifically includes the following sub-steps:

[0107] S210. Obtaining the target requested partition status parameters: Access the global partition status table sequentially according to the preset polling order, and when polling to any target requested partition, read the latest running status parameters of that target requested partition, including:

[0108] Current queue length : Represents the number of pending requests in partition i at time t; request arrival rate : Represents the rate of change of the number of requests arriving in partition i per unit time, defined the same as S120; queue growth rate. : Indicates the trend of arrival rate change of partition i, defined the same as S140;

[0109] Historical state sequence : Represents the sequence of states of partition i over the most recent sampling periods, for example The parameters mentioned above will serve as input features for the reinforcement learning model, used to predict subsequent load trends.

[0110] S220, Reinforcement learning model predicts subsequent load trends: The state parameters of the target request partition are input into the reinforcement learning model M, and the model outputs the predicted load trend value for the next time period:

[0111]

[0112] Where M is the Reinforcement Learning Model, which is used to output load trend prediction results based on historical and current states;

[0113] The Predicted Load Trend is used to represent the estimated request growth trend of partition i at time t+1. The larger the value, the higher the expected load in the next period.

[0114] Model update strategy notation:

[0115] To enhance the policy parameters of the learning model; The learning rate is used to control the speed at which parameters are updated.

[0116] Model parameter updates are performed using policy gradients:

[0117]

[0118] The above formula is an illustrative description and does not limit the specific form of the model. It can be any reinforcement learning method such as DQN, DDPG, PPO, or Actor-Critic. Indicates about policy parameters gradient operator, This indicates an assignment operation, which updates the variable value on the left side with the calculation result on the right side of the formula.

[0119] In one specific embodiment of the present invention, the reinforcement learning model employs a deep Q-network (DQN) structure. For ease of implementation by those skilled in the art, the specific network structure configuration is as follows:

[0120] Input Layer: The dimension is designed as 3+K, where 3 represents the current state parameter (queue length). Arrival rate growth rate K represents the historical state sequence. The length of the sample (e.g., taking the state of the most recent 10 sampling periods, i.e., K equals 10).

[0121] Hidden Layers: These consist of two fully connected layers. The first hidden layer contains 128 neurons, activated by ReLU (Rectified Linear Unit); the second hidden layer contains 64 neurons, also activated by ReLU. This design is intended to fully extract the nonlinear characteristics of load fluctuations.

[0122] Output Layer: Contains one neuron, uses a linear activation function, and directly outputs continuous values ​​as a prediction of load trends. .

[0123] Optimizer and Loss Function: The model training uses the Adam optimizer, and the loss function is the mean squared error (MSE). This lightweight, fully connected network structure can maintain prediction accuracy while keeping inference latency in the millisecond range, meeting the performance requirements of real-time scheduling on the server side.

[0124] In this embodiment, the inference and training of the reinforcement learning model are deployed on edge server nodes equipped with TPUs (Tensor Processing Units) or FPGA accelerator cards. TensorRT or ONNX Runtime is used to accelerate the model through quantization, ensuring that the time taken for a single inference operation is kept within 1ms to meet the real-time scheduling requirements of high-concurrency scenarios.

[0125] S230. Calculation of dynamic sleep time window based on predicted load trend: Based on the predicted load trend output by the reinforcement learning model. And the current state of the target requested partition, calculate the dynamic sleep time window of the partition. .

[0126] The formula for defining the dynamic sleep time window is:

[0127]

[0128] in: The Dynamic Sleep Window represents the sleep duration of partition i at time t. , , These are weighting coefficients used to adjust the impact of predicted load trends, queue occupancy levels, and growth rates on the dormancy window. The maximum capacity of the queue is defined the same as S120; preferably, =0.5: Assign the highest weight to the predicted load trend to achieve forward-looking control; =0.3: Assign the second highest weight to the current queue occupancy level; =0.2: Assign a basic weight to the rate of change of growth.

[0129] It should be noted that: the higher the predicted load, The larger the value, the shorter the sleep time (timely processing); the fuller the queue, the shorter the sleep time. The larger the value, the shorter the hibernation time; the higher the growth rate, the faster the load increases, and the shorter the hibernation time; ensure that the hibernation window has dynamic adjustment capabilities.

[0130] S240. Stability and Adaptive Adjustment of Dynamic Sleep Time Window: To avoid unstable oscillations in the sleep time window during continuous polling, the current sleep time window is adjusted accordingly. Compared to the previous window Perform a difference analysis:

[0131]

[0132] in: This represents the change in the dormant window size, used to indicate the trend of window size changes.

[0133] If the following conditions are met: This indicates that the window has changed too much and needs to be adjusted smoothly and adaptively. The stability threshold is used to define the acceptable range of window fluctuations. Preferably, the stability threshold is... =5ms, meaning that smooth adjustment is only triggered when the sleep window changes for more than 5 milliseconds.

[0134] Smoothing adjustments can be performed using exponential smoothing:

[0135]

[0136] in The smoothing factor is used to control the window convergence speed. Preferably, the smoothing factor is... =0.8 indicates that the new window value retains 80% of the historical inertia, avoiding violent fluctuations.

[0137] S250, Recording and Outputting Dynamic Sleep Time Window: This involves recording and outputting the smoothly adjusted dynamic sleep time window. Write to the global partition status table to serve as the valid time range for the next step of performing content clustering (S310–S350).

[0138] This record includes: partition number i; dynamic hibernation time window. Model predictions Current state parameters , , This parameter will be used directly in subsequent steps to ensure that polling-prediction-dormant-clustering forms a closed loop.

[0139] S3 specifically includes the following sub-steps:

[0140] S310. Collection of pending requests within the hibernation window: The target request partition enters a dynamic hibernation time window. When this happens, immediate processing of the target request partition is paused, and the set of pending requests for that partition is continuously collected throughout the entire hibernation window, denoted as:

[0141]

[0142] in: The set of pending requests represents all requests that have arrived but not yet been processed within the sleep window of partition i at time t. Let j be the j-th pending request; n is the number of requests, representing the number of requests actually collected within the current sleep window.

[0143] S320. Content-based request clustering processing: for sets Each request in Extract content features to form a request vector:

[0144]

[0145] in: This is a content feature extraction function used to extract key features such as resource identifier, parameter list, and request type from the request. The request feature vector represents the request. A structured representation of content.

[0146] Specifically, content feature extraction function A combination of hierarchical hash mapping and numerical normalization is used:

[0147] For discrete parameters in the request (such as resource ID and user ID), the MurmurHash algorithm is used to map them into sparse vectors of fixed dimensions; for continuous numerical parameters (such as purchase quantity and price), Min-Max normalization is used to map them to the [0,1] interval; the above vectors are concatenated and then passed through a fully connected embedding layer for dimensionality reduction, outputting a dense vector of fixed length (e.g., 64 dimensions) as... This approach ensures that request parameters in different formats can be used to calculate Euclidean distance or cosine similarity within the same vector space.

[0148] Subsequently, similarity-based clustering is performed on the request set. Cosine similarity can be used as an example of similarity:

[0149]

[0150] in For similarity functions; Let represent the Euclidean norm of the vector, and k be the index number of the vector to be compared, where k is not equal to j. Define the similarity threshold: This is a cluster similarity threshold used to determine whether two requests belong to the same content cluster; if the following conditions are met: Then the request will be made. and They are grouped into the same request cluster; this results in a final set of request clusters. ;in:

[0151] For the request cluster set; is the l-th request cluster; m is the number of request clusters.

[0152] S330. Content-level deduplication within a request cluster: For any request cluster... The request performs content-level deduplication.

[0153] Define the request content hash:

[0154]

[0155] in This is a content hash function used to calculate a unique hash value for the requested content. The hash value of the request content; within the same request cluster, the hash values ​​of the content of all requests are compared;

[0156] If satisfied Then the request is considered valid. With request If the content is completely identical, keep one of them and remove the rest as duplicate requests. This process yields the deduplicated request set:

[0157]

[0158] in: For deduplication request set; For the q-th deduplicated request; For requesting clusters The number of requests remaining after deduplication.

[0159] S340. Consistency check of the deduplication request set: To ensure that the deduplication results within the request cluster all meet the conditions for merging, the set... Perform consistency checks, including but not limited to:

[0160] Are the number of parameters consistent? Are the parameter types consistent? Are the request types consistent (read / write / idempotent write)? Are the target resource identifiers consistent?

[0161] Consistency checks can define consistency metrics functions:

[0162]

[0163] in: This is a consistency check function; an output of 1 indicates that the consistency check has passed, and an output of 0 indicates that it has failed. If all requests in the set satisfy: If so, the request cluster is considered ready to proceed to the next step of merging.

[0164] Consistency check function It also includes business semantic-level conflict detection:

[0165] Version number verification (based on the Compare and Exchange (CAS) Check mechanism): Check whether the version numbers of the data carried in the request within the same cluster belong to the same generation. If the version number span exceeds the threshold, it is determined that it cannot be merged to prevent the ABA problem.

[0166] Permission context verification: Checks whether requests within the same cluster have the same tenant ID or security level, and prohibits the merging of requests across tenants.

[0167] S350. Formation and Output of the Final Deduplication Request Set: All deduplication request sets filtered according to consistency checks are merged to form the final deduplication request set of the target request partition at time t.

[0168]

[0169] in: The final deduplication request set represents the valid request set after deduplication of all request clusters, which is used for subsequent merging and execution steps (S410–S450). The final deduplication request set is recorded and passed as the only input to the unified processing flow of the next stage.

[0170] S4 specifically includes the following sub-steps:

[0171] S410. Request Type Determination and Merging Strategy Selection: For the final deduplication request set Each request cluster in First, determine the request type of all requests within the cluster:

[0172]

[0173] in: This is the function for determining the request type; Read represents a read operation; Write_Idempotent represents an idempotent write operation. This is the qth deduplicated request mentioned above; if all request types within the request cluster are identical, then select the corresponding merging strategy to proceed to the next sub-step.

[0174] S420. Unified read processing of read operation requests: For request clusters belonging to the read operation type... Perform a unified resource read operation. The formula for the read operation execution is defined as follows:

[0175]

[0176] in This represents the cluster-level read operation result, indicating the unified read result for the target resource corresponding to the requested cluster l; This is a resource read function used to read the latest status of a target resource based on its resource identifier. This is the target resource identifier for the request cluster, representing the common target resource ID accessed by all requests in the request cluster; after performing a unified read, the result is cached in the read operation cache of this processing cycle.

[0177] S430. Broadcast backfilling of read operation results within the requesting cluster: For the requesting cluster Each deduplication request in The read result backfilling operation can be represented as follows:

[0178]

[0179] in: This is a function that requests and responds to a function, indicating that the corresponding cluster-level read result will be written into the response data structure of each request. Through this operation, all original requests will obtain the same response result as the unified read operation, thus realizing the batch merging of read operations.

[0180] S440, Merged Write Execution of Idempotent Write Requests: For request clusters belonging to the idempotent write operation type A single final write operation is performed according to the preset write strategy.

[0181] First, the request content within the request cluster is aggregated to form cluster-level write content:

[0182]

[0183] in: For aggregated write content, it means the unified write content obtained by aggregating all deduplication requests for this cluster; An aggregation function for writing content, used to extract the final written content from the parameters of multiple idempotent write requests; This represents the number of duplicate requests in the l-th request cluster (defined as in S330).

[0184] The preset write merging strategy includes the following two specific implementation modes, which the system automatically selects based on the request type field:

[0185] Overwrite merging: Applicable to status update requests (such as modifying order status). The strategy is to sort requests within a cluster by their arrival timestamps, and only retain the request parameters with the latest timestamp as the aggregated content. Discard old version requests.

[0186] Incremental merging: Applicable to numerical accumulation requests (such as increasing inventory). The strategy is to extract the incremental numerical fields of all requests within the cluster, calculate their algebraic sum (Sum), and use this algebraic sum as the final write parameter to perform a single database update operation, thereby avoiding database row lock contention.

[0187] Perform a final write operation on the aggregated write content:

[0188]

[0189] in: Write results at the cluster level; This function writes the aggregated content to the target resource.

[0190] S450. Backfilling of write results and consistency of intra-cluster responses: After completing a single write operation, the write result is backfilled to the requesting cluster. All deduplicated requests and their corresponding original requests are in the following format:

[0191]

[0192] All symbols inherit the aforementioned definitions and maintain the same meaning: : Request and response functions; This step produces cluster-level write results; it ensures that all write requests within the same request cluster have consistent write results; the system performs only one write operation, significantly reducing write pressure during peak periods.

[0193] S5 specifically includes the following sub-steps:

[0194] S510. Processing and recording feedback parameters: After completing the final deduplication request set for the target request partition. After merging, the running feedback parameters of this partition during this round of processing are collected, including:

[0195] Processing response time : Represents the average request response time of partition i at time t;

[0196] resource consumption This indicates the total resource consumption of the server node in terms of CPU, memory, or I / O during this processing round.

[0197] Deduplication ratio This indicates the proportion of deduplicated requests to the total number of requests within the sleep window. The calculation formula is as follows:

[0198]

[0199] Where: m is the number of requested clusters (defined as in S320); is the number of requests remaining after deduplication in request cluster l (defined as in S330); n is the number of requests to be processed actually collected within the sleep window (defined as in S310); the above feedback parameters will be used as training samples for the reinforcement learning model to fine-tune subsequent sleep strategies.

[0200] S520. Evaluation of the effect of feedback parameters and calculation of the difference between expected and actual performance: Based on the feedback parameters of this round, calculate the difference between the current performance and the target performance to describe the current dynamic sleep time window. The effectiveness of [the evaluation]. Define comprehensive performance evaluation indicators:

[0201]

[0202] in: This is a comprehensive performance evaluation value; , , These are weighting coefficients used to adjust the impact weights of response time, resource consumption, and deduplication ratio.

[0203] Define the target performance expectation: The target evaluation value represents the evaluation indicator target under ideal conditions.

[0204] The difference between the two indicates the direction of model optimization:

[0205]

[0206] in: Performance difference is used to describe the degree of deviation between the current scheduling strategy and the target performance.

[0207] S530, Parameter Update of Reinforcement Learning Model Based on Reward Function: Incorporating Performance Differences The policy parameters used to construct the reward function to train the reinforcement learning model M .

[0208] Define the reward function:

[0209]

[0210] in: This is a reward value used to guide the model to obtain higher rewards when performance bias decreases.

[0211] Define the loss function:

[0212]

[0213] in: The loss function; For policy functions, it means that in the policy parameters Select hibernation time window below The probability; symbol " "" indicates a conditional probability relationship, that is, in the state Select action The probability of.

[0214] For the partitioned state vector, by Composition (definitions remain consistent with those above).

[0215] Model parameter updates are performed using gradient descent.

[0216]

[0217] in The learning rate controls the magnitude of parameter updates. This update process ensures that the model policy is gradually optimized over multiple iterations, with the optimal learning rate being determined. =0.001, to ensure the stability of model convergence, with a sampling period of 100ms, meaning the state is updated every 100 milliseconds.

[0218] To address the cold start problem of reinforcement learning models in the initial stage, the system has implemented a warm-up protection mechanism:

[0219] Exploitation and Exploitation (Epsilon-Greedy) Strategy: In the early stages of system operation (e.g., the first 1000 polling cycles), set the exploration rate. That is, there is an 80% probability of using a rule-based fixed sleep time (e.g., a fixed 50ms), and a 20% probability of using the model output value;

[0220] Replay Buffer Filling: During the warm-up phase, only state data is collected. The samples are stored in a buffer without gradient updates. Once the number of samples in the buffer reaches a preset threshold (e.g., 5000), the backpropagation of the neural network is started, and the exploration rate is linearly decayed to 0.05 over time.

[0221] S540, Sleep time window correction based on updated policy: based on the updated policy parameters. Recalculate the next round of dynamic sleep time window, defined as:

[0222]

[0223] in: This will be the next dynamic hibernation time window; This is the partition state vector for the next sampling period, consistent with the previous definition. To avoid window oscillations, the stability smoothing formula can continue to be used:

[0224]

[0225] in The smoothing coefficient is defined as described above. This method enables the dormancy strategy to possess both adaptive and asymptotic convergence capabilities.

[0226] S550, recording and output of hibernation strategy and feedback parameters: updating the dynamic hibernation time window. With reward value Loss function value And the latest policy parameter θ is written to the global partition state table so that:

[0227] Used for the next round of partitioned polling step S210; used for stability analysis of the global peak shaving process; forming a complete closed loop of prediction → execution → feedback → update. Thus, the dynamic dormancy tuning process based on reinforcement learning forms a closed loop.

[0228] S6 specifically includes the following sub-steps:

[0229] S610, Application of Dynamic Sleep Time Window in Cross-Partition Polling: The dynamic sleep time window is used to complete the polling of the currently requested partition. After the update, the hibernation window is applied to the polling process of the next requested partition. The next requested partition is recorded as i+1, and its hibernation window is denoted as:

[0230]

[0231] in: The dynamic hibernation time window for the next partition; A policy function is used to base decisions on policy parameters. Calculate the hibernation window for the next partition;

[0232] This is the next partition state vector, and its structure is the same as described above. Consistent, by This step ensures that the dynamic hibernation strategy not only applies to the current partition but can also be applied continuously across partitions.

[0233] S620, Continuous polling and content clustering across all request partitions: Execute across all request partitions Perform continuous polling and execute the following sub-processes in each partition:

[0234] Get status parameters Call the reinforcement learning policy function Calculate the dynamic sleep time window Collect the request set within the dormant window and perform content clustering and deduplication; perform merging processing (read merging or idempotent write merging); perform local feedback updates and record the results.

[0235] Cross-partition polling can be represented as:

[0236]

[0237] in For partition execution, this is the function to execute all steps S110–S550 on partition i; N is the number of globally requested partitions, defined the same as S110; the symbol " " indicates a universal quantifier (For All), meaning for all sets" Each integer i in the sequence is followed by an operation. This step ensures that all requested partitions are processed according to a consistent dynamic hibernation and content clustering rule.

[0238] S630. Construction and Recording of Global Peak Shaving Indicators: To measure the overall peak shaving effect of the system, global peak shaving indicators are constructed. Its exemplary definition is as follows:

[0239]

[0240] in: This is a global peak reduction metric; a higher value indicates a better peak reduction effect. This represents the peak load of the system after peak shaving. This represents the original peak load before peak shaving. The average deduplication ratio is defined as the mean of the deduplication ratios across all partitions:

[0241]

[0242] This represents the average resource consumption of the system after peak shaving. This represents the consumption of raw, unshaving peak resources. , , These are weighting coefficients used to adjust the influence weights of the three indicators in the overall peak-shaving analysis. Preferably, =0.4 (peak load weight) =0.4 (weight of deduplication ratio) =0.2 (Resource consumption weight). Global peak shaving index. It will be recorded in the global state table for subsequent system-level policy optimization.

[0243] S640. Update strategy parameters based on global peak shaping index: Update global peak shaping index... The global reward used as the model for reinforcement learning is defined as follows:

[0244]

[0245] in The global reward value describes the peak-shaving performance of the entire system at time t; combined with the local reward value... (Defined in S530), construct the multi-partition joint loss function:

[0246]

[0247] in: The global loss function; , These are weighting coefficients used to balance global and local rewards. Gradient descent is used for policy updates.

[0248]

[0249] in: These are global policy parameters; The learning rate (defined as above). This step integrates the system's multi-partition peak-shaving strategies into a unified strategy parameter update, enabling the model to have global optimization capabilities.

[0250] S650, Global Loop Execution and Policy Convergence: After completing the global policy parameter update, the new policy parameters will be... Global peak shaving index Global reward value Write to the global partition status table and proceed to the next time period t+1 to execute the cross-partition loop:

[0251]

[0252] Here: For the next time period, a cross-partition peak-shaving loop is performed; after multiple iterations, the global strategy parameters... Through multiple gradient updates, the system gradually converges, enabling it to consistently achieve stable and efficient peak-shaving performance in peak scenarios.

[0253] Example 2: Figure 6 As shown, this embodiment provides a batch request peak shaping system based on dynamic sleep and partitioned polling, including:

[0254] The request partitioning module is used to divide batch requests into multiple request partitions according to resource identifier mapping rules, and to establish a queue to be processed for each request partition; the request partitioning module is used to record status parameters such as the maximum capacity of the queue, the current queue length, the request arrival rate, and the queue growth rate.

[0255] The partition polling and dynamic hibernation calculation module is used to poll each request partition in a preset order. When polling to any target request partition, it reads its current queue length, request arrival rate, queue growth rate and historical state sequence.

[0256] The aforementioned state parameters are then input into the reinforcement learning model to predict the load trend of the partition in the next cycle; the dynamic sleep time window of the target request partition is calculated based on the predicted load trend, and stability smoothing is performed on the sleep time window.

[0257] The request clustering and content deduplication module within the hibernation window is used to collect pending requests from the target request partition within a dynamic hibernation time window, perform content feature extraction on each request, and cluster the content based on similarity.

[0258] By comparing content hashes and verifying consistency, content-level deduplication is performed on requests within the same cluster to form the final deduplicated request set.

[0259] The request merging processing module is used to perform unified processing on each request cluster in the final deduplicated request set: for request clusters of read operation type, a single unified resource read is performed and the read result is broadcast to all requests in that cluster;

[0260] For request clusters of idempotent write operations, perform write content aggregation, and then perform a single final write operation based on the aggregated content, backfilling the write results to all requests in that cluster.

[0261] The feedback collection and rhythm optimization module is used to collect the actual response time, resource consumption and deduplication ratio of the target request partition after the merging process is completed, and construct a comprehensive performance evaluation value; and calculate the reward function and loss function based on the evaluation value, update the policy parameters of the reinforcement learning model, and adjust the dynamic sleep time window of the next cycle.

[0262] The global peak shaping control module is used to record the processing results of each requesting partition during cross-partition polling and construct a global peak shaping index; the global peak shaping index is used as a global reward to perform a global update on the policy parameters of the reinforcement learning model; and the updated policy parameters and the latest dynamic sleep time window are written into the global state table for use in the next cycle of cross-partition loop execution.

[0263] The global status management module records the status parameters, dynamic sleep time windows, clustering results, merging results, feedback parameters, and global peak-shaving indicators of all requested partitions, so as to support the system to continuously perform cyclic updates of partition polling, content merging, and peak-shaving strategies.

[0264] like Figure 1As shown, six consecutive batch request sampling points (marked as items 1 to 6 in the figure) were selected as observation objects to compare the system resource consumption before and after merging processing without using this method.

[0265] like Figure 2 As shown, the horizontal axis represents the time axis (00:00 to 20:00), and the curve reflects the implementation of the system's peak shaving strategy at different time points.

[0266] like Figure 3 As shown, the horizontal axis represents the sequence number of the request entering the queue, and the vertical axis represents the feature similarity score (range 0-1) between the request and the current cluster center. The scatter distribution visually demonstrates the clustering characteristics of the request content.

[0267] like Figure 4 As shown, the curve illustrates the load trend prediction calculated by the reinforcement learning model based on the current queue state and historical sequences. It can be seen that as the system sampling period progresses, the model's output prediction curve exhibits significant dynamic fluctuations, indicating that the model can sensitively capture minute changes in traffic.

[0268] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters and thresholds in the formulas are set by those skilled in the art according to the actual situation.

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

[0270] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A batch request peak-shaving processing method based on dynamic sleep and partitioned polling, characterized in that, Includes the following steps: S1. Construct multiple independent request partitions based on resource identifiers, and write the arriving batch requests into the corresponding pending queues according to the mapping rules; S2. Poll each request partition to obtain the queue status and change rate, use the reinforcement learning model to predict the load trend based on historical data, and calculate the dynamic sleep time window of the target partition accordingly. S3. Collect pending requests within the dynamic sleep time window, perform content feature-based similarity clustering, content-level deduplication, and consistency verification, and generate a deduplicated request set. S4. Perform unified processing on the deduplication request set: perform a single read and broadcast the result for read requests of the same type, perform a single write after aggregation for write requests of the same type that are idempotent, and fill the result back into the original request; S5. Resource consumption and deduplication feedback during the data acquisition and processing process are addressed by adaptively optimizing the dynamic sleep time window for subsequent polling through updating the reinforcement learning model.

2. The batch request peak shaping method based on dynamic sleep and partitioned polling according to claim 1, characterized in that, Also includes: S6. Apply the optimized dynamic sleep time window to the polling process of the next partition, and achieve global collaborative peak shaving through cross-partition cyclic execution.

3. The batch request peak-shaving processing method based on dynamic sleep and partitioned polling according to claim 1, characterized in that, S1 specifically includes: In the server node, according to the preset resource identifier mapping rules, the range of resources accessible by batch requests is divided into multiple independent request partitions to form a set of request partitions for partitioned management. Initialize the corresponding queue to be processed in any request partition, and record initial state parameters such as the maximum capacity of the queue, the current queue length, and the historical arrival rate for that request partition. When a new request arrives at the server node, it is written into the pending queue of the corresponding target request partition according to the resource identifier mapping rule, so as to maintain the consistency between the request access and the partition structure. The queue length, queue growth rate, and arrival rate per unit time of each request partition are continuously updated as input parameters for subsequent dynamic sleep time window calculations. Establish a partition status table containing all requested partition status information, so that the partition status table can be continuously queried in subsequent steps for scheduling partition polling and dynamic sleep time window calculation.

4. The batch request peak-shaving processing method based on dynamic sleep and partitioned polling according to claim 1, characterized in that, S2 specifically includes: The request partition set is accessed sequentially according to a preset polling order, and when any target request partition is polled, its latest queue length, queue growth rate and arrival rate per unit time are read. The aforementioned state parameters of the target request partition and its corresponding historical state sequence are input into the reinforcement learning model, which then predicts the load trend of the target request partition in the next time period based on the online update strategy. Based on the trend of the unprocessed load output by the reinforcement learning model, and combined with the current state parameters of the target request partition, calculate the dynamic sleep time window for the target request partition. Determine the difference between the dynamic sleep time window and the dynamic sleep time window of the target request partition in the previous round of polling to determine whether the sleep parameters of the target request partition need to be adaptively adjusted. Record the calculated dynamic dormancy time window and use this dynamic dormancy time window as the effective time range for subsequent content clustering steps, so that content clustering is only performed within this dormancy time window.

5. The batch request peak shaping method based on dynamic sleep and partitioned polling according to claim 1, characterized in that, S3 specifically includes: When the target request partition enters the dynamic hibernation time window, the immediate processing operation on the target request partition is paused, and the collection of all pending requests within the hibernation window begins. For pending requests within the same dormant window, content clustering is performed based on resource identifier, idempotent features, or parameter similarity to form multiple request clusters with high content consistency. Within each request cluster, the request content is compared item by item, and requests with completely duplicate content are removed to obtain an initial version of the deduplicated request set. Perform a consistency check on the initial version of the deduplication request set to ensure that requests in the same request cluster meet the merging conditions in terms of format, number of parameters, and access path. The set of deduplication requests that has passed the consistency check is recorded as the final set of deduplication requests, and this set is used as the sole input set for subsequent merging processing steps.

6. The batch request peak shaping method based on dynamic sleep and partitioned polling according to claim 1, characterized in that, S4 specifically includes: For the final deduplication request set, determine whether the request type of each request cluster is a read operation request or an idempotent write operation request, so as to select the appropriate merging processing method; For read operation requests belonging to the same request cluster, perform a unified resource read operation and cache the read result as the corresponding read operation result cache; The read operation result is cached and broadcast back to all original read operation requests in the request cluster to achieve unified processing of read operation requests in the final deduplicated request set; For idempotent write operation requests belonging to the same request cluster, a single final write operation is performed according to the preset write merging strategy, and the execution result of the final write operation is recorded as a write result cache. The write result is cached and returned to all original idempotent write operation requests corresponding to the request cluster, so that all original requests obtain the same write processing result.

7. The batch request peak shaping method based on dynamic sleep and partitioned polling according to claim 1, characterized in that, S5 specifically includes: After completing the merging process of the final deduplication request set, the actual response time, resource consumption, and deduplication ratio of the target request partition in this round of processing are collected. The actual response time, resource consumption, and deduplication ratio are compared with similar parameters in the previous round of polling to evaluate the effectiveness of the current dynamic sleep time window and content clustering strategy. The above evaluation parameters are input into the reinforcement learning model, which then adjusts the sleep policy parameters corresponding to the target request partition based on the policy update rules. Based on the updated sleep policy parameters of the reinforcement learning model, the dynamic sleep time window of the target request partition in the next round of polling is adaptively adjusted. Record the revised dynamic sleep time window to make it the latest sleep parameter when performing subsequent polling and content clustering on the target requested partition.

8. The batch request peak shaping method based on dynamic sleep and partitioned polling according to claim 2, characterized in that, S6 specifically includes: After processing the current target request partition, the revised dynamic sleep time window and content clustering rules are applied to the next request partition to maintain the consistency of the partition polling logic. The remaining requested partitions are sequentially processed by obtaining partition status, calculating dynamic sleep time windows, and performing content clustering and merging, ensuring that the partition polling process remains continuous globally. During cross-partition polling, the processing results and deduplication ratio of each requested partition are recorded in the global processing status table to evaluate the overall peak shaving effect.

9. The batch request peak shaping method based on dynamic sleep and partitioned polling according to claim 8, characterized in that, S6 also includes: Based on the peak-shaving effect, request load balancing degree and resource consumption in the global processing status table, the reinforcement learning model is updated in an overall manner to improve the peak-shaving efficiency in the next round of global polling. By repeatedly executing the above steps, the server nodes can continuously perform cross-partition peak shaving under peak traffic scenarios, so as to maintain a balance between system stability and resource utilization.

10. A batch request peak shaping system based on dynamic sleep and partitioned polling, employing the batch request peak shaping method based on dynamic sleep and partitioned polling as described in any one of claims 1-9, characterized in that, include: The request partitioning module is used to divide batch requests into multiple request partitions according to resource identifier mapping rules, and to establish a queue to be processed for each request partition. The partition polling and dynamic hibernation calculation module is used to poll each request partition in a preset order. When polling to any target request partition, it reads its current queue length, request arrival rate, queue growth rate and historical state sequence. The request clustering and content deduplication module within the hibernation window is used to collect pending requests from the target request partition within a dynamic hibernation time window, perform content feature extraction on each request, and cluster the content based on similarity. The request merging processing module is used to perform unified processing on each request cluster in the final deduplicated request set: for request clusters of read operation type, a single unified resource read is performed and the read result is broadcast to all requests in that cluster; The feedback collection and rhythm optimization module is used to collect the actual response time, resource consumption and deduplication ratio of the target request partition after the merging process is completed, and to construct a comprehensive performance evaluation value. The global peak shaping control module is used to record the processing results of each request partition during cross-partition polling and to build global peak shaping metrics. The global status management module is used to record the status parameters, dynamic sleep time windows, clustering results, merge processing results, feedback parameters, and global peak shaving indicators for all requested partitions.

Images