High-concurrency business elastic scheduling method and system for new retail platform

Abstract

The application discloses a high-concurrency business elastic scheduling method and system for a new retail platform, relates to the technical field of communication, and comprises the following steps: for each service instance, a comprehensive load index is calculated based on the covariance matrix of its multi-dimensional running index and a load fluctuation penalty factor; the comprehensive load index sequence is input into an LSTM neural network to predict load quantile values at future time steps; the stretching urgency is calculated according to the quantile prediction values, and the final resource adjustment amount is determined in combination with the historical stretching amplitude; for each service instance, the final instance weight is calculated by comprehensively considering the current comprehensive load index, the remaining resource capacity, the future load trend and the historical load stability; and based on the final instance weight, the service instance is executed for real-time request routing through a gateway component to complete business elastic scheduling. The application realizes stable support for high-concurrency business of new retail through intelligent elastic scheduling.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and more specifically to a method and system for elastic scheduling of high-concurrency services for new retail platforms. Background Technology

[0002] With the rapid development of internet technology, new retail platforms have become an important part of the modern business system. During major promotional events such as 618 and Double Eleven, these platforms face unprecedented high-concurrency access pressure. Marketing tactics such as flash sales and limited-time offers can trigger instantaneous traffic surges, with order volumes potentially increasing dozens of times in a short period, posing a severe challenge to the stability and responsiveness of backend service clusters. Currently, the industry generally adopts elastic scheduling solutions based on cloud computing and microservice architecture to cope with traffic fluctuations. These solutions typically achieve automatic scaling of resources by monitoring system resource metrics.

[0003] However, existing elastic scheduling methods still have shortcomings in dealing with the unique business scenarios of new retail platforms. First, traditional methods mostly adopt a passive response model, only triggering scaling operations when the system load reaches a threshold, resulting in response delays when facing sudden traffic surges, potentially causing service avalanche. Second, scaling decisions based on a single metric often lack accuracy, easily leading to frequent resource fluctuations, affecting both system stability and increasing operating costs. Third, existing load balancing strategies typically only consider the current load status of instances, ignoring future load trends, potentially allocating traffic to instances that are about to become overloaded. Finally, most systems lack a deep understanding of business characteristics, cannot distinguish the priority of different types of requests, and struggle to guarantee the service quality of core transaction links.

[0004] For example, Chinese patent CN117478600A discloses a traffic control method and system for a high-concurrency multi-center business platform. The method includes: obtaining upper and lower limits of business frequency, the current pre-allocated baseline number, the maximum usable frequency of the business, the pre-allocated but unused frequency corresponding to a time node, and the un-allocated frequency corresponding to a time node; calculating the average unused frequency corresponding to a time node based on the time node, the pre-allocated but unused frequency, and the un-allocated frequency; and calculating the usable frequency within the current time period and the current pre-allocated frequency based on the maximum usable frequency of the business, the average unused frequency, CPU utilization, memory utilization, and I / O utilization, thus completing traffic control. This invention, through its traffic control mechanism, can effectively limit the number and frequency of concurrent requests, avoiding system overload and crashes; and rationally allocate and schedule traffic, enabling the system to smoothly handle business requests, improving response speed and performance stability.

[0005] For example, Chinese Patent Publication No. CN104639461A discloses a method, apparatus, and system for scheduling business data. For each node in the tree structure upon which the scheduler is based, the number of bytes actually requested for scheduling corresponding to each priority level of the node is reported to its parent node. The number of bytes actually requested for scheduling corresponding to each priority level reported by all child nodes of the root node is obtained, and the number of bytes actually scheduled corresponding to each priority level of the root node is calculated based on a preset maximum concurrent scheduling byte count. Based on the number of candidate bytes for scheduling corresponding to each priority level of each node, and the number of already scheduled bytes and the number of actually scheduled bytes corresponding to each priority level of the node's parent node, a preset scheduling rule is used to obtain the number of bytes actually scheduled corresponding to each priority level of the node. This invention provides a parallel scheduling method for business data, enabling parallel scheduling of multiple nodes in each scheduling process, thereby improving the scheduling efficiency of business data. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to address the shortcomings of the existing technology by providing a method and system for elastic scheduling of high-concurrency business for new retail platforms.

[0007] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0008] A method for elastic scheduling of high-concurrency business on new retail platforms includes the following steps:

