Http request task queue concurrent processing method based on UE engine

Abstract

The invention provides an http request task queue concurrent processing method based on a UE engine, and relates to the technical field of network communication methods, and the method comprises the steps of request receiving, data acquisition, model construction, load prediction, request enqueue, task scheduling, task distribution, request response and the like. According to the method, the system load change can be accurately predicted, so that the processing of the request can be dynamically adjusted according to the actual state of the system load, and the instability caused by static scheduling in a traditional method is reduced.

Description

Technical Field

[0001] The present application relates to the technical field of network communication methods, and in particular to a concurrent processing method for http request task queues based on a UE engine. Background Art

[0002] Unreal Engine (UE) is a highly optimized game engine that is widely used in game development, virtual reality, augmented reality and other fields. The UE engine is characterized by extremely high requirements for real-time and high concurrency. In the UE engine, HTTP requests are usually used for communication between clients and servers to process in-game data, user requests, real-time updates, etc. The request task queue concurrent processing mechanism in the UE engine, especially in real-time applications such as multiplayer online games, faces the challenge of a large number of concurrent requests.

[0003] The Chinese invention patent with application publication date of October 12, 2020 and publication number CN112346834A provides a database request processing method and device, electronic device and medium. The patent receives an operation request from a client, and determines the priority of the operation request according to preset rules based on the operation request and the submission mode of the transaction to which the operation request belongs; according to the priority of the operation request, adds the operation request to the task queue of the corresponding priority of the thread pool; and according to the priority of the task queue, obtains the task from the task queue for processing.

[0004] In view of the above technical solution, it is proposed to set the request priority according to the preset rules to deal with the thread situation that may occur in high-concurrency scenarios. However, the high-concurrency requests in the UE engine are dynamic and complex. Unlike the fixed mode of database requests, in scenarios such as multiplayer online games and real-time applications, HTTP requests have very strong real-time requirements, and the frequency and distribution of requests are very uneven. With the sharp increase in the number of requests, the system may be overloaded instantly, affecting the system performance and response time. Summary of the invention

[0005] In order to cope with the dynamics and complexity of high concurrent requests in the UE engine and improve the performance and response time of the system, the present application provides a concurrent processing method for http request task queue based on the UE engine.

[0006] In the first aspect, the present application provides a method for concurrently processing an http request task queue based on a UE engine, which adopts the following technical solution: A method for concurrently processing an http request task queue based on a UE engine comprises the following steps: Request reception: receiving a request sent by a user requester of the UE engine, and setting a request priority according to the request time; the request includes request content, request load, request source and request time; Data collection: including collecting real-time operation data and collecting historical operation data; Collect real-time operation data: Collect real-time operation data, which includes user behavior data and game event data corresponding to the request; Collect historical operation data: Collect historical operation data, including historical requests, historical system resource data, historical user behavior data, and historical game event data; Model building: Build a load prediction model based on deep learning algorithms; Load prediction: Use real-time operation data and requests sent by user requesters as inputs to the load prediction model, and output load prediction data; Request queuing: Classify the received requests according to their priorities and send the classified requests to the corresponding request priority task queue; Task scheduling: Sort requests in each task queue based on load forecast data; Task distribution: Distribute tasks in order according to the sorting results, and assign corresponding processing nodes to the requests for processing according to the load of each request and the load of the processing node; Request response: After the request is processed, a request response is sent to the user requester.

[0007] By adopting the above technical solution and using deep learning algorithm to build a load prediction model, it is possible to accurately predict the load changes in different time periods and request types, so that the processing of requests can be dynamically adjusted according to the actual status of system resources, thereby reducing the instability caused by static scheduling in traditional methods. In addition, by classifying the priority of requests, reasonable scheduling can be performed according to the urgency and importance of the requests, so that high-priority requests can be processed in a timely manner, improving the service quality and user experience of the system. At the same time, the task distribution and scheduling links can intelligently allocate requests to appropriate processing nodes and thread pools according to the load prediction results and the priority of the requests, reducing the overload of some resources in the system, while ensuring load balancing and improving the stability and resource utilization of the system. Moreover, by dynamically adjusting the allocation of task queues and processing nodes, the system can better adapt to user request volume and load fluctuations, reduce the risk of system crashes and overloads, and enhance the fault tolerance and stability of the system.

