Data distribution method, electronic device, storage medium and program product

Abstract

The invention provides a data distribution method, electronic equipment, a storage medium and a program product. The method comprises the following steps: for each service node cluster in a plurality of service node clusters, performing state detection on each service node in the service node cluster to obtain a state parameter of each service node; determining a weight corresponding to each service node cluster based on the state parameters of the service nodes in the plurality of service node clusters; and distributing the service data in the plurality of service node clusters based on the weight corresponding to each service node cluster. According to the invention, the accuracy of data distribution can be effectively improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a data distribution method, electronic device, storage medium, and program product. Background Art

[0002] A business node cluster is a collection of multiple business nodes. Each business node is an independent computing unit, which can be a server, container, or other computing resource, used to process specific business logic. Organizing multiple business nodes into clusters improves the scalability and reliability of business processing. Business nodes in a business node cluster can work together to complete business data processing. Typically, there are multiple business node clusters, and how to distribute business data across them has become a hot research topic. Summary of the Invention

[0003] The embodiments of the present application provide a data distribution method, electronic device, storage medium, and program product, which can effectively improve the accuracy of data distribution.

[0004] The technical solution of the embodiment of the present application is implemented as follows:

[0005] The present invention provides a data distribution method, including:

[0006] For each service node cluster in the plurality of service node clusters, performing status detection on each service node in the service node cluster to obtain a status parameter of each service node;

[0007] Determine the weight corresponding to each business node cluster based on the status parameters of the business nodes in the multiple business node clusters;

[0008] Based on the weight of each service node cluster, the service data is distributed among the multiple service node clusters.

[0009] The present invention provides a data distribution device, including:

[0010] a detection module, configured to perform status detection on a service node in each of the plurality of service node clusters to obtain a status parameter of the service node;

[0011] A weight module, configured to determine a weight corresponding to each of the plurality of service node clusters based on status parameters of the service nodes in the plurality of service node clusters;

[0012] The distribution module is used to distribute the business data among the multiple business node clusters based on the weight of each business node cluster.

[0013] An embodiment of the present application provides an electronic device, including:

[0014] a memory for storing computer-executable instructions or computer programs;

[0015] The processor is configured to implement the data allocation method provided in the embodiment of the present application when executing the computer executable instructions or computer program stored in the memory.

[0016] An embodiment of the present application provides a computer-readable storage medium storing computer-executable instructions for causing a processor to execute the instructions to implement the data allocation method provided in the embodiment of the present application.

[0017] An embodiment of the present application provides a computer program product, which includes a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the data distribution method described in the embodiment of the present application.

[0018] The embodiments of the present application have the following beneficial effects:

[0019] By performing status detection on the business nodes in the business node cluster for each business node cluster in multiple business node clusters, the status parameters of the business nodes are obtained. The status parameters reflect the comprehensive conditions of the business nodes, such as the processing capacity and load conditions of the business nodes. Based on the status parameters of the business nodes in multiple business node clusters, the corresponding weight of each business node cluster is determined. Since the calculation of the weight takes into account the comprehensive performance of the business nodes in the business node cluster, the rationality of the weight distribution is ensured. Based on the weight, the business data is distributed among multiple business node clusters. The weight-based distribution method can dynamically adjust the data distribution amount according to the actual processing capacity of the business node cluster, thereby improving the accuracy of data distribution and ensuring that the business data can be processed efficiently and reasonably in each business node cluster. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 Schematic diagram of the data distribution system provided in the embodiment of the present application;

[0021] Figure 2 This is a schematic diagram of the structure of an electronic device for data distribution provided by an embodiment of the present application;

[0022] Figure 3 Schematic diagram of the data distribution method provided in the embodiment of the present application;

[0023] Figure 4It is a schematic diagram of the principle of the data distribution method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0024] In order to make the purpose, technical solutions and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limiting this application. All other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0025] In the following description, reference is made to “some embodiments”, which describes a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0026] In the following description, the terms "first\second\third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0027] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0028] Before further describing the embodiments of the present application in detail, the nouns and terms involved in the embodiments of the present application are explained. The nouns and terms involved in the embodiments of the present application are subject to the following interpretations.

[0029] 1) Routing Gateway: A network device that connects and selects paths between different networks or subnets. Based on the destination address and a specific routing algorithm, it forwards packets to the correct path, enabling communication between different networks.

[0030] 2) Business Node: A business node is the basic unit of a business node cluster. It is an entity with data processing capabilities, typically in the form of a server or high-performance computing device. In a business node cluster, multiple business nodes are organized into several business node clusters, each containing at least one business node. These business nodes jointly handle the business data to be processed by the cluster.

[0031] 3) Test Business Data: Test business data refers to data sets used in a specific test environment to verify and evaluate the performance, functionality, and stability of systems, applications, or business processes. This data is typically carefully designed to simulate various situations in real-world business scenarios, including normal operations, boundary conditions, and abnormal situations.

[0032] 4) Baseline business data: Baseline business data refers to a dataset used for reference and comparison in the initial or standard state of a system or business process. Baseline data is typically used to assess system performance changes at different time points or under different configurations, helping to identify and analyze performance improvements or degradations.

[0033] 5) Business Node Cluster: A business node cluster is a collection of multiple business nodes that work together to process and manage business data. Business nodes in a cluster can be further organized into multiple business node clusters, each containing at least one business node. The primary purpose of a business node cluster is to improve data processing efficiency and reliability through distributed computing and load balancing.

[0034] 6) Business Node: A basic unit within a business node cluster. Each business node is an entity with data processing capabilities, typically in the form of a server or high-performance computing device. A business node possesses computing resources, such as CPU, memory, and storage, to perform data processing operations.

[0035] 7) Load Balancer: A load balancer is a network device or software application used to distribute incoming network traffic across multiple servers or service instances. Its primary purpose is to optimize resource utilization, improve system throughput, and ensure that no single server becomes a performance bottleneck, thereby improving system reliability and responsiveness. The main function of a load balancer is to distribute incoming network requests to multiple backend servers or service instances. By properly distributing traffic, a load balancer ensures that no single server is overloaded, thereby improving the overall performance and responsiveness of the system. A load balancer can monitor the health of backend servers. If a server fails or degrades, the load balancer can automatically redirect traffic to other healthy servers, thereby improving system availability and reliability. A load balancer can handle SSL / TLS encryption and decryption operations, reducing the burden on backend servers and improving overall system performance.

[0036] During the implementation of the embodiments of this application, the applicant discovered that the related technology has the following problems:

[0037] In the related technology, for data distribution of the routing gateway, the business data is directly distributed evenly to each business node cluster in the business node cluster. Since the status of different business node clusters in the business node cluster is different, different business node clusters have different data requirements. Distributing the data evenly to each business node cluster in the business node cluster will lead to insufficient accuracy of data distribution. How to distribute business among multiple business node clusters has become a hot research issue.

[0038] The embodiments of the present application provide a data distribution method, electronic device, storage medium, and program product, which can effectively improve the accuracy of data distribution. The following describes an exemplary application of the data distribution system provided by the embodiments of the present application.

[0039] See also Figure 1 , Figure 1 1 is a schematic diagram of the architecture of the data distribution system 100 provided in an embodiment of the present application. The terminal (terminal 400 is shown as an example) is connected to the server 200 via the network 300. The network 300 can be a wide area network or a local area network, or a combination of the two.

[0040] The terminal 400 is used for the user to use the client 410 and display business data on a graphical interface 410-1 (graphic interface 410-1 is shown as an example). The terminal 400 and the server 200 are connected to each other via a wired or wireless network.

[0041] In some embodiments, the server 200 can be an independent physical server, or a server cluster or business system composed of multiple physical servers, or a cloud server that provides cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDN), and basic cloud computing services such as big data and artificial intelligence platforms. The terminal 400 can be a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a smart TV, a smart watch, a car terminal, etc., but is not limited to this. The electronic device provided in the embodiment of the present application can be implemented as a terminal or as a server. The terminal and the server can be directly or indirectly connected via wired or wireless communication, which is not limited in the embodiment of the present application.

[0042] In some embodiments, the server 200 performs status detection on each business node in the business node cluster to obtain the status parameters of each business node; based on the status parameters of each business node in each business node cluster, determines the weight corresponding to each business node cluster; based on the weight of each business node cluster, distributes the business data among multiple business node clusters.

[0043] In other embodiments, the terminal 400 performs status detection on each business node in the business node cluster to obtain status parameters of each business node; determines the weight corresponding to each business node cluster based on the status parameters of each business node in each business node cluster; and distributes business data among multiple business node clusters based on the weight of each business node cluster.

[0044] In other embodiments, the embodiments of the present application can be implemented with the help of cloud technology. Cloud technology refers to a hosting technology that unifies a series of resources such as hardware, software, and network within a wide area network or local area network to realize data calculation, storage, processing, and sharing.

[0045] Cloud technology is a general term for network, information, integration, management platform, and application technologies used in the cloud computing business model. It can form a resource pool that can be used flexibly and conveniently on demand. Cloud computing technology will become a key support. The backend services of technical network systems require a large amount of computing and storage resources.

[0046] See also Figure 2 , Figure 2 is a structural diagram of an electronic device 500 for data distribution provided in an embodiment of the present application, wherein: Figure 2 The electronic device 500 shown may be Figure 1 The server 200 or the terminal 400 in Figure 2 The electronic device 500 shown includes: at least one processor 430, a memory 450, and at least one network interface 420. The various components in the electronic device 500 are coupled together via a bus system 440. It is understood that the bus system 440 is used to achieve connection and communication between these components. In addition to including a data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, the bus system 440 is not described in detail. Figure 2 Various buses are labeled as bus system 440 .

[0047] The processor 430 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., where the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0048] The memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard drives, optical drives, etc. The memory 450 may optionally include one or more storage devices that are physically remote from the processor 430.

[0049] The memory 450 includes volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory may be a read-only memory (ROM), and the volatile memory may be a random access memory (RAM). The memory 450 described in the embodiments of the present application is intended to include any suitable type of memory.

[0050] In some embodiments, the memory 450 can store data to support various operations, examples of which include programs, modules, and data structures, or a subset or superset thereof, as exemplified below.

[0051] Operating system 451, including system programs for processing various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, and driver layer, which are used to implement various basic services and process hardware-based tasks;

[0052] The network communication module 452 is used to reach other electronic devices via one or more (wired or wireless) network interfaces 420. Exemplary network interfaces 420 include: Bluetooth, Wireless Fidelity (WiFi), and Universal Serial Bus (USB).