[0009] Step S1: For each service instance, calculate the comprehensive load index based on the covariance matrix of its multidimensional operating metrics and the load fluctuation penalty factor.

[0010] Step S2: Input the comprehensive load index sequence into the LSTM neural network to predict the load quantile values ​​for future time steps;

[0011] Step S3: Calculate the scaling urgency based on the quantile prediction value, and determine the final resource adjustment amount by combining it with the historical scaling range;

[0012] Step S4: For each service instance, calculate the final instance weight by combining its current overall load index, remaining resource capacity, future load trend and historical load stability.

[0013] Step S5: Based on the final instance weight, perform real-time request routing on the service instance through the gateway component to complete elastic business scheduling.

[0014] Furthermore, step S1 specifically includes the following steps:

[0015] Step S1.1: Collect CPU utilization, memory utilization, average response time and request throughput metrics of business service instances in real time, and normalize them to form an metric vector;

[0016] Step S1.2: Calculate the covariance matrix of the index vector within the sliding time window, and calculate the dynamic weight vector based on the covariance matrix;

[0017] Step S1.3: Perform a dot product between the dynamic weight vector and the index vector, and add a load fluctuation penalty term calculated based on Mahalanobis distance to obtain the comprehensive load index.

[0018] Furthermore, step S2 specifically includes the following steps:

[0019] Step S2.1: Construct an LSTM neural network based on an encoder-decoder architecture, wherein the encoder contains 3 layers of LSTM units with a hidden state dimension of 128, and the decoder contains 3 layers of LSTM units with a hidden state dimension of 64.

[0020] Step S2.2: Construct an overall loss function to train the LSTM neural network, wherein the overall loss function is constructed by weighted summation of three quantile loss functions, and the three quantiles are 0.1, 0.5 and 0.9 respectively;

[0021] Step S2.3: Input the historical composite load index sequence into the trained LSTM neural network to obtain the load quantile prediction value for the future time step.

[0022] Furthermore, in step S2.2, the specific formula for the quantile loss function is as follows:

[0023]

[0024] in, Represents the overall loss function. Represents the set of target quantiles. Indicates the target quantile. Indicates a point-in-time index. This represents the total length of the time series. This represents the actual load value at time step t. This indicates the predicted value of quantile q corresponding to time point t. This represents the quantile loss function. Indicates the quantile weighting coefficient;

[0025] The formula for calculating the quantile loss function is as follows:

[0026]

[0027] in, Indicates the predicted residual. , Indicates an indicator function, when If the value is less than 0, take 1; otherwise, take 0.

[0028] Furthermore, step S3 specifically includes the following steps:

[0029] Step S3.1: Calculate the scaling urgency based on the relative relationship between the predicted load value and the system safety threshold, and in conjunction with the prediction uncertainty represented by the interval width of the 0.1 quantile and the 0.9 quantile.

[0030] Step S3.2: Transform the stretching tightness using a nonlinear factor, then divide by 1 and add the product of the oscillation suppression coefficient and the absolute amplitude of the previous stretching to obtain the adjustment ratio;

[0031] Step S3.3: Multiply the adjustment ratio by the current number of instances, and round down to obtain the final resource adjustment amount.

[0032] Furthermore, step S4 specifically includes the following steps:

[0033] Step S4.1: Calculate the instance base weight, which is inversely proportional to the instance's current comprehensive load index and directly proportional to the instance's remaining CPU resource capacity;

[0034] Step S4.2: Calculate the trend adjustment factor, which uses the Sigmoid function to transform the difference between the instance's future predicted load and the current load.

[0035] Step S4.3: Calculate the stability factor, which is inversely proportional to the historical load variance of the instance;

[0036] Step S4.4: Multiply the base weight, trend adjustment factor and stability factor to obtain the final instance weight.

[0037] Furthermore, in step S5, the request routing adopts a weighted round-robin algorithm to prioritize routing business requests to service instances with higher weights.

[0038] A high-concurrency business elastic scheduling system for new retail platforms, implemented based on the aforementioned high-concurrency business elastic scheduling method for new retail platforms, includes:

[0039] The monitoring and data collection layer consists of lightweight monitoring agents deployed on various business service instances, used to collect CPU utilization, memory utilization, response time and throughput metrics in real time.

[0040] The distributed caching layer, using a Redis cluster architecture, is used to store real-time load data, session state, and intermediate prediction results, providing high-concurrency read and write support.