[0008] Optionally, after executing the step of building the model and before executing the step of load prediction, the method further includes: First data processing: Time-aligning historical user behavior data, historical requests, historical system resource data, and historical game event data, obtaining the generation time of each historical game event data, recording the historical user behavior data and historical requests before the generation time of each historical game event data as first data, and recording the historical user behavior data and historical requests after the generation time of each historical game event data as second data; Second data processing: compare the first data with the second data of each time period in chronological order, record it as the first difference, obtain the time corresponding to the second data when the first difference is less than the preset difference threshold, record it as the end time of the historical game event data, calculate the duration from the generation time to the end time of each historical game event data, record it as the activity duration of the historical game event data; The third data processing: clustering the activity duration of the historical game event data using a clustering algorithm, taking the clustering result as the classification result of the historical game event data, and taking the activity duration of each type of historical game event data as the lag time window of the historical game event data of that type; Fourth data processing: according to the lag time window of each historical game event data, marking the historical user behavior data, historical request and historical system resource data corresponding to the lag time window of the historical game event data with the lag time mark of the historical game event, and using the marked historical user behavior data, historical request and historical system resource data as new historical user behavior data, new historical request and new historical system resource data; Build sample training sets: Build load sample training sets based on historical user behavior data, historical requests, historical system resource data, and historical game events; Iterative optimization: Define the mean square error loss function, use the load sample training set as the input of the load prediction model, perform model inference, iteratively optimize the load prediction model by minimizing the mean square error loss function, and use the optimized load prediction model as the new load prediction model.

[0009] By adopting the above technical solution, calculating the activity duration of historical game events and analyzing the lag time window of historical game events through clustering algorithm, the dynamic change characteristics of game events can be better identified. The lag time window can be used to capture the dynamic changes in the number of requests, helping the load prediction model to understand the lag effect of each game event on the system load, thereby taking into account the real-time and dynamic fluctuations of the system load when predicting the load, thereby improving the prediction accuracy of the load prediction model in a dynamic high-concurrency environment.

[0010] Optionally, after performing the iterative optimization step and before performing the load prediction step, the method further includes: Fifth data processing: determine whether game event data exists in the real-time running data: If so, the game event data is classified according to the classification result of the historical game event data, and the lag time window of the game event data is obtained according to the classification result of the game event data. The user behavior data in the real-time operation data and the request sent by the user requester are marked with the lag time mark of the game event data according to the lag time window of the game event data, and the marked user behavior data and request are used as new user behavior data and new request to perform the load prediction step; If not, no processing is performed and the load prediction step is executed.

[0011] By adopting the above technical solution, it is determined whether there is game event data in the real-time operation data, the current real-time data is classified and processed according to the classification results of the historical game event data, and the real-time data is marked with a lag time mark according to the classification results. This helps the load prediction model to dynamically adjust the response time and load prediction for real-time requests according to the historical characteristics of the current game event, reducing the error caused by the load prediction model not considering the lag effect. When facing actual application scenarios, the load prediction model can not only utilize the regularity of historical data, but also track and adapt to load changes in real time, further improving the accuracy and reliability of the load prediction model.

[0012] Optionally, after executing the step of load prediction and before executing the step of enqueuing the request, the method further includes: Feature extraction: extracting features from the request, and recording the extracted features as first features, wherein the first features include request source, request content, and request time; Get historical data: Get historical requests and corresponding priority tags; Model construction: Build a request classification model based on deep learning algorithms; Second training: Build a priority sample training set based on historical requests and corresponding priority labels, input the priority samples into the request classification model for model inference, define the priority loss function, iteratively optimize the request classification model by minimizing the priority loss function, and use the optimized request classification model as the new request classification model; Request classification: The first feature is used as the input of the request classification model, the priority label of the request is output, and the obtained priority label is used as the new priority of the request.

[0013] By adopting the above technical solution, feature extraction is performed on each request and a request classification model is constructed based on a deep learning algorithm, which helps to more accurately determine the priority of each request. At the same time, the urgency and importance of the request are reflected through the request priority label, so that high-priority requests are given priority and important requests are less likely to be delayed. In addition, marking the priority of the request can ensure that requests of different categories are reasonably assigned to the appropriate task queue according to their priority, further optimizing the system's load scheduling and reducing the bottleneck caused by excessive load or long request queuing time.

[0014] Optionally, after executing the step of load prediction and before executing the step of enqueuing the request, the method further includes: Request quantity judgment: within the preset waiting time, judge whether the request quantity is 1: If so, execute the step of requesting to enqueue; If not, then the step of parameter feature extraction is performed; Parameter feature extraction: Extract request parameter features based on the user behavior data and request content corresponding to the request. Request parameter features include user behavior data, request source, and request content. Request similarity judgment: Use the fuzzy matching algorithm to calculate the similarity between the request parameter features of each request, record it as the first similarity, and judge whether the first similarity is greater than the preset similarity threshold: If yes, the two requests of the first similarity are merged, the merged request is sent to the temporary queue, and the task scheduling step is performed; If not, execute the step of requesting to enqueue.

[0015] By adopting the above technical solution, a fuzzy matching algorithm is used to calculate the similarity between requests, and requests with high similarity are merged for processing, which reduces the redundant calculation and resource occupation of the system when processing multiple similar requests, improves the system's throughput and response speed, and helps optimize system performance. In addition, by merging similar requests, it helps to reduce the length of the request queue and reduce the problem of excessive load caused by repeated requests.

