A load balancing method, device, medium and product

Abstract

The application discloses a load balancing method and device, medium and product. The method comprises the following steps: determining the index data of a service node based on a preset collection strategy, evaluating the index data, determining the node state type and comprehensive score of the service node; in response to a batch of user requests, determining the target proportion of request distribution according to the node state type and comprehensive score of the service node, and determining the matching result of the batch of user requests and the service node; forwarding the batch of user requests to the corresponding service node according to the target proportion and the matching result, so that the corresponding service node processes the received user requests, and load balancing is realized. The technical scheme of the application can comprehensively evaluate the service capacity of the node, accurately match the requests and the node according to the evaluation result, improve the business processing efficiency, and realize effective load balancing.

Description

Technical Field

[0001] This invention relates to the field of big data, and is applicable to the field of financial technology, particularly to a load balancing method, apparatus, medium, and product. Background Technology

[0002] Currently, the load balancing technologies of basic platforms in the financial industry are mainly divided into two categories: static load balancing technology and traditional dynamic load balancing technology. However, the core defect of static technology is that "rules are fixed" and cannot cope with the dynamic changes of the financial system. Traditional dynamic technology has obvious limitations in core financial scenarios: on the one hand, the indicators it collects are limited to the number of connections and response time, ignoring key financial indicators (such as data synchronization delay and transaction success rate); on the other hand, the strategy adjustment cycle is as long as 10-30 seconds, which cannot cope with sudden financial scenarios.

[0003] Therefore, how to conduct a more comprehensive evaluation of the service capabilities of nodes, combine the evaluation results to accurately match requests and nodes, improve business processing efficiency, and achieve effective load balancing is an urgent problem to be solved. Summary of the Invention

[0004] This invention provides a load balancing method, apparatus, medium, and product to more comprehensively evaluate the service capabilities of nodes, combine the evaluation results to accurately match requests and nodes, improve business processing efficiency, and achieve effective load balancing.

[0005] According to one aspect of the present invention, a load balancing method is provided, comprising: Based on the preset data collection strategy, the indicator data of the service nodes are determined, and the indicator data is evaluated to determine the node status type and comprehensive score of the service nodes. In response to batch user requests, the target proportion of request allocation is determined based on the node status type and comprehensive score of the service node, and the matching result of batch user requests and service nodes is determined. Based on the target ratio and matching results, batch user requests are forwarded to the corresponding service nodes to instruct the corresponding service nodes to perform business processing according to the received user requests, thereby achieving load balancing.

[0006] According to another aspect of the present invention, a load balancing device is provided, comprising: The evaluation module is used to determine the indicator data of service nodes based on a preset collection strategy, evaluate the indicator data, and determine the node status type and comprehensive score of the service nodes. The allocation module is used to respond to batch user requests, determine the target ratio of request allocation based on the node status type and comprehensive score of the service nodes, and determine the matching results of batch user requests and service nodes. The load balancing module forwards batch user requests to the corresponding service nodes based on the target ratio and matching results, instructing the corresponding service nodes to perform business processing according to the received user requests, thereby achieving load balancing.

[0007] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the load balancing method according to any embodiment of the present invention.

[0008] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the load balancing method according to any embodiment of the present invention.

[0009] According to another aspect of the present invention, a computer program product is also provided, the computer program product including a computer program that, when executed by a processor, implements the load balancing method of any embodiment of the present invention.

[0010] The technical solution of this invention, based on a preset data collection strategy, determines the indicator data of service nodes and evaluates the indicator data to determine the node status type and comprehensive score of the service nodes. In response to batch user requests, it determines the target proportion of request allocation based on the node status type and comprehensive score of the service nodes, and determines the matching result between the batch user requests and the service nodes. Based on the target proportion and the matching result, it forwards the batch user requests to the corresponding service nodes, instructing the corresponding service nodes to perform business processing according to the received user requests, thereby achieving load balancing. By conducting a more comprehensive evaluation of the service capabilities of the nodes and combining the evaluation results for precise matching of requests and nodes, business processing efficiency can be improved, and effective load balancing can be achieved.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart of a load balancing method provided in an embodiment of the present invention; Figure 2 This is a structural block diagram of a load balancing device provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of the electronic device provided in an embodiment of the present invention. Detailed Implementation

[0014] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0015] It should be noted that the terms "first," "second," "target," "candidate," and "alternative," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the invention described herein can be practiced in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus. The acquisition, storage, use, and processing of data in the technical solutions of this application comply with relevant laws and regulations.