[0041] The elastic computing layer, built on the Kubernetes container orchestration platform, is used to provide automatic deployment, horizontal scaling, and resource isolation capabilities for business service instances.

[0042] The intelligent scheduling center includes a load analyzer, an elastic decision-maker, and a weight calculation engine. The load analyzer receives monitoring data and performs comprehensive load index calculation and LSTM quantile regression prediction. The elastic decision-maker calculates scaling urgency and resource adjustment based on the prediction results and generates scaling instructions. The weight calculation engine combines instance status and prediction trends to generate the final instance weights.

[0043] The distributed task scheduling layer, based on the distributed task framework, is responsible for the distributed execution and state synchronization of tasks, ensuring the eventual consistency of scheduling decisions.

[0044] The intelligent gateway layer is used to integrate dynamic weight configuration and execute request routing based on weighted round-robin according to the weight table issued by the scheduling center.

[0045] A storage medium storing instructions that, when read by a computer, cause the computer to execute a high-concurrency business elastic scheduling method for a new retail platform.

[0046] An electronic device includes a processor and the storage medium, the processor executing instructions in the storage medium.

[0047] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0048] 1. This invention uses an LSTM quantile regression model to accurately predict future load trends, enabling the system to expand its resources before traffic peaks arrive, effectively avoiding response delays and service avalanches.

[0049] 2. The active scheduling strategy based on instance weight in this invention comprehensively considers four dimensions: current instance load, remaining resources, future trends, and stability, and prioritizes routing requests to the optimal instance, thereby improving system throughput.

[0050] 3. This invention ensures strong consistency of state data through a Redis cluster and achieves coordinated execution of scheduling decisions by combining a distributed task architecture, enabling the system to maintain millisecond-level response even in scenarios with tens of thousands of concurrent users. Attached Figure Description

[0051] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0052] Figure 1 This is a flowchart illustrating an embodiment of the present invention;

[0053] Figure 2 This is a system schematic diagram according to an embodiment of the present invention;

[0054] Figure 3 This is a distributed task architecture diagram according to an embodiment of the present invention. Detailed Implementation

[0055] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0056] like Figure 1 As shown, the high-concurrency business elastic scheduling method for new retail platforms includes the following steps:

[0057] Step S1: For each service instance, calculate the comprehensive load index based on the covariance matrix of its multidimensional operating metrics and the load fluctuation penalty factor.

[0058] Step S2: Input the comprehensive load index sequence into the LSTM neural network to predict the load quantile values ​​for future time steps;

[0059] Step S3: Calculate the scaling urgency based on the quantile prediction value, and determine the final resource adjustment amount by combining it with the historical scaling range;

[0060] Step S4: For each service instance, calculate the final instance weight by combining its current overall load index, remaining resource capacity, future load trend and historical load stability.

[0061] Step S5: Based on the final instance weight, perform real-time request routing on the service instance through the gateway component to complete elastic business scheduling.

[0062] Step S1 specifically includes the following steps:

[0063] Step S1.1: Collect CPU utilization, memory utilization, average response time and request throughput metrics of business service instances in real time, and normalize them to form an metric vector;

[0064] Step S1.2: Calculate the covariance matrix of the index vector within the sliding time window, and calculate the dynamic weight vector based on the covariance matrix;

[0065] Step S1.3: Perform a dot product between the dynamic weight vector and the index vector, and add a load fluctuation penalty term calculated based on Mahalanobis distance to obtain the comprehensive load index.

[0066] Real-time collection of multi-dimensional operational metrics for each service instance i within a time window, forming a metric vector, calculated using the following formula:

[0067]

[0068] in, Represents an index vector. Indicates CPU utilization. Indicates memory usage. Indicates the average response time. Indicates the requested throughput. Indicates the time window index;

[0069] Process using the min-max normalization method Scaling each indicator to the [0,1] interval yields a normalized indicator vector. ;

[0070] The formula for calculating the dynamic weight vector is:

[0071]

[0072] in, Represents a dynamic weight vector. Represents the initial vector. Represents the covariance matrix among the indicators;

[0073] The formula for calculating the comprehensive load index is:

[0074]

[0075] in, This represents the overall load index of instance i within time window t. This represents the penalty coefficient, which is determined based on experience with the business scenario. For example, 0.3 for flash sales, 0.15 for daily transactions, and the default value is 0.2.

