Message data scheduling method and device, electronic equipment and storage medium

Abstract

The invention relates to a message data scheduling method and device, electronic equipment and a storage medium, and relates to the technical field of Internet. The method comprises the following steps: in response to a received user request, analyzing the user request to obtain a key request feature; determining the type of the user request according to the key request feature; determining a message data grading result of the user request based on the type of the user request; determining a routing target processing device of the user request according to the message data grading result, collecting a running state index of a system, and analyzing and obtaining a load rate of the routing target processing device for processing the user request; selecting a preset routing strategy according to the message data grading result; and distributing the user request to the routing target processing device based on the routing policy, and processing the user request in combination with the load rate of the routing target processing device. The resource utilization rate is improved, and the system response speed is optimized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet, in particular to a message data scheduling method and device, electronic equipment and storage medium. BACKGROUND

[0002] In the running process of the activity operation platform, there is a situation of high concurrency request caused by the limitation of the activity period. The existing high concurrency system usually uses a static scheme to process traffic, but there are defects: the routing strategy cannot be dynamically adjusted according to real-time request characteristics (such as device type, URL parameter); simple query request (such as hot data reading) still needs to penetrate to the backend server, increasing the response delay; there is no active degradation mechanism for non-core requests under burst traffic, which is easy to cause system avalanche downtime. SUMMARY

[0003] Therefore, a message data scheduling method and device, electronic equipment and storage medium are provided to solve the technical problems that the high concurrency system in the related art cannot dynamically adjust the routing strategy according to real-time request characteristics, the response delay for simple query request, and the system downtime caused by burst traffic.

[0004] In one aspect, a message data scheduling method is provided, the method comprising: In response to receiving a user request, analyzing the user request to obtain key request characteristics; According to the key request characteristics, determining the type of the user request; Based on the type of the user request, determining the message data classification result of the user request; According to the message data classification result, determining the routing target processing device of the user request, collecting the running state index of the system, and analyzing to obtain the load rate of the routing target processing device processing the user request; According to the message data classification result, selecting a preset routing strategy; Based on the routing strategy, distributing the user request to the routing target processing device, and processing the user request in combination with the load rate of the routing target processing device.

[0005] In one embodiment, in response to receiving a user request, analyzing the user request to obtain key request characteristics comprises: Extracting device type information from the user request as a request header; Extracting query string parameters from the user request as request parameters, the request parameters including at least one of the following: request timestamp, user ID, request ID; extracting routing path information as a request path from the user request, the routing path information being used to identify a request resource type or an operation target; taking the request header, the request parameter and the request path as key request features.

[0006] In one of the embodiments, the determining the message data classification result of the user request based on the type of the user request comprises: acquiring the type of the user request, the type of the user request comprising one of a front-end operation request, a read operation request and a write operation request; in response to the type of the user request being the front-end operation request, determining the message data classification result of the user request as static resource data; in response to the type of the user request being the read operation request, determining the message data classification result of the user request as simple query resource data; in response to the type of the user request being the write operation request, determining the message data classification result of the user request as complex operation resource data.

[0007] In one of the embodiments, the determining the routing target processing device of the user request according to the message data classification result comprises: in response to the message data classification result of the user request being the static resource data, the routing target processing device of the static resource data being a content distribution network; in response to the message data classification result of the user request being the simple query resource data, the routing target processing device of the simple query resource data being a high-performance key-value storage database; in response to the message data classification result of the user request being the complex operation resource data, the routing target processing device of the complex operation resource data being a back-end server; acquiring CPU utilization, memory usage, requests per second (QPS), average response time and thread pool usage information as the running state indicators; determining the load rate of the routing target processing device of the user request according to the running state indicators.

[0008] In one of the embodiments, the processing the user request in combination with the load rate of the routing target processing device comprises: in response to the message data classification result being the static resource data and the load rate of the content distribution network being greater than a first threshold, classifying sub-requests in the user request into core requests and non-core requests, and closing the non-core requests; in response to the message data classification result being simple query resource data and the load rate of the high-performance key-value storage database being greater than a second threshold, classifying sub-requests in the user request into core requests and non-core requests, and closing the non-core requests; in response to the message data classification result being complex operation resource data and the load rate of the backend server being greater than a third threshold, classifying sub-requests in the user request into core requests and non-core requests, and closing the non-core requests.