[0016] It's important to note that static load balancing technologies often rely on round-robin or weighted round-robin algorithms. They allocate requests according to pre-defined fixed rules, without requiring real-time node status updates. Typical applications include non-core financial services (such as credit card bill push notifications). However, the core flaw of static technology lies in its "fixed rules," making it unable to handle dynamic changes in financial systems. For example, if a node experiences data processing delays due to disk failure, the weighted round-robin algorithm will still allocate requests according to fixed weights, causing some brokerage terminals to experience lag in market data updates. Traditional dynamic load balancing technologies, based on least-connections and response-time weighted algorithms, adjust allocation strategies by collecting basic node operational data. They are primarily used for non-core financial services. However, traditional dynamic technologies have significant limitations in core financial scenarios: firstly, the collected metrics are limited to connection count and response time, neglecting key financial indicators (such as data synchronization latency and transaction success rate); secondly, the strategy adjustment cycle is as long as 10-30 seconds, making it unable to handle sudden financial events. For instance, a sudden surge of tens of thousands of order requests might cause the CPU utilization of some nodes to spike to 95%, while traditional algorithms require more than 10 seconds to complete strategy adjustments, during which a large number of order requests fail. In summary, the relevant technologies suffer from three core problems: a single indicator dimension, which fails to meet the strong consistency requirements of finance; a slow response speed, which fails to cope with high-concurrency scenarios in finance; and a rudimentary switching mechanism, which fails to guarantee the continuity of financial business. To address these issues, this invention proposes a load balancing scheme with multi-dimensional perception, dynamic allocation, and seamless node switching. The specific implementation method will be described in detail in subsequent embodiments.

[0017] Example 1 Figure 1 This is a flowchart of a load balancing method provided in an embodiment of the present invention. This embodiment is applicable to situations where the service capabilities of nodes are evaluated more comprehensively, and requests and nodes are accurately matched based on the evaluation results to process batch requests and achieve load balancing. This method can be executed by a load balancing device, which can be implemented in hardware and / or software and can be configured in an electronic device, such as... Figure 1 As shown, the load balancing method includes: S101. Based on the preset collection strategy, determine the indicator data of the service node, evaluate the indicator data, and determine the node status type and comprehensive score of the service node.

[0018] The preset collection strategy represents the specific collection frequency and metrics for service nodes. This strategy can specify the collection frequency and metrics for different service nodes. A service node is a node that independently executes business processing in response to user requests; each service node corresponds to one primary node and one backup node. Metric data refers to data collected from service nodes based on the collected metrics. Metric data can specifically include at least one of the following: CPU (Central Processing Unit) utilization, memory usage, network bandwidth utilization, average transaction response time, transaction success rate, and data synchronization latency of the service node. Node status type represents whether a service node is operating normally or abnormally. Node status types are normal node, compliance-abnormal node, or business-abnormal node. The comprehensive score is the evaluation value obtained after evaluating the metric data of each service node based on a weighted scoring strategy and a compliance verification strategy.

[0019] Optionally, based on a preset collection strategy, the indicator data of the service node is determined, including: determining the collection indicators according to the node type and indicator category corresponding to the service node, and collecting data based on the preset collection frequency and collection indicators to obtain the indicator data corresponding to the service node.

[0020] The service nodes include the following node types: account query node, large-amount transfer node, transaction query node, core transaction node, accounting processing node, and market data push node. Indicator categories may include at least one of the following: basic resource indicators, business processing indicators, and regulatory compliance indicators. The business processing indicators and regulatory compliance indicators corresponding to different node types may be different or the same. Each indicator category may include at least one data collection indicator. Specifically, data collection indicators under basic resource indicators may include at least one of the following: CPU utilization, memory usage, and network bandwidth utilization; data collection indicators under business processing indicators may include average transaction response time and / or transaction success rate; data collection indicators under regulatory compliance indicators may include data synchronization latency.

[0021] For example, the collection frequency can be different for different collection indicators. For instance, the collection frequency for CPU utilization, memory usage, transaction success rate, and data synchronization latency can be once per second, the collection frequency for network bandwidth utilization can be once every 2 seconds, and the collection frequency for average transaction response time can be once every 500 milliseconds.

[0022] Optionally, the collected indicator data can be transmitted based on a bilateral protocol transmission mechanism. Specifically, the indicator data can be transmitted first via UDP (User Datagram Protocol) (high real-time performance). If the packet loss rate is greater than 1%, it will automatically switch to TCP (Transmission Control Protocol) (high reliability) to ensure that the data transmission meets the requirement of a data loss rate of ≤0.1%.

