Data request processing method, system, device and medium for web service cluster

Abstract

The application relates to the technical field of data request, and particularly provides a data request processing method, system and device for a Web service cluster and a medium, aiming to solve the technical problem that, due to the different performance and loads of each backend server, the weak-performance backend server and the high-load backend server are overloaded, and the request response time is increased. To this end, the data request processing method for the Web service cluster comprises the following steps: when a gateway layer receives a request from a client, the type of the request is determined; when the type is determined as a dynamic request, a candidate node is selected from all backend nodes according to a load balancing strategy; health check data is sent to the candidate node to obtain the health status of the candidate node; when the health status is determined as normal, the request is sent to the candidate node, and the response data returned by the candidate node is sent to the client.

Description

Technical Field

[0001] This application relates to the field of data request technology, specifically providing a data request processing method, system, device, and medium for a Web service cluster. Background Technology

[0002] With the rapid development of internet services, the access volume to internet backend servers has continued to surge, placing higher demands on their stability, response speed, and resilience. Currently, internet data request systems typically employ backend servers. When a client sends a request, the request is forwarded to the backend server, which then sends the data to the client.

[0003] In existing technologies, multiple backend servers and a load balancer module are typically configured. The client sends a request to the load balancer module, which distributes the request to the appropriate backend server according to the server's order. Upon receiving the request, the backend server sends the data to the client, thereby improving the response speed and stability of the internet data request system. However, because each backend server has different performance and handles different requests, its load also varies. This can cause overload on weaker backend servers and heavily loaded backend servers, leading to increased request response time.

[0004] Accordingly, there is a need in the field for a new method for processing data requests for Web service clusters to address the aforementioned problems. Summary of the Invention

[0005] In order to overcome the above-mentioned defects, this application is made to provide a solution or at least a partial solution to the technical problem in the prior art where the performance and load of each backend server are different, causing the weak backend server and the high-load backend server to become overloaded, thereby increasing the request response time.

[0006] In a first aspect, this application provides a data request processing method for a Web service cluster, the Web service cluster including a gateway layer and an application service layer, the application service layer including at least one backend node, the method comprising:

[0007] When the gateway layer receives a request from the client, it determines the type of the request;

[0008] When the type is determined to be a dynamic request, a candidate node is selected from all backend nodes according to the load balancing strategy.

[0009] Send health check data to the candidate nodes to obtain their health status;

[0010] When the health status is determined to be normal, the request is sent to the candidate node, and the response data returned by the candidate node is sent to the client.

[0011] In one technical solution of the above-mentioned data request processing method for Web service clusters, the gateway layer includes a master node and a backup node. When the gateway layer receives a request from a client, it includes:

[0012] Perform a health check on the master node to obtain its health status;

[0013] When the health status of the primary node is determined to be normal, the primary node receives the request from the client; otherwise, the request is forwarded to the backup node, which then receives the request from the client.

[0014] In one technical solution of the above-mentioned data request processing method for a Web service cluster, after determining that the master node's health status is normal, the method further includes:

[0015] Obtain the client data corresponding to the request;

[0016] Rate limiting detection is performed based on the client data to obtain the rate limiting result;

[0017] If the rate limiting result is determined to be unsuccessful, the request will be intercepted.

[0018] In one technical solution of the above-mentioned data request processing method for Web service clusters, the method further includes:

[0019] When the type is determined to be a static request, the cached data corresponding to the static request is obtained;

[0020] The cached data is validated to obtain the validation result;

[0021] If the verification result is found to be valid, the cached data is sent to the client.

[0022] In one technical solution of the above-mentioned data request processing method for Web service clusters, after verifying the cached data and obtaining the verification result, the method further includes:

[0023] When the verification result is determined to be invalid;

[0024] Obtain the local static data corresponding to the request, and send the local static data to the client;

[0025] The cached data is updated based on the local static data.