[0053] In some embodiments, the data distribution device provided in the embodiments of the present application can be implemented in software. Figure 2 The data distribution device 455 stored in the memory 450 is shown. This device can be software in the form of a program or plug-in, and includes the following software modules: a detection module 4551, a weighting module 4552, and an allocation module 4553. These modules are logical and can be arbitrarily combined or further separated according to the functions they implement. The functions of each module will be described below.

[0054] In other embodiments, the data distribution device provided in the embodiments of the present application can be implemented in hardware. As an example, the data distribution device provided in the embodiments of the present application can be a processor in the form of a hardware decoding processor, which is programmed to execute the data distribution method provided in the embodiments of the present application. For example, the processor in the form of a hardware decoding processor can adopt one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field programmable gate arrays (FPGAs), or other electronic components.

[0055] In some embodiments, the terminal or server can implement the data distribution method provided in the embodiment of the present application by running a computer program or computer executable instructions. For example, the computer program can be a native program (e.g., a dedicated distribution program) or a software module in the operating system, for example, a distribution module that can be embedded in any program (such as an instant messaging client, a photo album program, an electronic map client, a navigation client); for example, it can be a local (Native) application (APP, Application), that is, a program that needs to be installed in the operating system to run. In short, the above-mentioned computer program can be any form of application, module or plug-in.

[0056] The data distribution method provided in the embodiment of the present application will be described in conjunction with the exemplary application and implementation of the server or terminal provided in the embodiment of the present application.

[0057] See also Figure 3 , Figure 3 This is a flow chart of the data distribution method provided in the embodiment of the present application, which will be combined with Figure 3 Steps 101 to 103 are shown for illustration. The data distribution method provided in the embodiment of the present application can be implemented by the server or the terminal alone, or by the server and the terminal in collaboration. The following description will be made using the server alone as an example.

[0058] In step 101 , for each service node cluster among a plurality of service node clusters, status detection is performed on the service nodes in the service node cluster to obtain status parameters of the service nodes.

[0059] In some embodiments, status parameters refer to a set of indicators used to describe and measure the current operating status of a single service node. These parameters typically include health parameters and load parameters, which can reflect the performance and health of the service node. Status parameters include health parameters: parameters that reflect whether the service node is operating normally, such as CPU temperature, memory error rate, disk failure rate, etc. These parameters are used to determine whether the node has hardware failures or abnormal conditions. Load parameters: parameters that reflect the current load of the service node, such as CPU utilization, memory usage, disk I / O speed, network bandwidth utilization, etc. These parameters are used to evaluate the processing capacity and load level of the node.

[0060] In some embodiments, the above-mentioned status parameters include the health parameters of the business node and the load parameters of the business node. The above-mentioned step 101 can be implemented in the following manner: performing a health check on each of the business nodes in the business node cluster to obtain the health parameters of each of the business nodes in the business node cluster, and the health parameters are used to indicate whether the operation of the business node is normal; performing a load check on each of the business nodes in the business node cluster to obtain the load parameters of each of the business nodes in the business node cluster.

[0061] In some embodiments, health parameters refer to a set of indicators used to measure the operational status of service node hardware and software. These parameters can reflect whether a service node has experienced a fault or anomaly, thereby helping to determine whether the node is functioning properly. Health parameters may include hardware health parameters such as CPU temperature, memory error rate, disk failure rate, and fan speed. These parameters are used to detect whether the hardware device is functioning properly. Software health parameters include system log error rate, application crash rate, and service response time. Health parameters are used to detect whether the software system is functioning properly.

[0062] In some embodiments, load parameters refer to a set of indicators used to measure the current processing capacity of a business node. These parameters can reflect the resource usage of the business node, thereby helping to determine whether the node can handle more business data. Load parameters may include: CPU load parameters: including CPU utilization, CPU waiting time, etc. These parameters are used to measure CPU usage. Memory load parameters: including memory utilization, memory swap rate, etc. These parameters are used to measure memory usage. Disk load parameters: including disk I / O speed, disk queue length, etc. These parameters are used to measure disk usage. Network load parameters: including network bandwidth utilization, network latency, etc. These parameters are used to measure network usage.

[0063] For example, consider the following health check parameters for node A1: CPU temperature: 40°C; memory error rate: 0.1%. The judgment is: Node A1 is operating normally and its health parameters are within the normal range. The following health check parameters for node A2: CPU temperature: 45°C; memory error rate: 0.2%. The judgment is: Node A2 is operating normally and its health parameters are within the normal range. Load check parameters for node A1: CPU utilization: 50%; memory utilization: 60%. The judgment is: Node A1 has a moderate load and can handle more business data. The following load parameters for node A2: CPU utilization: 60%; memory utilization: 70%. The judgment is: Node A2 has a high load, but is still within an acceptable range and can handle a small amount of business data.

[0064] In some embodiments, the above-mentioned status detection of the business nodes in the business node cluster to obtain the status parameters of the business nodes can also be achieved in the following way: for each business node in the business node cluster, a parameter acquisition request is sent to the business node, and the operating parameters returned by the business node based on the parameter acquisition request are received; based on the operating parameters, a health detection is performed on the business node to obtain the health parameters of the business node.

[0065] In other embodiments, for each business node, the status parameters of the business node include the load parameters of the business node; the above-mentioned status detection of the business nodes in the business node cluster to obtain the status parameters of the business nodes can be achieved in the following way: calculating the mean and standard deviation of the node loads of multiple business nodes in the business node cluster; for each business node, determining the difference between the mean and the node load of the business node as the first parameter of the business node; and determining the ratio between the first parameter and the standard deviation as the load parameter of the business node.

[0066] In this way, the health of each business node in the business node cluster is checked and its health parameters are obtained. This step ensures that only nodes that are operating normally are included in the subsequent load assessment and data allocation process, thereby avoiding the impact of faulty nodes on overall performance. Subsequently, based on the cluster parameters of the business node cluster, each business node is load-checked to obtain load parameters. This enables the system to accurately understand the current resource usage of each node. By combining health parameters and load parameters, the system can dynamically and reasonably allocate business data, ensuring that data is allocated to nodes that are both healthy and have low loads. This dynamic allocation strategy based on status parameters not only improves data processing efficiency and reduces performance bottlenecks caused by node overload, but also enhances the overall stability and availability of the system. Through meticulous status detection and reasonable data allocation, efficient and stable operation of the business node cluster is achieved.

[0067] In some embodiments, the above-mentioned health check of the business nodes in the business node cluster to obtain the health parameters of the business nodes in the business node cluster can be achieved as follows: the following processing is performed for each of the business nodes in the business node cluster: multiple parameter acquisition requests are sent to each of the business nodes in the business node cluster, and the operating parameters of the business nodes returned by each business node based on the parameter acquisition request are received; based on the operating parameters corresponding to each parameter acquisition request, the health check of the business node is performed to obtain the health parameters of the business node.

[0068] In some embodiments, multiple parameter acquisition requests are sent to each service node in the service node cluster. These requests are intended to obtain key operating parameters of the service node, such as CPU temperature, memory error rate, disk failure rate, fan speed, etc. Through these requests, a comprehensive understanding of the hardware and software operating status of the service node can be obtained, thereby determining whether the node is operating normally. Parameter acquisition requests are sent to each service node using standardized detection protocols (such as SNMP, IPMI) or custom APIs. These requests can be sent periodically to ensure real-time detection of node status.

[0069] In some embodiments, operating parameters returned by each service node in response to a parameter acquisition request are received. These parameters are specific numerical values ​​indicating the service node's current operating status. By receiving these parameters, real-time operating data of the service node can be collected, providing a basis for subsequent health monitoring. After receiving the parameter acquisition request, the service node returns the corresponding operating parameters. These parameters can be transmitted back to the detection system via the network, which receives and stores them.

[0070] In some embodiments, a health check is performed on the service node based on the operating parameters corresponding to each parameter acquisition request. Health checking is performed by analyzing these operating parameters to determine whether the service node is in normal operation. Through health checking, abnormal conditions of the service node, such as hardware failures and software errors, can be discovered in a timely manner, so that corresponding measures can be taken. Health checking can be judged based on preset thresholds or rules. For example, a CPU temperature exceeding 80°C may be considered abnormal, and a memory error rate exceeding 0.5% may be considered abnormal. The detection system will evaluate each operating parameter based on these thresholds or rules to generate health parameters. Health parameters are the results of health checks and are used to indicate whether the service node is operating normally. These parameters can be binary (normal / abnormal) or specific numerical values ​​(such as health scores). Health parameters provide an important basis for subsequent data allocation and resource management. Only service nodes whose health parameters indicate that the node is operating normally will be included in the scope of data allocation.

[0071] By sending multiple parameter retrieval requests to each service node in the service node cluster and receiving the returned operational parameters, health checks are performed to obtain health parameters, significantly improving the reliability and operational efficiency of the service node cluster. First, multi-parameter retrieval requests ensure comprehensive monitoring of service node status, covering key indicators such as CPU temperature and memory error rate, making health checks more accurate. Health checks based on these operational parameters can promptly detect potential faults, such as abnormally high CPU temperature or excessive memory error rate. This not only prevents faulty nodes from participating in service data processing, preventing data loss and processing delays, but also provides data support for preventive maintenance and extends the lifespan of hardware equipment. Furthermore, accurate health parameters provide a reliable basis for subsequent load balancing strategies, ensuring that only healthy nodes participate in load distribution, optimizing resource utilization, and improving overall system performance. This combination of proactive monitoring and preventive maintenance significantly reduces the risk of system failures, enhances business continuity, and provides a strong guarantee for the stable operation of large-scale distributed systems.

[0072] In some embodiments, the above-mentioned health detection of the business node based on the operating parameters to obtain the health parameters of the business node can be achieved in the following manner: obtaining the parameter difference between the operating parameters corresponding to multiple parameter acquisition requests, and comparing the parameter difference with the difference interval to obtain a comparison result; if the comparison result of the difference interval indicates that the parameter difference falls within the difference interval, then the preset health parameter corresponding to the difference interval is determined as the health parameter of the business node.