[0023] Optionally, after determining the indicator data of the service node, the process also includes: preprocessing and storing the indicator data; the preprocessing includes at least one of the following: deduplication, filtering and noise reduction, and compliance verification.

[0024] For example, duplicate data can be removed based on the triple key value of "node IP (Internet Protocol Address) + indicator type + collection timestamp", i.e., deduplication processing can be performed, such as duplicate reports caused by network fluctuations.

[0025] For example, a sliding window filtering algorithm (e.g., a window size of 5 acquisition cycles) can be used to eliminate instantaneous outliers (e.g., instantaneous CPU peak values), i.e., to perform filtering and noise reduction. For instance, if the CPU utilization of a node over 5 cycles is 55%, 57%, 98% (instantaneous peak value), 58%, and 57%, then the result after filtering is (55+57+58+57) / 4=56.75%.

[0026] For example, based on indicator data, the system can connect to the financial regulatory rule base. If the indicator data is detected to exceed the regulatory threshold (e.g., data synchronization delay > 500 milliseconds), the data is immediately marked as "compliance abnormal" and a pre-warning is triggered, i.e., compliance verification processing is carried out.

[0027] Optionally, after determining the indicator data, standardized data can be stored in a cluster (such as a cluster based on master-slave replication + sentinel mode) with a storage period of 30 days, which meets the requirement of "retaining transaction-related data for at least 5 years" in relevant regulations (long-term data is archived to a distributed file system).

[0028] Optionally, the indicator data is evaluated to determine the node status type and comprehensive score of the service node, including: for each service node, determining the transformation rules for the indicator data according to the indicator type corresponding to the collected indicator; and determining the node status type and comprehensive score of the service node according to the indicator data, the indicator weights corresponding to the collected indicators, and the transformation rules.

[0029] For different data collection metrics, such as CPU utilization, memory usage, network bandwidth utilization, average transaction response time, transaction success rate, and data synchronization latency, the weights can be set to 20%, 18%, 12%, 25%, 15%, and 10%, respectively. Metrics can be positive or negative; for positive metrics, higher values ​​are better, such as transaction success rate; for negative metrics, lower values ​​are better, such as response time.

[0030] Optionally, after determining the weights of each collected indicator, these weights can be adjusted if the adjustment criteria are met. Specifically, since core trading nodes are CPU-sensitive, their weights can be higher than those of non-core nodes. Accounting processing nodes' memory usage affects data consistency, so their weight can be set to 18%. Market data push nodes are bandwidth-sensitive, so their weight can be increased to 18%. Average transaction response time directly impacts customer experience, so its weight can be set to a maximum of 25%. Transaction success rate is a core regulatory indicator, so its weight is set second only to average transaction response time, at 15%. Data synchronization latency is a crucial indicator for ensuring transaction consistency, so its weight should not be lower than 8%.

[0031] Optionally, for negative indicators, such as average transaction response time, the conversion rules can be set as follows: ≤100 milliseconds earns 100 points, every additional 50 milliseconds deducts 20 points, and ≥300 milliseconds earns 0 points. For negative indicator data synchronization latency, the conversion rules can be set as follows: ≤300 milliseconds earns 100 points, every additional 100 milliseconds deducts 25 points, and ≥700 milliseconds earns 0 points.

[0032] For example, based on the conversion rules and indicator data, the standardized score of the service node for each collected indicator can be determined. Then, a weighted sum is calculated based on the indicator weights and standardized scores of each collected indicator to obtain the comprehensive score of the service node. Specifically, the comprehensive score of the service node can be calculated based on the formula: Comprehensive Score = Σ(Standardized Score of Single Collected Indicator × Indicator Weight of Single Collected Indicator).

[0033] For example, the scores and weights of the indicators for a bank's core transaction node are as follows: CPU utilization score 80 (20%), memory usage score 75 (18%), transaction response time score 90 (25%), transaction success rate score 95 (15%), data synchronization latency score 85 (10%), and network bandwidth utilization score 80 (12%). The final comprehensive score is 80×20%+75×18%+90×25%+95×15%+85×10%+80×12%=16+13.5+22.5+14.25+8.5+9.6=84.35 (rounded to 84).

[0034] Optionally, financial-specific verification logic can be added to the weighted scoring. If a preset verification rule is triggered, the score can be directly corrected or the node status of the service node can be changed from normal to the corresponding abnormal status.

