High-concurrency service flexible scheduling method and system for new retail platform

Abstract

The invention discloses a high-concurrency business flexible scheduling method and system for a new retail platform, and relates to the technical field of communication, and the method comprises the following steps: for each service instance, calculating a comprehensive load index based on a covariance matrix and a load fluctuation penalty factor of a multi-dimensional operation index of the service instance; inputting the comprehensive load index sequence into an LSTM neural network, and predicting to obtain a load quantile value of a future time step length; according to the quantile predicted value, calculating a scaling urgency degree, and determining a final resource adjustment amount in combination with a historical scaling amplitude; for each service instance, synthesizing the current comprehensive load index, the residual resource capacity, the future load trend and the historical load stability of the service instance, and calculating to obtain a final instance weight; and on the basis of the final instance weight, executing real-time request routing on the service instance through a gateway component to complete service flexible scheduling. According to the invention, through intelligent elastic scheduling, stable support for new retail high-concurrency business is realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication, in particular to a high-concurrency business elastic scheduling method and system for a new retail platform. BACKGROUND

[0002] With the rapid development of Internet technology, new retail platforms have become an important part of modern business systems. During large-scale promotional activities such as 618 and Double Eleven, these platforms face unprecedented high-concurrency access pressure. Marketing methods such as flash sales and time-limited purchases can cause instantaneous traffic surges, and order volume can grow by tens of times in a short period of time, posing a serious challenge to the stability and response capability of the backend service cluster. Currently, the industry generally uses elastic scheduling solutions based on cloud computing and microservices architecture to cope with traffic fluctuations. These solutions usually monitor system resource indicators to automatically scale resources.

[0003] However, existing elastic scheduling methods still have shortcomings when dealing with business scenarios specific to new retail platforms. First, traditional methods mostly use a passive response mode, which can only trigger scaling operations when system load reaches a threshold, resulting in a response delay when facing sudden traffic, which may cause service avalanches. Second, scaling decisions based on a single indicator often lack accuracy, easily causing frequent oscillation of resources, affecting system stability and increasing operating costs. Third, existing load balancing strategies usually only consider the current load state of instances, ignoring future changes in load trends, which may distribute traffic to instances that will soon be overloaded. Finally, most systems lack a deep understanding of business characteristics, making it difficult to distinguish the priority of different types of requests and guarantee the quality of service for core transaction links.

[0004] A traffic control method and system for high-concurrency multi-center business middle platform are disclosed in Chinese Patent No. CN117478600A, which includes: obtaining business frequency upper and lower limit values, current pre-allocable reference number, and business maximum available frequency, time node corresponding to pre-allocated unused frequency, and time node corresponding to unallocated frequency; calculating the average unused frequency corresponding to the time node based on the time node, the pre-allocated unused frequency, and the unallocated frequency; calculating the available frequency in the current period and the current pre-allocable frequency based on the business maximum available frequency, the average unused frequency, and the cpu usage, memory usage, and io usage, to complete traffic control. This invention can effectively limit the number and frequency of concurrent requests, avoid system overload and collapse, and reasonably allocate and schedule traffic to enable the system to handle business requests smoothly, improving response speed and performance stability.

[0005] A scheduling method, device and system for service data are disclosed in Chinese Patent Publication No. CN104639461A. For each node on the tree structure based on which the scheduler is, the number of bytes of actual request scheduling corresponding to each priority of the node is reported to the parent node of the node. The number of bytes of actual request scheduling corresponding to each priority reported by all child nodes of the root node is obtained, and the number of bytes of actual scheduling corresponding to each priority of the root node is calculated according to a preset maximum concurrent scheduling byte number. According to the scheduling candidate byte number corresponding to each priority of each node, and the scheduled byte number and actual scheduling byte number corresponding to each priority of the parent node of the node, the actual scheduling byte number corresponding to each priority of the node is obtained by using a preset scheduling rule. The embodiment of the application provides a parallel scheduling method for service data, which can realize parallel scheduling of multiple nodes in each scheduling process, and improves the scheduling efficiency of service data. SUMMARY

[0006] The technical problem to be solved by the application is to provide a high-concurrency service elastic scheduling method and system for a new retail platform to solve the problems of the prior art.

[0007] To achieve the above object, the technical scheme adopted by the application is as follows:

[0008] The high-concurrency service elastic scheduling method for the new retail platform comprises the following steps:

[0009] Step S1, for each service instance, based on the covariance matrix of its multi-dimensional running index and the load fluctuation penalty factor, a comprehensive load index is calculated;

[0010] Step S2, the sequence of the comprehensive load index is input into an LSTM neural network, and a load quantile value at a future time step is predicted;

[0011] Step S3, the scaling urgency is calculated according to the quantile prediction value, and the final resource adjustment amount is determined in combination with the historical scaling amplitude;

[0012] Step S4, for each service instance, the final instance weight is calculated by comprehensively considering its current comprehensive load index, remaining resource capacity, future load trend and historical load stability;

[0013] Step S5, based on the final instance weight, the real-time request routing of the service instance is performed through the gateway component, and the service elastic scheduling is completed.

[0014] Further, the step S1 specifically comprises the following steps:

[0015] Step S1.1, real-time collection of CPU usage, memory usage, average response time and request throughput rate indicators of the service instance, and normalization processing to form an indicator vector;

[0016] Step S1.2, calculating the covariance matrix of the indicator vector in the sliding time window, and calculating the dynamic weight vector according to the covariance matrix;

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

[0018] Further, the step S2 specifically comprises the following steps:

[0019] Step S2.1, constructing 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, constructing a total loss function to train the LSTM neural network, wherein the total loss function is composed of three quantile loss functions by weighted summation, and the three quantiles are 0.1, 0.5 and 0.9 respectively;

[0021] Step S2.3, inputting the historical comprehensive load index sequence into the trained LSTM neural network to obtain the load quantile prediction value of the future time step.

[0022] Further, in the step S2.2, the specific formula of the quantile loss function is:

[0023]

[0024] Wherein, denotes the total loss function, denotes the target quantile set, denotes the target quantile, denotes the time point index, denotes the total length of the time series, denotes the true load value of time step t, denotes the predicted value of time point t corresponding to quantile q, denotes the quantile loss function, denotes the quantile weight coefficient;

[0025] Wherein, the calculation formula of the quantile loss function is:

[0026]

[0027] wherein, represents a prediction residual, , represents an indicator function, which takes 1 when 1 otherwise.

[0028] Further, the step S3 specifically comprises the following steps:

[0029] Step S3.1, based on the relative relationship between the 0.9 quantile predicted load value and the system safety threshold, and combined with the prediction uncertainty represented by the interval width between the 0.1 quantile and the 0.9 quantile, the scaling urgency is calculated;

[0030] Step S3.2, the scaling urgency is transformed by a nonlinear factor, and then divided by 1 plus the product of the oscillation suppression coefficient and the last scaling absolute amplitude, to obtain the adjustment ratio;

[0031] Step S3.3, the adjustment ratio is multiplied by the current instance number, and after rounding, the final resource adjustment amount is obtained.

[0032] Further, the step S4 specifically comprises the following steps:

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

[0034] Step S4.2, the trend adjustment factor is calculated, which uses the Sigmoid function to transform the difference between the instance future predicted load and the current load;

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

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

[0037] Further, in the step S5, the request routing adopts a weighted round robin algorithm to preferentially route service requests to service instances with higher weights.

[0038] The high-concurrency business elastic scheduling system for the new retail platform is realized based on the high-concurrency business elastic scheduling method for the new retail platform, comprising:

[0039] The monitoring collection layer is composed of lightweight monitoring agents deployed in each business service instance, and is used to collect CPU usage, memory usage, response time and throughput rate indicators in real time;

[0040] A distributed cache layer using a Redis cluster architecture is used to store real-time load data, session states and prediction intermediate results, and provides high-concurrency read-write support.

[0041] An elastic computing layer is constructed based on a Kubernetes container orchestration platform, and is used to provide automatic deployment, horizontal expansion and resource isolation capabilities of business service instances.

[0042] An intelligent scheduling center includes a load analyzer, an elastic decision maker and a weight calculation engine, wherein the load analyzer is used to receive monitoring data, perform comprehensive load index calculation and LSTM quantile regression prediction; the elastic decision maker is used to calculate the stretching urgency and resource adjustment amount according to the prediction result, and generate expansion and contraction instructions; and the weight calculation engine is used to generate the final instance weight by comprehensively considering the instance state and the prediction trend.