[0073] In some embodiments, parameter difference refers to the degree of difference between the operating parameters returned by different parameter acquisition requests. These differences can be numerical differences or state differences. By calculating the parameter difference, the stability of the business node in multiple key indicators can be evaluated. For example, the difference between CPU temperature and memory error rate can reflect the overall health status of the node. The difference interval refers to a preset series of numerical ranges, each interval corresponding to a different health status. By comparing the parameter difference with the difference interval, the health status of the business node can be quickly determined. The health parameter is determined based on the difference interval to which the parameter difference belongs, and is used to indicate the health status of the business node. By comparing the parameter difference with the difference interval, the health status of the business node can be quickly determined, providing a basis for subsequent operation, maintenance and management.

[0074] As an example, assume a service node cluster contains two service nodes (node ​​A and node B). The specific implementation process is as follows: Determine parameter difference: Node A's operating parameters are: CPU temperature is 45°C, memory error rate is 0.1%. Node B's operating parameters are: CPU temperature is 50°C, memory error rate is 0.2%. Calculate the parameter difference of node A: parameter difference A = 45-0.1×100 = 45-10 = 35, calculate the parameter difference of node B: parameter difference B = 50-0.2×100 = 50-20 = 30, compare the difference and the difference interval: preset difference interval: interval 1: 0-10 (good health); interval 2: 11-20 (medium health); interval 3: 21-30 (poor health); interval 4: 31 and above (abnormal health), compare the parameter difference 35 of node A with the difference interval: 35 belongs to interval 4 (31 and above), the health parameter is abnormal, compare the parameter difference 30 of node B with the difference interval: 30 belongs to interval 3 (21-30), the health parameter is poor, determine the health parameter, the health parameter of node A: abnormal, the health parameter of node B: poor.

[0075] In this way, the health status of a service node is assessed by determining parameter variance and comparing it against a preset variance range. Parameter variance is calculated based on multiple key operating parameters, such as CPU temperature and memory usage. The variance of these parameters comprehensively reflects the operational status of the service node. Comparing parameter variance with the preset variance range quickly identifies the health level of the service node. For example, if the parameter variance falls within a low range, it indicates stable node operation and good health; whereas, a high variance may indicate a potential failure risk. The advantage is that it can quickly and accurately identify nodes requiring attention, allowing proactive maintenance or adjustments to be taken to prevent potential failures from impacting overall system performance. Furthermore, by presetting health parameters, decisions can be made based on clear criteria, improving operational efficiency and system reliability. This parameter variance-based health assessment method not only improves fault detection accuracy but also provides strong support for preventive maintenance, helping to extend equipment life, reduce operational costs, and ensure the efficient and stable operation of the service node cluster.

[0076] In some embodiments, the above-mentioned load detection of the business nodes in the business node cluster to obtain the load parameters of the business nodes in the business node cluster can be achieved as follows: the following processing is performed on each of the business nodes in the business node cluster: the difference between the mean of the node load of each business node in the business node cluster and the node load of the business node is determined as the first parameter of the business node; the ratio between the first parameter and the standard deviation of the node load of each business node in the business node cluster is determined as the load parameter of the business node.

[0077] In some embodiments, in a business node cluster, the mean and standard deviation of the node load of each business node in the business node cluster are used to evaluate the overall performance and stability of the business node cluster. Based on these cluster parameters, each business node can be load detected to obtain the load parameters of each business node. The average value of the node load of all business nodes in the business node cluster is calculated, and the standard deviation of the node load of all business nodes in the business node cluster is calculated to measure the degree of dispersion of the node load. For each business node in the business node cluster, the difference between its node load and the mean is calculated, and this difference is called the first parameter. The first parameter reflects the deviation of the node load of the node from the average level of the business node cluster. The ratio of the first parameter to the standard deviation is determined as the load parameter of the business node. The load parameter is used to measure the degree of deviation of the load of the node from the average level of the business node cluster. The load parameter can help identify which nodes have a load higher or lower than the average level, thereby providing a basis for load balancing.

[0078] In some embodiments, node load refers to the number or complexity of service requests a service node needs to process within a certain period of time. It reflects the workload and resource consumption of the node. Node load is an important indicator for measuring service node performance and resource utilization. By monitoring and analyzing node load, we can understand the system's operating status, identify performance bottlenecks, and implement corresponding optimization and expansion.

[0079] For example, in a data center server cluster scenario, suppose we have a business node cluster consisting of several servers, each responsible for processing business data. To ensure these servers operate efficiently and evenly, we need to monitor their load. Key performance indicators, such as CPU utilization, are collected for each server in the business node cluster. The average (mean) and dispersion (standard deviation) of these indicators across the entire business node cluster are then calculated. These two values ​​constitute the cluster parameters of the business node cluster, providing a reference for the overall performance level of the business node cluster. We perform load monitoring on each server in the business node cluster. Specifically, we calculate the difference between each server's CPU utilization and the business node cluster mean. This difference reflects the degree to which the server's performance indicator deviates from the business node cluster average, and we call it the first parameter. We then compare this first parameter with the standard deviation of the business node cluster to obtain a ratio, which is the server's load parameter. The load parameter indicates whether each server's load is high or low relative to the business node cluster average. If a server's load parameter is positive and large, it means its CPU utilization is significantly higher than the average for the business node cluster, indicating it may be overloaded. Conversely, if the load parameter is negative and large in absolute value, it may mean that the server's CPU utilization is below average and has spare capacity to handle more tasks. This allows us to quickly identify which servers need to be relieved of their load and which servers can share more work, thereby achieving load balancing across the entire business node cluster and improving data center operational efficiency and resource utilization.

[0080] In this way, the load parameter for each node is calculated using the mean and standard deviation of the node loads of the service nodes in the service node cluster. This step establishes a performance baseline and fluctuation range for the entire service node cluster. The mean reflects the average performance level of the service node cluster under specific parameters, while the standard deviation measures the dispersion of node performance. Next, for each service node, the difference between its node load and the mean is calculated to obtain a first parameter. This difference intuitively reflects the performance deviation of the node relative to the average level of the service node cluster. The ratio of the first parameter to the standard deviation is determined as the load parameter. This step further standardizes the node performance deviation, allowing direct comparison of load conditions across different nodes. This standardized load parameter not only allows for rapid identification of nodes with excessive or insufficient loads but also provides a scientific basis for resource allocation and task scheduling. For example, when allocating tasks, new tasks are preferentially assigned to nodes with lower load parameters, thus avoiding overloading some nodes while leaving others idle, thereby improving resource utilization efficiency across the entire service node cluster.

[0081] In step 102, based on the status parameters of the service nodes in the plurality of service node clusters, a weight corresponding to each service node cluster is determined.

[0082] In some embodiments, weight refers to a relative importance value assigned to each business node cluster in a multi-node system based on the status parameters of the business nodes of each business node cluster. The weight reflects the processing power and resource allocation priority of the business node cluster in the overall system, and is used to optimize data distribution and load balancing. The weight is used to reasonably distribute business data among multiple business node clusters to ensure that the load of each business node cluster matches its processing power. Business node clusters with higher weights usually have stronger processing power and therefore are allocated more business data. The weight helps to dynamically adjust resource allocation based on the actual performance and health of the business node cluster, thereby improving the overall efficiency and stability of the system. When some business node clusters fail or performance degrades, more business data can be allocated to healthy business node clusters by adjusting the weight, ensuring high availability of the system.

[0083] In some embodiments, the calculation of weights is typically based on status parameters of the business nodes in the business node cluster, such as health parameters and load parameters. These parameters reflect the current operating status and processing capacity of each node. The weights can be determined by a comprehensive evaluation of multiple status parameters. For example, the health parameters and load parameters can be weighted and summed to obtain a comprehensive score for each business node cluster, and then these scores are normalized into weights. The weights are not fixed, but are dynamically adjusted according to the real-time status of the business node cluster. For example, if the load parameters of a business node cluster suddenly increase, its weight may be reduced accordingly to avoid overload.

[0084] As an example, assume a data center's service node clusters consist of three service node clusters, each containing multiple servers. To optimize data distribution, a weight for each service node cluster needs to be calculated. Health and load checks are performed on the servers in each service node cluster, collecting health parameters (such as CPU temperature and memory error rate) and load parameters (such as CPU utilization and memory usage). The health and load parameters of each service node cluster are weighted and summed to obtain a comprehensive score. For example, the comprehensive score of service node cluster A is: 0.8 (health parameter) + 0.7 (load parameter) = 1.5; the comprehensive score of service node cluster B is: 0.9 (health parameter) + 0.6 (load parameter) = 1.5; and the comprehensive score of service node cluster C is: 0.7 (health parameter) + 0.8 (load parameter) = 1.5. The comprehensive scores are normalized to weights, ensuring that the sum of the weights of all service node clusters is 1. For example, the weight of each service node cluster is determined to be 0.33. During the actual data distribution process, the system will distribute business data to various business node clusters based on these weights, ensuring that the load of each business node cluster matches its processing capacity, thereby improving the efficiency and stability of the entire system.

[0085] In some embodiments, the above-mentioned determination of the weight corresponding to each business node cluster based on the status parameters of the business nodes in the multiple business node clusters can be achieved in the following manner: the sum of the status parameters of the business nodes in the multiple business node clusters is determined as the first status parameter; for each business node cluster, the sum of the status parameters of the multiple business nodes in the business node cluster is determined as the second status parameter of the business node cluster, and the ratio between the second status parameter and the first status parameter is determined as the weight corresponding to the business node cluster.

[0086] In some embodiments, in a distributed system, to optimize resource allocation and load balancing, the weight of each service node cluster needs to be determined based on the status parameters of the service nodes in each service node cluster. For each service node, its status parameters (such as health parameters and load parameters) are summed to obtain a first status parameter for the node. These status parameters may include CPU utilization, memory usage, disk I / O speed, etc. By summing multiple status parameters, a comprehensive indicator is obtained, which is used to evaluate the overall performance and health of a single service node. Assuming that each service node has multiple status parameters, such as CPU utilization, memory usage, and disk I / O speed, the values ​​of these parameters are summed to obtain the first status parameter of the node. For each service node cluster, the first status parameters of all service nodes in the service node cluster are summed to obtain the second status parameter of the service node cluster. By summing the first status parameters of all service nodes in the service node cluster, a comprehensive indicator is obtained, which is used to evaluate the overall performance and health of the entire service node cluster. Assuming that there are multiple service nodes in the service node cluster, the first status parameters of each node are summed to obtain the second status parameter of the service node cluster. The weight of each service node cluster is calculated by calculating the ratio of the second state parameter of each service node cluster to the sum of the second state parameters of all service node clusters. By calculating this ratio, the weight of each service node cluster is normalized to ensure that the sum of the weights of all service node clusters is 1. This ensures fair and reasonable resource allocation. Assuming there are multiple service node clusters in the system, the second state parameter of each service node cluster is added together to obtain the sum. Then, the second state parameter of each service node cluster is divided by the sum to obtain the weight of the service node cluster.