[0009] In one of the embodiments, the method further comprises: in response to closing the non-core requests, recording a processing log of the non-core requests, the log content including request key features, degradation processing reasons, and degradation processing time; feeding back to the user reminding information of suspension of processing of the non-core requests.

[0010] In one of the embodiments, the processing of the user request in combination with the load rate of the routing target processing device further comprises: acquiring the load rates of the content distribution network, the high-performance key-value storage database, and the backend server, and comparing and analyzing whether the load rates of the content distribution network, the high-performance key-value storage database, and the backend server are balanced; if the load rates of the content distribution network, the high-performance key-value storage database, and the backend server are the same, it is determined that the load rates are balanced, and the process ends; if the load rates of the content distribution network, the high-performance key-value storage database, and the backend server are not the same, it is determined that the load rates are not balanced, the message data classification result of complex operation resource data causing the load rate of the backend server to be greater than a third threshold is degraded to simple query resource data for processing, the message data classification result of simple query resource data causing the load rate of the high-performance key-value storage database to be greater than a second threshold is degraded to static resource data for processing, and static resource data causing the load rate of the content distribution network to be greater than a first threshold is closed.

[0011] On the other hand, a message data scheduling device is provided, the device comprising: a request analysis module configured to analyze a user request to obtain key request features in response to receiving the user request; a request type determination module configured to determine the type of the user request according to the key request features; a message data classification module configured to determine the message data classification result of the user request based on the type of the user request; The routing target processing device determination module is configured to determine the routing target processing device requested by the user according to the message data classification result, collect an operation state index of the system, and analyze and obtain a load rate of the routing target processing device processing the user request; The routing strategy selection module is configured to select a preset routing strategy according to the message data classification result. The request distribution and processing module is configured to distribute the user request to the routing target processing device based on the routing strategy, and process the user request in combination with the load rate of the routing target processing device.

[0012] In another aspect, an electronic device is provided, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the steps of the message data scheduling method when executing the computer program.

[0013] In yet another aspect, a computer readable storage medium is provided, which stores a computer program, and the computer program implements the steps of the message data scheduling method when executed by a processor.

[0014] The above message data scheduling method, device, electronic device, and storage medium can classify and classify message data by analyzing the key features (such as request header, request parameter, and request path) of the user request, so as to realize accurate request routing. The method can dynamically select different routing target processing devices (such as CDN, Redis, or backend service) according to different request types, and allocate traffic in combination with the load condition of the system, thereby improving resource utilization, optimizing system response speed, and effectively reducing service pressure. This intelligent message data scheduling not only ensures the high availability of the system, but also improves the user experience. BRIEF DESCRIPTION OF DRAWINGS

[0015] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0016] Figure 1 The flowchart of the message data scheduling method in one embodiment of the present application is shown in the figure. Figure 2 The structural block diagram of the message data scheduling device in one embodiment of the present application is shown in the figure. Figure 3 The internal structure diagram of the electronic device in one embodiment of the present application is shown in the figure. DETAILED DESCRIPTION

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0018] In one embodiment, such as Figure 1 As shown, a message data scheduling method is provided, including the following steps: Step S1: In response to receiving a user request, parse the user request to obtain key request features; Step S2: Determine the type of the user request based on the key request characteristics; Step S3: Determine the message data classification result of the user request based on the type of the user request; Step S4: Determine the routing target processing device of the user request based on the packet data classification result, collect the system's operating status indicators, and parse and obtain the load rate of the routing target processing device that processes the user request. Step S5: Select a preset routing strategy based on the packet data classification results; Step S6: Distribute the user request to the routing target processing device based on the routing policy, and process the user request in combination with the load rate of the routing target processing device.

[0019] Specifically, by parsing key characteristics of user requests (such as request headers, request parameters, and request paths), user requests are classified and message data is graded to achieve precise request routing. This method can dynamically select different routing target processing devices (such as CDN, Redis, or backend services) based on different request types and allocate traffic according to system load, improving resource utilization, optimizing system response speed, and effectively reducing service pressure. This intelligent message data scheduling not only ensures high system availability but also enhances the user experience.

[0020] In this embodiment, the step of responding to a received user request and parsing the user request to obtain key request features includes: Extract device type information from the user request as a request header; Extract query string parameters from the user request as request parameters, and the request parameters include at least one of the following: request timestamp, user ID, and request ID; The routing path information is extracted from the user request as the request path, and the routing path information is used to identify the requested resource type or operation target. The request header, request parameters, and request path are used as key request features.

