Server cluster load balancing method based on improved consistent hashing and Redis

Abstract

The application relates to a server cluster load balancing method based on improved consistent hashing and Redis, which comprises the following steps of: firstly, constructing a modular cluster architecture containing a user management layer, a load balancing layer and the like; collecting node hardware performance parameters and real-time load data through a cluster state monitoring layer; dynamically calculating the number of virtual nodes based on parameters such as node performance ratio in the load balancing layer, mapping a hash ring by using an improved consistent hashing algorithm, locating a target physical node, and distributing a request in combination with a dynamic scheduling strategy; realizing efficient switching of a master and a backup through an election queue mechanism in a cluster high-availability layer, and completing redundant backup and synchronous sharing of Session data by means of a Redis cluster. The application solves problems such as data tilt, inefficient master-backup switching and inconsistent Session sharing in traditional technologies, improves the cluster load balancing efficiency and high availability, and is suitable for high-concurrency scenes such as medical treatment, finance and e-commerce.

Description

Technical Field

[0001] This invention belongs to the field of server cluster load balancing technology, and particularly relates to a server cluster load balancing method based on improved consistent hashing and Redis. Background Technology

[0002] With the rapid development of information technology, the business scale of key industries such as healthcare, finance, and e-commerce continues to expand, and user traffic is experiencing explosive growth. This places unprecedentedly stringent demands on the load-bearing capacity and high availability of server clusters. Traditional single-point server architectures, due to limited hardware resources, are prone to resource exhaustion, increased response latency, and even system crashes when facing high-concurrency request scenarios, and can no longer meet the stable operation requirements of modern businesses. Therefore, server cluster architecture has become the mainstream choice, and load balancing technology and high availability design have become the core keys to ensuring the efficient and stable operation of clusters.

[0003] Currently, various load balancing algorithms and high-availability architecture solutions have emerged in the industry, but many technical pain points still need to be addressed in practical applications. Regarding load balancing, while traditional consistent hashing algorithms can solve the data migration problem to some extent when nodes are added or removed, they do not consider the differences in hardware performance among nodes. They only use a fixed number of virtual nodes for hash ring mapping, resulting in high-performance nodes not being able to fully utilize their computing power, while weaker nodes face the risk of overload, ultimately leading to data skew and reducing the overall load balancing efficiency of the cluster. At the same time, existing dynamic scheduling strategies mostly rely on a single load metric for decision-making, lacking a comprehensive consideration of node performance and remaining load capacity, making it difficult to achieve accurate and balanced distribution of request traffic.

[0004] Regarding cluster high availability, traditional master-slave failover mechanisms often employ simple priority sorting or random election to select a standby node, without considering key factors such as the node's real-time performance status and data synchronization progress. This can lead to issues like insufficient resources and incomplete data on the new master node after failover, impacting service continuity. Furthermore, session data sharing between master and standby nodes is crucial for ensuring seamless business continuity. Some existing solutions use local storage for session data, meaning that if the master node fails, the standby node cannot obtain complete session information, resulting in lost user login status and interrupted business processes. Even solutions that use distributed storage for session sharing still suffer from high data synchronization latency and difficulty in guaranteeing consistency.

[0005] Furthermore, existing server cluster architectures often suffer from high module coupling and complex interaction logic between functional modules. This makes rapid expansion and adaptation difficult when business requirements change or cluster size is adjusted, increasing system maintenance costs and upgrade complexity. In summary, addressing issues such as data skew, inefficient master-slave failover, inconsistent session sharing, and poor system scalability in existing technologies to achieve efficient load balancing and high-reliability operation of server clusters in high-concurrency scenarios has become a pressing technical challenge in this field.

[0006] Therefore, this invention aims to provide a server cluster load balancing method based on improved consistent hashing and Redis to solve the technical problems existing in the prior art. Summary of the Invention

[0007] The purpose of this invention is to provide a server cluster load balancing method based on improved consistent hashing and Redis, in order to solve the technical problems existing in the prior art.

[0008] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0009] A server cluster load balancing method based on improved consistent hashing and Redis includes the following steps:

[0010] S1: Build a server cluster architecture, including a user management layer, a version control layer, a load balancing layer, a cluster high availability layer, and a cluster status monitoring layer. Each layer establishes a communication connection through a preset API interface.

[0011] S2: The cluster status monitoring layer periodically collects hardware performance parameters and real-time load data of each node in the server cluster. Hardware performance parameters include CPU utilization, memory usage, and network bandwidth throughput. Real-time load data includes the current number of connections, task processing queue length, and data transmission latency.

[0012] S3: The load balancing layer calculates the performance value of each node and determines the number of virtual nodes corresponding to each node, with the node performance ratio and the maximum linearity of virtual nodes as the core parameters.

[0013] S4: The load balancing layer uses an improved consistent hashing algorithm to map each virtual node to a hash ring. User request data is processed by a hash function to obtain the corresponding hash value. The target virtual node is located on the hash ring based on the hash value, and then the target physical node is determined.

[0014] S5: The load balancing layer combines real-time load data and location results to allocate user requests to target physical nodes through dynamic scheduling strategies. If the real-time load of the target physical node exceeds a preset threshold, the optimal physical node is repositioned based on the node performance value and remaining load capacity.

[0015] S6: The cluster high availability layer monitors the running status of the master node in real time through an election queue mechanism. When the master node fails, a new master node is elected from the standby nodes to complete the master-standby switchover.

[0016] S7: Utilizes Redis cluster to store session data. After completing the master-slave switch, the cluster high availability layer synchronously retrieves the session data from the original master node from the Redis cluster and transfers it to the new master node, thereby achieving session sharing.

[0017] Preferably, step S2 further includes a data preprocessing process, as follows:

[0018] S21: Define the baseline thresholds for each hardware performance parameter, including the baseline thresholds for CPU utilization, memory usage, and network bandwidth throughput.

[0019] S22: Normalize each parameter and calculate it using the formula: Normalized parameter value = (actual node parameter value / parameter baseline threshold) × 100;

[0020] S23: Output the normalized CPU value, normalized memory value, and normalized network bandwidth value of each node, denoted as P1, P2, and P3.

[0021] Preferably, the specific process of step S3 is as follows:

[0022] S31: Based on the preprocessed standardized parameters, the weighted summation method is used to calculate the comprehensive performance value of each node;

[0023] S32: Calculate the performance ratio of a single node based on the performance values ​​of all nodes;

[0024] S33: Based on the node performance ratio, the maximum linear value of virtual nodes, and the total number of cluster nodes, calculate the number of virtual nodes corresponding to each node through a preset model.

[0025] Preferably, the specific process of step S33 is as follows:

[0026] S331: Configure the maximum linearity value L for virtual nodes;

[0027] S332: Configure the preset number of baseline nodes M;

[0028] S333: Solve the model based on the following number of virtual nodes:

[0029] The number of virtual nodes V = node performance ratio R × maximum linear value of virtual nodes L × (total number of cluster nodes N / preset baseline number of nodes M);

[0030] S334: Round the calculated result V to the nearest integer;

[0031] S335: Output the number of virtual nodes corresponding to each node, as an input parameter for the hash ring mapping in the improved consistent hashing algorithm.

[0032] Preferably, the specific process of step S4 is as follows:

[0033] S41: Generate a unique identifier for each virtual node: based on the number of virtual nodes corresponding to each physical node obtained through calculation;