[0043] A distributed task scheduling layer based on a distributed task framework is used to be responsible for distributed execution and state synchronization of tasks, and to ensure the eventual consistency of scheduling decisions.

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

[0045] A storage medium has instructions stored therein, and when a computer reads the instructions, the computer executes a high-concurrency business elastic scheduling method for a new retail platform.

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

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

[0048] 1、The present application accurately predicts future load trends through an LSTM quantile regression model, so that the system can complete resource expansion before the traffic flood arrives, effectively avoiding response delay and service avalanche.

[0049] 2、The present application considers four dimensions of current instance load, remaining resources, future trends and stability based on an active scheduling strategy of instance weight, and routes requests to the optimal instance first, so as to improve the system throughput.

[0050] 3、The present application ensures the strong consistency of state data through a Redis cluster, and realizes collaborative execution of scheduling decisions in combination with a distributed task architecture, so that the system still maintains millisecond-level response in a ten-thousand-level concurrency scenario. BRIEF DESCRIPTION OF DRAWINGS

[0051] Other features, objects, and advantages of the application will become more apparent from the following detailed description of non-limiting embodiments thereof, when read in conjunction with the accompanying drawings:

[0052] Figure 1 Flowchart of an embodiment of the application;

[0053] Figure 2 System diagram of an embodiment of the application;

[0054] Figure 3 Distributed task architecture diagram of an embodiment of the application. DETAILED DESCRIPTION

[0055] In order to make the purposes, technical solutions and advantages of the application more clear, the application is described in detail below in conjunction with the drawings and specific embodiments.

[0056] As shown in the figure, the high-concurrency business elastic scheduling method for a new retail platform comprises the following steps: Figure 1

[0057] Step S1, for each service instance, based on the covariance matrix of its multi-dimensional running index and the load fluctuation penalty factor, calculate the comprehensive load index;

[0058] Step S2, input the comprehensive load index sequence into the LSTM neural network to predict the load quantile value at the future time step;

[0059] Step S3, calculate the stretching urgency according to the quantile prediction value, and determine the final resource adjustment amount in combination with the historical stretching amplitude;

[0060] Step S4, for each service instance, calculate the final instance weight based on its current comprehensive 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 the business elastic scheduling.

[0062] The step S1 specifically comprises the following steps:

[0063] Step S1.1, real-time collect the CPU usage, memory usage, average response time and request throughput rate indicators of the business service instance, and perform normalization processing to form an indicator vector;

[0064] Step S1.2, calculate the covariance matrix of the indicator vector within the sliding time window, and calculate a dynamic weight vector according to the covariance matrix;

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

[0066] Real-time collection of multi-dimensional running indexes of each service instance i in a time window forms an index vector, and the calculation formula is:

[0067]

[0068] Among them, represents the index vector, represents the CPU usage, represents the memory usage, represents the average response time, represents the request throughput rate, represents the time window index;

[0069] Using the min-max normalization method to process , each index is scaled to the interval [0, 1] to obtain the normalized index vector ;

[0070] The calculation formula of the dynamic weight vector is:

[0071]

[0072] Among them, represents the dynamic weight vector, represents the initial vector, represents the covariance matrix between indexes;

[0073] The calculation formula of the comprehensive load index is:

[0074]

[0075] Among them, represents the comprehensive load index of instance i in time window t, represents the penalty coefficient, which is valued according to the experience of business scenarios, for example: 0.3 for a seconds killing scenario, 0.15 for daily transactions, and 0.2 for the default value.

[0076] The step S2 specifically comprises the following steps:

[0077] Step S2.1, constructing 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. This represents 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 comprehensive load index sequence into the LSTM neural network to predict the load quantile values ​​for future time steps; 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; 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.

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, Step S3 specifically includes the following steps: 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. 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.

6. The method according to claim 5, characterized in that, Step S4 specifically includes the following steps: 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; 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. Step S4.3: Calculate the stability factor, which is inversely proportional to the historical load variance of the instance; Step S4.4: Multiply the base weight, trend adjustment factor and stability factor to obtain the final instance weight.

7. The method according to claim 6, 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.

8. 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-7, 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.

9. 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-7.

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

Images