[0021] By analyzing request data in detail, this method can efficiently identify the specific content of user requests, providing accurate input for subsequent message data classification and routing strategy formulation. This fine-grained request analysis helps to achieve more intelligent message data scheduling and resource allocation, especially when facing complex or large-scale requests, ensuring that requests are quickly and accurately directed to the appropriate processing devices.

[0022] In this embodiment, determining the message data classification result of the user request based on the type of the user request includes: Obtain the type of the user request, which includes one of the following: front-end operation request, read operation request, and write operation request; If the user request is a front-end operation request, then the message data classification result of the user request is determined to be static resource data. If the user request is a read operation request, then the message data classification result of the user request is determined to be simple query resource data. If the user request is a write operation request, then the message data classification result of the user request is determined to be complex operation resource data.

[0023] By classifying user request types (such as front-end operation requests, read operation requests, and write operation requests), the system effectively categorizes and processes different types of traffic. Through this packet data categorization, the system can adopt appropriate optimization strategies for different request types. For example, it can distribute static resource requests to a CDN and query requests to a high-performance database, thereby reducing resource waste, improving overall system processing efficiency, and reducing unnecessary load.

[0024] Specifically, the access request type is a static resource request: Characteristics: The path contains / static / or the file extension (.js, .png, .html, .css); Action: Returns a temporary redirect (302) status code containing the pre-configured Content Delivery Network (CDN) (target address) or object storage service domain name, with the option to attach an appropriate Cache-Control header, directing the client to retrieve resources from the nearest CDN node, thereby minimizing the load on the target gateway and backend servers and improving the user experience.

[0025] The access request type is a simple query request: Features: GET method with cache_key as a parameter; Action: The lightweight query module built into the Lua script or gateway queries the backend database (e.g., relational database, NoSQL database) or distributed caching system (e.g., Redis cluster) directly or through a short connection pool, and quickly returns the query results; the query operation is usually an idempotent read operation with low consumption of backend computing resources, and cache preheating and invalidation strategies can be configured to further accelerate the response.

[0026] The access request type is a complex operation request: Characteristics: POST / PUT methods or paths containing / transaction / ; or GET requests that do not use the Redis cache. Action: The gateway forwards the access request to the backend service cluster (e.g., a reactive service cluster or microservice cluster based on Spring WebFlux) through a reverse proxy server. The forwarding process may include one or more of the following strategies: Load balancing: Select a suitable backend instance based on the real-time load, health status, and preset load balancing algorithms (such as round-robin, least connections, weighted round-robin, etc.). Circuit breaking and rate limiting: When a backend service fails or has excessively high response latency, the circuit breaking mechanism is automatically triggered to prevent a cascading failure; when the request traffic exceeds the backend service's processing capacity, the rate limiting mechanism is triggered to protect the backend service from being overwhelmed. Request retry: For certain idempotent complex operations, an automatic retry strategy can be configured under specific error codes; Request tracing: Inject a distributed tracing ID to facilitate subsequent link tracing and troubleshooting.

[0027] In this embodiment, determining the routing target processing device for the user request based on the packet data classification result, collecting system operating status indicators, and parsing to obtain the load rate of the routing target processing device processing the user request includes: The message data classification result in response to the user request is static resource data, and the routing target processing device for the static resource data is the content delivery network; The message data classification result in response to the user request is simple query resource data, and the routing target processing device for the simple query resource data is a high-performance key-value storage database; The message data classification result in response to the user request is complex operation resource data, and the routing target processing device of the complex operation resource data is the backend server; The system's CPU utilization, memory usage, requests per second (QPS), average response time, and thread pool utilization are collected as operational status indicators. The load rate of the target processing device for the user request is determined based on the operating status indicators.

[0028] The system includes a content delivery network (CDN), a high-performance key-value store database (Redis), and backend servers.

[0029] By analyzing system performance metrics such as CPU utilization, memory usage, requests per second (QPS), and average response time, the system can dynamically adjust request routing to ensure requests are distributed to devices with lower loads, preventing system overload and improving resource utilization and system stability. This solution can adapt to load changes and automatically optimize resource allocation.