[0026] In one technical solution of the above-mentioned data request processing method for Web service clusters, after sending health check data to the candidate node to obtain the health status of the candidate node, the method further includes:

[0027] When the health status is determined to be abnormal, the candidate node is removed from all backend nodes to obtain the remaining backend nodes;

[0028] According to the load balancing strategy, a new candidate node is selected from the remaining backend nodes, and the process of sending health check data to the candidate node is returned.

[0029] In one technical solution of the above-mentioned data request processing method for Web service clusters, the step of selecting candidate nodes from all backend nodes according to a load balancing strategy includes:

[0030] Obtain the connection count and weight of each backend node;

[0031] The backend node with the largest weight and a number of connections less than a preset connection threshold is selected as the candidate node.

[0032] Secondly, this application provides a data request processing system, comprising:

[0033] A receiving module is used to receive a request from a client and determine the type of the request;

[0034] The selection module is used to select candidate nodes from all backend nodes according to the load balancing strategy when the receiving module determines that the type is a dynamic request.

[0035] The inspection module is used to send health check data to the candidate nodes to obtain the health status of the candidate nodes;

[0036] The sending module is used to send the request to the candidate node when the health status is determined to be normal, and to send the response data returned by the candidate node to the client.

[0037] Thirdly, this application provides a data request processing apparatus, including at least one processor and a memory; wherein,

[0038] The memory stores computer-executed instructions;

[0039] The at least one processor executes computer execution instructions stored in the memory, causing the at least one processor to perform the method described in any one of the first aspects.

[0040] Fourthly, this application provides a computer-readable storage medium storing a plurality of program codes adapted to be loaded and run by a processor to perform the method described in any one of the first aspects.

[0041] This application provides a data request processing method, system, device, and medium for a Web service cluster. The method specifically involves: when the gateway layer receives a request from a client, determining the type of the request; if the type is determined to be a dynamic request, selecting a candidate node from all backend nodes according to a load balancing strategy; sending health check data to the candidate node to obtain the health status of the candidate node; and if the health status is determined to be normal, sending the request to the candidate node and sending the response data returned by the candidate node to the client, thereby reducing request response time. Attached Figure Description

[0042] The disclosure of this application will become more readily understood with reference to the accompanying drawings. It will be readily understood by those skilled in the art that these drawings are for illustrative purposes only and are not intended to limit the scope of protection of this application. Furthermore, similar numbers in the drawings are used to denote similar components, wherein:

[0043] Figure 1 This is a flowchart illustrating a data request processing method for a Web service cluster according to an embodiment of this application.

[0044] Figure 2 This is a flowchart illustrating a second embodiment of a data request processing method for a Web service cluster provided in this application.

[0045] Figure 3 This is a flowchart illustrating a third embodiment of a data request processing method for a Web service cluster provided in this application.

[0046] Figure 4 This is a flowchart illustrating a fourth embodiment of a data request processing method for a Web service cluster provided in this application.

[0047] Figure 5 This is a flowchart illustrating a fifth embodiment of a data request processing method for a Web service cluster provided in this application.

[0048] Figure 6 This is a flowchart illustrating a sixth embodiment of a data request processing method for a Web service cluster provided in this application.

[0049] Figure 7 This is a flowchart illustrating Embodiment Seven of a data request processing method for a Web service cluster provided in this application.

[0050] Figure 8 This is a schematic diagram of the structure of a data request processing system provided in an embodiment of this application;

[0051] Figure 9 This is a schematic diagram of the structure of a data request processing device provided in an embodiment of this application.

[0052] List of reference numerals in the attached diagram:

[0053] 11: Receiving module; 12: Selection module; 13: Inspection module; 14: Transmitting module; 21: Processor; 22: Memory. Detailed Implementation

[0054] Some embodiments of this application are described below with reference to the accompanying drawings. Those skilled in the art should understand that these embodiments are merely illustrative of the technical principles of this application and are not intended to limit the scope of protection of this application.