[0087] As an example, assume a service node cluster includes three service node clusters (A, B, and C), each containing two service nodes. The state parameters of each service node include CPU utilization, memory utilization, and disk I / O speed. The specific implementation process is as follows: Calculate the first state parameters of each service node. Service node cluster A: Node 1: CPU utilization = 50%, memory utilization = 60%, disk I / O speed = 70%. Node 2: CPU utilization = 60%, memory utilization = 70%, disk I / O speed = 80%. Node 1's first state parameters = 50 + 60 + 70 = 180. Node 2's first state parameters = 60 + 70 + 80 = 210. Service node cluster B: Node 1: CPU utilization = 70%, memory utilization = 80%, disk I / O speed = 90%. Node 2: CPU utilization = 80%, memory utilization = 90%, disk I / O speed = 100%. Node 1's first state parameter = 70 + 80 + 90 = 240, and Node 2's first state parameter = 80 + 90 + 100 = 270. Service node cluster C: Node 1: CPU utilization = 40%, memory utilization = 50%, disk I / O speed = 60%. Node 2: CPU utilization = 50%, memory utilization = 60%, disk I / O speed = 70%. Node 1's first state parameter = 40 + 50 + 60 = 150. Node 2's first state parameter = 50 + 60 + 70 = 180. Calculate the second state parameter for each service node cluster: Service node cluster A's second state parameter = 180 + 210 = 390; Service node cluster B's second state parameter = 240 + 270 = 510; Service node cluster C's second state parameter = 150 + 180 = 330. Calculate the weight of each service node cluster. The sum of the second state parameters of all service node clusters = 390 + 510 + 330 = 1230. The weight of service node cluster A = 1230390≈0.32, the weight of service node cluster B = 1230510≈0.42, and the weight of service node cluster C = 1230330≈0.27.

[0088] In this way, weight calculation is based on real-time status parameters, dynamically reflecting the processing capacity and health of each business node cluster. This enables the system to rationally distribute business data based on the current operating status, preventing situations where some business node clusters are overloaded while others are idle. By normalizing weights, the sum of the weights of all business node clusters is ensured to be 1, thereby achieving fair resource allocation. When certain business node clusters fail or experience performance degradation, their weights are reduced accordingly, and the system automatically allocates more business data to healthy business node clusters, ensuring high system availability. By comprehensively considering multiple status parameters, the performance of each business node cluster can be comprehensively assessed, providing a sound basis for decision-making and further optimizing system performance and resource utilization efficiency. This effectively evaluates and optimizes resource allocation and load balancing across business node clusters, improving overall system performance and stability.

[0089] In step 103, the service data is distributed among the multiple service node clusters based on the weight of each service node cluster.

[0090] In some embodiments, business data refers to the various data generated, processed, and transmitted during the business processes of an enterprise or organization. This data is typically related to business operations, transactions, user behavior, system status, and other aspects, and is a critical resource supporting enterprise decision-making, operations, and management. In a distributed computing environment, business data is processed by a cluster of business nodes and is used to implement various business logic and functions.

[0091] In some embodiments, business data may come from business systems, human-computer interaction, and external data sources. Business data primarily comes from various business systems of an enterprise, such as customer relationship management systems (CRM), enterprise resource planning systems (ERP), and supply chain management systems (SCM). Data generated by users when using the system, such as order information, transaction records, and user behavior logs. Data obtained from external systems or third-party services, such as market data, weather data, and news data, may also be sourced.

[0092] In some embodiments, business data can be structured data, which has a fixed format and structure, such as table data in a database or records in a log file. Semi-structured data, which has a certain structure but is less strict than structured data, can be formatted as JSON or XML. Unstructured data, which has no fixed format or structure, can be formatted as text files, images, or videos.

[0093] In some embodiments, determining the business data to be processed by a business node cluster can be achieved by: clarifying the specific requirements for the business data the business node cluster needs to process, including data type, data source, and data volume. For example, a business node cluster in an e-commerce system may need to process order data, user behavior data, and inventory data. Based on the business requirements, determine the performance requirements for data processing, such as response time and throughput. Identify the enterprise's internal business systems and databases to determine which systems can provide the required business data. For example, an ERP system can provide inventory data, and a CRM system can provide customer order data. If necessary, identify external data sources, such as third-party data service providers, to obtain supplemental data. Business data is acquired from data sources in real time using data collection tools or APIs. For example, ETL (Extract, Transform, Load) tools can be used to extract data from a database. For data that does not require real-time processing, batch collection can be performed periodically. For example, transaction data for the previous day can be extracted from a data warehouse every evening. Remove noise and errors from the data to ensure data accuracy and consistency. For example, duplicate records can be deleted and format errors corrected. Compress the data to reduce storage space and transmission time, thereby obtaining the business data to be processed by the business node cluster.

[0094] In some embodiments, cluster parameters refer to a set of indicators used to describe and measure the overall performance and status of a service node cluster. These parameters are typically calculated based on the node load of each service node in the cluster and can reflect the overall performance and health of the cluster. The average value of the node load of all service nodes in the cluster parameters is used to reflect the average performance level of the cluster, and the standard deviation of the node load of all service nodes in the cluster is used to measure the degree of dispersion of node performance in the cluster. The smaller the standard deviation, the more uniform the node performance; the larger the standard deviation, the greater the difference in node performance.

[0095] In some embodiments, the above-mentioned distribution of business data among multiple business node clusters based on the weight of each business node cluster can be achieved in the following manner: performing fault detection on each business node cluster to obtain a fault detection result corresponding to each business node cluster; for each business node cluster, adjusting the weight corresponding to the business node cluster based on the fault detection result corresponding to the business node cluster to obtain an adjusted weight; based on the adjusted weight corresponding to each business node cluster, distributing the business data among the multiple business node clusters.

[0096] In some embodiments, in a distributed system, the allocation of business data needs to consider not only the weight of the business node cluster, but also the health status of the business node cluster. Through fault detection and weight adjustment, it can be ensured that business data is reasonably allocated to healthy business node clusters, thereby improving overall performance and reliability. Fault detection is performed on each business node cluster to determine whether there is a fault in the business node cluster. Fault detection can be achieved in a variety of ways, such as detecting the health parameters, response time, error rate, etc. of the business nodes in the business node cluster. Through fault detection, abnormal conditions in the business node cluster are discovered in a timely manner, and business data is avoided from being allocated to a faulty business node cluster, thereby improving the reliability and stability of the system. Regularly perform health checks on each business node cluster to collect the health parameters and operating status of the business nodes in the business node cluster. If multiple nodes in a business node cluster are found to have faults or performance abnormalities, the business node cluster is marked as a faulty state.

[0097] In some embodiments, the weights of service node clusters are adjusted based on fault detection results. If a service node cluster is detected to be faulty, its weight should be reduced accordingly, or even temporarily set to zero to prevent service data from being allocated. By adjusting weights, service data is allocated only to healthy service node clusters, thereby optimizing resource allocation and improving overall system performance and reliability. The weights of service node clusters are dynamically adjusted based on fault detection results. For example, if service node cluster A is detected to be faulty, its weight can be adjusted from 0.32 to 0.10, or temporarily set to 0 until the fault is fixed. By allocating data based on the adjusted weights, service data is allocated only to healthy service node clusters, thereby improving overall system performance and reliability. The amount of service data to be allocated to each service node cluster is calculated based on the adjusted weights. For example, if service node cluster A has a weight of 0.10, service node cluster B has a weight of 0.42, and service node cluster C has a weight of 0.48, service data will be allocated to each service node cluster based on these weight ratios.

[0098] In some embodiments, fault detection is performed on each of the business node clusters to obtain a fault detection result corresponding to each business node cluster, which can be achieved as follows: define fault detection indicators: Health parameters: including CPU temperature, memory error rate, disk failure rate, network delay, etc. These parameters are used to evaluate the health of the hardware and network. Performance parameters: including CPU utilization, memory usage, disk I / O speed, network bandwidth utilization, etc. These parameters are used to evaluate the performance and load of the system. Response time: The response time of the system to a request, used to evaluate the real-time and responsiveness of the system. Error rate: The number of errors occurring in the system, used to evaluate the stability and reliability of the system. Set a reasonable threshold for each fault detection indicator. The setting of the threshold should be based on historical data and system design requirements. For example: CPU temperature: over 80°C; memory error rate: over 0.5%; disk failure rate: over 0.1%; network latency: over 100ms; CPU utilization: over 90%; memory usage: over 90%; disk I / O speed: less than 10MB / s; network bandwidth utilization: over 90%; response time: over 2 seconds; error rate: over 1%. Set a fixed monitoring cycle, such as every 5 minutes. During each monitoring cycle, perform a health check on all service nodes in each service node cluster. Analyze the collected data to determine whether each metric exceeds the preset threshold. If a metric exceeds the threshold, record the abnormality and generate a corresponding alarm. Comprehensively assess the overall health of the service node cluster based on the health and performance parameters of all service nodes. If multiple nodes in a service node cluster fail or multiple key metrics exceed thresholds, the service node cluster is marked as faulty. Detailed fault information, including the faulty node, fault metric, and fault time, is recorded.

[0099] As an example, assume a service node cluster contains three service node clusters (A, B, and C), each with an initial weight of 0.32, 0.42, and 0.27, respectively. Fault detection is performed on each service node cluster, collecting the health parameters and operating status of the service nodes within the cluster. Assume that the fault detection results indicate that multiple nodes in service node cluster A have failed, and service node cluster A is marked as faulty. Based on the fault detection results, the weight of service node cluster A is adjusted. For example, the weight of service node cluster A is adjusted from 0.32 to 0.10. The weights of service node clusters B and C remain unchanged at 0.42 and 0.27, respectively. To ensure that the sum of the weights of all service node clusters is 1, the weights need to be normalized. The adjusted weights are: service node cluster A: 0.13; service node cluster B: 0.56; service node cluster C: ≈0.33. Assume the total service data volume is 1000 units. Based on the adjusted weights, the amount of business data to be allocated to each business node cluster is calculated: Business node cluster A's business data volume: 130 units; Business node cluster B's business data volume: 560 units; and Business node cluster C's business data volume: 330 units. Business data is distributed to each business node cluster based on the above proportions. This ensures a reasonable distribution of business data, ensuring that business data is allocated only to healthy business node clusters, thereby improving the overall performance and reliability of the system.