[0030] In this embodiment, processing the user request based on the load rate of the routing target processing device includes: In response to the message data classification result being static resource data, and the load rate of the content delivery network being greater than a first threshold, the sub-requests in the user request are classified into core requests and non-core requests, and the non-core requests are closed. In response to the message data classification result being simple query resource data, and the load rate of the high-performance key-value storage database being greater than the second threshold, the sub-requests in the user request are classified into core requests and non-core requests, and the non-core requests are closed. In response to the message data classification result being complex operation resource data, and the load rate of the backend server being greater than the third threshold, the sub-requests in the user request are classified into core requests and non-core requests, and the non-core requests are closed.

[0031] By dynamically adjusting requests based on load rate information, load balancing and intelligent request distribution are achieved. When the load rate of the target processing device exceeds a threshold, requests are degraded to ensure that core requests are prioritized, while non-core requests can be closed or delayed, thus preventing system overload. This method effectively prevents system bottlenecks, guarantees high-priority processing of core business requests, and improves system stability and response speed.

[0032] In this embodiment, the method further includes: In response to closing the non-core request, a processing log for the non-core request is recorded, including the request's key characteristics, the reason for the downgrade, and the downgrade processing time. The system will send a notification to the user indicating that the non-core request has been paused.

[0033] One key improvement is the addition of logging functionality when non-core requests are disabled, along with notifications to users. This helps system maintenance personnel quickly identify the reasons for request degradation and the processing time, enabling rapid identification and resolution of potential issues. Furthermore, user feedback enhances system transparency and user understanding, improving user experience and preventing user dissatisfaction caused by service unavailability.

[0034] In this embodiment, processing the user request based on the load rate of the routing target processing device further includes: Obtain the load rates of the content distribution network, the high-performance key-value storage database, and the backend server, and compare and analyze whether the load rates of the content distribution network, the high-performance key-value storage database, and the backend server are balanced; If the load rates of the content delivery network, the high-performance key-value storage database, and the backend server are the same, it is determined that the load rate is balanced, and the process ends. If the load rates of the content delivery network, the high-performance key-value storage database, and the backend server are not the same, it is determined that the load rate is unbalanced. In this case, the message data classification results of complex operation resource data that cause the load rate of the backend server to exceed the third threshold will be downgraded to simple query resource data for processing. The message data classification results of simple query resource data that cause the load rate of the high-performance key-value storage database to exceed the second threshold will be downgraded to static resource data for processing. The static resource data that causes the load rate of the content delivery network to exceed the first threshold will be shut down.

[0035] This system incorporates load balancing analysis of various routing target processing devices (CDN, Redis, backend servers). By intelligently adjusting traffic distribution, it prevents any single processing device from becoming a system bottleneck due to excessive load. If the load is unbalanced, it can dynamically adjust the request type classification and traffic path based on the load rate, thereby ensuring load balance across all devices and improving the overall system performance and stability. This intelligent packet data scheduling mechanism enables the system to automatically adapt to constantly changing load conditions, effectively enhancing the flexibility of resource allocation.

[0036] a. System Load Monitoring and Synchronization: Each service instance in the backend service cluster periodically collects its own operational status metrics, including at least one of the following: CPU utilization, memory usage, requests per second (QPS), average response time, thread pool utilization, etc., and writes this load information to shared storage (e.g., distributed cache, message queue, or dedicated configuration database); the Lua script in the target gateway periodically retrieves and updates the real-time load status of the current system as a whole or a specific backend service cluster from the shared storage.

[0037] b. Dynamic Degradation Strategy: In response to any or a combination of the following conditions, the Lua script will downgrade the message data classification result corresponding to the access request and record the degradation log: i. The request path of the access request is identified as a non-core business interface (e.g., data statistics interface, non-critical notification interface). ii. The overall system load or the load of a specific backend service cluster exceeds a preset dynamic threshold (e.g., CPU utilization exceeds 80%, QPS exceeds the maximum carrying capacity). iii. Health check results for the backend service cluster show that some instances are in an unhealthy state or all instances are unavailable; iv. The target gateway detects a continuously increasing error rate in communication with backend services (e.g., HTTP 5xx errors).

[0038] c. Downgrade measures: The downgrade measures include at least one of the following: i. Directly return preset error messages, user-friendly error messages, or static cached data to avoid requests reaching the backend; ii. Place the request in a message queue for asynchronous processing, and process it again after the system load recovers; iii. Return simplified or partial data, sacrificing integrity to ensure availability; iv. Deny service and return an HTTP 503 (Service Unavailable) status code.