[0016] Optionally, after executing the step of requesting similarity determination and before executing the step of task scheduling, the method further includes: Waiting for merging: After sending the merged request to the temporary queue, within the preset waiting time, determine whether there is a request whose first similarity with the above two requests is greater than the preset similarity threshold: If yes, the request is sent to a temporary queue and merged with the above merged request, and then the task scheduling step is performed; If not, execute the task scheduling steps.

[0017] By adopting the above technical solution, we continue to monitor whether there are new requests similar to the merged requests within the specified time, and process the monitored similar requests together with the merged requests, which helps to reduce the processing of duplicate requests, while reducing redundant calculations, optimizing the use of system resources, and improving task processing efficiency. If there are no more similar requests within the specified time, the task scheduling stage is directly entered to avoid unnecessary waiting and delays. In addition, the request merging strategy is flexibly adjusted according to the time setting, which can not only maximize the benefits of request merging, but also enter the task scheduling stage as soon as possible when the high-priority task queue needs a quick response.

[0018] Optionally, after executing the step of load prediction and before executing the step of enqueuing the request, the method further includes: First load judgment: judging whether the load prediction data is lower than a preset load threshold; If so, a token bucket algorithm is used to generate tokens at a first preset rate, and a flow rate of the task queue processing request is set; If not, the leaky bucket algorithm is used to set the flow of the task queue processing request at a second preset rate.

[0019] By adopting the above technical solution, the current system load is judged based on the load prediction data, so that the system can select the appropriate flow control strategy according to the load level. When the load is low, the token bucket algorithm is used to make request processing more flexible and efficient, which helps to improve the system's throughput and enables the system to process more requests when the load is low. When the system load is high, the leaky bucket algorithm is used to control the flow at a constant rate, which helps to keep the system load within the preset processing capacity range, reduces the situation where too many requests in a short period of time cause system overload, and improves the stability and reliability of the system.

[0020] In summary, the present application includes at least one of the following beneficial technical effects: 1. Using deep learning algorithms to build a load prediction model can accurately predict load changes in different time periods and request types, so that the processing of requests can be dynamically adjusted according to the actual status of system resources, thereby reducing the instability caused by static scheduling in traditional methods. In addition, by classifying the priority of requests, reasonable scheduling can be performed according to the urgency and importance of the requests, so that high-priority requests can be processed in a timely manner, improving the system's service quality and user experience. At the same time, the task distribution and scheduling links can intelligently allocate requests to appropriate processing nodes and thread pools based on the load prediction results and the priority of the requests, reducing the overload of some resources in the system, while ensuring load balancing and improving the stability and resource utilization of the system. Moreover, by dynamically adjusting the allocation of task queues and processing nodes, the system can better adapt to user request volume and load fluctuations, reduce the risk of system crashes and overloads, and enhance the system's fault tolerance and stability.

[0021] 2. Calculate the activity duration of historical game events and analyze the lag time window of historical game events through clustering algorithms, which can better identify the dynamic change characteristics of game events. The lag time window can capture the dynamic changes in the number of requests, helping the load prediction model understand the lag effect of each game event on the system load, thereby taking into account the real-time and dynamic fluctuations of the system load when predicting the load, improving the prediction accuracy of the load prediction model in a dynamic high-concurrency environment.

[0022] 3. Use fuzzy matching algorithm to calculate the similarity between requests, merge requests with high similarity, reduce redundant calculation and resource usage when processing multiple similar requests, improve system throughput and response speed, and help optimize system performance. In addition, by merging similar requests, it helps to reduce the length of the request queue and reduce the problem of excessive load caused by repeated requests. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 is a flow chart of Example 1 of the present application; Figure 2 This is a flowchart of the first training in S4 of Example 1 of the present application; Figure 3 This is a flowchart of the first classification of S53 of Example 1 of the present application; Figure 4 This is a flowchart of S54 request merging in Example 1 of the present application. DETAILED DESCRIPTION

[0024] The following combination Figures 1 to 4 This application is described in further detail.

[0025] Embodiment 1: This embodiment discloses a concurrent processing method of http request task queue based on UE engine, such as Figure 1 As shown, the method includes: receiving a request sent by a user requester of a UE engine, setting a request priority according to a request time, collecting real-time operation data and collecting historical operation data, building a load prediction model based on a deep learning algorithm, using the real-time operation data and the request sent by the user requester as inputs of the load prediction model, outputting load prediction data, classifying the received requests according to their priorities, sending the classified requests to a task queue of a corresponding request priority, sorting the requests in each task queue based on the load prediction data, distributing the tasks in sequence according to the sorting results, assigning the thread pool of the corresponding processing node to the request for processing, and sending a request response to the user requester after the request processing is completed. This embodiment includes the following steps: S1 Request reception: Receive the request sent by the user requester of the UE engine and set the request priority according to the request time. The request includes request content, request load, request source and request time.