[0034] S42: Calculate the hash value of the virtual node and the user request: Use a unified hash function to perform hash calculation on the virtual node identifier and the user request data to ensure the uniform distribution of hash values ​​and computational efficiency;

[0035] S43: Virtual Node Mapping to Hash Ring: Map the hash values ​​of all virtual nodes to a preset hash ring according to their numerical values, and construct a complete hash ring mapping relationship;

[0036] S44: Locate the target virtual node based on the hash value: Find the corresponding target virtual node on the hash ring based on the hash value requested by the user;

[0037] S45: Determine the target physical node through the target virtual node: Based on the association between the target virtual node and the physical node, the target physical node requested by the user is finally determined.

[0038] Preferably, the specific process of step S45 is as follows:

[0039] S451: Search the mapping table of virtual node hash value and physical node established in step S43, and obtain the complete information of the original physical node corresponding to the target virtual node through the hash value of the target virtual node;

[0040] S452: Pre-verify the current load status of the target physical node: If the real-time load of the physical node does not exceed the preset threshold, then directly determine it as the final target physical node;

[0041] S453: If the real-time load of the target physical node exceeds the preset threshold, a clockwise suboptimal node search is triggered: continue to search for the next virtual node in a clockwise direction on the hash ring, repeat the verification process of steps S451 to S452, until a physical node with a load that meets the requirements is found and it is identified as the target physical node.

[0042] Preferably, the specific process of step S5 is as follows:

[0043] S51: Preset load threshold range and core parameters: Complete the basic parameter configuration before the dynamic scheduling strategy is executed;

[0044] S52: Obtain initial positioning results and real-time load data;

[0045] S53: Determine the status of the target node based on the load threshold;

[0046] S54: Request allocation under normal or low load conditions: Under normal load conditions: User requests are directly routed to the target physical node, and request allocation logs are recorded at the same time;

[0047] Low load state: After the request allocation is completed, the virtual node dynamic adjustment mechanism is triggered to increase the number of virtual nodes corresponding to the node and synchronously update the virtual node mapping relationship of the hash ring to expand the allocation range of subsequent requests;

[0048] S55: Optimal physical node reselection under high load conditions: When the load rate of the target physical node exceeds the preset threshold, the node reselection process is initiated to select the optimal node based on the node performance value and remaining load capacity.

[0049] Preferably, the specific process of step S6 is as follows:

[0050] S61: Initialize the standby node election queue: When the server cluster starts, the election queue is built and configured to provide a basis for candidate nodes for subsequent primary-standby switching;

[0051] S62: Real-time monitoring of master node operating status: The cluster high availability layer monitors the master node's operating status in real time through a multi-dimensional monitoring mechanism;

[0052] S63: Filter candidate master nodes from the election queue: Based on the initialized election queue, quickly filter out candidate master nodes that meet the conditions;

[0053] S64: Verification and Confirmation of Candidate Master Nodes: Verify the selected candidate master nodes from multiple dimensions to ensure that they have the ability to take over the business of the master node;

[0054] S65: Perform primary / standby failover: After determining the new primary node, complete the role switching, resource configuration, and business takeover to ensure seamless service continuity;

[0055] S66: Switchover Result Confirmation and Status Synchronization: After completing the primary / standby switchover, verify the switchover effect and synchronize the status to each layer of the cluster to ensure system consistency.

[0056] Preferably, the specific process of step S7 is as follows:

[0057] S71: Perform Session data initialization, generation, and storage: When a user makes their first request to the server cluster, the Session data is created and stored in the Redis cluster.

[0058] S72: Perform redundant backup of Redis cluster session data: Redis clusters achieve real-time data synchronization through master-slave replication mechanism to build redundant backups;

[0059] S73: Session data synchronization triggered after master-slave switchover: After the cluster high availability layer completes the master-slave node switchover, the session data synchronization process between the new master node and the Redis cluster is automatically triggered.

[0060] S74: Batch Synchronization and Verification of Session Data: The new master node retrieves session data from the specified Redis slave node to complete batch synchronization and integrity verification;

[0061] S75: Session sharing activation and real-time synchronization maintenance: After the initial data synchronization is completed, the new master node enters the real-time synchronization state of session data to ensure the consistency of session data in subsequent business interactions.

[0062] S76: Synchronization Result Feedback and Anomaly Handling: After the Session data synchronization is completed, the synchronization result is fed back and any anomalies that may occur are handled.

[0063] The beneficial effects of this invention include:

[0064] Load balancing efficiency is significantly improved, completely resolving data skew issues: By comprehensively collecting hardware performance parameters and real-time load data of each node through the cluster status monitoring layer, core parameters such as node performance ratio and maximum linearity of virtual nodes are introduced into the load balancing layer to construct a dynamic virtual node quantity calculation model. This ensures that more powerful nodes are allocated more virtual nodes, and weaker nodes are allocated fewer virtual nodes, fundamentally avoiding the data skew caused by the fixed number of virtual nodes in traditional consistent hashing algorithms. Simultaneously, combined with a dynamic scheduling strategy, request allocation is performed by considering both node performance values ​​and remaining load capacity, achieving accurate and even distribution of high-concurrency traffic among cluster nodes. This significantly improves the overall load-bearing capacity of the cluster, reduces the risk of single-point overload, minimizes cluster load balancing errors, and maximizes node resource utilization.

[0065] Highly efficient and reliable master-slave failover ensures service continuity: Based on an election queue, the master-slave failover mechanism constructs an ordered election queue at cluster startup by integrating node performance values ​​and historical service quality data, and updates it dynamically in real time to ensure the quality of candidate nodes. Master node status monitoring employs a multi-dimensional mechanism combining heartbeat detection and service availability verification, along with a secondary confirmation process to avoid misjudgments of faults. Candidate master node verification covers connectivity, resource availability, data integrity, and service readiness, ensuring that the new master node has the capability to fully take over business operations. This design reduces master-slave failover time to the second level, with a high success rate, effectively avoiding service interruptions caused by unreasonable node selection or data inconsistency in traditional failover mechanisms, and ensuring the continuous and stable operation of critical businesses.

[0066] Session data sharing is highly efficient and consistent, enhancing user experience: Real-time redundant backup of session data is achieved through the master-slave replication mechanism of the Redis cluster, ensuring no data loss. After master-slave failover, the optimal data synchronization source is quickly selected through a sentinel mechanism. Encrypted sharding transmission and integrity verification technologies are employed to achieve fast and secure session data synchronization with a high completion rate and millisecond-level latency. After completing data synchronization, the new master node can respond to user requests in real time, avoiding issues such as lost user login status and business process interruptions, ensuring the continuity of user interaction, and significantly improving user experience. This is particularly suitable for scenarios with extremely high requirements for session continuity, such as e-commerce orders and financial transactions.

[0067] The system's scalability and maintainability are significantly enhanced: The constructed server cluster architecture adopts a modular design, dividing the system into a user management layer, a version control layer, a load balancing layer, a cluster high availability layer, and a cluster status monitoring layer. These layers communicate through pre-defined API interfaces, enabling independent development, deployment, and maintenance of each module. When business demands increase and the cluster size needs to be expanded, new nodes can be quickly connected through standardized interfaces. The load balancing and cluster high availability layers can automatically complete node performance evaluation, virtual node configuration, and election queue updates without requiring large-scale adjustments to the existing system architecture. When a module needs upgrading or optimization, it will not affect the normal operation of other modules, significantly reducing system maintenance costs and upgrade difficulty, and improving the system's lifecycle and adaptability. Attached Figure Description