[0035] For example, if a data synchronization delay of ≥700 milliseconds (regulatory red line) is detected, the overall score will be revised to 30 points, and the service node will be identified as a compliance-abnormal node. If the transaction success rate is ≤99.9% (regulatory bottom line), 20 points will be deducted from the determined overall score. If the updated overall score is <40 points, the service node will be identified as a business-abnormal node. If a backup node heartbeat delay of ≥500 milliseconds (backup failure) is detected, 15 points will be deducted from the primary node's score, and the backup node will be forcibly activated.

[0036] S102. In response to batch user requests, determine the target proportion of request allocation based on the node status type and comprehensive score of the service node, and determine the matching result of batch user requests and service nodes.

[0037] A batch of user requests can include at least one user request. Batch user requests can be obtained through a pre-deployed load balancing gateway based on a public network service address. The target ratio refers to the proportion of user requests allocated to different service nodes. The matching result can represent the service node assigned to each user request.

[0038] Optionally, after determining the batch of user requests, request parsing can be performed to determine the request protocol, business type (such as transfer / query / order), and priority marker (such as core transaction, ordinary business) corresponding to each user request in the batch. Further, based on preset security standards (such as rejecting transfer requests from overseas IPs that are not registered), illegal requests in the batch of user requests can be filtered. Finally, a financial priority queue (such as core transaction queue > ordinary business queue > query queue) is used to load the batch of user requests into the queue. When the number of requests per second exceeds the cluster processing capacity (such as 100,000 requests / second), core transaction requests are processed first, and ordinary business requests are queued and wait. The queue timeout time is set to 500 milliseconds (to meet regulatory delay requirements). Timeout requests return "Please try again later" and are logged.

[0039] Optionally, in response to batch user requests, a target ratio for request allocation is determined based on the node status type and comprehensive score of the service node, including: in response to batch user requests, determining a basic ratio for request allocation to the service node based on the node status type and comprehensive score of the service node; and adjusting the basic ratio based on the business type to which the batch user requests belong to, thereby determining the target ratio for request allocation.

[0040] The business types include core transactions (such as transfers and orders), ordinary transactions (such as inquiries and insurance applications), or low-priority transactions (such as log inquiries and report generation).

[0041] Optionally, a node selection strategy can be determined based on the node status type of the service node. For example, nodes with a normal node status type can be selected first. If the number of normal nodes is less than 3 (minimum redundancy requirement for financial clusters), then early warning nodes (such as those with a comprehensive score of 40-50) can be selected and node expansion alarms can be triggered.

[0042] Optionally, after determining the node selection strategy for service nodes, a basic ratio for request allocation to service nodes can be further determined based on the comprehensive score of the service nodes. The formula can be: Basic ratio of node i = Comprehensive score of node i / Σ (Comprehensive score of all selectable nodes). For example, if the comprehensive scores of three normal nodes are 90, 85, and 80 respectively, with a total score of 255, then the basic ratio of node 1 is approximately 90 / 255 ≈ 35.3%, node 2 ≈ 33.3%, and node 3 ≈ 31.4%.

[0043] Optionally, for batch user requests that all belong to core transactions or have a pre-set high proportion of core transactions, the proportion of nodes in the top 30% of the overall score can be increased by 20%, and the proportion of nodes in the bottom 30% can be decreased by 20% to obtain the target proportion. For example, the proportion of node 1 can be increased to 35.3% × 1.2 ≈ 42.4%, and the proportion of node 3 can be decreased to 31.4% × 0.8 ≈ 25.1%. For batch user requests that all belong to ordinary transactions or have a pre-set high proportion of ordinary transactions, the base proportion can be kept unchanged as the final target proportion. For batch user requests that all belong to low-priority transactions or have a pre-set high proportion of low-priority transactions, the proportion of nodes in the bottom 50% of the overall score can be increased by 10% to obtain the target proportion, so as to make full use of redundant resources.

[0044] Optionally, determining the matching results for batch user requests and service nodes includes: matching corresponding service nodes for batch user requests based on the target ratio and the service identifier of the batch user requests, and determining the matching results for batch user requests and service nodes.

[0045] Among them, the business identifier refers to the unique identifier of a financial business (such as a transfer serial number or order identifier). The business identifier can be bound to the business session to ensure that all requests for the same business or transaction (such as transfer application and transfer confirmation) are assigned to the same service node, thus avoiding data inconsistency caused by cross-node sessions.

[0046] It should be noted that by assigning a unique financial business identifier to each user request, recording the request reception time, forwarding node, processing result, and response time, and storing this information in the log system, subsequent auditing and troubleshooting can be facilitated.