[0026] An HTTP server is set in the UE engine, requests sent by user requesters are received through the HTTP server, and request priorities are set according to the order of request time.

[0027] The request includes the request content, request load, request source and request time. The request content refers to the requested resources, functions or behavior requirements requested by the user. For example, in a game, it may be a data resource or operation request (such as entering a game, loading a scene, submitting an operation, etc.) requested by the user. The request load refers to the system resources such as computing, storage or bandwidth required by the request. The request source includes the user's IP address, device type and account information, etc. The request time is the actual timestamp when the request is issued.

[0028] S2 data collection: includes S21 collection of real-time operation data and S22 collection of historical operation data.

[0029] S21 collects real-time operation data: collects real-time operation data, which includes user behavior data and game event data corresponding to the request. User behavior data includes user operation data, behavior patterns, or game scenes, etc. Game event data includes game version update event data, game activity data, and game server update and maintenance data. Game activity data includes game special events and game promotions.

[0030] In this embodiment, the collection time of the real-time operation data is consistent with the request time.

[0031] S12 collects historical operation data: collects historical operation data, which includes historical requests, historical system resource data, historical user behavior data, and historical game event data.

[0032] Historical requests include historical request content, historical request load, historical request source and historical request time. Historical system resource data is historical system load. Historical user behavior data includes historical operation data, historical behavior patterns or historical game scenes of users. Historical game event data includes historical game version update event data, historical game activity data and historical game server update and maintenance data. Historical game activity data includes historical game special events and historical game promotion activities. The historical user behavior data corresponds to historical requests.

[0033] In this embodiment, after the real-time operation data and historical operation data are collected, the data needs to be preprocessed. The data preprocessing steps include data cleaning and data normalization.

[0034] Data cleaning: De-noising, processing of missing values, and removal of outliers are performed on the collected real-time operation data and historical operation data.

[0035] Data normalization: Normalize the collected real-time operation data and historical operation data.

[0036] S3 builds the model: Based on the deep learning algorithm, the long short-term memory network model is used as the basic model to build a load prediction model.

[0037] S4 first training: including S41 first data processing, S42 second data processing, S43 third data processing, S44 fourth data processing, S45 building a sample training set and S46 iterative optimization, such as Figure 2 shown.

[0038] S41 first data processing: time-align historical user behavior data, historical requests, historical system resource data and historical game event data, obtain the generation time of each historical game event data, record the historical user behavior data and historical requests before the generation time of each historical game event data as the first data, and record the historical user behavior data and historical requests after the generation time of each historical game event data as the second data.

[0039] S42 second data processing: compare the first data with the second data of each time period in chronological order, record it as the first difference, obtain the time corresponding to the second data when the first difference is less than the preset difference threshold, record it as the end time of the historical game event data, calculate the duration from the generation time to the end time of each historical game event data, and record it as the activity duration of the historical game event data.

[0040] S43 The third data processing: Use a clustering algorithm to cluster the activity duration of the historical game event data, use the clustering result as the classification result of the historical game event data, and use the activity duration of each type of historical game event data as the lag time window of this type of historical game event data.

[0041] In this embodiment, clustering algorithms such as the K-Means clustering algorithm can be used for clustering, or the activity duration of each historical game event data can be directly used as a classification standard to group historical game event data with the same activity duration, and the activity duration of each type of historical game event data can be used as the lag time window of that type of historical game event data.

[0042] S44 Fourth data processing: According to the lag time window of each historical game event data, the historical user behavior data, historical request and historical system resource data corresponding to the lag time window of the historical game event data are marked with the lag time mark of the historical game event, and the marked historical user behavior data, historical request and historical system resource data are used as new historical user behavior data, new historical request and new historical system resource data.

[0043] S45 builds a sample training set: builds a load sample training set based on historical user behavior data, historical requests, historical system resource data, and historical game events.

[0044] S46 iterative optimization: use the load sample training set as the input of the load prediction model, perform model inference, define the mean square error loss function, calculate the loss value of the load prediction model, use the back propagation algorithm to calculate the model parameter gradient of the load prediction model, and use the gradient descent method to update the model parameters of the load prediction model until the preset number of iterative training times is completed or the calculated loss value of the load prediction model no longer decreases. The model training is completed and the optimized load prediction model is obtained. The optimized load prediction model is used as the new load prediction model.

[0045] The mean square error loss function formula is: .

[0046] in, represents the mean square error loss function of the load forecasting model, represents the number of samples in the load sample training set, Indicates The actual system load of samples, The model predicts the Load forecast data for samples.