[0100] In this way, abnormal conditions in the business node cluster, such as node failures or performance degradation, can be discovered in a timely manner. The fault detection results provide an accurate basis for subsequent weight adjustments, ensuring that only healthy business node clusters are assigned business data. Weights are adjusted based on the fault detection results so that the weights can dynamically reflect the actual health status and processing capacity of the business node cluster. For example, if a business node cluster is detected to have a fault, its weight will be reduced or even temporarily set to zero, thereby preventing the business node cluster from receiving new business data. The dynamic adjustment mechanism not only improves the system's fault tolerance, but also ensures that business data is reasonably distributed to healthy business node clusters, optimizing resource utilization. Finally, business data is distributed based on the adjusted weights. This process ensures that the distribution of business data takes into account both the processing capacity and health status of the business node cluster, thereby achieving efficient load balancing.

[0101] In some embodiments, the above-mentioned adjustment of the weight corresponding to the business node cluster based on the fault detection result corresponding to the business node cluster can be achieved in the following manner: if the fault detection result of the business node cluster indicates that there is no fault, no adjustment is made; if the fault detection result of the business node cluster indicates that there is a fault, the preset value is used as the adjusted weight.

[0102] In some embodiments, the preset value can be set to zero. In a distributed system, adjusting the weights of service node clusters based on fault detection results is an effective resource management strategy. This approach ensures that only healthy service node clusters are allocated service data, thereby improving overall system performance and reliability. Each service node cluster is fault-checked to obtain a fault detection result. The fault detection result indicates whether the service node cluster is faulty. The fault detection result is used to determine the health of the service node cluster, providing a basis for weight adjustment. Monitoring tools are used to regularly monitor the health and performance parameters of the service nodes in the service node cluster, such as CPU temperature, memory error rate, disk failure rate, and network latency. If multiple nodes in a service node cluster experience faults or multiple key metrics exceed thresholds, the service node cluster is marked as faulty. Based on the fault detection results, the weight of the service node cluster is adjusted to ensure that only healthy service node clusters are allocated service data, preventing faulty service node clusters from impacting the overall system performance and reliability. If the fault detection result for a service node cluster indicates that the service node cluster is not faulty, the weight of the service node cluster remains unchanged and is determined as the adjusted weight. If the fault detection result of the service node cluster indicates that the service node cluster has a fault, the adjusted weight of the service node cluster is determined to be zero, and the allocation of service data to the service node cluster is temporarily stopped.

[0103] As an example, assume a service node cluster contains three service node clusters (A, B, and C), each with an initial weight of 0.32, 0.42, and 0.27, respectively. Fault detection is performed on each service node cluster, and the health and performance parameters of the service nodes in the cluster are collected. Assume that the fault detection results show: Service node cluster A: Fault (CPU temperatures of multiple nodes exceed thresholds); Service node cluster B: No fault; Service node cluster C: No fault. Based on the fault detection results, the weight of each service node cluster is adjusted: Service node cluster A: Fault, adjusted weight to 0. Service node cluster B: No fault, adjusted weight remains unchanged at 0.42. Service node cluster C: No fault, adjusted weight remains unchanged at 0.27. To ensure that the sum of the weights of all service node clusters is 1, the adjusted weights need to be normalized. The total adjusted weight is 0.42 + 0.27 = 0.69.

[0104] In this way, by adjusting the weights of service node clusters based on fault detection results, the reliability and performance of distributed systems can be significantly improved. When the fault detection results for a service node cluster indicate that it is not faulty, its original weight remains unchanged. This ensures that healthy service node clusters can continue to receive service data based on their processing capabilities, maintaining efficient system operation. Conversely, if the fault detection results indicate that a service node cluster is faulty, its weight is adjusted to a preset value (zero). This measure directly prevents service data from flowing to the faulty service node cluster, avoiding performance degradation, data loss, or service interruption that may result from data processing by the faulty node. This weight adjustment strategy not only improves the system's fault tolerance but also optimizes resource allocation, ensuring that service data is rationally distributed to healthy service node clusters, thereby improving resource utilization efficiency and responsiveness across the entire system. By dynamically adjusting weights, the system can quickly adapt to changes in the health of the service node cluster, enhancing the system's adaptability and stability, and providing a strong guarantee for the efficient and stable operation of the distributed system.

[0105] In some embodiments, the multiple service node clusters include multiple test service node clusters and multiple baseline service node clusters, and the service data includes test service data to be processed by the test service node clusters and baseline service data to be processed by the baseline service node clusters.

[0106] In some embodiments, the above-mentioned allocation of the business data to the sub-business data corresponding to each of the business node clusters based on the weight can be achieved in the following ways: based on the weight of each of the test business node clusters, the test business data is allocated to the sub-business data corresponding to each of the test business node clusters; based on the weight of each of the baseline business node clusters, the baseline business data is allocated to the sub-business data corresponding to each of the baseline business node clusters.

[0107] In some embodiments, in a distributed system, business data can generally be divided into test business data and baseline business data. Test business data is used to verify the performance of new features or optimization solutions, while baseline business data is used to maintain the system's daily operations. To ensure that this data is reasonably distributed to different business node clusters, business node clusters can be divided into test business node clusters and baseline business node clusters, and data distribution is performed based on their respective weights. Test business node clusters: Process test business data, which is generally used to verify the performance of new features or optimization solutions. Baseline business node clusters: Process baseline business data, which is used to maintain the system's daily operations and ensure system stability and reliability. Test business node cluster weighting: The weight of each test business node cluster is determined based on its health and processing capacity. Baseline business node cluster weighting: The weight of each baseline business node cluster is determined based on its health and processing capacity. Test business data distribution: Test business data is distributed to each test business node cluster based on its weight. Baseline business data distribution: Baseline business data is distributed to each baseline business node cluster based on its weight.

[0108] As an example, assume a service node cluster consists of three test service node clusters (T1, T2, and T3) and two baseline service node clusters (B1 and B2). The specific implementation steps are as follows: Test service node clusters: T1, T2, and T3; Baseline service node clusters: B1 and B2. Assume that through fault detection and health assessment, the following weights are obtained: Weight of test service node cluster T1: 0.4; Weight of test service node cluster T2: 0.3; Weight of test service node cluster T3: 0.3; Weight of baseline service node cluster B1: 0.6; Weight of baseline service node cluster B2: 0.4. Assume that the total test service data volume is 1000 units and the total baseline service data volume is 800 units. The sub-service data volume of T1 is: 1000 × 0.4 = 400 units; the sub-service data volume of T2 is: 1000 × 0.3 = 300 units; the sub-service data volume of T3 is: 1000 × 0.3 = 300 units. The sub-service data volume of B1 is: 800×0.6=480 units; the sub-service data volume of B2 is: 800×0.4=320 units.

[0109] In this way, dividing business data into test business data and baseline business data and allocating them according to their respective weights can significantly improve the resource utilization efficiency and system stability of distributed systems. Specifically, test business data is allocated to the test business node cluster, ensuring that the verification process of new functions or optimization solutions does not affect the daily operation of the system. At the same time, baseline business data is allocated to the baseline business node cluster, ensuring system stability and reliability. This separation and weighted distribution strategy not only improves the overall performance of the system, but also enhances its fault tolerance, enabling the system to better cope with various situations and ensure efficient and stable operation.

[0110] In this way, by performing status detection on each business node in the business node cluster, the status parameters of each business node are obtained. The status parameters reflect the comprehensive conditions of the business nodes, such as the processing capacity and load conditions of the business nodes. Based on the status parameters of the business nodes in each business node cluster, the weight corresponding to each business node cluster is determined. Since the calculation of the weight takes into account the comprehensive performance of all business nodes in the business node cluster, the rationality of the weight distribution is ensured. Based on the weight, the business data is distributed to each business node cluster for separate processing. The weight-based distribution method can dynamically adjust the data distribution amount according to the actual processing capacity of the business node cluster, thereby improving the accuracy of data distribution and ensuring that the business data can be processed efficiently and reasonably in each business node cluster, thereby effectively improving the accuracy of data distribution.

[0111] The following describes an exemplary application of the embodiment of the present application in an actual routing gateway application scenario.