[0055] In the description of this application, "module" and "processor" can include hardware, software, or a combination of both. A module can include hardware circuitry, various suitable sensors, communication ports, memory, and can also include software components, such as program code, or a combination of software and hardware. A processor can be a central processing unit, microprocessor, image processor, digital signal processor, or any other suitable processor. The processor has data and / or signal processing capabilities. The processor can be implemented in software, in hardware, or a combination of both. Non-transitory computer-readable storage media includes any suitable medium capable of storing program code, such as magnetic disks, hard disks, optical disks, flash memory, read-only memory, random access memory, etc. The term "A and / or B" means all possible combinations of A and B, such as only A, only B, or A and B. The terms "at least one A or B" or "at least one of A and B" have a similar meaning to "A and / or B" and can include only A, only B, or A and B. The singular terms "a" or "this" can also include plural forms.

[0056] In existing technologies, with the rapid development of internet businesses, web services face a continuous surge in access traffic, placing higher demands on service stability, response speed, and resilience. Current mainstream web service cluster deployments generally suffer from the following pain points:

[0057] Single point of failure: If a single Nginx gateway server goes down, experiences a network interruption, or a process crash, the entire service will become unavailable, causing business interruption and user loss. There is a lack of a robust self-healing mechanism.

[0058] Uneven traffic load: The lack of a reasonable traffic distribution strategy for multiple backend application servers can easily lead to situations where some servers are overloaded while others are idle, making it impossible to fully utilize server resources and reducing the overall service throughput.

[0059] Traffic surge risk: In the face of sudden large traffic surges, malicious access, or web crawler attacks, the lack of a refined traffic limiting and control mechanism can easily lead to the exhaustion of backend server resources, causing service lag, timeouts, or even paralysis.

[0060] Low request processing efficiency: Mixed processing of static resources (images, CSS, JS, static pages, etc.) and dynamic interface requests, resulting in increased pressure on the Nginx gateway and backend application server, increases request response time and reduces user access experience.

[0061] Based on this, in order to solve the above-mentioned technical problems, the technical concept of this application is to provide a new data request processing method for Web service clusters to reduce request response time.

[0062] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0063] Figure 1 This is a flowchart illustrating an embodiment of a data request processing method for a Web service cluster provided in this application. Figure 1 As shown, specifically, the Web service cluster includes a gateway layer and an application service layer, and the application service layer includes at least one backend node. Therefore, the method includes:

[0064] Step S101: When the gateway layer receives a request from the client, it determines the type of the request.

[0065] In this embodiment, the Web service includes a physical layer, a data link layer, a gateway layer, an application service layer, and a static resource layer. When a client sends a request, the request is first received by the gateway layer within the Web service, which analyzes the request data to determine the type of the request.

[0066] Step S102: When the type is determined to be a dynamic request, a candidate node is selected from all backend nodes according to the load balancing strategy.

[0067] In this embodiment, the backend node is the backend server. Currently, to ensure the reliability of web services, multiple backend nodes are usually set up to avoid the problem of not being able to provide services to users if one backend node goes down or the network is disconnected.

[0068] In this embodiment, when the type of request is determined to be a dynamic request, the Nginx in the gateway layer needs to select a candidate node from the backend nodes according to the preset load balancing strategy.

[0069] In this embodiment, for example, the load balancing strategy can be a round-robin strategy, a weighted round-robin strategy, an IP hash strategy, or a least connections strategy.

[0070] Step S103: Send health check data to the candidate nodes to obtain the health status of the candidate nodes.

[0071] In this embodiment, Nginx has a built-in health check module. After setting the check interval, number of failures and number of successes, it sends health check commands to candidate nodes multiple times according to the check interval. After receiving the health check command, the candidate node reports its health status back to Nginx.

[0072] In this embodiment, for example, the check interval is 30 seconds, the number of failures is 3, and the number of successes is 2.