[0047] S5 load prediction: includes S51 fifth data processing and S52 load prediction.

[0048] S51 Fifth data processing: determining whether game event data exists in the real-time operation data.

[0049] If so, the game event data is classified according to the classification results of the historical game event data, and the lag time window of the game event data is obtained according to the classification results of the game event data. The user behavior data in the real-time operation data and the request sent by the user requester are marked with the lag time mark of the game event data according to the lag time window of the game event data, and the marked user behavior data and request are used as new user behavior data and new request, and S52 predicts the load.

[0050] If not, no processing is performed and S52 is executed to predict the load.

[0051] S52 predicts load: uses real-time operation data and the request sent by the user requester as inputs of the load prediction model, and outputs load prediction data.

[0052] S6 Request Enqueue: Classify the received requests according to their priorities and send the classified requests to the task queue of the corresponding request priority.

[0053] Requests are classified according to their priority, and requests of the same priority are grouped together. Then, requests in each group of requests are assigned to the task queues of the corresponding request priority in the order of the request time.

[0054] S7 task scheduling: Sorts requests in each task queue based on load forecast data.

[0055] Determine whether the load prediction data is higher than the preset load threshold. If so, reorder the requests in each task queue in ascending order based on the request load of each request. If not, do not process it.

[0056] S8 Task distribution: Distribute tasks in sequence according to the sorting results, and assign corresponding processing nodes to requests for request processing according to the load of each request and the load of the processing node, including S81 first judgment, S82 second judgment, S83 third judgment, S84 first allocation and S85 second allocation.

[0057] S81 first judgment: judge whether the load prediction data is higher than the preset load threshold, if so, execute S82 second judgment; if not, execute S85 second allocation.

[0058] S82 second judgment: obtain the load data of each processing node, and judge whether the load data of each processing node is higher than the preset node load threshold. If so, execute S83 third judgment; if not, execute S84 first allocation.

[0059] S83 third judgment: judge whether the number of threads in the thread pool of the current processing node reaches the maximum number of threads. If so, execute S84 first allocation; if not, increase the number of threads in the thread pool of the processing node, and then execute S84 first allocation.

[0060] S84 first allocation: based on the load data of each processing node, sort them in ascending order, and according to the sorting results of the processing nodes, prioritize the allocation of requests to the high-priority task queue, and delay the processing of the medium-priority task queue and the low-priority task queue until the request allocation of the high-priority task queue is completed or the load forecast data is lower than the preset load threshold.

[0061] If the medium priority task queue or the low priority task queue does not perform a processing node allocation operation within the preset delay time, the request in the medium priority task queue or the low priority task queue is adjusted to the high priority task queue for processing node allocation operation.

[0062] S85 Second allocation: Based on the load data of each processing node, a weighted round-robin algorithm is used to allocate a processing node to the request of each task queue.

[0063] S9 Request Response: After the request is processed, a request response is sent to the user requester.

[0064] After the request processing is completed, the corresponding request response is generated. The request response includes the result of the request, the processing status (such as success or failure) or error information, etc. The request response is packaged and sent to the user requester through the HTTP protocol, and the request response status is recorded at the same time.

[0065] Example 1. In a multiplayer online game based on the UE engine, the game client and the backend server communicate via HTTP requests. The game server uses the HTTP request task queue concurrent processing method described in the above embodiment to process the requests initiated by 5 players (such as entering the battlefield, loading the map, performing combat operations, etc.).

[0066] 1. Receive player requests Player A's request (request to enter the battlefield): Request content: Request to enter the battlefield and load the battle scene.

[0067] Request load: High load (computation load 5000ms, storage load 200MB, bandwidth load 1000KB / s).

[0068] Request source: Player A’s IP address is 192.168.1.101, the device is a personal computer, and the account information is userA_001.

[0069] Request time: 12:00:00.

[0070] Player B's request (request to enter the battlefield): Request content: Request to enter the battlefield and load the battle scene.

[0071] Request load: High load (computation load 5000ms, storage load 200MB, bandwidth load 1000KB / s).

[0072] Request source: Player B’s IP address is 192.168.1.102, the device is a personal computer, and the account information is userB_042.

[0073] Request time: 12:00:01.

[0074] Player C's request (request to load the store): Request content: Request to load the mall page and view virtual items.

[0075] Request load: Medium load (computation load 500ms, storage load 50MB, bandwidth load 200KB / s).

[0076] Request source: Player C’s IP address is 192.168.1.105, the device is a personal computer, and the account information is userC_302.

[0077] Request time: 12:00:02.

[0078] Player D's request (request to view battle log): Request Content: Request to view personal combat history.

[0079] Request load: Low load (computation load 100ms, storage load 10MB, bandwidth load 50KB / s).

[0080] Request source: Player D’s IP address is 192.168.1.107, the device is a personal computer, and the account information is userD_215.