[0039] d. Degradation Logs and Alarms: Simultaneously, the degradation event is recorded to the degradation log system. The log content includes key request characteristics, degradation reasons, degradation time, etc., for subsequent data analysis, performance optimization, and triggering alarm notifications.

[0040] The message data scheduling method further includes: a. Rule Configuration and Hot Reloading: A centralized management interface or configuration center is provided, allowing operations and maintenance personnel to dynamically configure and update the key feature parsing rules, request type matching rules, message data classification strategies, routing targets, and degradation thresholds. The target gateway can hot reload these updated configurations by subscribing to the configuration center or by periodically pulling them, without restarting the gateway service, thus ensuring business continuity.

[0041] b. Backend service health checks and dynamic adjustments: The target gateway periodically performs active or passive health checks on each instance in the backend service cluster (e.g., sending heartbeat requests, monitoring response time) to obtain the availability status of the backend services in real time; when an unhealthy instance is detected, it is removed from the routing target list and can be automatically restored according to the policy to ensure that traffic is forwarded only to healthy backend services.

[0042] c. Traffic Statistics and Visual Monitoring: The target gateway performs real-time statistics and aggregation on different packet data levels, different request types, different backend services, degradation events, and other key performance indicators (such as QPS, latency, and error rate), and reports the statistical data to a unified monitoring system (e.g., Prometheus, ELK Stack), providing a visual display of traffic trends, performance bottlenecks, and abnormal events to assist in operational decision-making and troubleshooting.

[0043] In this embodiment, before distributing the user request to the routing target processing device based on the routing policy, the method further includes: The urgency of the user's request is assessed based on the request timestamp, request source, and request type. Based on the urgency level, assign a priority to the user request; After the user request is assigned a priority, resources are allocated in descending order of priority based on the current load rate and the load balancing strategy.

[0044] The urgent requests can be dynamically adjusted based on factors such as user roles, business needs, and request latency tolerance. High-priority requests are processed first, while low-priority requests may be subject to resource constraints or delayed processing. The priority allocation strategy is determined according to a preset priority rule table. Resources are allocated in descending order of priority so that high-priority requests can be processed promptly even with limited resources, while low-priority requests may be postponed or degraded. Considering the load rate of the current target processing device, if the device is heavily loaded, high-priority requests are processed first, while low-priority requests may be temporarily suspended or assigned to other less loaded processing devices. Furthermore, through a system adaptive learning mechanism, the priority allocation strategy and load balancing mechanism are dynamically adjusted based on historical request processing data. This adaptive learning mechanism, based on big data analytics algorithms, analyzes different request types, user needs, and historical processing data to optimize priority and resource scheduling strategies, reducing system load and improving processing efficiency.

[0045] The priority evaluation mechanism ensures that the system can better meet business needs under high concurrency, reduce service latency caused by overload, and improve overall system performance. Through this mechanism, the system can effectively optimize resource allocation and guarantee service quality under diverse request and high-load scenarios.

[0046] This involves introducing a request preprocessing mechanism during user request processing to reduce system load and improve processing efficiency. The request preprocessing mechanism includes the following steps: Upon receiving a user request, the system performs a format check to ensure that the request header, request path, and request parameters conform to the system's preset specifications. If the request format is incorrect, the system sends a format error message to the user and corrects the request format according to preset rules. The transmitted request data is compressed using a preprocessing algorithm; After request data compression, resource matching and cache prediction are performed based on user request type and request content. Load prediction is performed in advance based on the computational complexity and resource consumption of the request content, and the request is allocated to suitable computing resources through a load balancing mechanism.

[0047] The system implements request data compression and optimization, particularly for requests transmitting large messages. Preprocessing algorithms compress the data to reduce data transmission volume. This effectively alleviates network bandwidth burden and improves request response speed, especially suitable for static resource requests and large-scale data queries. After request data compression, the system performs preliminary resource matching and cache prediction based on the user request type and content. For highly repetitive requests, the system prioritizes retrieving data from the local cache rather than recalculating or fetching from a remote database, significantly improving processing speed. The cache prediction mechanism intelligently judges cached data lifecycles and prefetching strategies based on historical request data and user behavior patterns. For data requests requiring complex computations, the system also performs load prediction based on the computational complexity and resource consumption of the request content, allocating requests to the most suitable computing resources through a load balancing mechanism, thereby avoiding system resource bottlenecks.