[0073] Step S104: When the health status is determined to be normal, the request is sent to the candidate node, and the response data returned by the candidate node is sent to the client.

[0074] In this embodiment, if Nginx receives healthy health data from a candidate node twice in a row, it determines that the candidate node is in normal health status. Then, Nginx sends the client's request to the candidate node, and the candidate node sends the response data corresponding to the request to the client.

[0075] In this embodiment, when the gateway layer receives a request from the client, it determines the type of the request. If the type is determined to be a dynamic request, a candidate node is selected from all backend nodes according to the load balancing strategy. Health check data is sent to the candidate node to obtain its health status. If the health status is determined to be normal, the request is sent to the candidate node, and the response data returned by the candidate node is sent to the client. Compared with the prior art, where the performance and load of each backend server are different, causing the weak backend server and the high-load backend server to become overloaded, thus increasing the request response time, this application reduces the request response time and improves the user access experience by selecting a candidate node from all backend nodes according to the load balancing strategy when the client's request is determined to be a dynamic request, sending health check data to the candidate node to obtain its health status, and forwarding the client's request to the candidate node when the candidate node's health status is determined to be normal. The candidate node then sends the response data corresponding to the request to the client.

[0076] Figure 2 This is a flowchart illustrating a second embodiment of a data request processing method for a Web service cluster provided in this application. Based on the above embodiments, as follows... Figure 2 As shown, specifically, the gateway service layer includes a primary node and a backup node, so the method also includes:

[0077] Step S201: Perform a health check on the master node to obtain its health status.

[0078] In this embodiment, the backend nodes in the application service layer include one primary node and multiple backup nodes. After the web service is initialized, Keepalived initializes the primary and backup nodes, including configuring virtual IPs, heartbeat detection, and health check scripts. After initialization, the health check scripts are executed to obtain the health status of the primary node.

[0079] Step S202: When the health status of the primary node is determined to be normal, the primary node receives the request from the client; otherwise, the request is forwarded to the backup node, which then receives the request from the client.

[0080] In this embodiment, the master node sends heartbeat information to the backup nodes. When the master node sends heartbeat information to the backup nodes normally at preset intervals, the master node's health status is determined to be normal. Otherwise, a backup node is selected as the master node, and the virtual IP is switched to that backup node. Then, requests sent by the client are sent to that backup node, which processes the request.

[0081] In this embodiment, in order to determine the node that handles client requests, a health check needs to be performed on the primary node to obtain its health status. If the primary node's health status is normal, the primary node receives the request from the client; otherwise, the request is forwarded to the backup node, which receives the request from the client. If the primary node's health status is abnormal, the backup node can automatically take over the virtual IP within 1 second and continue to handle the client's request, achieving seamless switching and thereby improving the high availability and business continuity of the Web service.

[0082] Figure 3 This is a flowchart illustrating a third embodiment of a data request processing method for a Web service cluster provided in this application. Based on the above embodiments, as follows... Figure 3 As shown, specifically, in step S202, after determining that the master node's health status is normal, the method further includes:

[0083] Step S301: Obtain the client data corresponding to the request.

[0084] In this embodiment, the client data includes the client's access frequency and concurrency.

[0085] Step S302: Perform rate limiting detection based on client data to obtain rate limiting results.

[0086] In this embodiment, if the client data is greater than a preset threshold, the rate limiting result is "failed"; if it is less than the preset threshold, the rate limiting result is "passed".

[0087] Step S303: If the rate limiting result is determined to be unsuccessful, the request will be intercepted.

[0088] In this embodiment, if the rate limiting result is not passed, the request will not be forwarded to the node, that is, the request will be intercepted.

[0089] In this embodiment, after obtaining the client data corresponding to the request, rate limiting detection is performed based on the client data to obtain the rate limiting result. When it is determined that the rate limiting result is not passed, the request is intercepted to resist sudden traffic and malicious access, thereby protecting the stable operation of the backend server.