[0081] Request time: 12:00:03.

[0082] Player E's request (request for character upgrade): Request content: Request to upgrade the character and submit the operation.

[0083] Request load: low load high load (computation load 200ms, storage load 20MB, bandwidth load 100KB / s).

[0084] Request source: Player E’s IP address is 192.168.1.110, the device is a mobile phone, and the account information is userE_511.

[0085] Request time: 12:00:04.

[0086] After receiving 5 requests, the system sets a priority for each request based on the request time. The priority from high to low is player A's request, player B's request, player C's request, player D's request and player E's request. Player A's request and player B's request are high priority, player C's request and player D's request are medium priority, and player E's request is low priority.

[0087] 2. Collect player behavior data and game event data Player A's behavior data: entering the battlefield, loading the scene, and executing the battle.

[0088] Player B's behavior data: entering the battlefield, loading the battle scene, and executing the task.

[0089] Player C's behavior data: viewing the mall and purchasing virtual items.

[0090] Player D's behavior data: view battle records and query historical tasks.

[0091] Player E's behavior data: character upgrade, submit operation request.

[0092] The current game event is the "Double Experience" event. Players who participate in battles during the event will receive double experience rewards.

[0093] 3. Predict the current system load At this time, there is game event data for the "double experience" activity. The current game event is classified according to the classification results of the historical game event data, and the player's behavior data and player request are marked with the lag time window corresponding to the current game event based on the classification results. The marked player's behavior data and player request are used as new player's behavior data and new player request to input into the load prediction model to obtain the system's load prediction data.

[0094] 4. Classify player requests, send them to the corresponding task queue and schedule tasks.

[0095] According to the priority classification of the requests, the requests of player A and player B are sent to the high priority task queue, the requests of player C and player D are sent to the medium priority task queue, and the request of player E is sent to the low priority task queue.

[0096] Assuming that the system's load forecast data is higher than the preset load threshold, the requests in each task queue are sorted in ascending order according to the request load of each request. At this time, since the request loads of player A and player B are the same, they are still sorted according to the request time. In the high-priority task queue, the order is player A's request, then player B's request. In the medium-priority task queue, the order is player D's request, then player C's request.

[0097] 5. Assign a processing node to the request. After the request is processed, send a request response to the player requester.

[0098] The load data of each processing node is obtained, and it is determined that the load data of each processing node is lower than a preset node load threshold.

[0099] Prioritize allocating processing nodes to the requests of player A in the high-priority task queue, and then allocate processing nodes to the requests of player B. After the allocation of the requests of the high-priority task queue is completed and the requests of the high-priority task queue are completed within the preset delay time, start allocating processing nodes to the requests of player D in the medium-priority task queue, and then allocate processing nodes to the requests of player C in the medium-priority task queue, and finally allocate processing nodes to the requests of player E in the low-priority task queue.

[0100] After the request processing is completed, the request response for each request is generated and sent to the players. Send "Loading Successfully, Entering Battle" to Player A and Player B, "Loading Successfully, Browse Items" to Player C, "Query Successfully, Display Historical Battles" to Player D, and "Upgrade Successfully, Raise Character Level" to Player E.

[0101] Embodiment 2: The difference from Embodiment 1 is as follows: like Figure 3 As shown, after executing S5 load prediction and before executing S6 request enqueueing, S53 first classification is also included. S53 first classification includes: S531 feature extraction, S532 acquisition of historical data, S533 model construction, S534 second training and S535 request classification.

[0102] S531 Feature extraction: extract features from the request and record the extracted features as first features, where the first features include request source, request content, and request time.

[0103] S532 obtains historical data: includes S5321 obtains historical data request and S5322 first mark.

[0104] S5321 Get historical request: Get historical request from the collected historical operation data.

[0105] Historical requests include historical request content, historical request payload, historical request source, and historical request time.

[0106] S5322 First marking: According to the timeliness and interactivity of the historical request content, the historical requests are manually marked with priority tags.

[0107] S533 model construction: Based on the deep learning algorithm, the support vector machine model is used as the basic model of the request classification model to build a request classification model.

[0108] S534 Second training: Construct a priority sample training set based on historical requests and corresponding priority labels, input the priority sample training set into the request classification model, perform model inference, define the priority loss function as the Hinge loss function, iteratively optimize the request classification model by minimizing the priority loss function, and use the optimized request classification model as the new request classification model.

[0109] S535 Request classification: Use the first feature as the input of the request classification model, output the priority label of the request, and use the obtained priority label as the new priority of the request.

[0110] In this embodiment, feature extraction is performed on each request and a request classification model is constructed based on a deep learning algorithm, which helps to more accurately determine the priority of each request. At the same time, the urgency and importance of the request are reflected through the request priority label, so that high-priority requests are given priority and important requests are delayed. In addition, marking the priority of the request can ensure that requests of different categories are reasonably assigned to the appropriate task queue according to their priority, further optimizing the load scheduling of the system and reducing the bottleneck caused by excessive load or long request queuing time.