[0112] In some embodiments, see Figure 4 , Figure 4 This is a schematic diagram of the data distribution method provided in an embodiment of the present application. It includes a weighted decision engine; a health probe module that collects HTTP status codes every 5 seconds and uses a sliding window to calculate health H_i(t); a load detection module that obtains APISIX connections in real time and performs Z-Score normalization; a dynamic compensation algorithm that ensures baseline traffic flow (Q_base = max(0.2, 1-ΣW_slane / N_slane); a routing executor (ETCD synchronizer that pushes routing configurations to cluster nodes every 10 seconds); an APISIX configuration generator that converts weight calculation results into upstream configurations; additional modules: a reverse label injection module that automatically converts the Host header through DNS resolution and mapping; and a circuit breaker controller that isolates and recovers from abnormal environments based on a Redis cluster.

[0113] In some embodiments, see Figure 4, Message Queue Agent: Production Agent, HMAC Tag Generation: Use 256-bit key to calculate message header MAC value, Shadow Queue Routing: Automatically deliver to baseline_topic_shadow_{laneID}. Consumer Agent Tag Verification Filter: Verify message HMAC integrity, Dead Letter Queue Processing: Isolate messages with mismatched tags.

[0114] In some embodiments, the dynamic configuration center: version tree management: the baseline environment is the trunk branch, and the lane is lane_{ID}; incremental patch generation: generating configuration patches by comparing grayscale parameter differences; hot update push: long polling mechanism realizes dynamic update of connection pool parameters.

[0115] In some embodiments, see Figure 4 ,Detection system: Component 1: Collects circuit breaking status indicators; Component 2: Visually displays routing weight distribution and circuit breaking status.

[0116] In some embodiments, see Figure 4 The intelligent routing gateway is the core control layer of the system. It implements traffic scheduling across hybrid environments through dynamic weight allocation and real-time health detection, and supports full-link grayscale release. The weight decision engine dynamically adjusts the traffic distribution strategy through multi-dimensional indicators to ensure the load balancing and high availability of the business gateway cluster. Health probe module: Initiates a health check request to the business gateway cluster every 5 seconds, collects HTTP status codes (such as 200, 503), and calculates the real-time health H_i(t) based on the sliding window algorithm. The health H_i(t) is calculated based on the sliding window algorithm. By collecting the HTTP status code (such as 200, 503) of each node in the business gateway cluster every 5 seconds, the real-time health status of the node is dynamically evaluated. The health is for a single node, and the health of different nodes is different, not for the cluster as a whole. The health probe directly detects the HTTP status of each node in the business gateway cluster as the basis for health assessment.

[0117] In some embodiments, see Figure 4 Health probes directly monitor the HTTP status of each node in the service gateway cluster as a basis for health assessment. Real-time APISIX connection counts (such as the number of active requests) are obtained and normalized using the Z-Score formula: Z = \frac{L_i(t) - \mu}{\sigma}; where \mu is the average number of connections in the cluster and \sigma is the standard deviation, which is used to eliminate the impact of varying node sizes.

[0118] In some embodiments, the object is a business gateway cluster. Standardization uses Z-Score instead of a fixed threshold to dynamically adapt to traffic fluctuations. The baseline traffic guarantee formula is: Q_{base}=\max(0.2,1-\frac{\sumW_{slane}}{N_{slane}}. W_{slane} represents the sum of the weights of a lane (slane, that is, the business node cluster described above). When the total weight of a lane exceeds the threshold, the dynamic compensation algorithm reduces its traffic allocation to prevent overload. N_{slane} refers to the number of nodes in the lane (that is, the business node cluster described above) or the total number of lanes, which is used to calculate the baseline traffic guarantee Q_{base}. The formula dynamically adjusts the traffic distribution by the ratio of the sum of the weights to the number of nodes.

[0119] In some embodiments, when the sum of the weights of a lane exceeds a threshold, its traffic allocation is dynamically reduced to prevent overload. Lanes are logically isolated traffic paths (such as a grayscale environment or a baseline environment). The service gateway cluster is responsible for allocating traffic to nodes in different lanes based on weight. For example, grayscale traffic might be routed to lane 1, while baseline traffic is routed to lane 2. Weights are calculated using health H_i(t) and the load metric Z. The routing executor converts these weights into APISIX configurations, enabling dynamic traffic adjustments (e.g., de-weighting a faulty node). The weight calculation formula is: text{weight} = H_i(t) \ times (1-Z), where H_i(t) is the node health and Z is the load Z-score. Nodes with high health and low load receive higher weights and receive more traffic. The routing executor converts the weight calculation results into APISIX upstream configurations (e.g., 70% weight allocated to lane 1). APISIX dynamically adjusts routing policies based on the new configuration. For example, if the health of a faulty node decreases, its weight decreases, and traffic is diverted to healthy nodes.

[0120] In some embodiments, see Figure 4 , the routing executor is responsible for sending the decision results to the gateway cluster to ensure that the policy takes effect in real time. The ETC D synchronizer pushes the latest routing configuration (such as weight, circuit breaker status) to the intelligent routing gateway cluster node every 10 seconds, not the Redis cluster. Refers to the cluster node of the intelligent routing gateway itself to ensure multi-node configuration consistency. Cluster node The cluster node of the intelligent routing gateway itself. The ET CD synchronizer pushes the routing configuration to these nodes to ensure that the configuration of all intelligent routing gateway instances is consistent and avoid policy conflicts. Convert the weight calculation results into the upstream configuration of APISIX, for example: yaml, upstreams:id:lane_1;weight:70%;id:lane_2;weight:30%.

[0121] In some embodiments, APISIX makes routing decisions based on the new configuration, such as allocating 70% of traffic (i.e., the business data described above) to the healthier lane_1. Traffic originates from client requests (e.g., HTTP requests from users accessing services). APISIX routes the requests to the service gateway node in the corresponding lane based on the configured weight (e.g., 70% allocated to lane_1).

[0122] In some embodiments, see Figure 4 , through DNS resolution, the Host header is mapped to an internal label (such as env=gray), enabling automatic grayscale identification of requests. Through DNS resolution, the Host header is mapped to an internal label (such as env=gray), allowing requests to automatically carry the grayscale identification. The routing component implements grayscale traffic distribution without client modification based on the label matching strategy.

[0123] In some embodiments, see Figure 4 , based on the Redis cluster to store circuit breaker status (such as node failure flags), automatically isolate the abnormal node when triggered, and gradually redirect traffic after recovery. The circuit breaker status (such as node_1:CIRCUIT_OPEN) is written to Redis, and the circuit breaker node is preferentially excluded when making routing decisions. Suppose the business gateway cluster has nodes A, B, and C. When node A fails, the circuit breaker controller writes its status (node_A:CI RCUIT_OPEN) to Redis. The routing executor reads the Redis status and sets the weight of node A to 0, distributing traffic only to nodes B and C to achieve fault isolation.

[0124] In some embodiments, see Figure 4 The message queue proxy implements grayscale control of cross-environment message routing, ensuring consistency throughout the entire data link. The message queue proxy and the gateway share grayscale parameters (such as laneID) from the dynamic configuration center, ensuring that message tags (such as x-env=gray) are consistent with the gateway routing policy, achieving full-link grayscale control.

[0125] In some embodiments, see Figure 4For the production agent, the 256-bit key issued by the dynamic configuration center is used to calculate the HMAC signature of the message header to identify the grayscale environment (such as x-env:gray). The identification allows the system to route grayscale messages to the corresponding environment (such as the test queue), ensuring that the test traffic is physically isolated from the baseline traffic to avoid data contamination. The shadow queue routing automatically delivers grayscale messages to baseline_topic_shadow_{laneID} to isolate the test traffic. The test traffic comes from the grayscale release process, such as requests sent by test users or automated testing tools. The production agent delivers it to baseline_topic_shadow_2 based on the message tag (such as laneID=2), isolating it from the production queue.

[0126] In some embodiments, the production agent reads the message tag (e.g., laneID=2) and dynamically selects a queue topic to achieve physical isolation between the baseline environment and the grayscale environment. The baseline environment (i.e., the baseline service node cluster described above) is a stable production environment, corresponding to the trunk branch (i.e., the test service node cluster described above), which handles normal traffic. The grayscale environment is an isolated test environment, corresponding to the lane branch (lane_{ID}), used to verify new features or configurations.

[0127] In some embodiments, see Figure 4 , for consumer agents, verify the HMAC signature of the message and reject unsigned or invalidly signed messages. Messages that fail verification are transferred to the dead letter queue and an alarm is triggered (such as notifying operations and maintenance to investigate key leaks). Dead letter messages are persistently stored and support manual review, replay, or batch repair to avoid data loss. The production agent obtains grayscale parameters (such as laneID) from the dynamic configuration center to ensure that the message label is consistent with the routing policy. The production agent obtains grayscale parameters (such as laneID) from the dynamic configuration center and uses the same configuration source as the gateway. Consistency ensures that grayscale messages are correctly routed to the corresponding lane to avoid routing errors or data confusion due to label mismatch. When a lane (such as lane_2) triggers a circuit breaker (node ​​failure), the consumer agent suspends consuming messages in that lane to avoid continuous processing of failed requests, which causes a surge in downstream service pressure (avalanche effect) until the lane is restored.

[0128] In some embodiments, see Figure 4 The dynamic configuration center implements unified management and real-time synchronization of all parameters across the entire chain, supporting grayscale releases. Baseline environments (trunk branches) and lane environments (lane_{ID}) are managed independently, supporting parallel modifications and rapid rollbacks.

[0129] In some embodiments, the baseline environment (trunk branch) is functionally positioned as the production trunk environment, corresponding to the stable released configuration version, and all functions that have passed the final verification are merged into this branch. Features: The configuration only accepts merge requests that have passed test verification to ensure the stability of the production environment. Data is physically isolated from the grayscale environment (such as an independent database and API gateway) to prevent test traffic from contaminating production data. Lane environment (lane_{ID}): Functional positioning: a logically isolated test branch, each lane_{ID} represents an independent development / grayscale test scenario 37. Features: Parallel development: different lanes can carry different functional iterations or version updates at the same time without affecting each other. For example: lane_1: verification branch configuration for new function A; lane_2: branch configuration for emergency bug fixes. Routing isolation: traffic is distributed to corresponding lanes according to labels (such as env=lane_1) through the dynamic routing policy of the intelligent gateway.

[0130] In some embodiments, by comparing grayscale parameter differences (e.g., timeout period from 100ms to 150ms), a patch file containing only the changes is generated, reducing distribution overhead. Configuration updates (e.g., key rotation, weight thresholds) are pushed to intelligent routing gateways and message queue agents via a long polling mechanism. The routing gateway detects configuration changes and immediately implements new policies (e.g., dynamic compensation algorithm parameters) without restarting the service.

[0131] In some embodiments, for the detection system, component 1: collects indicators such as circuit breaker status (such as the number of circuit breaker triggers), routing weight distribution, etc., and stores them as time series data. Visualize key indicators: Component 2: visualize key indicators, for example, the proportion of traffic in each lane, circuit breaker node status), and set threshold alarms (such as the node is disconnected for more than 5 minutes). The circuit breaker indicator can be used for real-time circuit breaker status for automatic expansion (such as K8s elastic scaling). Historical data analysis optimizes the weight algorithm (such as the weight decay strategy for high-load nodes).

[0132] In some embodiments, access and label injection are requested (data flow 1: service gateway → routing gateway). Traditionally, direct access to the lane SLB results in label loss, requiring manual intervention to repair the link. DNS hijacking and domain name resolution: DNS resolution for all grayscale domain names (e.g., gray.example.com) is hijacked to the VIP (virtual IP) of the intelligent routing gateway cluster, rather than directly pointing to the backend service gateway. The routing gateway automatically identifies grayscale traffic based on the domain name suffix (e.g., -gray), triggering label injection logic.

[0133] In some implementations, HTTP header rewriting allows the routing gateway to dynamically insert the following tags through OpenResty's header_filter_by_lua phase: nginx; add_header X-Env gray; add_header X-LaneID 2. A reverse label injection engine is introduced, combining DNS hijacking with HTTP header rewriting to achieve zero-intrusion transparent transmission of labels, completely resolving the label gap issue.

[0134] In some embodiments, request routing and weighting are pre-determined. Before receiving a request, the routing gateway obtains the latest routing rules (data flow 2) from the configuration center through long polling. The weighting decision engine pre-calculates the initial weights for each lane (e.g., 80% for the baseline environment and 20% for the lane) and generates a routing snapshot. Requests with the X-Env:gray tag enter the grayscale routing logic. Untagged requests are routed to the baseline environment by default as a fallback.

[0135] In some embodiments, dynamic routing decision and execution (data flow 2+3: Weight Engine → Routing Executor). The health probe module collects HTTP status codes from the service gateway every 5 seconds and calculates the success rate within a 60-second window. An exponential decay function is introduced to penalize nodes with high latency: H_i(t) = \frac{\text{Number of Successes}}{\text{Total Number}}\times e^{-0.01\times\text{Average Latency}}. The Moving Average Convergence Divergence (MACD) model identifies trending changes in node health and avoids transient jitter interference.

[0136] In some embodiments, the load monitoring module obtains the number of active connections of APISIX in real time. Based on the historical data of the cluster, μ (mean) and σ (standard deviation) are calculated, and the Z value is updated in real time: Z = \frac{L_i(t)-\mu}{\sigma}. When Z>2, the node weight is reduced according to the gradient (such as weight × 0.8 when Z = 2, weight × 0.5 when Z = 3). When the sum of the lane weights exceeds 80%, at least 20% of the traffic is forced to be retained in the baseline environment, the formula is: Q_{base} = \max(0.2,1-\frac{\sumW_{slane}}{N_{slane}}).

[0137] In some embodiments, if a lane's weight is reduced to zero due to a fault, its traffic is redistributed according to the health ratio of the remaining lanes. The weight decision engine converts the calculation results into Protobuf format, with the following structure:

[0138]

[0139] In some embodiments, the TCD synchronizer writes the routing table to the / gray / routes path of ETCD every 10 seconds, and each node of the intelligent routing gateway monitors the changes in real time through the Watch mechanism. The routing executor converts the Protobuf data into the upstream configuration of APISIX, for example:

[0140]

[0141] APISIX performs routing based on the new configuration and dynamically adjusts traffic distribution with an error control within ±3%.

[0142] In some embodiments, for circuit breaker detection and triggering, the continuous error threshold is that the node returns a 5xx status code five times in a row. The response time threshold is that the average delay exceeds 500ms and the success rate is less than 90%. For circuit breaker marking, the circuit breaker controller writes the circuit breaker status to the Redis cluster, and the data structure is a Hash. An expiration time is set for each circuit breaker record (the default is 300 seconds) to prevent the faulty node from occupying resources. After the circuit breaker node is restored, 10% of the traffic is first allocated to observe the stability. If the trial is successful, the traffic is increased to 30% → 50% → 100% every 5 minutes. If the circuit breaker is triggered again at any stage, it will immediately fall back to the previous step and extend the recovery cycle.

[0143] In some embodiments, when generating and delivering message tags, the production agent obtains a 256-bit key (rotated every 24 hours) from the dynamic configuration center and uses the HMAC-SHA256 algorithm to generate a signature: \text{Signature} = \text{HMAC}(Key, \text{Message ID} + \text{Timestamp}). The signature is written to the X-Gray-Sign field of the message header, along with the lane ID (e.g., X-LaneID: 2).

[0144] In some embodiments, shadow queue routing, the production agent delivers messages to the baseline queue (baseline_topic) and the shadow queue (baseline_topic_shadow_2) at the same time. The shadow queue uses an independent storage cluster to prevent grayscale traffic from affecting the baseline business. The consumer agent obtains the latest key from the configuration center through long polling. The consumer agent reads the X-Gray-Sign of the message header, recalculates the HMAC value and compares it, with an error tolerance time window of ±30 seconds. Messages that fail verification are transferred to dead_letter_queue_gray, and the reason for failure is recorded (such as signature expiration, key mismatch). If the backlog of the dead letter queue exceeds the threshold, the Serverless function is triggered to re-sign and re-deliver in batches.

[0145] In some embodiments, the Prometheus data model: routing metrics: promql, route_weight{slane="lane_2"}0.5, circuit_breaker_status{node="192.168.2.1"}1#1=OPEN,0=CLOSED; message queue metrics: promql, message_latency_seconds{queue="baseline_topic_shadow_2"}0.8, dead_letter_count{reason="invalid_sign"}15.

[0146] In some embodiments, visualization and alerting are provided through Grafana dashboard design: Traffic distribution chart: A stacked area chart displays the traffic share of each lane. Abnormal lanes are marked in red and display the circuit breaker status. Message trace tracking: HTTP requests and message delivery are linked using TraceIDs to achieve end-to-end tracing across components. If the proportion of circuit breaker nodes in a lane exceeds 30%, the alarm platform will trigger a notification and automatically create a work order. If the synchronization delay between the configuration center and the routing gateway exceeds 10 seconds, an enterprise WeChat alert will be triggered.

[0147] In some embodiments, the weight algorithm is adjusted and historical data is analyzed: based on the health and load data of the past 7 days, a linear regression model is trained to optimize the attenuation coefficient α and the Z-Score threshold. A / B testing: the old and new weight algorithms are run in parallel, and the optimal solution is selected by comparing the success rate and latency indicators. Automatically merge patches: If a lane configuration (such as the database timeout) performs well during the grayscale period, a merge request is automatically generated to the baseline branch. Rollback robot: If the grayscale configuration causes the error rate to increase, it will automatically trigger a rollback to the previous stable version.

[0148] This approach integrates financial risk control models with real-time load balancing to achieve sub-second response times and baseline security for traffic distribution. DNS hijacking and HTTP header rewriting address the fundamental label gap problem in traditional solutions. The HMAC signature-based shadow queue mechanism fills the industry gap in support for asynchronous message grayscale. Combined with TCP slow start and circuit breaker state persistence, this approach enables gradual recovery of failed nodes.

[0149] It is understandable that in the embodiments of the present application, when business data and other related data are involved, when the embodiments of the present application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions.

[0150] The following continues to describe the exemplary structure of the data distribution device 455 provided in the embodiment of the present application implemented as a software module. In some embodiments, such as Figure 2 As shown, the software modules stored in the data distribution device 455 of the memory 450 may include: a detection module, which is used to perform status detection on the business nodes in each business node cluster in a plurality of business node clusters to obtain status parameters of the business nodes; a weight module, which is used to determine the weight corresponding to each of the business node clusters based on the status parameters of the business nodes in the plurality of business node clusters; and an allocation module, which is used to allocate business data among the plurality of business node clusters based on the weight of each business node cluster.

[0151] In some embodiments, the status parameters of the business node include the health parameters of the business node; the above-mentioned detection module is also used to send a parameter acquisition request to the business node, and receive the operating parameters returned by the business node based on the parameter acquisition request; based on the operating parameters, perform a health check on the business node to obtain the health parameters of the business node.

[0152] In some embodiments, the number of the parameter acquisition requests is multiple; the above-mentioned detection module is also used to obtain the parameter difference between the operating parameters corresponding to the multiple parameter acquisition requests, and compare the parameter difference with the difference interval to obtain a comparison result; if the comparison result indicates that the parameter difference falls within the difference interval, the health parameter corresponding to the difference interval is determined as the health parameter of the business node.

[0153] In some embodiments, the status parameters of the business node include the load parameters of the business node; the number of the business nodes is multiple; the above-mentioned detection module is also used to calculate the mean and standard deviation of the node load of multiple business nodes in the business node cluster; for each business node, the difference between the mean and the node load of the business node is determined as the first parameter of the business node; and the ratio between the first parameter and the standard deviation is determined as the load parameter of the business node.

[0154] In some embodiments, the above-mentioned weight module is also used to perform fault detection on each business node cluster to obtain a fault detection result corresponding to each business node cluster; for each business node cluster, based on the fault detection result corresponding to the business node cluster, the weight corresponding to the business node cluster is adjusted to obtain an adjusted weight; based on the adjusted weight corresponding to each business node cluster, the business data is distributed among the multiple business node clusters.

[0155] In some embodiments, the weight module is further configured to: if the fault detection result of the service node cluster indicates that no fault exists, then no adjustment is made; if the fault detection result of the service node cluster indicates that a fault exists, then a preset value is used as the adjusted weight.

[0156] An embodiment of the present application provides a computer program product, which includes a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the data distribution method described in the embodiment of the present application.

[0157] The embodiment of the present application provides a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, the processor will execute the data distribution method provided by the embodiment of the present application, for example, Figure 3 The data distribution method shown.

[0158] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface storage, optical disk, or CD-ROM; or various electronic devices including one or any combination of the above memories.

[0159] In some embodiments, computer-executable instructions may be in the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0160] As an example, computer-executable instructions may, but need not, correspond to a file in a file system, may be stored as part of a file that stores other programs or data, such as, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinating files (e.g., files storing one or more modules, subroutines, or code portions).