[0090] Figure 4 This is a flowchart illustrating a fourth embodiment of a data request processing method for a Web service cluster provided in this application. Based on the above embodiments, as... Figure 4 As shown, specifically, after step S101, the method further includes:

[0091] Step S401: If the type is determined to be a static request, then obtain the cached data corresponding to the static request.

[0092] In this embodiment, if the request type is a static request, Nginx reads the cached data corresponding to the static request from the local machine.

[0093] In this implementation, the data corresponding to static requests includes images, scripts, static pages, and other similar data.

[0094] Step S402: Verify the cached data and obtain the verification result.

[0095] In this embodiment, the cached data has an expiration date. Therefore, before sending the cached data to the client, the expiration date of the cached data needs to be compared with the current date to obtain a verification result. Specifically, if the expiration date is later than the current date, the verification result is valid; if the expiration date is earlier than the current date, the verification result is invalid.

[0096] Step S403: If the verification result is found to be valid, the cached data is sent to the client.

[0097] In this embodiment, if the verification result is determined to be valid, that is, the cached data is within the validity period, the cached data is sent to the client.

[0098] In this embodiment, when the type is determined to be a static request, the cached data corresponding to the static request is obtained; the cached data is validated to obtain the validation result; when the validation result is determined to be valid, the cached data is sent to the client, reducing the forwarding of static requests, significantly reducing the pressure on the backend server, and thus improving the access speed of static resources.

[0099] Figure 5 This is a flowchart illustrating a fifth embodiment of a data request processing method for a Web service cluster provided in this application. Based on the above embodiments, as follows... Figure 5 As shown, specifically, after step S402, the method further includes:

[0100] Step S501: When the verification result is determined to be invalid.

[0101] Step S502: Obtain the local static data corresponding to the request and send the local static data to the client.

[0102] In this embodiment, when the verification result is determined to be invalid, i.e. the cached data has expired, it is necessary to retrieve the local static data corresponding to the request from the backend server again and send the local static data to the client.

[0103] Step S503: Update the cached data based on the local static data.

[0104] In this embodiment, the cached data corresponding to the static request in the local data is updated using the local static data, and the validity period of the cached data is set.

[0105] In this embodiment, when the verification result is determined to be invalid, the local static data corresponding to the request is obtained and sent to the client; the cached data is updated based on the local static data, thereby improving the validity of the data corresponding to the static request.

[0106] Figure 6 This is a flowchart illustrating a sixth embodiment of a data request processing method for a Web service cluster provided in this application. Based on the above embodiments, as follows... Figure 6 As shown, specifically, after step S103, the method further includes:

[0107] Step S601: When the health status is determined to be abnormal, the candidate node is removed from all backend nodes to obtain the remaining backend nodes.

[0108] In this embodiment, if the health status of a candidate node selected from all backend nodes is abnormal through the load balancing strategy, the candidate node is removed from all backend nodes, and other remaining backend nodes are obtained.

[0109] Step S602: Based on the load balancing strategy, reselect candidate nodes from the remaining backend nodes and return to the execution state to send health check data to the candidate nodes.

[0110] In this embodiment, according to the load balancing strategy, a new candidate node is selected from the remaining backend nodes, and health check data is sent to the candidate node to obtain the health status of the candidate node.

[0111] In this embodiment, steps S601 and S602 are repeated until a candidate node with a normal health status is obtained.

[0112] In this embodiment, when the health status is determined to be abnormal, the candidate node is removed from all backend nodes to obtain the remaining backend nodes; according to the load balancing strategy, a new candidate node is selected from the remaining backend nodes, and the process is returned to send health check data to the candidate node to avoid forwarding requests to the faulty server and ensure stable request forwarding.