[0111] Embodiment 3: The difference from Embodiment 1 is as follows: like Figure 4 As shown, after executing S5 load prediction and before executing S6 request queueing, S54 request merging is also included. S54 request merging includes: S541 request quantity judgment, S542 parameter feature extraction, S543 request similarity judgment and S544 waiting for merging.

[0112] S541 Request quantity determination: within a preset waiting time, determine whether the request quantity is 1.

[0113] If so, execute S6 to request to join the queue.

[0114] If not, execute S542 parameter feature extraction.

[0115] S542 Parameter feature extraction: based on the user behavior data and request content corresponding to the request, extract the request parameter features. The request parameter features include user behavior data, request source and request content.

[0116] S543 Request similarity judgment: Use a fuzzy matching algorithm to calculate the similarity between the request parameter features of each request, record it as a first similarity, and judge whether the first similarity is greater than a preset similarity threshold.

[0117] If so, the two requests with the first similarity are merged, and the merged request is sent to a temporary queue, and then S544 is executed to wait for merging.

[0118] If not, execute step S6 to request to join the queue.

[0119] In this embodiment, algorithms such as cosine similarity or Jaccard similarity may be used to calculate the similarity between the request parameter features of each request.

[0120] S544 Waiting for merging: After sending the merged request to the temporary queue, within a preset waiting time, determine whether there is a request whose first similarity with the above two requests is greater than a preset similarity threshold.

[0121] If yes, the request is sent to a temporary queue and merged with the above merged request, and then the S7 task scheduling is executed.

[0122] If not, execute the steps of S7 task scheduling.

[0123] After executing S7 task scheduling to S8 task distribution, when executing S9 request response, the request response is sent to each user requester of the merged request respectively.

[0124] In this embodiment, the priority of the temporary queue is the priority corresponding to the request with the highest priority among the merged requests.

[0125] In this embodiment, a fuzzy matching algorithm is used to calculate the similarity between requests, and requests with high similarity are merged for processing, which reduces the redundant calculation and resource usage of the system when processing multiple similar requests, improves the throughput and response speed of the system, and helps to optimize system performance. In addition, by continuing to monitor whether there are new requests similar to the merged requests within a specified time, the monitored similar requests are processed together with the merged requests, which helps to reduce the processing of duplicate requests, reduces redundant calculations, optimizes the use of system resources, and improves task processing efficiency. If there are no more similar requests within the specified time, the task scheduling stage is directly entered, reducing unnecessary waiting and delays.

[0126] Embodiment 4: The difference from Embodiment 1 is as follows: After executing S5 load prediction and before executing S6 request enqueueing, S55 first load determination is also included.

[0127] S55 First load judgment: judging whether the load prediction data is lower than a preset load threshold.

[0128] If so, a token bucket algorithm is used to generate tokens at a first preset rate, and the flow of the task queue processing request is set.

[0129] If not, the leaky bucket algorithm is used to set the flow of the task queue processing request at a second preset rate.

[0130] In this embodiment, the current system load is determined based on the load prediction data, so that the system can select an appropriate flow control strategy according to the load level. When the load is low, the token bucket algorithm is used to make request processing more flexible and efficient, which helps to improve the throughput of the system and enables the system to process more requests when the load is low. When the system load is high, the leaky bucket algorithm is used to control the flow at a constant rate, which helps to keep the system load within the preset processing capacity range, reduces the situation where too many requests in a short period of time cause system overload, and improves the stability and reliability of the system.

[0131] The above are all preferred embodiments of the present application, and the protection scope of the present application is not limited thereto. Therefore, any equivalent changes made according to the structure, shape, and principle of the present application should be included in the protection scope of the present application.

Claims

1. A concurrent processing method for http request task queue based on UE engine, characterized in that: include: Request reception: Receives requests sent by the user requester of the UE engine and sets the request priority according to the request time; The request includes request content, request payload, request source and request time; Data collection: including collecting real-time operation data and collecting historical operation data; Collect real-time operation data: Collect real-time operation data, which includes user behavior data and game event data corresponding to the request; Collect historical operation data: Collect historical operation data, including historical requests, historical system resource data, historical user behavior data, and historical game event data; Model building: Build a load prediction model based on deep learning algorithms; Load prediction: Use real-time operation data and requests sent by user requesters as inputs to the load prediction model, and output load prediction data; Request queuing: Classify the received requests according to their priorities and send the classified requests to the corresponding request priority task queue; Task scheduling: Sort requests in each task queue based on load forecast data; Task distribution: Distribute tasks in order according to the sorting results, and assign corresponding processing nodes to the requests for processing according to the load of each request and the load of the processing node; Request response: After the request is processed, a request response is sent to the user requester.