[0047] S103. Based on the target ratio and matching results, forward the batch of user requests to the corresponding service nodes to instruct the corresponding service nodes to perform business processing according to the received user requests, thereby achieving load balancing.

[0048] Optionally, a preset forwarding mode can be used to forward batch user requests, such as DR mode (DirectRouting Mode), to reduce the forwarding latency of the load balancing gateway.

[0049] Optionally, based on the target ratio and matching results, batch user requests are forwarded to the corresponding service nodes. This includes: verifying the compliance of the matching results according to preset allocation requirements; if compliant, then forwarding the batch user requests to the corresponding service nodes using a weighted round-robin method based on the target ratio and matching results. The preset allocation requirements could be, for example, financial regulatory requirements, specifically allocating transfer requests only to nodes with a data synchronization latency ≤300 milliseconds, and order requests only to nodes with a transaction success rate ≥99.99%.

[0050] Optionally, requests can be forwarded using a "weighted round-robin" method based on the target ratio (to avoid session chaos caused by random forwarding in financial scenarios). This instructs the corresponding service nodes to process the received user requests and achieve load balancing. For example, in an order query node, there are three servers: node A has a weight of 5, node B has a weight of 3, and node C has a weight of 2. The weighted round-robin distribution logic is to forward requests to the load in sequence according to the weight ratio. That is, if there are ten requests, the first five are forwarded to node A, the next three are forwarded to node B, and the last two are forwarded to node C.

[0051] Optionally, after determining the service node's metrics data, the method further includes: based on the service node's metrics data, if it is detected that the node switching conditions are met, then the original node is isolated and the corresponding backup node is activated; the node switching conditions are automatic switching conditions or manual switching conditions; based on the user requests processed by the original node, the business session to which it belongs is determined, and based on the session type of the business session, a migration strategy is determined; and based on the migration strategy, a session migration operation from the original node to the backup node is executed.

[0052] The session type can be either a core business session or a regular business session. Node switching conditions can be automatic or manual. Automatic switching conditions can include at least one of the following: a node's overall score ≤ 40 points for three consecutive periods (e.g., 3 seconds); data synchronization latency ≥ the regulatory red line (e.g., 700 milliseconds) for two consecutive periods (e.g., 2 seconds); transaction success rate ≤ the regulatory bottom line (e.g., 99.9%) for two consecutive periods (e.g., 2 seconds); and a node heartbeat interruption exceeding 1 second (determined as a node failure). Manual switching conditions refer to conditions triggered when a node requires downtime maintenance (e.g., patch updates), triggered by an operations and maintenance personnel submitting a switching request, which is then approved by the department head.

[0053] Optionally, isolating the original node may include: stopping the allocation of new requests to the node (core transaction requests are given priority to complete current processing, while ordinary requests are immediately interrupted); marking the node status as isolated and synchronizing it to the financial monitoring platform to trigger a node isolation alarm; if the node is still online, sending a "session freeze command" to it to prohibit the creation of new sessions and allow only existing sessions to complete processing.

[0054] Optionally, the specific operations for activating the standby node corresponding to the service node may include: selecting a "ready" node from the financial standby node pool (configured identically to the primary node and synchronizing data in real time) (the standby node must meet the requirements of data synchronization latency ≤ 100 milliseconds and transaction success rate 100%); sending an activation command to the standby node, loading financial business configurations (such as transfer rules), and starting core service processes (such as bank core transaction processes and securities order processing processes); after the standby node is activated, it is automatically added to the performance collection and evaluation queue to obtain its comprehensive score (a score ≥ 80 is required to participate in load balancing).

[0055] Optionally, for core business sessions, the migration strategy can be determined as reading session data from the distributed database based on the transaction serial number, with the standby node directly taking over the incomplete transactions; for ordinary business sessions, the migration strategy can be determined as synchronizing session data (such as user login status) through shared memory, with the standby node reading and restoring the session.

[0056] Optionally, after the migration is complete, a "session migration complete" command can be sent to the isolated node (i.e. the original node). The isolated node can then be taken offline for maintenance (if it is a downtime node, a fault recovery process needs to be started). Switching logs (switching time, faulty node IP, standby node IP, number of migration sessions, and transaction success rate) can also be recorded and stored in the financial audit database.

[0057] Optionally, after the node switch is executed, periodic verification can be performed. Specifically, the transaction success rate (≥99.99%) and data synchronization latency (≤300 milliseconds) of the backup node can be verified. If the standards are not met, the second backup node will be activated immediately. The transaction failure rate during the switch can also be counted (≤0.01%). If the threshold is exceeded, a "switch failure alarm" will be triggered, and the manual intervention process will be initiated.