[0113] Figure 7 This is a flowchart illustrating Embodiment Seven of a data request processing method for a Web service cluster provided in this application. Based on the above embodiments, as... Figure 7 As shown, specifically, in step S102, candidate nodes are selected from all backend nodes according to the load balancing strategy, including:

[0114] Step S701: Obtain the connection count and weight of each backend node.

[0115] In this embodiment, the number of connections refers to the number of session connections maintained between the backend node and the client. Each backend node is assigned a different weight; the higher the weight of a backend node, the more requests it receives.

[0116] Step S702: Select the backend node with the largest weight and fewer connections than the preset connection threshold as the candidate node.

[0117] In this embodiment, the backend node with the largest weight value is selected as the candidate node from the backend nodes whose number of connections is less than a preset connection threshold.

[0118] In this embodiment, the number of connections and weights of each backend node are obtained; the backend node with a number of connections less than a preset connection threshold and the largest weight value is selected as a candidate node, and then the client's requests are evenly distributed to the backend nodes to improve the throughput of requests and the utilization of the backend server.

[0119] It should be noted that although the steps in the above embodiments are described in a specific order, those skilled in the art will understand that in order to achieve the effect of this application, different steps do not necessarily have to be executed in such an order. They can be executed simultaneously (in parallel) or in other orders, and these variations are all within the scope of protection of this application.

[0120] Furthermore, this application also provides a data request processing system.

[0121] Figure 8 This is a schematic diagram of the structure of a data request processing system provided in an embodiment of this application. Figure 8 As shown, the data request processing system in this embodiment mainly includes a receiving module 11, a selection module 12, a checking module 13, and a sending module 14. In some embodiments, one or more of the receiving module 11, selection module 12, checking module 13, and sending module 14 can be combined into a single module. In some embodiments, the receiving module 11 can be configured to receive a request from a client and determine the type of the request. The selection module 12 can be configured to select a candidate node from all backend nodes according to a load balancing strategy when the receiving module 11 determines that the request type is a dynamic request. The checking module 13 can be configured to send health check data to the candidate node to obtain the health status of the candidate node. The sending module 14 can be configured to send the request to the candidate node and send the response data returned by the candidate node to the client when the health status is determined to be normal.

[0122] The aforementioned data request processing system is used for execution Figures 1 to 7 The data request processing method embodiments for Web service clusters shown are similar in technical principles, the technical problems they solve, and the technical effects they produce. Those skilled in the art can clearly understand that, for the sake of convenience and brevity, the specific working process and related descriptions of the data request processing system can be found in the embodiments of the data request processing method for Web service clusters, and will not be repeated here.

[0123] Those skilled in the art will understand that all or part of the processes in the method of the above-described embodiment can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable file, or some intermediate form. The computer-readable storage medium can include any entity or device capable of carrying the computer program code, a medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory, a random access memory, an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0124] Furthermore, this application also provides a data request processing device.

[0125] Figure 9 This is a schematic diagram of the structure of a data request processing device provided in an embodiment of this application. Figure 9 As shown, the data request processing device includes a processor 21 and a memory 22. The memory 22 can be configured to store a program for executing the data request processing method for a Web service cluster as described in the above method embodiments. The processor 21 can be configured to execute the program stored in the memory, which includes, but is not limited to, the program for executing the data request processing method for a Web service cluster as described in the above method embodiments. For ease of explanation, only the parts related to the embodiments of this application are shown. For specific technical details not disclosed, please refer to the method section of the embodiments of this application. The data request processing device can be a control device device comprising various electronic devices.

[0126] Furthermore, this application also provides a computer-readable storage medium. In one embodiment of the computer-readable storage medium according to this application, the computer-readable storage medium can be configured to store a program that performs the data request processing method for a Web service cluster described in the above-described method embodiments. This program can be loaded and run by a processor to implement the data request processing method for a Web service cluster described above. For ease of explanation, only the parts related to the embodiments of this application are shown; for specific technical details not disclosed, please refer to the method section of the embodiments of this application. The computer-readable storage medium can be a storage device device comprising various electronic devices. Optionally, in the embodiments of this application, the computer-readable storage medium is a non-transitory computer-readable storage medium.