[0161] By way of example, computer-executable instructions may be deployed to be executed on one electronic device, or on multiple electronic devices located at one site, or on multiple electronic devices distributed across multiple sites and interconnected by a communication network.

[0162] In summary, the embodiments of the present application have the following beneficial effects:

[0163] (1) By performing status detection on each business node in the business node cluster, the status parameters of each business node are obtained. The status parameters reflect the comprehensive status of the business node, such as the processing capacity and load condition of the business node. Based on the status parameters of the business nodes in each business node cluster, the weight corresponding to each business node cluster is determined. Since the calculation of the weight takes into account the comprehensive performance of all business nodes in the business node cluster, the rationality of the weight distribution is ensured. Based on the weight, the business data is allocated to each business node cluster for separate processing. The weight-based allocation method can dynamically adjust the data allocation amount according to the actual processing capacity of the business node cluster, thereby improving the accuracy of data allocation and ensuring that the business data can be processed efficiently and reasonably in each business node cluster, thereby effectively improving the accuracy of data allocation.

[0164] (2) By sending multiple parameter acquisition requests to each business node in the business node cluster and receiving the operating parameters returned by it, health detection is performed to obtain health parameters, which significantly improves the reliability and operation and maintenance efficiency of the business node cluster. First, the multi-parameter acquisition request ensures comprehensive monitoring of the business node status, covering key indicators such as CPU temperature and memory error rate, making health detection more accurate. Health detection based on these operating parameters can timely detect potential faults, such as abnormally high CPU temperature or excessive memory error rate. This not only prevents the faulty node from participating in business data processing, preventing data loss and processing delays, but also provides data support for preventive maintenance and extends the service life of hardware equipment. In addition, accurate health parameters provide a reliable basis for subsequent load balancing strategies, ensuring that only healthy nodes participate in load distribution, optimizing resource utilization, and improving overall system performance. This combination of active monitoring and preventive maintenance greatly reduces the risk of system failures, enhances business continuity, and provides a strong guarantee for the stable operation of large-scale distributed systems.