[0048] By introducing a request preprocessing mechanism, the system can intelligently optimize user requests in advance, which not only reduces the pressure on backend processing but also improves the overall request processing response speed, ensuring stable operation of the system in a high-concurrency environment.

[0049] The aforementioned message data scheduling method categorizes user requests and classifies message data by parsing key characteristics of user requests (such as request headers, request parameters, and request paths), thereby achieving precise request routing. This method dynamically selects different routing target processing devices (such as CDN, Redis, or backend services) based on different request types and allocates traffic according to system load, improving resource utilization, optimizing system response speed, and effectively reducing service pressure. This intelligent message data scheduling not only ensures high system availability but also enhances the user experience.

[0050] In one embodiment, such as Figure 2 As shown, a message data scheduling device 10 is provided, including: a request parsing module 1, a request type determination module 2, a message data classification module 3, a route target processing device determination module 4, a route policy selection module 5, and a request distribution and processing module 6.

[0051] The request parsing module 1 is used to respond to a received user request by parsing the user request to obtain key request features.

[0052] The request type determination module 2 is used to determine the type of the user request based on the key request characteristics.

[0053] The message data classification module 3 is used to determine the message data classification result of the user request based on the type of the user request.

[0054] The routing target processing device determination module 4 is used to determine the routing target processing device of the user request based on the packet data classification result, collect the system's operating status indicators, and parse and obtain the load rate of the routing target processing device that processes the user request.

[0055] The routing strategy selection module 5 is used to select a preset routing strategy based on the packet data classification results.

[0056] The request distribution and processing module 6 is used to distribute the user request to the routing target processing device based on the routing policy, and process the user request in combination with the load rate of the routing target processing device.

[0057] In this embodiment, the step of responding to a received user request and parsing the user request to obtain key request features includes: Extract device type information from the user request as a request header; Extract query string parameters from the user request as request parameters, and the request parameters include at least one of the following: request timestamp, user ID, and request ID; The routing path information is extracted from the user request as the request path, and the routing path information is used to identify the requested resource type or operation target. The request header, request parameters, and request path are used as key request features.

[0058] In this embodiment, determining the message data classification result of the user request based on the type of the user request includes: Obtain the type of the user request, which includes one of the following: front-end operation request, read operation request, and write operation request; If the user request is a front-end operation request, then the message data classification result of the user request is determined to be static resource data. If the user request is a read operation request, then the message data classification result of the user request is determined to be simple query resource data. If the user request is a write operation request, then the message data classification result of the user request is determined to be complex operation resource data.

[0059] In this embodiment, determining the routing target processing device for the user request based on the packet data classification result, collecting system operating status indicators, and parsing to obtain the load rate of the routing target processing device processing the user request includes: The message data classification result in response to the user request is static resource data, and the routing target processing device for the static resource data is the content delivery network; The message data classification result in response to the user request is simple query resource data, and the routing target processing device for the simple query resource data is a high-performance key-value storage database; The message data classification result in response to the user request is complex operation resource data, and the routing target processing device of the complex operation resource data is the backend server; The system's CPU utilization, memory usage, requests per second (QPS), average response time, and thread pool utilization are collected as operational status indicators. The load rate of the target processing device for the user request is determined based on the operating status indicators.

[0060] In this embodiment, processing the user request based on the load rate of the routing target processing device includes: In response to the message data classification result being static resource data, and the load rate of the content delivery network being greater than a first threshold, the sub-requests in the user request are classified into core requests and non-core requests, and the non-core requests are closed. In response to the message data classification result being simple query resource data, and the load rate of the high-performance key-value storage database being greater than the second threshold, the sub-requests in the user request are classified into core requests and non-core requests, and the non-core requests are closed. In response to the message data classification result being complex operation resource data, and the load rate of the backend server being greater than the third threshold, the sub-requests in the user request are classified into core requests and non-core requests, and the non-core requests are closed.

[0061] In this embodiment, as Figure 2 As shown, the message data scheduling device 10 further includes: an exception handling module 7, which is used for: In response to closing the non-core request, a processing log for the non-core request is recorded, including key characteristics of the request, reasons for exception handling, and exception handling time. The system will send a notification to the user indicating that the non-core request has been paused.