[0076] Step S2 specifically includes the following steps:

[0077] Step S2.1: Construct an LSTM neural network based on an encoder-decoder architecture, wherein the encoder contains 3 layers of LSTM units with a hidden state dimension of 128, and the decoder contains 3 layers of LSTM units with a hidden state dimension of 64.

[0078] Step S2.2: Construct an overall loss function to train the LSTM neural network, wherein the overall loss function is constructed by weighted summation of three quantile loss functions, and the three quantiles are 0.1, 0.5 and 0.9 respectively;

[0079] Step S2.3: Input the historical composite load index sequence into the trained LSTM neural network to obtain the load quantile prediction value for the future time step.

[0080] The network employs an encoder-decoder architecture, with both the encoder and decoder containing three LSTM layers. The hidden state dimension of the encoder LSTM is set to 128, and that of the decoder LSTM is set to 64. The network input is a historical load sequence from the past 60 time points, with each time step interval being 30 seconds. The input dimension is 60×1, expanded to 60×32 after the embedding layer. The last hidden state of the encoder's third LSTM layer is used as a context vector and passed to the decoder. The decoder's initial input is the encoder output, generating prediction sequences for the next 10 time steps in an autoregressive manner. A Dropout layer is introduced before the fully connected output layer, with a dropout rate set to 0.2 to prevent overfitting.

[0081] In step S2.2, the specific formula for the quantile loss function is as follows:

[0082]

[0083] in, Represents the overall loss function. Represents the set of target quantiles. Indicates the target quantile. Indicates the time step index. This represents the total length of the time series. Indicates time step The actual load value, Indicates time step The predicted value corresponding to quantile q, This represents the quantile loss function. Indicates the quantile weighting coefficient;

[0084] Quantile weight Set to: =0.25, =0.5, =0.25, emphasizing the accuracy of median prediction;

[0085] The formula for calculating the quantile loss function is as follows:

[0086]

[0087] in, Indicates the predicted residual. , Indicates an indicator function, when If the value is less than 0, take 1; otherwise, take 0.

[0088] The LSTM neural network ultimately outputs three time series:

[0089]

[0090] in, , and Representing the future The 0.1, 0.5, and 0.9 quantiles of the time-bound load.

[0091] Step S3 specifically includes the following steps:

[0092] Step S3.1: Calculate the scaling urgency based on the relative relationship between the predicted load value and the system safety threshold, and in conjunction with the prediction uncertainty represented by the interval width of the 0.1 quantile and the 0.9 quantile.

[0093] Step S3.2: Transform the stretching tightness using a nonlinear factor, then divide by 1 and add the product of the oscillation suppression coefficient and the absolute amplitude of the previous stretching to obtain the adjustment ratio;

[0094] Step S3.3: Multiply the adjustment ratio by the current number of instances, and round down to obtain the final resource adjustment amount.

[0095] The formula for calculating the tension of the extension is:

[0096]

[0097] in, Indicates the degree of urgency or tightness. This indicates the maximum allowable load threshold. Indicates the system security threshold. This represents the adjustment coefficient, which is usually set to 0.35;

[0098] The formula for calculating the resource adjustment amount is:

[0099]

[0100] in, Indicates the amount of resource adjustment. This represents the floor function. This indicates the number of currently running instances. Indicates the oscillation suppression coefficient. This indicates the absolute magnitude of the previous expansion or contraction. This represents the scaling nonlinearity factor.

[0101] Oscillation suppression coefficient Adjust based on historical scaling frequency: If the scaling operation frequency in the most recent hour is >0.1 times / minute, then Take 0.3; if the frequency of telescoping operations in the past hour is >0.05 times / minute, then Take 0.15; otherwise, Take 0.05.

[0102] Scaling nonlinear factor The settings are based on the characteristics of different business periods: 1.2 for peak business periods and 1.8 for stable business periods.

[0103] Step S4 specifically includes the following steps:

[0104] Step S4.1: Calculate the instance base weight, which is inversely proportional to the instance's current comprehensive load index and directly proportional to the instance's remaining CPU resource capacity;

[0105] Step S4.2: Calculate the trend adjustment factor, which uses the Sigmoid function to transform the difference between the instance's future predicted load and the current load.