[0127] Furthermore, it should be understood that since the various modules are only provided to illustrate the functional units of the device described in this application, the physical devices corresponding to these modules may be the processor itself, or a part of the processor's software, hardware, or a combination of both. Therefore, the number of modules shown in the figures is merely illustrative.

[0128] Those skilled in the art will understand that the various modules in the device can be adaptively split or combined. Such splitting or combining of specific modules will not cause the technical solution to deviate from the principles of this application; therefore, the technical solutions after splitting or combining will fall within the protection scope of this application.

[0129] The technical solutions of this application have been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of this application is obviously not limited to these specific embodiments. Without departing from the principles of this application, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of this application.

Claims

1. A data request processing method for a Web service cluster, characterized in that, The web service cluster includes a gateway layer and an application service layer, the application service layer including at least one backend node, and the method includes: When the gateway layer receives a request from the client, it determines the type of the request; When the type is determined to be a dynamic request, a candidate node is selected from all backend nodes according to the load balancing strategy. Send health check data to the candidate nodes to obtain their health status; When the health status is determined to be normal, the request is sent to the candidate node, and the response data returned by the candidate node is sent to the client.

2. The method according to claim 1, characterized in that, The gateway layer includes a master node and a backup node. When the gateway layer receives a request from a client, it includes: Perform a health check on the master node to obtain its health status; When the health status of the primary node is determined to be normal, the primary node receives the request from the client; otherwise, the request is forwarded to the backup node, which then receives the request from the client.

3. The method according to claim 2, characterized in that, After determining that the master node's health status is normal, the method further includes: Obtain the client data corresponding to the request; Rate limiting detection is performed based on the client data to obtain the rate limiting result; If the rate limiting result is determined to be unsuccessful, the request will be intercepted.

4. The method according to claim 1, characterized in that, The method further includes: When the type is determined to be a static request, the cached data corresponding to the static request is obtained; The cached data is validated to obtain the validation result; If the verification result is found to be valid, the cached data is sent to the client.

5. The method according to claim 4, characterized in that, After verifying the cached data and obtaining the verification result, the method further includes: When the verification result is determined to be invalid; Obtain the local static data corresponding to the request, and send the local static data to the client; The cached data is updated based on the local static data.

6. The method according to claim 1, characterized in that, After sending health check data to the candidate node to obtain the health status of the candidate node, the method further includes: When the health status is determined to be abnormal, the candidate node is removed from all backend nodes to obtain the remaining backend nodes; According to the load balancing strategy, a new candidate node is selected from the remaining backend nodes, and the process of sending health check data to the candidate node is returned.

7. The method according to claim 1, characterized in that, The step of selecting candidate nodes from all backend nodes according to the load balancing strategy includes: Obtain the connection count and weight of each backend node; The backend node with the largest weight and a number of connections less than a preset connection threshold is selected as the candidate node.

8. A data request processing system, characterized in that, include: A receiving module is used to receive a request from a client and determine the type of the request; The selection module is used to select candidate nodes from all backend nodes according to the load balancing strategy when the receiving module determines that the type is a dynamic request. The inspection module is used to send health check data to the candidate nodes to obtain the health status of the candidate nodes; The sending module is used to send the request to the candidate node when the health status is determined to be normal, and to send the response data returned by the candidate node to the client.

9. A data request processing apparatus, comprising at least one processor and a memory; wherein, The memory stores computer-executed instructions; The at least one processor executes computer execution instructions stored in the memory, causing the at least one processor to perform the method of any one of claims 1 to 7.

10. A computer-readable storage medium storing a plurality of program codes, characterized in that, The program code is adapted to be loaded and run by a processor to perform the method of any one of claims 1 to 7.

Images