[0068] Figure 1 This is a flowchart illustrating the server cluster load balancing method based on improved consistent hashing and Redis according to the present invention.

[0069] Figure 2 This is a schematic diagram illustrating the process of calculating the number of virtual nodes corresponding to each node according to the present invention. Detailed Implementation

[0070] The following is in conjunction with the appendix Figures 1-2 The present invention will be further described in detail below:

[0071] Example 1

[0072] See appendix Figure 1 As shown, the server cluster load balancing method based on improved consistent hashing and Redis is characterized by the following steps:

[0073] S1: Construct a server cluster architecture, including a user management layer, a version control layer, a load balancing layer, a cluster high availability layer, and a cluster status monitoring layer. Each layer establishes a communication connection through a preset API interface, enabling independent development and flexible expansion of each module.

[0074] S2: The cluster status monitoring layer periodically collects hardware performance parameters and real-time load data of each node in the server cluster. Hardware performance parameters include CPU utilization, memory usage, and network bandwidth throughput. Real-time load data includes the number of current connections, task processing queue length, and data transmission latency.

[0075] S3: The load balancing layer calculates the performance value of each node based on the collected hardware performance parameters. Combined with the total number of nodes in the server cluster, it determines the number of virtual nodes corresponding to each node through a preset virtual node number calculation model. The virtual node number calculation model uses the node performance ratio and the maximum linear value of virtual nodes as core parameters. The node performance ratio is the ratio of the performance value of a single node to the sum of the performance values ​​of all nodes in the cluster.

[0076] S4: The load balancing layer uses an improved consistent hashing algorithm to map each virtual node to a hash ring. At the same time, it calculates the corresponding hash value for user request data through a hash function, locates the target virtual node on the hash ring based on the hash value, and then determines the target physical node.

[0077] S5: The load balancing layer combines the real-time load data collected in step S2 and the location results in step S4, and uses a dynamic scheduling strategy to allocate user requests to target physical nodes. If the real-time load of the target physical node exceeds a preset threshold, the optimal physical node is repositioned based on the node performance value and remaining load capacity.

[0078] S6: The cluster high availability layer monitors the running status of the master node in real time through an election queue mechanism. When the master node fails, a new master node is elected from the standby nodes to complete the master-standby switchover.

[0079] S7: Utilize Redis cluster to store Session data. After the master-slave switch is completed in step S6, the cluster high availability layer synchronously retrieves the Session data from the original master node from the Redis cluster and transfers it to the new master node to achieve Session sharing.

[0080] In another embodiment of this example, step S7 is followed by S8: the cluster status monitoring layer monitors the request allocation result of step S5 and the master-slave switch status of step S6 in real time, stores the monitoring data in a preset relational database, and feeds it back to the load balancing layer to provide data support for subsequent adjustment of the number of virtual nodes and request scheduling.

[0081] In this embodiment, step S2 further includes a data preprocessing process, as follows:

[0082] S21: Define the baseline thresholds for each hardware performance parameter, including setting the CPU utilization baseline threshold to 80%, the memory utilization baseline threshold to 75%, and the network bandwidth throughput baseline threshold to 1000Mbps.

[0083] S22: Normalize each parameter using the following formula:

[0084] Standardized parameter value = (actual node parameter value / parameter baseline threshold) × 100;

[0085] If the actual parameter value of a node exceeds the baseline threshold, the standardized value is set to 100; if it is lower than the baseline threshold, it is calculated based on the actual ratio. For example, if the actual CPU utilization rate of a node is 40%, then the CPU standardized value = (40% / 80%) × 100 = 50.

[0086] S23: Output the normalized CPU value, normalized memory value, and normalized network bandwidth value of each node, denoted as P1, P2, and P3.

[0087] Example 2

[0088] Based on Example 1, see Figure 2 As shown, the specific process of step S3 is as follows:

[0089] S31: Based on the preprocessed standardized parameters, a weighted summation method is used to calculate the comprehensive performance value of each node, specifically:

[0090] The weight coefficients of each hardware performance parameter are preset and dynamically configured according to the business scenario. For example, CPU weight W1=0.4, memory weight W2=0.3, network bandwidth weight W3=0.3, satisfying W1+W2+W3=1.

[0091] The node's overall performance value is calculated using the following formula: Node performance value P = P1 × W1 + P2 × W2 + P3 × W3;

[0092] For example: If a node P1=80, P2=70, and P3=90, then P=80×0.4+70×0.3+90×0.3=32+21+27=80;

[0093] Iterate through all nodes in the server cluster and calculate the performance value for each node. P n , n For node sequence number, n =1,2,...,N, where N is the total number of nodes in the cluster.

[0094] S32: Calculate the performance ratio of a single node based on the performance values ​​of all nodes. The specific process is as follows:

[0095] S321: Calculate the sum of the performance values ​​of all nodes in the cluster, using the formula: Total Cluster Performance Value P total =Σ P n , n=1 to N.

[0096] S322: Calculate the performance ratio of each node using the following formula:

[0097] Node performance ratio R = performance value of a single node P n / Total cluster performance P total ;

[0098] For example: The cluster contains 3 nodes with performance values ​​of 80, 70, and 50 respectively. P total =200, then the performance ratio of the first node is R1=80 / 200=0.4; ensure that the sum of the performance ratios of all nodes is 1 (i.e. ΣR=1), as the basis for verifying the calculation results.

[0099] S33: Based on the node performance ratio, the maximum linear value of virtual nodes, and the total number of cluster nodes, calculate the number of virtual nodes corresponding to each node through a preset model.

[0100] S331: Configure the maximum linear value L for virtual nodes. The value is preset according to the cluster size. For example, L=100 when the total number of cluster nodes is ≤10 and L=200 when the total number of nodes is >10. This is used to limit the total number of virtual nodes and avoid resource waste.

[0101] S332: Configure the preset baseline number of nodes M, which is the standard configuration number of nodes in the server cluster. For example, M=5 is a fixed baseline parameter.

[0102] S333: Solve the model based on the following number of virtual nodes:

[0103] The number of virtual nodes V = node performance ratio R × maximum linear value of virtual nodes L × (total number of cluster nodes N / preset baseline number of nodes M).

[0104] S334: Round the calculated result V to the nearest integer to ensure that V is a positive integer and that the sum of the number of virtual nodes of all nodes is less than or equal to L×(N / M) to avoid hash ring overload.

[0105] For example, if a node has R=0.4, L=100, N=3, and M=5, then V=0.4×100×(3 / 5)=0.4×100×0.6=24, meaning that this node corresponds to 24 virtual nodes.

[0106] S335: Output the number of virtual nodes corresponding to each node, as an input parameter for the hash ring mapping in the improved consistent hashing algorithm.

[0107] The specific process of step S4 is as follows:

[0108] S41: Generate a unique identifier for each virtual node: based on the calculated number of virtual nodes corresponding to each physical node, denoted as... V n , n For each physical node, a unique identifier is assigned to all virtual nodes of that physical node. The specific process is as follows:

[0109] S411: Extract the core network identifier of each physical node, and use the IP address of the physical node (which can be 192.168.1.101) as the basic identifier to ensure the uniqueness and stability of the identifier.

[0110] S412 sequentially numbers the virtual nodes of each physical node, following a numbering rule from 1 to... V n If a physical node corresponds to 24 virtual nodes, then the virtual nodes are numbered 1 to 24.

[0111] S413: Generate a unique identifier for the virtual node using the concatenation format of IP address-virtual node number.

[0112] For example, if the physical node IP is 192.168.1.101, the identifier of its 5th virtual node is 192.168.1.101-5.

[0113] S42: Calculate the hash value of the virtual node and the user request: Use a unified hash function to perform hash calculations on the virtual node identifier and the user request data to ensure a uniform distribution of hash values ​​and computational efficiency. The specific process is as follows:

[0114] S421: The MD5 hash algorithm is selected as the core hash function. The hash value output length is 128 bits, which can be mapped to the integer range of 0~2³²-1 through base conversion, and is suitable for the numerical range of the hash ring.

[0115] S422: Perform MD5 hash calculation on the unique identifier of each generated virtual node: Convert the identifier string into a byte array, input it into the MD5 algorithm for calculation, obtain a 128-bit hash value, and then decode it using Base64 or convert it to hexadecimal to map it into an integer hash value in the range of 0~2³²-1, denoted as . H v (Virtual node hash value).

[0116] S423: Perform hash calculation on user request data: Extract the core feature data of the user request, including the request URL, request parameter digest, and user unique identifier (Session ID), and concatenate them into a request feature string; use the same MD5 hash algorithm as the virtual node to operate on the request feature string to obtain a 128-bit hash value, which is also mapped to an integer hash value in the range of 0~2³²-1, denoted as . H r (User request hash value).

[0117] S43: Mapping Virtual Nodes to a Hash Ring: Mapping the hash values ​​of all virtual nodes H v The hash values ​​are mapped to a predefined hash ring, constructing a complete hash ring mapping relationship. The specific process is as follows:

[0118] S431: Define the numerical range of the hash ring as 0~2³²-1, and regard this interval as a closed ring structure, that is, the next node after the value 2³²-1 is 0.

[0119] S432: Traverse the hash values ​​of all virtual nodes H v , each H v As a mapping point on the hash ring, it is located on the hash ring according to the value of Hv. For example, if Hv=10000, it is located at the position corresponding to the value 10000 on the hash ring.

[0120] S433: Establish a mapping table between "virtual node hash value and physical node" to store each H v The corresponding original physical node information, including IP address, performance value, and current load status, is used to facilitate subsequent processing. H v Quickly associate physical nodes.

[0121] S44: Locate the target virtual node based on the hash value requested by the user: H r The process of finding the corresponding target virtual node on the hash ring is as follows:

[0122] S441: Traverse all virtual nodes on the hash ring H v Construct an ordered list of hash values ​​in ascending order of their numerical values.

[0123] S442: Locate the target virtual node using a clockwise search rule: In the ordered hash value list, find the first one that is greater than or equal to... H r of H v ,Should H v The corresponding virtual node is the target virtual node.

[0124] S443: If H r Greater than all on the hash ring H v If the maximum value is not found, then the hash ring will default to the one with the smallest value. H v The corresponding virtual node, because the hash ring is a closed structure, satisfies the core logic of clockwise cyclic search.

[0125] S45: Determine the target physical node through the target virtual node: Based on the association between the target virtual node and the physical node, the target physical node requested by the user is finally determined.

[0126] Example 3

[0127] Based on Example 1 or Example 2, the specific process of step S45 is as follows:

[0128] S451: Search the "virtual node hash value - physical node" mapping table established in step S43, and use the target virtual node's... H v This allows you to obtain complete information about the corresponding original physical node, including its IP address, performance value, and current load status.

[0129] S452: Pre-verify the current load status of the target physical node: If the real-time load of the physical node does not exceed the preset threshold, then directly determine it as the final target physical node;

[0130] S453: If the real-time load of the target physical node exceeds the preset threshold, a clockwise suboptimal node search is triggered: continue to search for the next virtual node in a clockwise direction on the hash ring, repeat the verification process of steps S451 to S452, until a physical node with a load that meets the requirements is found, and it is determined as the target physical node to ensure the rationality of the request allocation.

[0131] In this embodiment, the specific process of step S5 is as follows:

[0132] S51: Preset load threshold range and core parameters: Before the dynamic scheduling strategy is executed, the basic parameter configuration is completed to provide a basis for load determination and scheduling decisions.

[0133] S511: Define load threshold range: Based on the upper limit of the server cluster's hardware performance and the service carrying capacity, divide the load into three ranges: low load range (0~40%), normal load range (40%~70%), and high load range (70%~100%). The critical value (70%) of the high load range is the preset load threshold.

[0134] S512: Define core evaluation metrics: Associate the real-time load data collected in step S2 (current connection count, task processing queue length, data transmission latency) with the node performance values ​​calculated in step S3 to define the remaining load capacity metric. The calculation formula is as follows:

[0135] Remaining load capacity = (1 - current load rate) × node performance value;

[0136] Wherein, the current load rate = (actual load data / load upper limit threshold) × 100%;

[0137] For example, if a node currently has 800 connections and the maximum number of connections is 1000, then the current load rate is 80%.

[0138] S513: Configure scheduling trigger conditions: Set the real-time load data collection period to 10 seconds, and the maximum number of node reselection retries to 3, to ensure that scheduling decisions are based on the latest load status and to avoid request blocking caused by infinite retries.

[0139] S52: Obtain initial positioning results and real-time load data:

[0140] S521: Extract the location results from step S4: Obtain complete information about the target physical node, including node IP address, performance value, node identifier and corresponding virtual node mapping relationship;

[0141] S522: Synchronize real-time load data: Call the latest real-time load data of the target physical node collected in step S2 from the cluster status monitoring layer, including the current number of connections, task processing queue length, data transmission latency, and calculate the current load rate.

[0142] S523: Data Consistency Verification: Verify whether the difference between the real-time load data collection timestamp and the current scheduling time is within a preset period, such as ≤10 seconds. If it exceeds this period, re-acquire the latest data to ensure the accuracy of load assessment.

[0143] S53: Determine the target node status based on load threshold:

[0144] S531: Calculate the current load rate of the target physical node: Based on the core indicators in the real-time load data, including the current number of connections and CPU utilization, calculate the comprehensive load rate using the weighted average method. The weight configuration is consistent with the performance value calculation weight in step S3, such as CPU utilization 0.4, memory usage 0.3, and network bandwidth utilization 0.3.

[0145] S532: Matching load threshold range: Match the calculated overall load rate with three preset load ranges to determine the current load status (low load, normal load, or high load) of the target physical node.

[0146] S533: Trigger the corresponding scheduling branch: If the load status is normal load or low load, proceed to S54 to execute the direct allocation logic; if the load status is high load, that is, the real-time load exceeds the preset threshold, proceed to step S55 to execute the node reselection logic.

[0147] S54: Request allocation under normal / low load conditions:

[0148] When the target physical node is under normal or low load, the request allocation is completed according to the following rules:

[0149] S541: Normal load status (40%~70%): Directly route user requests to the target physical node, and record the request allocation log, including request ID, allocation node IP, allocation time, and current node load rate.