[0058] Optionally, after performing the session migration operation from the original node to the standby node based on the migration strategy, the process further includes: determining the alarm level based on the service node's metric data and / or whether node migration has been performed, and determining the corresponding alarm strategy based on the alarm level to issue an alarm; and visualizing the service node's metric data and alarm level.

[0059] The alarm levels are categorized as Emergency Alarm, Important Alarm, or General Alarm. Emergency alarms are identified by conditions such as node switching, transaction success rate ≤ 99.9%, and data synchronization latency ≥ 700 milliseconds (requiring processing within 10 minutes). Important alarms are identified by conditions such as node score ≤ 40, TPS exceeding 90% of the threshold, and insufficient backup nodes (requiring processing within 30 minutes). General alarms are identified by conditions such as node score 40-50, load distribution deviation > 10%, and insufficient log storage capacity (requiring processing within 2 hours). For example, emergency alarms can be notified via SMS, phone, or pop-up (two-person notification to ensure O&M receives the message); important alarms can be notified via email or the O&M platform; and general alarms can be notified via email.

[0060] For example, the visualized content can include a cluster overview, node details, and compliance monitoring. Specifically, the cluster overview can display the number of primary nodes, backup nodes, normal nodes, isolated nodes, average response time, transaction success rate, data synchronization latency, etc. Node details can display the CPU utilization, memory usage, and transaction response time trends of each node in a line graph, with indicators exceeding thresholds marked in red. Compliance monitoring can display the compliance status of regulatory indicators in real time (such as transaction success rate ≥ 99.99%, data synchronization latency ≤ 500 milliseconds), and trigger flashing reminders for indicators that do not meet the standards.

[0061] It should be noted that this invention constructs a comprehensive indicator evaluation system for financial scenarios, breaking through the limitations of existing technologies that rely on "single basic indicators." It builds a three-dimensional indicator system encompassing "basic resources + business processing + regulatory compliance," and for the first time incorporates financial regulatory indicators (data synchronization latency, transaction success rate) into load balancing evaluation, achieving accurate scoring through a weighted algorithm. Furthermore, this invention implements a real-time response mechanism for financial scenarios. By designing a dynamic allocation mechanism of "second-level collection + millisecond-level adjustment," the performance data collection cycle is shortened to 1 second, and the load allocation strategy adjustment cycle is shortened to 500 milliseconds, resulting in a 20-60 times faster response speed compared to traditional technologies (10-30 seconds). Simultaneously, this mechanism supports priority scheduling for financial businesses, further ensuring the stability of core financial scenarios. Finally, this invention achieves a seamless node switching process in financial scenarios. Through a pioneering integrated "isolation-activation-migration" switching process, combined with session persistence technology (session binding based on transaction serial numbers), it enables smooth migration of existing sessions, ensuring business interruption time is ≤100 milliseconds, a reduction of over 98% compared to traditional technologies (3-5 seconds). Meanwhile, the process supports dynamic replenishment of backup nodes, and the cluster resource utilization rate remains at 75%-85% after the switch (the optimal resource utilization range for finance), avoiding the problem of "resource waste after switch" in traditional technologies.

[0062] The technical solution of this invention, based on a preset data collection strategy, determines the indicator data of service nodes and evaluates the indicator data to determine the node status type and comprehensive score of the service nodes. In response to batch user requests, it determines the target proportion of request allocation based on the node status type and comprehensive score of the service nodes, and determines the matching result between the batch user requests and the service nodes. Based on the target proportion and the matching result, it forwards the batch user requests to the corresponding service nodes, instructing the corresponding service nodes to perform business processing according to the received user requests, thereby achieving load balancing. By conducting a more comprehensive evaluation of the service capabilities of the nodes and combining the evaluation results for precise matching of requests and nodes, business processing efficiency can be improved, and effective load balancing can be achieved.

[0063] Example 2 Figure 2 This is a structural block diagram of a load balancing device provided in an embodiment of the present invention. This embodiment is applicable to situations where the service capabilities of nodes are evaluated more comprehensively, and requests and nodes are accurately matched based on the evaluation results to process batch requests and achieve load balancing. The load balancing device provided by the present invention can execute the load balancing method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of executing the method. The load balancing device can be implemented in hardware and / or software and configured in an electronic device with load balancing function, such as... Figure 2As shown, the load balancing device may specifically include: The evaluation module 201 is used to determine the indicator data of the service node based on the preset collection strategy, evaluate the indicator data, and determine the node status type and comprehensive score of the service node. The allocation module 202 is used to respond to batch user requests, determine the target ratio of request allocation based on the node status type and comprehensive score of the service node, and determine the matching result of batch user requests and service nodes. The load balancing module 203 is used to forward batch user requests to the corresponding service nodes according to the target ratio and matching results, so as to instruct the corresponding service nodes to perform business processing according to the received user requests and achieve load balancing.