[0106] Step S4.3: Calculate the stability factor, which is inversely proportional to the historical load variance of the instance;

[0107] Step S4.4: Multiply the base weight, trend adjustment factor and stability factor to obtain the final instance weight.

[0108] The formula for calculating the instance's basic weight is as follows:

[0109]

[0110] in, Represents the base weight of instance i. This represents the zero constant, typically taking a value of 0.001. This represents the number of CPU cores in instance i. This represents the CPU utilization of instance i within time window t;

[0111] The formula for calculating the trend adjustment factor is as follows:

[0112]

[0113] in, Indicates the trend adjustment factor. This represents the trend sensitivity coefficient, controlling the steepness of the Sigmoid function; it is typically set to 2.0. This represents the predicted median load for instance i in a future time window;

[0114] The formula for calculating the stability factor is:

[0115]

[0116] in, Indicates the stability factor. This represents the stability sensitivity coefficient, which is typically set to 0.5. This represents the load variance of instance i over a recent period.

[0117] The formula for calculating the final instance weight is:

[0118]

[0119] in, This represents the final instance weight of instance i.

[0120] In step S5, the request routing uses a weighted round-robin algorithm to prioritize routing business requests to service instances with higher weights.

[0121] The gateway component receives dynamic weights of each service instance from the scheduling center in real time. For each incoming business request, the gateway selects the target instance based on a weighted round-robin algorithm. This process is real-time and continuous, enabling traffic distribution to respond instantly to changes in the health status of the backend service cluster. This allows for fine-grained traffic management and elastic business scheduling during peak traffic periods, ensuring high availability and high throughput for the overall platform.

[0122] like Figure 2 As shown, the high-concurrency business elastic scheduling system for new retail platforms is implemented based on the aforementioned high-concurrency business elastic scheduling method for new retail platforms, including:

[0123] The monitoring and data collection layer consists of lightweight monitoring agents deployed on various business service instances, used to collect CPU utilization, memory utilization, response time and throughput metrics in real time.

[0124] The distributed caching layer, using a Redis cluster architecture, is used to store real-time load data, session state, and intermediate prediction results, providing high-concurrency read and write support.

[0125] The elastic computing layer, built on the Kubernetes container orchestration platform, is used to provide automatic deployment, horizontal scaling, and resource isolation capabilities for business service instances.

[0126] The intelligent scheduling center includes a load analyzer, an elastic decision-maker, and a weight calculation engine. The load analyzer receives monitoring data and performs comprehensive load index calculation and LSTM quantile regression prediction. The elastic decision-maker calculates scaling urgency and resource adjustment based on the prediction results and generates scaling instructions. The weight calculation engine combines instance status and prediction trends to generate the final instance weights.

[0127] The distributed task scheduling layer, based on the distributed task framework, is responsible for the distributed execution and state synchronization of tasks, ensuring the eventual consistency of scheduling decisions.

[0128] The intelligent gateway layer is used to integrate dynamic weight configuration and execute request routing based on weighted round-robin according to the weight table issued by the scheduling center.

[0129] like Figure 3 As shown, the distributed task framework adopts the XXL-JOB open-source job architecture for secondary development. The main contents of the secondary development include the containerization of the scheduling center and executors. The scheduling center management portal can view the task progress percentage, and the log system is changed to call its own unified log system.

[0130] Scheduling Center: There is only one scheduling center in a task cluster. Scheduling adopts a centralized design. The scheduling center is implemented based on Quartz and supports cluster deployment, ensuring high availability (HA). For the Quartz-based cluster solution, MySQL is used as the database. In the distributed concurrent environment of the cluster, Quartz scheduled tasks are used. Tasks are reported on each node and stored in the database. During execution, triggers are retrieved from the database. If the trigger name and execution time are the same, only one node will execute this task.

[0131] Executor: The program that performs the specific task. Tasks are executed in a distributed manner. Task "executors" support cluster deployment and can guarantee high availability (HA) for task execution.

[0132] The system mainly consists of three parts: a data center, a dispatch center, and actuators.

[0133] The dispatch center is configured as the core control module of the system, and it includes:

[0134] The task management module includes executors, task modes, and the JobHandler submodule, which are used to define the execution strategy and processing logic of tasks.

[0135] The executor management module includes sub-modules for registration method, AppName, and machine address list, which are configured to manage the executor's registration information and network address.