2. According to the UE engine-based http request task queue concurrent processing method according to claim 1, it is characterized in that: After executing the step of building the model and before executing the step of load prediction, it also includes: First data processing: Time-aligning historical user behavior data, historical requests, historical system resource data, and historical game event data, obtaining the generation time of each historical game event data, recording the historical user behavior data and historical requests before the generation time of each historical game event data as first data, and recording the historical user behavior data and historical requests after the generation time of each historical game event data as second data; Second data processing: compare the first data with the second data of each time period in chronological order, record it as the first difference, obtain the time corresponding to the second data when the first difference is less than the preset difference threshold, record it as the end time of the historical game event data, calculate the duration from the generation time to the end time of each historical game event data, record it as the activity duration of the historical game event data; The third data processing: clustering the activity duration of the historical game event data using a clustering algorithm, taking the clustering result as the classification result of the historical game event data, and taking the activity duration of each type of historical game event data as the lag time window of the historical game event data of that type; Fourth data processing: according to the lag time window of each historical game event data, marking the historical user behavior data, historical request and historical system resource data corresponding to the lag time window of the historical game event data with the lag time mark of the historical game event, and using the marked historical user behavior data, historical request and historical system resource data as new historical user behavior data, new historical request and new historical system resource data; Build sample training sets: Build load sample training sets based on historical user behavior data, historical requests, historical system resource data, and historical game events; Iterative optimization: Define the mean square error loss function, use the load sample training set as the input of the load prediction model, perform model inference, iteratively optimize the load prediction model by minimizing the mean square error loss function, and use the optimized load prediction model as the new load prediction model.

3. The method for concurrently processing http request task queues based on UE engine according to claim 2, characterized in that: After the step of performing iterative optimization and before the step of performing load prediction, the following steps are also included: Fifth data processing: determine whether game event data exists in the real-time running data: If so, the game event data is classified according to the classification result of the historical game event data, and the lag time window of the game event data is obtained according to the classification result of the game event data. The user behavior data in the real-time operation data and the request sent by the user requester are marked with the lag time mark of the game event data according to the lag time window of the game event data, and the marked user behavior data and request are used as new user behavior data and new request to perform the load prediction step; If not, no processing is performed and the load prediction step is executed.

4. The method for concurrently processing http request task queues based on UE engine according to claim 1, characterized in that: After the load prediction step and before the request enqueue step, the following steps are also included: Feature extraction: extracting features from the request, and recording the extracted features as first features, where the first features include request source, request content, and request time; Get historical data: Get historical requests and corresponding priority tags; Model construction: Build a request classification model based on deep learning algorithms; Second training: Build a priority sample training set based on historical requests and corresponding priority labels, input the priority samples into the request classification model for model inference, define the priority loss function, iteratively optimize the request classification model by minimizing the priority loss function, and use the optimized request classification model as the new request classification model; Request classification: The first feature is used as the input of the request classification model, the priority label of the request is output, and the obtained priority label is used as the new priority of the request.

5. The method for concurrently processing http request task queues based on UE engine according to claim 1, characterized in that: After the load prediction step and before the request enqueue step, the following steps are also included: Request quantity judgment: within the preset waiting time, judge whether the request quantity is 1: If so, execute the step of requesting to join the queue; If not, then the step of parameter feature extraction is performed; Parameter feature extraction: Extract request parameter features based on the user behavior data and request content corresponding to the request. Request parameter features include user behavior data, request source, and request content. Request similarity judgment: Use the fuzzy matching algorithm to calculate the similarity between the request parameter features of each request, record it as the first similarity, and judge whether the first similarity is greater than the preset similarity threshold: If yes, the two requests of the first similarity are merged, the merged request is sent to the temporary queue, and the task scheduling step is performed; If not, execute the step of requesting to enqueue.

6. The method for concurrently processing http request task queues based on UE engine according to claim 5, characterized in that: After executing the step of requesting similarity determination and before executing the step of task scheduling, the method further includes: Waiting for merging: After sending the merged request to the temporary queue, within the preset waiting time, determine whether there is a request whose first similarity with the above two requests is greater than the preset similarity threshold: If yes, the request is sent to a temporary queue and merged with the above merged request, and then the task scheduling step is performed; If not, execute the task scheduling steps.

7. The method for concurrently processing http request task queues based on UE engine according to claim 1, characterized in that: After the load prediction step and before the request enqueue step, the following steps are also included: First load judgment: judging whether the load prediction data is lower than a preset load threshold; If so, a token bucket algorithm is used to generate tokens at a first preset rate, and a flow rate of the task queue processing request is set; If not, the leaky bucket algorithm is used to set the flow of the task queue processing request at a second preset rate.

Images