[0062] In this embodiment, processing the user request based on the load rate of the routing target processing device further includes: Obtain the load rates of the content distribution network, the high-performance key-value storage database, and the backend server, and compare and analyze whether the load rates of the content distribution network, the high-performance key-value storage database, and the backend server are balanced; If the load rates of the content delivery network, the high-performance key-value storage database, and the backend server are the same, it is determined that the load rate is balanced, and the process ends. If the load rates of the content delivery network, the high-performance key-value storage database, and the backend server are not the same, it is determined that the load rate is unbalanced. In this case, the message data classification results of complex operation resource data that cause the load rate of the backend server to exceed the third threshold will be downgraded to simple query resource data for processing. The message data classification results of simple query resource data that cause the load rate of the high-performance key-value storage database to exceed the second threshold will be downgraded to static resource data for processing. The static resource data that causes the load rate of the content delivery network to exceed the first threshold will be shut down.

[0063] The exception handling module 7 is used to: record a degradation processing log when the user request is downgraded, the content of which includes key characteristics of the request, the reason for degradation processing, and the time of degradation processing.

[0064] The aforementioned message data scheduling device categorizes user requests and classifies message data by parsing key characteristics of user requests (such as request headers, request parameters, and request paths), thereby achieving precise request routing. This method dynamically selects different routing target processing devices (such as CDN, Redis, or backend services) based on different request types and allocates traffic according to system load, improving resource utilization, optimizing system response speed, and effectively reducing service pressure. This intelligent message data scheduling not only ensures high system availability but also enhances the user experience.

[0065] Specific limitations regarding the message data scheduling device can be found in the limitations of the message data scheduling method above, and will not be repeated here. Each module in the aforementioned message data scheduling device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independently of the processor in the electronic device, or stored in software in the memory of the electronic device, so that the processor can call and execute the corresponding operations of each module.

[0066] like Figure 3 As shown, embodiments of this application also provide an electronic device, including a memory and a processor. The memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above-described message data scheduling method embodiments. The electronic device includes a processor, a memory, a network interface, and a database connected via a system bus. The processor of the electronic device provides computing and control capabilities. The memory of the electronic device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the electronic device stores message data scheduling data. The network interface of the electronic device is used for communication with external terminals via a network connection.

[0067] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0068] Those skilled in the art will understand that Figure 3The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0069] In one embodiment, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: In response to receiving a user request, the user request is parsed to obtain key request characteristics; The type of the user request is determined based on the key request characteristics; The message data classification result of the user request is determined based on the type of the user request; Based on the message data classification results, determine the routing target processing device for the user request, collect the system's operating status indicators, and parse and obtain the load rate of the routing target processing device that processes the user request. A preset routing strategy is selected based on the packet data classification results; The user request is distributed to the routing target processing device based on the routing policy, and the user request is processed in combination with the load rate of the routing target processing device.

[0070] For specific limitations on the steps implemented by the processor when executing a computer program, please refer to the limitations on the method of message data scheduling mentioned above, which will not be repeated here.

[0071] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: In response to receiving a user request, the user request is parsed to obtain key request characteristics; The type of the user request is determined based on the key request characteristics; The message data classification result of the user request is determined based on the type of the user request; Based on the message data classification results, determine the routing target processing device for the user request, collect the system's operating status indicators, and parse and obtain the load rate of the routing target processing device that processes the user request. A preset routing strategy is selected based on the packet data classification results; The user request is distributed to the routing target processing device based on the routing policy, and the user request is processed in combination with the load rate of the routing target processing device.

[0072] For specific limitations on the steps implemented when a computer program is executed by a processor, please refer to the limitations on message data scheduling methods mentioned above, which will not be repeated here.

[0073] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0074] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0075] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A message data scheduling method, characterized in that, include: In response to receiving a user request, the user request is parsed to obtain key request characteristics; The type of the user request is determined based on the key request characteristics; The message data classification result of the user request is determined based on the type of the user request; Based on the message data classification results, determine the routing target processing device for the user request, collect the system's operating status indicators, and parse and obtain the load rate of the routing target processing device that processes the user request. A preset routing strategy is selected based on the packet data classification results; The user request is distributed to the routing target processing device according to the routing policy, and the user request is processed in combination with the load rate of the routing target processing device.