[0136] The scheduler, implemented using the Quartz framework, is configured to generate timed scheduling instructions.

[0137] The executor service communicates with the scheduler and is used to receive and forward scheduling instructions to the scheduling request queue.

[0138] The scheduling request queue is configured to cache scheduling requests to be executed.

[0139] The Rolling Log Real-Time Module connects to the log service and is used to collect system operation logs in real time.

[0140] The log service, with its nested execution log files, is configured to store and manage log data from the execution process.

[0141] The log management module includes view logs, rolling logs, and GLUE version log sub-modules, which are used for categorizing and viewing logs and version control.

[0142] Other modules, including runtime reports, failure alarms, and task dependency sub-modules, are configured to provide system monitoring and exception handling functions;

[0143] Callback service, connected to the callback thread, is used to handle callback notifications after task execution;

[0144] The callback thread communicates with the scheduling result queue and is configured to push the execution result to the queue.

[0145] The scheduling result queue is a white rounded rectangle connected to the task thread and used to cache task execution results.

[0146] The executor is configured as the specific execution unit of the task, and includes:

[0147] The task thread, connected to the scheduling result queue, is used to execute tasks issued by the scheduling center;

[0148] The self-developed RPC module is implemented using the xxl-rpc framework and configured as a remote procedure call interface within the system.

[0149] The data center is configured as the system's data storage and registration center, and includes:

[0150] The registration service connects to the registration thread and is used to handle the executor's registration requests;

[0151] Register the thread, communicate with the self-developed RPC module, and configure it to manage the registration status of the executor.

[0152] The data flow relationships between the components are as follows: Scheduler → Executor Service → Scheduling Request Queue constitutes the scheduling instruction transmission path; Log Service → Execution Log File → JobHandler constitutes the log data storage path; Callback Service → Callback Thread → Scheduling Result Queue → Task Thread constitutes the execution result feedback path.

[0153] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0154] The examples described herein are merely preferred embodiments of the invention and are not intended to limit the concept and scope of the invention. Any modifications and improvements made by those skilled in the art to the technical solutions of the invention without departing from the design concept of the invention should fall within the protection scope of the invention.

Claims

1. A high-concurrency business elastic scheduling method for new retail platforms, characterized in that: Includes the following steps: Step S1: For each service instance, calculate the comprehensive load index based on the covariance matrix of its multidimensional operating metrics and the load fluctuation penalty factor. Step S2: Input the sequence of the comprehensive load index into the LSTM neural network to predict the load quantile values ​​for future time steps; Step S3: Calculate the scaling urgency based on the predicted value of the quantile, and determine the final resource adjustment amount by combining it with the historical scaling range; Step S4: For each service instance, calculate the final instance weight by combining its current overall load index, remaining resource capacity, future load trend and historical load stability. Step S5: Based on the final instance weight, perform real-time request routing on the service instance through the gateway component to complete elastic business scheduling; Specifically, step S3 includes the following steps: Step S3.1: Based on the relative relationship between the predicted load value and the system safety threshold using the 0.9 quantile, and combined with the prediction uncertainty represented by the interval width of the 0.1 and 0.9 quantiles, calculate the scaling urgency. The calculation formula is as follows: in, Indicates the degree of urgency or tightness. This indicates the maximum allowable load threshold. Indicates the system security threshold. This represents the adjustment coefficient. , and Representing the future The 0.1, 0.5, and 0.9 quantiles of the time-bound load; Step S3.2: Transform the stretching tightness using a nonlinear factor, then divide by 1 and add the product of the oscillation suppression coefficient and the absolute amplitude of the previous stretching to obtain the adjustment ratio; Step S3.3: Multiply the adjustment ratio by the current number of instances, and round down to obtain the final resource adjustment amount. The calculation formula is as follows: in, Indicates the amount of resource adjustment. This represents the floor function. This indicates the number of currently running instances. This represents the oscillation suppression coefficient. This indicates the absolute magnitude of the previous expansion or contraction. Indicates the scaling nonlinearity factor; Step S4 specifically includes the following steps: Step S4.1: Calculate the instance's basic weight. The instance's basic weight is inversely proportional to the instance's current comprehensive load index and directly proportional to the instance's remaining CPU resource capacity. The calculation formula is as follows: in, Represents the base weight of instance i. This represents the overall load index of instance i within time window t. Indicates the prevention of zero constant, This represents the number of CPU cores in instance i. This represents the CPU utilization of instance i within time window t; Step S4.2: Calculate the trend adjustment factor. The trend adjustment factor uses the Sigmoid function to transform the difference between the instance's predicted future load and the current load. The calculation formula is as follows: in, Indicates the trend adjustment factor. Indicates the trend sensitivity coefficient. This represents the predicted median load for instance i in a future time window. Step S4.3: Calculate the stability factor, which is inversely proportional to the historical load variance of the instance. The calculation formula is as follows: in, Indicates the stability factor. Indicates the stability sensitivity coefficient. This represents the load variance of instance i over a recent period. Step S4.4: Multiply the base weight, trend adjustment factor and stability factor to obtain the final instance weight.