[0150] S542: Low load state (0~40%): Based on the completion of request allocation, the virtual node dynamic adjustment mechanism is triggered to increase the number of virtual nodes corresponding to the node;

[0151] Adjustment range = (40% - current load rate) × baseline adjustment amount. For example, if the baseline adjustment amount is 5, the virtual node mapping relationship of the hash ring is updated synchronously to expand the allocation range of subsequent requests and improve the load utilization of the node.

[0152] S543: Allocation Result Feedback: Feedback the information of successful allocation request to the cluster status monitoring layer, update the real-time load data of the node, such as the current number of connections +1 and the length of the task processing queue +1, and provide the latest status for the next round of scheduling.

[0153] S55: Optimal physical node reselection under high load conditions:

[0154] When the load rate of the target physical node is ≥70% (exceeding the preset threshold), the node reselection process is initiated to select the optimal node based on the node performance value and remaining load capacity:

[0155] S551: Filter the candidate node pool: Traverse all physical nodes in the server cluster, exclude nodes that are in a fault state or maintenance state, and retain nodes that are running normally as candidate nodes.

[0156] S552: Calculate the priority score of candidate nodes: For each candidate node, combine its performance value and remaining load capacity to calculate the priority score according to the following formula (the higher the score, the stronger the node's adaptability):

[0157] Priority score = node performance value × 0.6 + remaining load capacity × 0.4;

[0158] For example: Candidate node A has a performance value of 80 and a remaining load capacity of 32;

[0159] Candidate node B has a performance value of 70 and a remaining load capacity of 42.

[0160] Therefore, A's priority score = 80 × 0.6 + 32 × 0.4 = 48 + 12.8 = 60.8, and B's priority score = 70 × 0.6 + 42 × 0.4 = 42 + 16.8 = 58.8, meaning A's priority is higher than B's.

[0161] S553: ​​Sort and select the best node: Sort the candidate nodes from high to low priority score, and select the node ranked first as the new target physical node.

[0162] S554: Secondary load verification: Obtain the latest real-time load data of the new target physical node and verify whether its current load rate is ≤70%. If it meets the requirements, it is determined as the final optimal physical node; if it still exceeds the threshold, the next candidate node is verified in order of sorting results until a node that meets the requirements is found or the maximum number of retries is reached.

[0163] S555: Retry Limit Handling: If no node with the required load is found after traversing all candidate nodes, the request is temporarily placed in a buffer queue with a maximum queue length of 1000. Node reselection is triggered every 2 seconds until the request is successfully allocated or the buffer queue times out. The timeout period is 30 seconds. After the timeout, a request failure message is returned and an exception log is recorded.

[0164] S56: Final request allocation and scheduling state synchronization:

[0165] S561: Routing requests to the target node: Regardless of whether a node is directly assigned or reselected, the data packet of the user request (including request parameters, Session ID, and target node identifier) ​​will eventually be routed to the determined physical node, which will then process the request.

[0166] S562: Synchronize scheduling status to each layer: Synchronize the request allocation results (allocation node IP, allocation status, load data) to the cluster status monitoring layer and the cluster high availability layer. The cluster status monitoring layer updates the node load statistics, and the cluster high availability layer records the node service status.

[0167] S563: Dynamically optimize hash ring mapping: If node re-election is triggered in this scheduling, the virtual node distribution of the hash ring is adjusted according to the re-election result to reduce the number of virtual nodes of the original high-load nodes;

[0168] Adjustment range = (current load rate - 70%) × baseline adjustment amount, increasing the number of virtual nodes of the optimal node, optimizing the initial location results of subsequent requests, and reducing the probability of overload recurring.

[0169] Example 4

[0170] Based on Example 1, Example 2, or Example 3, the specific process of step S6 is as follows:

[0171] S61: Initialize the standby node election queue: When the server cluster starts, the election queue is built and configured to provide a foundation of candidate nodes for subsequent master-slave failover.

[0172] S611: Collect hardware performance parameters (consistent with the hardware performance parameters in step S3, including CPU utilization, memory usage, and network bandwidth throughput) and historical service quality data of all standby nodes in the cluster, including historical request processing success rate, average response latency, and number of fault recovery attempts.

[0173] S612: Calculate the overall priority score of the standby node: use a weighted summation method, in which the hardware performance value accounts for 60% of the weight (the calculation method is consistent with the node performance value calculation logic in step S3).

[0174] The historical service quality score accounts for 40% of the total score (historical request processing success rate × 0.6 + (1 - average response latency / baseline latency) × 0.2 + (1 - number of fault recovery attempts / total number of running days) × 0.2), and the final score range is mapped to 0~100 points.

[0175] S613: Sort all standby nodes from high to low according to their comprehensive priority scores, and generate an ordered standby node election queue. The queue records complete information of each node, including IP address, performance value, priority score, current running status, and data synchronization progress.

[0176] S61: Configure queue dynamic update rules: recalculate the priority score of each standby node every 30 seconds and adjust the queue order; if a new standby node is added or an existing node is removed, such as due to failure or maintenance removal, the queue members are updated in real time to ensure the validity of the queue.

[0177] S62: Real-time monitoring of master node operating status: The cluster high availability layer uses a multi-dimensional monitoring mechanism to monitor the operating status of master nodes in real time and detect faults promptly.

[0178] S621: Establish a heartbeat detection mechanism: The master node sends heartbeat data packets to the cluster high availability layer at a preset period. The data packets contain core information such as the master node's current CPU load, memory usage, task processing queue length, and data synchronization status (synchronization progress with the Redis cluster and standby nodes).

[0179] S622: Supplementary service availability verification: The cluster high availability layer sends a service probe request to the master node every 10 seconds, such as simulating a user's lightweight request or checking the interface connectivity, to verify whether the master node can process the request normally and return a valid response.

[0180] S623: Set fault judgment threshold: If the heartbeat data packet of the master node is not received for 3 consecutive times, that is, the heartbeat timeout lasts for a total of 6 seconds, or the service probe request returns an invalid response for 2 consecutive times, such as timeout, error code, or connection refusal, then the master node is preliminarily judged to be abnormal.

[0181] S624: Secondary confirmation mechanism: To avoid misjudgment, such as heartbeat delay caused by network jitter or instantaneous high load, the cluster high availability layer obtains the real-time load data and network status of the master node through the cluster status monitoring layer. If it is confirmed that the master node has no data updates and the network link is normal, the master node is finally determined to be down, triggering the master-slave switchover process.

[0182] S63: Filter candidate master nodes from the election queue: Based on the initialized election queue, quickly filter out candidate master nodes that meet the criteria to ensure switching efficiency.

[0183] S631: Read the latest standby node election queue and exclude nodes in the queue that are in a fault state, maintenance state, or whose data synchronization progress is lower than a preset threshold (which can be a synchronization completion rate of <95%).

[0184] S632: From the filtered valid queue, select the first-ranked backup node as the first candidate master node, and select the second and third-ranked nodes as backup candidate nodes for quick switching when the first candidate node fails to verify.

[0185] S633: Extract key information about candidate master nodes, including data synchronization progress (Session data and business data synchronization status with the original master node), hardware resource reserves (remaining CPU and memory capacity), and network bandwidth status, to provide a basis for subsequent verification.

[0186] S64: Candidate Master Node Verification and Confirmation: The shortlisted candidate master nodes undergo multi-dimensional verification to ensure they possess the capability to take over master node operations.

[0187] S641: Connectivity Verification: The high availability layer of the cluster establishes a dedicated communication link with the first candidate master node to verify the network connectivity of the node and ensure that there are no issues such as link interruption or excessive latency (average latency > 100ms).

[0188] S642: Resource Availability Verification: Check whether the current load rate (CPU, memory, network bandwidth) of the candidate master node is lower than the preset threshold (which can be 60%) to ensure that there are sufficient resources to handle the business traffic of the original master node;

[0189] S643: Data Integrity Verification: Through the Redis cluster sentinel mechanism, verify the synchronization completion rate of session data between the candidate master node and the original master node, which must reach 100% synchronization; at the same time, verify the synchronization differences of business data (including user information and version control information in relational databases) to ensure that the data consistency error is ≤0.01%.

[0190] S65: Perform primary / standby failover: After determining the new primary node, complete role switching, resource configuration, and business takeover to ensure seamless service continuity.

[0191] S651: Role Change Notification: The cluster high availability layer sends a role upgrade instruction to the new master node, and at the same time sends a role downgrade instruction (to become a standby node) to the original master node (if it recovers later), and sends a role retention instruction and new master node information to all other standby nodes.

[0192] S652: Resource Configuration Synchronization: Synchronize the core configuration parameters of the original master node, such as load balancing strategy, API interface configuration, and access control rules, to the new master node to ensure that the running configuration of the new master node is consistent with that of the original master node.

[0193] S653: Business Traffic Switching: The cluster high availability layer sends a node role update notification to the load balancing layer, informing it of the IP address, port, and other information of the new master node. The load balancing layer immediately routes subsequent user requests to the new master node. At the same time, it gradually stops forwarding new requests to the original master node, waiting for the original master node to finish processing any unfinished tasks (if any), ensuring that there is no business interruption and no data loss.

[0194] S654: Redis Cluster Role Synchronization: Notifies the Redis cluster to update the master node information, sets the new master node as the master node of the Redis cluster, and converts the Redis instance corresponding to the original master node to a slave node, ensuring that Session data is subsequently synchronized to the new master node and other slave nodes.

[0195] S66: Switchover Result Confirmation and Status Synchronization: After completing the primary / standby switchover, verify the switchover effect and synchronize the status to all layers of the cluster to ensure system consistency.

[0196] S661: Switchover effect verification: The cluster high availability layer monitors the request processing status of the new master node (including request success rate and response latency) for 30 seconds. If the request success rate is ≥99.9% and the average response latency is ≤1.2 times that of the original master node under normal conditions, the switchover is confirmed to be successful.

[0197] S662: Status synchronization to all layers: The switching results, such as the new master node information, the switching completion time, and the status of the original master node, are synchronized to the user management layer, version control layer, load balancing layer, cluster status monitoring layer, and relational database. Each layer updates its local node information cache to ensure that subsequent interactions are based on the latest node role.

[0198] S663: Election Queue Update: Remove the new primary node from the standby node election queue, and add the original primary node (if its state is restored) to the queue. Recalculate the priority scores of all nodes in the queue, generate a new election queue, and prepare for the next possible primary / standby switchover.

[0199] S664: Alarms and Log Recording: If the switch is successful, record the switch log, including the reason for the switch, the candidate node verification process, the switch time, and the data synchronization status; if an anomaly occurs during the switch, such as data synchronization delay or brief request failure, trigger a cluster alarm and notify the operation and maintenance personnel to investigate and handle it.

[0200] In this embodiment, the specific process of step S7 is as follows:

[0201] S71: Session Data Initialization, Generation, and Storage: When a user makes their first request to the server cluster, session data is created and stored in the Redis cluster, laying the foundation for subsequent sharing.

[0202] S711: After receiving a user request, the server cluster verifies the user's identity through the user management layer (which can be account password verification or token verification). After confirming its legitimacy, a unique Session identifier (Session ID) is generated, using the UUID (Universally Unique Identifier) ​​format to ensure global uniqueness.

[0203] S712: Encapsulate Session data content: Encapsulate core information such as user identity information (user ID, role permissions), request context data (request time, access path, device information), and business status data (shopping cart information, order temporary status, login validity) into Session data according to a preset data structure (such as key-value pairs).

[0204] S713: Determine the Redis cluster storage location: The load balancing layer determines the location based on the hash value of the user request (calculated in step S4). H r The Redis cluster node mapping relationship is used to route Session data to the master node of the Redis cluster for storage. The storage key is defined as Session:{Session ID}, and the value is the serialized Session data (serialized in JSON format to balance readability and storage efficiency).

[0205] S714: Storage Confirmation Feedback: After the Redis master node successfully writes Session data, it returns a storage success response to the server cluster. The server cluster returns the SessionID to the client via Cookie or URL rewriting for identity association in subsequent requests.

[0206] S72: Redis Cluster Session Data Redundancy Backup: To ensure no session data is lost, the Redis cluster uses a master-slave replication mechanism to achieve real-time data synchronization and build redundant backups.

[0207] S721: Redis cluster architecture configuration: adopts a master-slave architecture, with each Redis master node corresponding to at least 2 slave nodes. The master and slave nodes are distributed on different physical servers to avoid single points of failure.

[0208] S722: Real-time synchronization trigger: After the Redis master node completes the writing of session data, it immediately triggers the master-slave replication process to synchronize the session data to all slave nodes through asynchronous replication. During the synchronization process, the master node records data and writes it to the log. The slave nodes continuously read the log through a long connection to obtain incremental data and synchronize and update the local storage.

[0209] S723: Synchronization Status Monitoring: The Sentinel process of the Redis cluster monitors the data synchronization progress of the master and slave nodes in real time, recording the synchronization delay time (the time it takes to synchronize data from the master node to the slave node) and the synchronization completion rate (the amount of synchronized Session data / the total amount of Session data on the master node); if the synchronization delay exceeds the preset threshold (50ms) or the synchronization completion rate is lower than 99.9%, the Sentinel process triggers an alarm and optimizes the synchronization link (adjusting the slave node priority, switching the synchronization data source).

[0210] S73: Session data synchronization triggered after master-slave switchover: After the cluster high availability layer completes the master-slave node switchover, the session data synchronization process between the new master node and the Redis cluster is automatically triggered.

[0211] S731: Switchover Status Notification: After the cluster high availability layer determines the new master node and completes the role change, it sends a master-slave switchover completion notification to the Redis cluster sentinel process, which includes key information such as the original master node identifier, the new master node IP address, and the switchover completion time.

[0212] S732: Synchronization Request Initiation: After the new master node starts up, its built-in Redis data synchronization module automatically sends a Session data synchronization request to the Redis cluster sentinel process. The request carries the node identifier of the new master node, the data receiving port, and the time range of the Session data to be synchronized, such as all active Session data within 1 hour before the switch.

[0213] S733: Data source determination for synchronization: The sentinel process selects the optimal data synchronization source based on the synchronization completion rate, network latency, and hardware load status of each slave node in the Redis cluster. It prioritizes the slave node with a 100% synchronization completion rate and the lowest latency, and returns the address information of the slave node to the new master node. If the synchronization completion rate of all slave nodes is less than 100%, the node with the highest synchronization completion rate is selected as the data source, and the range of unsynchronized Session data is marked.

[0214] S74: Batch Synchronization and Verification of Session Data: The new master node retrieves session data from the specified Redis slave node to complete batch synchronization and integrity verification.

[0215] S741: Establish a dedicated synchronization link: The new master node establishes an encrypted TCP connection (using SSL / TLS protocol) with the selected Redis slave node to ensure the security of session data transmission and prevent data leakage or tampering.

[0216] S742: Data Sharding Transmission: Redis slave nodes split the Session data to be synchronized into preset shard sizes (1000 Session data per shard) and send the data to the new master node shards via the batch transmission protocol (Redis's PSYNC2 protocol). During transmission, each data shard carries a checksum (CRC32 check value) for the new master node to verify data integrity.

[0217] S743: Data Reception and Storage: The new master node receives Session data in shard order, first verifying the integrity of each shard using a checksum. If the verification passes, the data is deserialized and stored in local memory (for fast access) and local disk (for persistent backup). If the verification fails, the new master node sends a shard retransmission request to the Redis slave node until the shard passes verification.

[0218] S744: Full Synchronization Confirmation: After all data shards have been transmitted, the new master node counts the total amount of received Session data and the number of active Sessions (such as Sessions with interactions within the last 30 minutes), and compares it with the corresponding data volume of the Redis slave nodes. If the total amount of data is consistent and the difference in the number of active Sessions is ≤0.1%, then the full synchronization is confirmed to be complete. If the difference exceeds the threshold, the new master node triggers incremental synchronization, synchronizing only the missing or inconsistent Session data.

[0219] S75: Session Sharing Activation and Real-time Synchronization Maintenance: After initial data synchronization is completed, the new master node enters the real-time synchronization state of session data to ensure the consistency of session data in subsequent business interactions.

[0220] S751: Shared State Activation: The new master node sends a Session data synchronization completion notification to the cluster high availability layer and load balancing layer, informing itself that it has Session sharing capabilities; after receiving the notification, the load balancing layer begins to route subsequent user requests carrying SessionIDs to the new master node, and the new master node can directly read the corresponding Session data from local storage without repeatedly querying the Redis cluster.

[0221] S752: Real-time data synchronization maintenance: When the new master node processes user requests, if it updates Session data (modifies user login status, updates shopping cart information), it will synchronously write the updated Session data to the Redis cluster master node. The Redis cluster master node, using a master-slave replication mechanism, synchronizes the updated data to all slave nodes in real time, ensuring the consistency of Session data in the Redis cluster. At the same time, the Session data stored locally on the new master node is kept in real-time synchronized with the Redis cluster master node to avoid data deviation.

[0222] S753: Expired Session Cleanup: The new master node and Redis cluster work together to execute the session data expiration cleanup mechanism. According to the preset session expiration time (expiring after 30 minutes of no user interaction), expired session data is periodically scanned and deleted. During the cleanup process, the new master node synchronously deletes the expired data in local storage, and the Redis cluster master and slave nodes also synchronously clean up the corresponding data to release storage resources.

[0223] S76: Synchronization Result Feedback and Anomaly Handling: After the Session data synchronization is completed, the synchronization result will be fed back and any anomalies that may occur will be handled:

[0224] S761: Synchronization Result Reporting: The new master node reports the detailed results of the Session data synchronization, including the total amount of synchronized data, synchronization time, number of successful synchronizations, number of failed synchronizations, and range of unsynchronized data, to the cluster status monitoring layer. The monitoring layer stores the synchronization logs and updates the cluster status information.

[0225] S762: Anomaly Handling Mechanism: If synchronization fails due to network interruption, Redis slave node failure, or other anomalies, the new master node will retry according to a preset retry strategy, such as retrying once every 1 second for a total of 5 retries, and then re-initiate the synchronization request. If the retry still fails, it will switch to the second-best data synchronization source (the backup slave node recommended by the sentinel process) to try again. If all slave nodes are unable to provide valid data, the new master node will trigger a cluster alarm and allow users to log in again to generate new session data, avoiding business interruption.

[0226] S763: Original Master Node Data Processing: If the original master node subsequently recovers and becomes a standby node, its locally stored Session data will undergo consistency verification with the Redis cluster master node. After synchronizing any missing updated data, it will serve as a standby Session data source and participate in any subsequent possible master-standby switchover synchronization process.

Claims

1. A server cluster load balancing method based on improved consistent hashing and Redis, characterized in that, Includes the following steps: S1: Build a server cluster architecture, including a user management layer, a version control layer, a load balancing layer, a cluster high availability layer, and a cluster status monitoring layer. Each layer establishes a communication connection through a preset API interface. S2: The cluster status monitoring layer periodically collects hardware performance parameters and real-time load data of each node in the server cluster. Hardware performance parameters include CPU utilization, memory usage, and network bandwidth throughput. Real-time load data includes the current number of connections, task processing queue length, and data transmission latency. S3: The load balancing layer calculates the performance value of each node, using the node performance ratio and the maximum linearity of virtual nodes as the core parameters to determine the number of virtual nodes corresponding to each node. S4: The load balancing layer uses an improved consistent hashing algorithm to map each virtual node to a hash ring. User request data is processed by a hash function to obtain the corresponding hash value. The target virtual node is located on the hash ring based on the hash value, and then the target physical node is determined. S5: The load balancing layer combines real-time load data and location results to allocate user requests to target physical nodes through dynamic scheduling strategies. If the real-time load of the target physical node exceeds a preset threshold, the optimal physical node is repositioned based on the node performance value and remaining load capacity. S6: The cluster high availability layer monitors the running status of the master node in real time through an election queue mechanism. When the master node fails, a new master node is elected from the standby nodes to complete the master-standby switchover. S7: Use Redis cluster to store session data. After the master-slave switch is completed, the cluster high availability layer synchronously retrieves the session data of the original master node from the Redis cluster to the new master node to achieve session sharing. The specific process of step S3 is as follows: S31: Based on the preprocessed standardized parameters, a weighted summation method is used to calculate the comprehensive performance value of each node, specifically: Preset the weighting coefficients for each hardware performance parameter; The node's overall performance value is calculated using the following formula: Node performance value P = P1 × W1 + P2 × W2 + P3 × W3; Wherein, P1, P2, and P3 are the CPU normalized value, memory normalized value, and network bandwidth normalized value, respectively, with corresponding weights W1, W2, and W3; Iterate through all nodes in the server cluster and calculate the performance value for each node. P n , n The node number; S32: Calculate the performance ratio of a single node based on the performance values ​​of all nodes: S321: Calculate the sum of the performance values ​​of all nodes in the cluster, using the formula: Total Cluster Performance Value P total =Σ P n n=1 to N; S322: Calculate the performance ratio of each node using the following formula: Node performance ratio R = performance value of a single node P n / Total cluster performance P total ; S33: Based on the node performance ratio, the maximum linear value of virtual nodes, and the total number of cluster nodes, calculate the number of virtual nodes corresponding to each node through a preset model; S331: Configure the maximum linear value L for virtual nodes, preset according to the cluster size; S332: Configure the preset baseline number of nodes M, which is the standard configuration number of nodes in the server cluster; S333: Solve the model based on the following number of virtual nodes: The number of virtual nodes V = node performance ratio R × maximum linear value of virtual nodes L × (total number of cluster nodes N / preset baseline number of nodes M); S334: Round the calculated result V to the nearest integer; S335: Output the number of virtual nodes corresponding to each node, as the input parameter for hash ring mapping in the improved consistent hashing algorithm; The specific process of step S4 is as follows: S41: Generate a unique identifier for each virtual node: based on the calculated number of virtual nodes corresponding to each physical node, denoted as... V n , n For each physical node, a unique identifier is assigned to all virtual nodes of that physical node. The specific process is as follows: S411: Extract the core network identifier of each physical node, and use the IP address of the physical node as the basic identifier to ensure the uniqueness and stability of the identifier; S412 sequentially numbers the virtual nodes of each physical node, following a numbering rule from 1 to... V n ; S413: Generate a unique identifier for the virtual node using the concatenation format of IP address-virtual node number. S42: Calculate the hash value of the virtual node and the user request: Use a unified hash function to perform hash calculations on the virtual node identifier and the user request data to ensure a uniform distribution of hash values ​​and computational efficiency. The specific process is as follows: S421: The MD5 hash algorithm is selected as the core hash function, and the hash value output length is 128 bits. S422: Perform MD5 hash calculation on the unique identifier of each generated virtual node: Convert the identifier string into a byte array, input it into the MD5 algorithm for calculation, obtain a 128-bit hash value, and then decode it using Base64 or convert it to hexadecimal to map it into an integer hash value in the range of 0~2³²-1, denoted as . H v ; S423: Perform hash calculation on user request data: Extract the core feature data of the user request, including the request URL, request parameter digest, and user's unique identifier Session ID, and concatenate them into a request feature string; use the same MD5 hash algorithm as the virtual node to operate on the request feature string to obtain a 128-bit hash value, which is also mapped to an integer hash value in the range of 0~2³²-1, denoted as . H r ; S43: Mapping Virtual Nodes to a Hash Ring: Mapping the hash values ​​of all virtual nodes H v The hash values ​​are mapped to a predefined hash ring, constructing a complete hash ring mapping relationship. The specific process is as follows: S431: Define the numerical range of the hash ring as 0~2³²-1, and regard this range as a closed ring structure; S432: Traverse the hash values ​​of all virtual nodes H v , each H v As a mapping point on the hash ring, it is located on the hash ring according to the value of Hv; S433: Establish a mapping table between virtual node hash values ​​and physical nodes, storing each... H v The corresponding original physical node information includes IP address, performance value, and current load status; S44: Locate the target virtual node based on the hash value requested by the user: H r The process of finding the corresponding target virtual node on the hash ring is as follows: S441: Traverse all virtual nodes on the hash ring H v Construct an ordered list of hash values ​​in ascending order of their numerical values; S442: Locate the target virtual node using a clockwise search rule: In the ordered hash value list, find the first one that is greater than or equal to... H r of H v ,Should H v The corresponding virtual node is the target virtual node; S443: If H r Greater than all on the hash ring H v If the maximum value is not found, then the hash ring will default to the one with the smallest value. H v The corresponding virtual node; S45: Determine the target physical node through the target virtual node: Based on the association between the target virtual node and the physical node, the target physical node requested by the user is finally determined; S451: Search the virtual node hash value-physical node mapping table established in step S43, and use the target virtual node's... H v This allows you to obtain complete information about the original physical node, including its IP address, performance value, and current load status. S452: Pre-verify the current load status of the target physical node: If the real-time load of the physical node does not exceed the preset threshold, then directly determine it as the final target physical node; S453: If the real-time load of the target physical node exceeds the preset threshold, a clockwise suboptimal node search is triggered: continue to search for the next virtual node in a clockwise direction on the hash ring, repeat the verification process of steps S451 to S452, until a physical node with a load that meets the requirements is found and it is identified as the target physical node.

2. The server cluster load balancing method based on improved consistent hashing and Redis according to claim 1, characterized in that, Step S2 also includes a data preprocessing procedure, as detailed below: S21: Define the baseline thresholds for each hardware performance parameter, including the baseline thresholds for CPU utilization, memory usage, and network bandwidth throughput. S22: Normalize each parameter and calculate it using the formula: Normalized parameter value = (actual node parameter value / parameter baseline threshold) × 100; S23: Output the normalized CPU value, normalized memory value, and normalized network bandwidth value of each node, denoted as P1, P2, and P3.

3. The server cluster load balancing method based on improved consistent hashing and Redis according to claim 1, characterized in that, The specific process of step S5 is as follows: S51: Preset load threshold range and core parameters: Complete the basic parameter configuration before the dynamic scheduling strategy is executed; S52: Obtain initial positioning results and real-time load data; S53: Determine the status of the target node based on the load threshold; S54: Request allocation under normal or low load conditions: Under normal load conditions: User requests are directly routed to the target physical node, and request allocation logs are recorded at the same time; Low load state: After the request allocation is completed, the virtual node dynamic adjustment mechanism is triggered to increase the number of virtual nodes corresponding to the node and synchronously update the virtual node mapping relationship of the hash ring to expand the allocation range of subsequent requests; S55: Optimal physical node reselection under high load conditions: When the load rate of the target physical node exceeds the preset threshold, the node reselection process is initiated to select the optimal node based on the node performance value and remaining load capacity.

4. The server cluster load balancing method based on improved consistent hashing and Redis according to claim 1, characterized in that, The specific process of step S6 is as follows: S61: Initialize the standby node election queue: When the server cluster starts, the election queue is built and configured to provide a basis for candidate nodes for subsequent primary-standby switchover; S62: Real-time monitoring of master node operating status: The cluster high availability layer monitors the master node's operating status in real time through a multi-dimensional monitoring mechanism; S63: Filter candidate master nodes from the election queue: Based on the initialized election queue, quickly filter out candidate master nodes that meet the conditions; S64: Verification and Confirmation of Candidate Master Nodes: Verify the selected candidate master nodes from multiple dimensions to ensure that they have the ability to take over the business of the master node; S65: Perform primary / standby failover: After determining the new primary node, complete the role switching, resource configuration, and business takeover to ensure seamless service continuity; S66: Switchover Result Confirmation and Status Synchronization: After completing the primary / standby switchover, verify the switchover effect and synchronize the status to each layer of the cluster to ensure system consistency.

5. The server cluster load balancing method based on improved consistent hashing and Redis according to claim 1, characterized in that, The specific process of step S7 is as follows: S71: Perform Session data initialization, generation, and storage: When a user makes their first request to the server cluster, the Session data is created and stored in the Redis cluster. S72: Perform redundant backup of Redis cluster session data: Redis clusters achieve real-time data synchronization through master-slave replication mechanism to build redundant backups; S73: Session data synchronization triggered after master-slave switchover: After the cluster high availability layer completes the master-slave node switchover, the session data synchronization process between the new master node and the Redis cluster is automatically triggered. S74: Batch Synchronization and Verification of Session Data: The new master node retrieves session data from the specified Redis slave node to complete batch synchronization and integrity verification; S75: Session sharing activation and real-time synchronization maintenance: After the initial data synchronization is completed, the new master node enters the real-time synchronization state of session data to ensure the consistency of session data in subsequent business interactions. S76: Synchronization Result Feedback and Anomaly Handling: After the Session data synchronization is completed, the synchronization result is fed back and any anomalies that may occur are handled.

Images