2. The message data scheduling method according to claim 1, characterized in that, The step of responding to a received user request and parsing the user request to obtain key request features includes: Extract device type information from the user request as a request header; Extract query string parameters from the user request as request parameters, and the request parameters include at least one of the following: request timestamp, user ID, and request ID; The routing path information is extracted from the user request as the request path, and the routing path information is used to identify the requested resource type or operation target. The request header, request parameters, and request path are used as key request features.

3. The message data scheduling method according to claim 1, characterized in that, The determination of the message data classification result of the user request based on the type of the user request includes: Obtain the type of the user request, which includes one of the following: front-end operation request, read operation request, and write operation request; If the user request is a front-end operation request, then the message data classification result of the user request is determined to be static resource data. If the user request is a read operation request, then the message data classification result of the user request is determined to be simple query resource data. If the user request is a write operation request, then the message data classification result of the user request is determined to be complex operation resource data.

4. The message data scheduling method according to claim 1, characterized in that, The step of determining the routing target processing device for the user request based on the packet data classification result, collecting system operation status indicators, and parsing to obtain the load rate of the routing target processing device processing the user request includes: The message data classification result in response to the user request is static resource data, and the routing target processing device for the static resource data is the content delivery network; The message data classification result in response to the user request is simple query resource data, and the routing target processing device for the simple query resource data is a high-performance key-value storage database; The message data classification result in response to the user request is complex operation resource data, and the routing target processing device of the complex operation resource data is the backend server; The system's CPU utilization, memory usage, requests per second, average response time, and thread pool utilization are collected as operational status indicators. The load rate of the target processing device for the user request is determined based on the operating status indicators.

5. The message data scheduling method according to claim 4, characterized in that, The process of processing the user request based on the load rate of the routing target processing device includes: In response to the message data classification result being static resource data, and the load rate of the content delivery network being greater than a first threshold, the sub-requests in the user request are classified into core requests and non-core requests, and the non-core requests are closed. In response to the message data classification result being simple query resource data, and the load rate of the high-performance key-value storage database being greater than the second threshold, the sub-requests in the user request are classified into core requests and non-core requests, and the non-core requests are closed. In response to the message data classification result being complex operation resource data, and the load rate of the backend server being greater than the third threshold, the sub-requests in the user request are classified into core requests and non-core requests, and the non-core requests are closed.

6. The message data scheduling method according to claim 5, characterized in that, The method further includes: In response to closing the non-core request, a processing log for the non-core request is recorded, including the request's key characteristics, the reason for the downgrade, and the downgrade processing time. The system will send a notification to the user indicating that the non-core request has been paused.

7. The message data scheduling method according to claim 5, characterized in that, The process of processing the user request based on the load rate of the routing target processing device also includes: Obtain the load rates of the content distribution network, the high-performance key-value storage database, and the backend server, and compare and analyze whether the load rates of the content distribution network, the high-performance key-value storage database, and the backend server are balanced; If the load rates of the content delivery network, the high-performance key-value storage database, and the backend server are the same, it is determined that the load rate is balanced, and the process ends. If the load rates of the content delivery network, the high-performance key-value storage database, and the backend server are not the same, it is determined that the load rate is unbalanced. In this case, the message data classification results of complex operation resource data that cause the load rate of the backend server to exceed the third threshold will be downgraded to simple query resource data for processing. The message data classification results of simple query resource data that cause the load rate of the high-performance key-value storage database to exceed the second threshold will be downgraded to static resource data for processing. The static resource data that causes the load rate of the content delivery network to exceed the first threshold will be shut down.

8. A message data scheduling device, characterized in that, The device includes: The request parsing module is used to respond to a received user request by parsing the user request to obtain key request features; The request type determination module is used to determine the type of the user request based on the key request characteristics. The message data classification module is used to determine the message data classification result of the user request based on the type of the user request; The routing target processing device determination module is used to determine the routing target processing device of the user request based on the packet data classification result, collect the system's operating status indicators, and parse and obtain the load rate of the routing target processing device that processes the user request. The routing strategy selection module is used to select a preset routing strategy based on the packet data classification results; The request distribution and processing module is used to distribute the user request to the routing target processing device based on the routing policy, and process the user request in combination with the load rate of the routing target processing device.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images