2. The method according to claim 1, characterized in that, Step S1 specifically includes the following steps: Step S1.1: Collect CPU utilization, memory utilization, average response time and request throughput metrics of business service instances in real time, and normalize them to form an metric vector; Step S1.2: Calculate the covariance matrix of the index vector within the sliding time window, and calculate the dynamic weight vector based on the covariance matrix; Step S1.3: Perform a dot product between the dynamic weight vector and the index vector, and add a load fluctuation penalty term calculated based on Mahalanobis distance to obtain the comprehensive load index.

3. The method according to claim 2, characterized in that, Step S2 specifically includes the following steps: Step S2.1: Construct an LSTM neural network based on an encoder-decoder architecture, wherein the encoder contains 3 layers of LSTM units with a hidden state dimension of 128, and the decoder contains 3 layers of LSTM units with a hidden state dimension of 64. Step S2.2: Construct an overall loss function to train the LSTM neural network, wherein the overall loss function is constructed by weighted summation of three quantile loss functions, and the three quantiles are 0.1, 0.5 and 0.9 respectively; Step S2.3: Input the historical composite load index sequence into the trained LSTM neural network to obtain the load quantile prediction value for the future time step.

4. The method according to claim 3, characterized in that, In step S2.2, the specific formula for the quantile loss function is as follows: in, Represents the overall loss function. Represents the set of target quantiles. Indicates the target quantile. Indicates a point-in-time index. This represents the total length of the time series. This represents the actual load value at time step t. This indicates the predicted value of quantile q corresponding to time point t. This represents the quantile loss function. Indicates the quantile weighting coefficient; The formula for calculating the quantile loss function is as follows: in, Indicates the predicted residual. , Indicates an indicator function, when If the value is less than 0, take 1; otherwise, take 0.

5. The method according to claim 4, characterized in that, In step S5, the request routing uses a weighted round-robin algorithm to prioritize routing business requests to service instances with higher weights.

6. A high-concurrency business elastic scheduling system for new retail platforms, implemented based on the high-concurrency business elastic scheduling method for new retail platforms as described in any one of claims 1-5, characterized in that, include: The monitoring and data collection layer consists of lightweight monitoring agents deployed on various business service instances, used to collect CPU utilization, memory utilization, response time and throughput metrics in real time. The distributed caching layer, using a Redis cluster architecture, is used to store real-time load data, session state, and intermediate prediction results, providing high-concurrency read and write support. The elastic computing layer, built on the Kubernetes container orchestration platform, is used to provide automatic deployment, horizontal scaling, and resource isolation capabilities for business service instances. The intelligent scheduling center includes a load analyzer, an elastic decision-maker, and a weight calculation engine. The load analyzer receives monitoring data and performs comprehensive load index calculation and LSTM quantile regression prediction. The elastic decision-maker calculates scaling urgency and resource adjustment based on the prediction results and generates scaling instructions. The weight calculation engine combines instance status and prediction trends to generate the final instance weights. The distributed task scheduling layer, based on the distributed task framework, is responsible for the distributed execution and state synchronization of tasks, ensuring the eventual consistency of scheduling decisions. The intelligent gateway layer is used to integrate dynamic weight configuration and execute request routing based on weighted round-robin according to the weight table issued by the scheduling center.

7. A storage medium, characterized in that, The storage medium stores instructions, and when the computer reads the instructions, it causes the computer to execute the high-concurrency business elastic scheduling method for the new retail platform as described in any one of claims 1-5.

8. An electronic device, characterized in that, It includes a processor and the storage medium of claim 7, wherein the processor executes instructions in the storage medium.

Images