[0064] The technical solution of this invention, based on a preset data collection strategy, determines the indicator data of service nodes and evaluates the indicator data to determine the node status type and comprehensive score of the service nodes. In response to batch user requests, it determines the target proportion of request allocation based on the node status type and comprehensive score of the service nodes, and determines the matching result between the batch user requests and the service nodes. Based on the target proportion and the matching result, it forwards the batch user requests to the corresponding service nodes, instructing the corresponding service nodes to perform business processing according to the received user requests, thereby achieving load balancing. By conducting a more comprehensive evaluation of the service capabilities of the nodes and combining the evaluation results for precise matching of requests and nodes, business processing efficiency can be improved, and effective load balancing can be achieved.

[0065] Furthermore, the evaluation module 201 is specifically used for: For each service node, determine the transformation rules for the indicator data based on the indicator type corresponding to the collected indicators; Based on the indicator data, the indicator weights corresponding to the collected indicators, and the conversion rules, the node status type and comprehensive score of the service node are determined; the node status type is a normal node, a compliance abnormal node, or a business abnormal node.

[0066] Furthermore, the allocation module 202 is specifically used for: In response to batch user requests, a basic ratio for request allocation to service nodes is determined based on the node status type and comprehensive score of the service nodes. Based on the business type of the batch of user requests, the base ratio is adjusted to determine the target ratio for request allocation.

[0067] Furthermore, the allocation module 202 is also used for: Based on the target ratio and the business identifier of batch user requests, the corresponding service nodes are matched for batch user requests, and the matching results for batch user requests and service nodes are determined. The equalization module 203 is specifically used for: According to the preset allocation requirements, verify whether the matching results are compliant; If so, based on the target ratio and matching results, a weighted round-robin approach is used to forward batch user requests to the corresponding service nodes.

[0068] Furthermore, the above-mentioned device is also used for: Based on the service node's metric data, if the node switching conditions are detected, the original node is isolated and the corresponding backup node is activated; the node switching conditions can be automatic or manual. Based on the user request processed by the original node, determine the corresponding business session, and determine the migration strategy based on the session type of the business session; the session type is either a core business session or a normal business session. The session migration operation is performed from the original node to the standby node based on the migration policy.

[0069] Furthermore, the above-mentioned device is also used for: Based on the service node's metric data and / or whether node migration has been performed, the alarm level is determined, and the corresponding alarm strategy is determined based on the alarm level to issue an alarm; the alarm level is an emergency alarm, an important alarm, or a general alarm. The data is visualized based on the service node's metrics and alarm levels.

[0070] Furthermore, the evaluation module 201 is specifically used for: Based on the node type and indicator category corresponding to the service node, the collection indicators are determined, and data is collected based on the preset collection frequency and collection indicators to obtain the indicator data corresponding to the service node. The above-mentioned device is also used for: The indicator data undergoes preprocessing and storage processing; preprocessing includes at least one of the following: deduplication, filtering and noise reduction, and compliance verification.

[0071] Example 3 Figure 3 This is a schematic diagram of the structure of the electronic device provided in an embodiment of the present invention. Figure 3A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0072] like Figure 3 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory 12 or a random access memory 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the read-only memory 12 or loaded from storage unit 18 into the random access memory 13. The random access memory 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, read-only memory 12, and random access memory 13 are interconnected via a bus 14. An input / output interface 15 is also connected to the bus 14.

[0073] Multiple components in electronic device 10 are connected to input / output 15, including: input unit 16, such as a keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as a disk, optical disk, etc.; and communication unit 19, such as a network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0074] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, central processing units, graphics processing units, various special-purpose artificial intelligence computing chips, various processors running machine learning model algorithms, digital signal processors, and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as load balancing methods.

[0075] In some embodiments, the load balancing method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via read-only memory 12 and / or communication unit 19. When the computer program is loaded into random access memory 13 and executed by processor 11, one or more steps of the load balancing method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the load balancing method by any other suitable means (e.g., by means of firmware).