[0165] (3) The health status of the business node is evaluated by determining the parameter difference and comparing it with the preset difference interval. The parameter difference is calculated based on multiple key operating parameters, such as CPU temperature, memory usage, etc. The difference of these parameters can comprehensively reflect the operating status of the business node. By comparing the parameter difference with the preset difference interval, the level of health of the business node can be quickly located. For example, if the parameter difference falls within the lower interval, it indicates that the node is running stably and in good health; if the difference is high, it may mean that there is a potential failure risk. The advantage is that it can quickly and accurately identify nodes that need attention, so that measures can be taken in advance for maintenance or adjustment to avoid the impact of potential failures on the overall performance of the system. At the same time, by presetting health parameters, decisions can be made based on clear standards, which improves operation and maintenance efficiency and system reliability. This health assessment method based on parameter difference not only improves the accuracy of fault detection, but also provides strong support for preventive maintenance of the system, helps to extend the service life of equipment, reduce operation and maintenance costs, and ensure the efficient and stable operation of the business node cluster.

[0166] (4) By using the mean and standard deviation of the node load of the business nodes in the business node cluster to calculate the load parameters of each node, the mean and standard deviation of the node load are calculated. This step sets a performance benchmark and fluctuation range for the entire business node cluster. The mean reflects the average performance level of the business node cluster under specific parameters, while the standard deviation measures the degree of dispersion of the node performance. Then, for each business node, the first parameter is obtained by calculating the difference between its node load and the mean. This difference intuitively reflects the performance deviation of the node relative to the average level of the business node cluster. The ratio of the first parameter to the standard deviation is determined as the load parameter. This step further standardizes the performance deviation of the node, so that the load conditions between different nodes can be directly compared. This standardized load parameter can not only quickly identify nodes with excessively high or low loads, but also provide a scientific basis for resource allocation and task scheduling. For example, when allocating tasks, new tasks are preferentially allocated to nodes with lower load parameters, thereby avoiding the situation where some nodes are overloaded while other nodes are idle, thereby improving the resource utilization efficiency of the entire business node cluster.

[0167] (5) The calculation of weights is based on real-time status parameters, which can dynamically reflect the processing capacity and health status of each business node cluster. This enables the system to reasonably allocate business data based on the current operating status, avoiding the situation where some business node clusters are overloaded while other business node clusters are idle. By normalizing the weights, the sum of the weights of all business node clusters is ensured to be 1, thereby achieving fair resource allocation. When some business node clusters fail or their performance degrades, their weights will be reduced accordingly, and the system will automatically allocate more business data to healthy business node clusters to ensure high availability of the system. By comprehensively considering multiple status parameters, the performance of each business node cluster can be comprehensively evaluated, providing a scientific decision-making basis, and further optimizing the performance and resource utilization efficiency of the system. It can effectively evaluate and optimize the resource allocation and load balancing of business node clusters, and improve the overall performance and stability of the system.

[0168] (6) It can timely detect abnormal situations in the business node cluster, such as node failure or performance degradation. The fault detection results provide an accurate basis for subsequent weight adjustment, ensuring that only healthy business node clusters are allocated business data. The weights are adjusted based on the fault detection results so that the weights can dynamically reflect the actual health status and processing capacity of the business node cluster. For example, if a business node cluster is detected to have a fault, its weight will be reduced or even temporarily set to zero, thereby preventing the business node cluster from receiving new business data. The dynamic adjustment mechanism not only improves the fault tolerance of the system, but also ensures that business data is reasonably allocated to healthy business node clusters, optimizing resource utilization. Finally, business data is allocated based on the adjusted weights. This process ensures that the allocation of business data takes into account both the processing capacity and the health status of the business node cluster, thereby achieving efficient load balancing.

[0169] (7) By adjusting the weight of the business node cluster based on the fault detection results, the reliability and performance of the distributed system can be significantly improved. When the fault detection result of the business node cluster shows that there is no fault, its original weight remains unchanged, which ensures that the healthy business node cluster can continue to receive business data based on its processing capacity and maintain the efficient operation of the system. On the contrary, if the fault detection result shows that the business node cluster has a fault, its weight is adjusted to zero. This measure directly prevents business data from flowing to the faulty business node cluster, avoiding problems such as performance degradation, data loss or service interruption caused by the processing of data by the faulty node. The weight adjustment strategy not only improves the fault tolerance of the system, but also optimizes resource allocation, so that business data can be reasonably allocated to the healthy business node cluster, thereby improving the resource utilization efficiency and response speed of the entire system. By dynamically adjusting the weight, the system can quickly adapt to changes in the health status of the business node cluster, enhance the system's adaptability and stability, and provide a strong guarantee for the efficient and stable operation of the distributed system.

[0170] (8) Dividing business data into test business data and baseline business data and allocating them according to their respective weights can significantly improve the resource utilization efficiency and system stability of the distributed system. Specifically, test business data is allocated to the test business node cluster, ensuring that the verification process of new functions or optimization solutions does not affect the daily operation of the system. At the same time, baseline business data is allocated to the baseline business node cluster, ensuring the stability and reliability of the system. The separation and weight allocation strategy not only improves the overall performance of the system, but also enhances the system's fault tolerance, enabling the system to better cope with various situations and ensure efficient and stable operation.

[0171] (9) By determining the business data to be processed by the business node cluster, a clear goal is provided for the subsequent allocation process. Based on the cluster parameters of the business node cluster, the status of each business node in the business node cluster is detected to obtain the status parameters of each business node, so that the real-time status parameters of each business node can be accurately obtained. The status parameters reflect the comprehensive situation of the business node, such as the processing capacity and load condition of the business node. Based on the status parameters of the business nodes in each business node cluster, the weight corresponding to each business node cluster is determined. The calculation of the weight takes into account the comprehensive performance of all business nodes in the business node cluster, ensuring the rationality of the weight distribution. Based on the weight, the business data is distributed to the sub-business data corresponding to each business node cluster. The weight-based distribution method can dynamically adjust the data distribution amount according to the actual processing capacity of the business node cluster, thereby improving the accuracy of data distribution and ensuring that the business data can be processed efficiently and reasonably in each business node cluster, thereby effectively improving the accuracy of data distribution.

[0172] (10) Integrating financial risk control models with real-time load balancing, we achieve second-level response and baseline backup for traffic distribution. Through DNS hijacking and HTTP header rewriting, we address the fundamental problem of label faults in traditional solutions. The shadow queue mechanism based on HMAC signatures fills the industry gap in support for asynchronous message grayscale. Combining TCP slow start with circuit breaker state persistence, we achieve progressive recovery of failed nodes.

[0173] The above description is merely an embodiment of the present application and is not intended to limit the scope of protection of the present application. Any modifications, equivalent replacements, and improvements made within the spirit and scope of the present application are included in the scope of protection of the present application.

Claims

1. A data distribution method, characterized in that: The method comprises: For each service node cluster in the plurality of service node clusters, performing status detection on a service node in the service node cluster to obtain a status parameter of the service node; Determine the weight corresponding to each business node cluster based on the status parameters of the business nodes in the multiple business node clusters; Based on the weight corresponding to each service node cluster, the service data is distributed among the multiple service node clusters.

2. The method according to claim 1, characterized in that The status parameters of the service node include health parameters; The performing status detection on the service nodes in the service node cluster to obtain status parameters of the service nodes includes: Sending a parameter acquisition request to the service node, and receiving an operating parameter returned by the service node based on the parameter acquisition request; Based on the operating parameters, a health check is performed on the service node to obtain the health parameters of the service node.

3. The method according to claim 2, characterized in that The number of the parameter acquisition requests is multiple; the health detection of the service node based on the operating parameters to obtain the health parameters of the service node includes: Obtaining parameter differences between operating parameters corresponding to multiple parameter acquisition requests, and comparing the parameter differences with a difference interval to obtain a comparison result; If the comparison result indicates that the parameter difference falls within the difference interval, the health parameter corresponding to the difference interval is determined as the health parameter of the service node.

4. The method according to claim 1, wherein The state parameters of the service node include load parameters; the number of the service nodes is multiple; The performing status detection on the service nodes in the service node cluster to obtain status parameters of the service nodes includes: Calculating the mean and standard deviation of node loads of multiple service nodes in the service node cluster; For each service node, determining a difference between the mean value and the node load of the service node as a first parameter of the service node; A ratio between the first parameter and the standard deviation is determined as a load parameter of the service node.

5. The method according to claim 1, wherein There are multiple service nodes in each service node cluster, and determining a weight corresponding to each service node cluster based on status parameters of the service nodes in the multiple service node clusters includes: Determine the sum of the state parameters of the service nodes in the plurality of service node clusters as a first state parameter; For each service node cluster, summing the status parameters of multiple service nodes in the service node cluster to determine the second status parameter of the service node cluster; A ratio between the second state parameter and the first state parameter is determined as a weight corresponding to the service node cluster.

6. The method according to claim 1, characterized in that The distributing the service data among the plurality of service node clusters based on the weight of each service node cluster includes: Perform fault detection on each business node cluster to obtain the fault detection results corresponding to each business node cluster; For each service node cluster, based on a fault detection result corresponding to the service node cluster, adjusting a weight corresponding to the service node cluster to obtain an adjusted weight; The service data is distributed among the multiple service node clusters based on the adjusted weight corresponding to each service node cluster.

7. The method according to claim 6, characterized in that The adjusting the weight corresponding to the service node cluster based on the fault detection result corresponding to the service node cluster includes: If the fault detection result of the service node cluster indicates that there is no fault, no adjustment is performed; If the fault detection result of the service node cluster indicates that a fault exists, the preset value is used as the adjusted weight.

8. An electronic device, characterized in that: The electronic device comprises: a memory for storing computer-executable instructions or computer programs; The processor is configured to implement the data distribution method according to any one of claims 1 to 7 when executing the computer executable instructions or computer program stored in the memory.

9. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that: When the computer executable instructions or computer program are executed by a processor, the data distribution method according to any one of claims 1 to 7 is implemented.

10. A computer program product comprising a computer program or computer executable instructions, characterized in that When the computer program or computer executable instructions are executed by a processor, the data distribution method according to any one of claims 1 to 7 is implemented.

Images