[0076] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays, application-specific integrated circuits (ASICs), application-specific standard products (ASICs), system-on-a-chip (SoCs), complex programmable logic devices (PLCs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0077] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0078] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0079] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a cathode ray tube or liquid crystal display) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (e.g., voice input, speech input, or tactile input).

[0080] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0081] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a host product within the cloud computing service system to address the shortcomings of traditional physical hosts and virtual reality services, such as high management difficulty and weak business scalability.

[0082] In one embodiment, the present invention further includes a computer program product, which includes a computer program that, when executed by a processor, implements the load balancing method of any embodiment of the present invention.

[0083] In the implementation of a computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​as well as conventional procedural programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0084] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0085] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A load balancing method, characterized in that, include: Based on the preset data collection strategy, the indicator data of the service nodes are determined, and the indicator data is evaluated to determine the node status type and comprehensive score of the service nodes. In response to batch user requests, the target proportion of request allocation is determined based on the node status type and comprehensive score of the service node, and the matching result of batch user requests and service nodes is determined. Based on the target ratio and matching results, batch user requests are forwarded to the corresponding service nodes to instruct the corresponding service nodes to perform business processing according to the received user requests, thereby achieving load balancing.

2. The method according to claim 1, characterized in that, The indicator data is evaluated to determine the node status type and overall score of the service nodes, including: For each service node, determine the transformation rules for the indicator data based on the indicator type corresponding to the collected indicators; Based on the indicator data, the indicator weights corresponding to the collected indicators, and the conversion rules, the node status type and comprehensive score of the service node are determined; the node status type is a normal node, a compliance abnormal node, or a business abnormal node.

3. The method according to claim 1, characterized in that, In response to batch user requests, the target proportion of request allocation is determined based on the node status type and overall score of the service nodes, including: In response to batch user requests, a basic ratio for request allocation to service nodes is determined based on the node status type and comprehensive score of the service nodes. Based on the business type of the batch of user requests, the base ratio is adjusted to determine the target ratio for request allocation.

4. The method according to claim 1, characterized in that, Determine the matching results for batch user requests and service nodes, including: Based on the target ratio and the business identifier of batch user requests, the corresponding service nodes are matched for batch user requests, and the matching results for batch user requests and service nodes are determined. Accordingly, based on the target ratio and matching results, batch user requests are forwarded to the corresponding service nodes, including: According to the preset allocation requirements, verify whether the matching results are compliant; If so, based on the target ratio and matching results, a weighted round-robin approach is used to forward batch user requests to the corresponding service nodes.

5. The method according to claim 1, characterized in that, After determining the service node's metric data, the following also includes: Based on the service node's metric data, if the node switching conditions are detected, the original node is isolated and the corresponding backup node is activated; the node switching conditions can be automatic or manual. Based on the user request processed by the original node, determine the corresponding business session, and determine the migration strategy based on the session type of the business session; the session type is either a core business session or a normal business session. The session migration operation is performed from the original node to the standby node based on the migration policy.

6. The method according to claim 5, characterized in that, After performing the session migration operation from the original node to the standby node based on the migration policy, the following steps are also included: Based on the service node's metric data and / or whether node migration has been performed, the alarm level is determined, and the corresponding alarm strategy is determined based on the alarm level to issue an alarm; the alarm level is an emergency alarm, an important alarm, or a general alarm. The data is visualized based on the service node's metrics and alarm levels.

7. The method according to claim 1, characterized in that, Based on a preset data collection strategy, the indicator data for the service nodes are determined, including: Based on the node type and indicator category corresponding to the service node, the collection indicators are determined, and data is collected based on the preset collection frequency and collection indicators to obtain the indicator data corresponding to the service node. Accordingly, after determining the service node's metric data, the following also includes: The indicator data undergoes preprocessing and storage processing; preprocessing includes at least one of the following: deduplication, filtering and noise reduction, and compliance verification.

8. A load balancing device, characterized in that, include: The evaluation module is used to determine the indicator data of service nodes based on a preset collection strategy, evaluate the indicator data, and determine the node status type and comprehensive score of the service nodes. The allocation module is used to respond to batch user requests, determine the target ratio of request allocation based on the node status type and comprehensive score of the service nodes, and determine the matching results of batch user requests and service nodes. The load balancing module forwards batch user requests to the corresponding service nodes based on the target ratio and matching results, instructing the corresponding service nodes to perform business processing according to the received user requests, thereby achieving load balancing.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the load balancing method according to any one of claims 1-7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the load balancing method according to any one of claims 1-7.

Images