Server cluster load balancing method based on improved consistency Hash and Redis

Abstract

The invention relates to a server cluster load balancing method based on improved consistency Hash and Redis, and the method comprises the steps: firstly constructing a modular cluster architecture comprising a user management layer, a load balancing layer and the like, and collecting node hardware performance parameters and real-time load data through a cluster state monitoring layer; the load balancing layer dynamically calculates the number of virtual nodes based on parameters such as a node performance ratio, maps a hash ring and positions a target physical node by adopting an improved consistency hash algorithm, and allocates a request in combination with a dynamic scheduling strategy; and the cluster high-availability layer realizes high-efficiency switching of main and standby devices through an election queue mechanism, and completes redundant backup and synchronous sharing of Session data by means of a Redis cluster. According to the method, the problems of data inclination, low efficiency of master-slave switching, inconsistent Session sharing and the like in the traditional technology are solved, the cluster load balancing efficiency and high availability are improved, and the method is suitable for high-concurrency scenes such as medical treatment, finance and e-commerce.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of server cluster load balancing, and particularly relates to a server cluster load balancing method based on improved consistent hashing and Redis. BACKGROUND

[0002] With the rapid development of information technology, the business scale of key industries such as medical treatment, finance and e-commerce continues to expand, and the user access volume is growing explosively, which puts unprecedentedly severe requirements on the load bearing capacity and high availability of server clusters. The traditional single-point server architecture is limited by hardware resources, and when facing high-concurrency request scenarios, it is prone to problems such as resource exhaustion, dramatic increase in response delay and even system crash, and thus cannot meet the stable operation needs of modern businesses. Therefore, the server cluster architecture becomes the mainstream choice, and the load balancing technology and high-availability design become the core keys to guarantee the efficient and stable operation of the cluster.

[0003] At present, a variety of load balancing algorithms and high-availability architecture schemes have emerged in the industry, but there are still many technical pain points to be solved in actual application. In terms of load balancing, although the traditional consistent hashing algorithm can solve the data migration problem when nodes are added or deleted to some extent, it does not consider the hardware performance differences of each node, and only uses a fixed number of virtual nodes for hash ring mapping, which leads to the fact that the nodes with strong performance cannot fully exert their computing power, while the nodes with weak performance face the risk of overload, ultimately causing data skew and reducing the overall load balancing efficiency of the cluster; at the same time, the existing dynamic scheduling strategies mostly rely on a single load indicator for decision-making, lack comprehensive consideration of node performance values and remaining load capacity, and are difficult to achieve precise and balanced allocation of request traffic.

[0004] In terms of cluster high availability, the traditional master-slave switching mechanism mostly uses simple priority sorting or random election to select standby nodes, without considering key factors such as the real-time performance state of the nodes and the data synchronization progress, which leads to the fact that the new master node after switching may have problems such as insufficient resources and incomplete data, affecting service continuity; in addition, the sharing of Session data between master and standby nodes is an important link to ensure seamless connection of services, and in the existing schemes, some use the way of storing Session data locally, so that the standby node cannot obtain complete Session information after the master node fails, resulting in loss of user login state and interruption of business processes; even if some schemes use distributed storage to realize Session sharing, there are still problems such as high data synchronization delay and difficulty in guaranteeing consistency.

[0005] Furthermore, the existing server cluster architecture has the problem of high module coupling, the interaction logic between the functional modules is complex, when the business requirements change or the cluster size is adjusted, it is difficult to quickly expand and adapt, increasing the system maintenance cost and upgrading difficulty. In summary, how to solve the problems of data skew, inefficient master-slave switching, inconsistent Session sharing and poor system scalability in the prior art, and realize efficient load balancing and high reliable operation of the server cluster in a high concurrency scenario, has become a technical problem to be solved in the field.

[0006] Therefore, the present application provides a server cluster load balancing method based on improved consistent hashing and Redis to solve the above technical problems in the prior art. SUMMARY

[0007] The purpose of the present application is to provide a server cluster load balancing method based on improved consistent hashing and Redis to solve the above technical problems in the prior art.

[0008] To solve the above technical problems, the technical solution adopted by the present application is as follows: The server cluster load balancing method based on improved consistent hashing and Redis comprises the following steps: 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 state monitoring layer, and establish communication connection between each layer through a pre-set API interface; S2: The cluster state monitoring layer periodically collects hardware performance parameters and real-time load data of each node in the server cluster, the hardware performance parameters include CPU usage, memory occupancy, network bandwidth throughput, the real-time load data includes current connection number, task processing queue length, data transmission delay; S3: The load balancing layer calculates the performance value of each node, determines the number of virtual nodes corresponding to each node, and takes the node performance ratio and the maximum linear value of the virtual node as the core parameters; S4: The load balancing layer uses an improved consistent hashing algorithm to map the virtual nodes of each node to a hash ring, calculates the corresponding hash value of the user request data through a hash function, locates the target virtual node on the hash ring according to the hash value, and then determines the target physical node; S5: The load balancing layer combines the real-time load data and the positioning result, and distributes the user request to the target physical node through a dynamic scheduling strategy, if the real-time load of the target physical node exceeds a pre-set threshold, the optimal physical node is repositioned based on the node performance value and the remaining load capacity; S6: The cluster high availability layer monitors the running state of the master node in real time through the election queue mechanism, elects a new master node from the standby nodes when the master node is down, and completes the master-slave switching; S7: Store the Session data by using the Redis cluster, and after the master-slave switching is completed, the cluster high-availability layer synchronously obtains the Session data of the original master node from the Redis cluster to the new master node, so as to realize the Session sharing.

[0009] Preferably, the step S2 further comprises a data preprocessing process, and the data preprocessing process specifically comprises the following steps: S21: Define the benchmark threshold values of the hardware performance parameters, including the CPU usage benchmark threshold value, the memory occupancy benchmark threshold value, and the network bandwidth throughput benchmark threshold value; S22: Perform a normalization conversion on each parameter, and the calculation formula is: parameter standardized value=(node actual parameter value / parameter benchmark threshold value) x 100; S23: Output the CPU standardized value, the memory standardized value, and the network bandwidth standardized value of each node, and mark them as P1, P2, and P3.

[0010] Preferably, the step S3 specifically comprises the following steps: S31: Based on the preprocessed standardized parameters, the weighted summation method is used to calculate the comprehensive performance value of each node; S32: According to the performance values of all nodes, the performance ratio of a single node is calculated; S33: Based on the node performance ratio, the maximum linear value of the virtual node, and the total number of cluster nodes, the number of virtual nodes corresponding to each node is calculated through a preset model.

[0011] Preferably, the step S33 specifically comprises the following steps: S331: Configure the maximum linear value L of the virtual node; S332: Configure the preset benchmark node number M; S333: Solve according to the following virtual node number calculation model: Virtual node number V=node performance ratio R x maximum linear value L of virtual node x (total number of cluster nodes N / preset benchmark node number M); S334: Perform an integer processing on the calculation result V; S335: Output the number of virtual nodes corresponding to each node as an input parameter of the hash ring mapping in the improved consistent hashing algorithm.

[0012] Preferably, the step S4 specifically comprises the following steps: S41: Generate a unique identifier of the virtual node based on the number of virtual nodes corresponding to each physical node calculated; S42: Calculate the hash value of the virtual node and the user request: use a unified hash function to perform a hash calculation on the virtual node identifier and the user request data, so as to ensure the uniform distribution and calculation efficiency of the hash value; S43: mapping virtual nodes to a hash ring: mapping hash values of all virtual nodes to a preset hash ring according to numerical values to construct a complete hash ring mapping relationship; S44: locating a target virtual node based on a hash value: locating a corresponding target virtual node on the hash ring according to a hash value requested by a user; S45: determining a target physical node through the target virtual node: determining a target physical node requested by a user based on an association relationship between the target virtual node and a physical node.

[0013] Preferably, the specific process of step S45 is as follows: S451: searching the mapping relationship table of virtual node hash values-physical nodes established in step S43 to obtain complete information of an original physical node corresponding to the hash value of the target virtual node; S452: pre-verifying a current load state of the target physical node: if a real-time load of the physical node does not exceed a preset threshold, the physical node is directly determined as a final target physical node; S453: if the real-time load of the target physical node exceeds the preset threshold, triggering a clockwise suboptimal node search: continuing to search for a next virtual node on the hash ring in a clockwise direction, repeating the verification process of steps S451-S452 until a physical node with a load meeting a requirement is found, and the physical node is determined as the target physical node.

[0014] Preferably, the specific process of step S5 is as follows: S51: presetting a load threshold interval and a core parameter: completing basic parameter configuration before executing a dynamic scheduling strategy; S52: obtaining initial positioning results and real-time load data; S53: determining a target node state based on a load threshold; S54: request distribution in a normal state or a low load state: normal load state: directly routing a user request to the target physical node, and recording a request distribution log; low load state: on the basis of completing request distribution, triggering a virtual node dynamic adjustment mechanism, increasing a number of virtual nodes corresponding to the node, and synchronously updating virtual node mapping relationships of the hash ring to expand a distribution range of subsequent requests; S55: optimal physical node reselection in a high load state: when a load rate of the target physical node exceeds a preset threshold, starting a node reselection process, and screening an optimal node based on a node performance value and a remaining load capacity.

[0015] Preferably, the specific process of step S6 is as follows: S61: initialize the standby node election queue: when the server cluster starts, complete the construction and configuration of the election queue, and provide candidate node basis for subsequent master-standby switching; S62: real-time monitoring of the master node running state: the cluster high availability layer masters the running state of the master node in real time through a multi-dimensional monitoring mechanism; S63: screening candidate master nodes from the election queue: based on the initialized election queue, quickly screen out candidate master nodes that meet the conditions; S64: candidate master node verification and confirmation: multi-dimensional verification is performed on the screened candidate master nodes to ensure that they have the ability to take over the master node business; S65: execute master-standby switching operation: after determining the new master node, complete role switching, resource configuration and business takeover to ensure seamless service connection; S66: switching result confirmation and state synchronization: after completing the master-standby switching, verify the switching effect and synchronize the state to each layer of the cluster to ensure system consistency.

[0016] Preferably, the specific process of step S7 is as follows: S71: Session data initialization generation and storage: when a user initiates a request to the server cluster for the first time, create and store Session data in the Redis cluster; S72: Redis cluster Session data redundancy backup: the Redis cluster realizes real-time data synchronization through the master-slave replication mechanism to build redundancy backup; S73: Session data synchronization trigger after master-standby switching: after the cluster high availability layer completes the master-standby node switching, automatically trigger the Session data synchronization process between the new master node and the Redis cluster; S74: Session data batch synchronization and verification: the new master node obtains Session data from the specified Redis slave node, completes batch synchronization and integrity verification; S75: Session sharing takes effect and is maintained in real time: after completing the initial data synchronization, the new master node enters the Session data real-time synchronization state to ensure the consistency of Session data in subsequent business interactions; S76: synchronization result feedback and exception handling: after the Session data synchronization is completed, feedback the synchronization result and handle possible abnormal situations.

[0017] The beneficial effects of the application include: The load balancing efficiency is greatly improved, and the data skew problem is completely solved: through the cluster state monitoring layer, the hardware performance parameters and real-time load data of each node are comprehensively collected, the node performance ratio and virtual node maximum linear value are introduced in the load balancing layer, a dynamic virtual node number calculation model is constructed, the nodes with stronger performance are allocated more virtual nodes, and the nodes with weaker performance are allocated fewer virtual nodes, which fundamentally avoids the data skew caused by fixed virtual node number in the traditional consistent hashing algorithm. At the same time, combined with the dynamic scheduling strategy, the request distribution is carried out by comprehensively considering the node performance value and the remaining load capacity, which realizes the accurate and uniform distribution of high-concurrency traffic among cluster nodes, significantly improves the overall load bearing capacity of the cluster, reduces the risk of single-point overload, the load balancing error of the cluster is small, and the node resource utilization is high.

[0018] The master-slave switching is efficient and reliable, and the service continuity is guaranteed: based on the master-slave switching mechanism of the election queue, an ordered election queue is constructed by comprehensively considering the node performance value and historical service quality data when the cluster starts, and is updated in real time and dynamically, which ensures the quality of the candidate nodes; the master node state monitoring adopts a multi-dimensional mechanism combining heartbeat detection and service availability verification, cooperates with the secondary confirmation process, and avoids fault misjudgment; the candidate master node verification covers connectivity, resource availability, data integrity and service readiness, etc., which ensures that the new master node has the ability to completely take over the business. The above design shortens the master-slave switching time to seconds, has high switching success rate, effectively avoids the service interruption problem caused by unreasonable node selection and inconsistent data in the traditional switching mechanism, and guarantees the continuous and stable operation of the key business.

[0019] The Session data sharing is efficient and consistent, and the user experience is improved: with the help of the master-slave replication mechanism of Redis cluster, real-time redundant backup of Session data is realized, and data loss is avoided; after master-slave switching, the optimal data synchronization source is quickly screened through the sentinel mechanism, and the encryption sharding transmission and integrity verification technology are adopted to realize the fast and safe synchronization of Session data, the synchronization completion rate is high, and the synchronization delay is controlled within milliseconds. After completing data synchronization, the new master node can respond to user requests in real time, avoiding problems such as user login state loss and business process interruption, guaranteeing the continuity of user interaction, and significantly improving the user experience, especially suitable for scenarios such as e-commerce ordering and financial transactions which have high requirements for session continuity.

[0020] The system scalability and maintainability are significantly enhanced: the constructed server cluster architecture adopts a modular design, divides the system into a user management layer, a version control layer, a load balancing layer, a cluster high availability layer, and a cluster state monitoring layer, and communicates between the layers through a preset API interface, realizing independent development, deployment, and maintenance of each module. When the business demand grows and the cluster size needs to be expanded, the new nodes can be quickly accessed through the standardized interface, and the load balancing layer and the cluster high availability layer can automatically complete node performance evaluation, virtual node configuration, and election queue updating, without the need for large-scale adjustment of the existing system architecture; when a module needs to be upgraded or optimized, it will not affect the normal operation of other modules, greatly reducing the maintenance cost and upgrade difficulty of the system, and improving the life cycle and adaptability of the system. BRIEF DESCRIPTION OF DRAWINGS

[0021] Figure 1 The flowchart of the server cluster load balancing method based on improved consistent hashing and Redis of the application.

[0022] Figure 2 The flowchart of calculating the number of virtual nodes corresponding to each node. DETAILED DESCRIPTION

[0023] The following will be described in conjunction with the accompanying Figures 1-2 Further detailed description of the application: Example 1 Referring to the accompanying Figure 1 The server cluster load balancing method based on improved consistent hashing and Redis, characterized in that it comprises the following steps: 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 state monitoring layer, and establish a communication connection between the layers through a preset API interface, realizing independent development and flexible expansion of each module.

[0024] S2: The cluster state monitoring layer periodically collects hardware performance parameters and real-time load data of each node in the server cluster, the hardware performance parameters include CPU usage, memory occupancy, network bandwidth throughput, and the real-time load data includes current connection number, task processing queue length, and data transmission delay.

[0025] S3: The load balancing layer calculates the performance value of each node based on the collected hardware performance parameters, combines the total number of nodes of the server cluster, and determines the number of virtual nodes corresponding to each node through a preset virtual node number calculation model, the virtual node number calculation model takes node performance ratio and virtual node maximum linear value as core parameters, and 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.

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

[0027] S5: The load balancing layer combines the real-time load data collected in step S2 and the positioning result of step S4, and distributes the user request to the target physical node through a dynamic scheduling strategy. If the real-time load of the target physical node exceeds the preset threshold, the optimal physical node is repositioned based on the node performance value and the remaining load capacity.

[0028] S6: The cluster high-availability layer monitors the running state of the master node in real time through the election queue mechanism, and elects a new master node from the standby nodes when the master node is down, and completes the master-standby switchover.

[0029] S7: The Session data is stored in the Redis cluster, and the cluster high-availability layer synchronously obtains the Session data of the original master node from the Redis cluster to the new master node after completing the master-standby switchover in step S6, and realizes Session sharing.

[0030] In another embodiment of the present embodiment, step S7 is followed by S8: The cluster state monitoring layer monitors the request distribution result of step S5 and the master-standby switchover state of step S6 in real time, stores the monitoring data to a preset relational database, and feeds back to the load balancing layer, providing data support for subsequent virtual node number adjustment and request scheduling.

[0031] In the present embodiment, step S2 further includes a data preprocessing process, which is as follows: S21: Define the reference threshold of each hardware performance parameter, including setting the CPU usage reference threshold to 80%, the memory occupancy reference threshold to 75%, and the network bandwidth throughput reference threshold to 1000Mbps; S22: Normalize each parameter, and the calculation formula is: Parameter standardization value=(node actual parameter value / parameter reference threshold) x 100; Wherein, if the node actual parameter value exceeds the reference threshold, the standardization value is 100; if it is lower than the reference threshold, it is calculated according to the actual ratio, such as a node CPU actual usage rate of 40%, then the CPU standardization value=(40% / 80%) x 100=50; S23: Output the CPU standardization value, memory standardization value, and network bandwidth standardization value of each node, denoted as P1, P2, and P3.

[0032] Embodiment 2 On the basis of embodiment 1, referring to Figure 2As shown, the specific process of step S3 is as follows: S31: Based on the pre-processed normalized parameters, the comprehensive performance value of each node is calculated by using the weighted summation method, specifically: The weight coefficients of each hardware performance parameter are preset and dynamically configured according to the business scenario, such as CPU weight W1=0.4, memory weight W2=0.3, and network bandwidth weight W3=0.3, satisfying W1+W2+W3=1; The node comprehensive performance value is calculated according to the following formula: node performance value P=P1×W1+P2×W2+P3×W3; For example: if P1=80, P2=70, and P3=90, then P=80×0.4+70×0.3+90×0.3=32+21+27=80; All nodes in the server cluster are traversed to calculate the performance value of each node P n , n is the node number, n =1,2,...,N, N is the total number of cluster nodes.

[0033] S32: According to the performance values of all nodes, the performance ratio of a single node is calculated, specifically: S321: The total sum of the performance values of all nodes in the cluster is calculated, and the formula is: cluster performance total value P total =Σ P n , n=1 to N.

[0034] S322: The performance ratio of each node is calculated according to the following formula: Node performance ratio R=Single node performance value P n / Cluster performance total value P total ; For example: if the cluster contains 3 nodes with performance values of 80, 70, and 50, P total =200, then the performance ratio of the first node R1=80 / 200=0.4; and the sum of the performance ratios of all nodes is ensured to be 1 (i.e. ΣR=1), which is used as a calculation result verification basis.

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

[0036] S331: Configure the maximum linear value L of the virtual node, which is preset according to the cluster size, such as L = 100 when the total number of cluster nodes is less than or equal to 10, and L = 200 when the total number of nodes is greater than 10, which is used to limit the total number of virtual nodes and avoid resource waste.

[0037] S332: Configure the preset reference node number M, which is the standard configuration node number of the server cluster, such as M = 5, which is a fixed reference parameter.

[0038] S333: Solve according to the following virtual node number calculation model: Virtual node number V = node performance ratio R x maximum linear value L of virtual node x (total number of cluster nodes N / preset reference node number M).

[0039] S334: Round the calculation result V, use the rounding method to ensure that V is a positive integer, and the sum of the virtual node numbers of all nodes is less than or equal to L x (N / M), to avoid overloading the hash ring.

[0040] For example: If a node R = 0.4, L = 100, N = 3, and M = 5, then V = 0.4 x 100 x (3 / 5) = 0.4 x 100 x 0.6 = 24, that is, the node corresponds to 24 virtual nodes.

[0041] S335: Output the virtual node number corresponding to each node as the input parameter of the hash ring mapping in the improved consistent hash algorithm.

[0042] The specific process of step S4 is as follows: S41: Generate a unique identifier for the virtual node: based on the calculated virtual node number corresponding to each physical node, denoted as V n , n Assign a unique identifier to each virtual node of the physical node, and the specific process is as follows: S411: Extract the core network identifier of each physical node, 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.

[0043] S412 sequentially numbers the virtual nodes of each physical node, and the numbering rule is from 1 to V n For example, if a physical node corresponds to 24 virtual nodes, then the numbering is 1~24.

[0044] S413: Generate a unique identifier for the virtual node using the IP address-virtual node number splicing format, For example: The IP of the physical node is 192.168.1.101, and the identifier of the 5th virtual node is 192.168.1.101-5.

[0045] 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. 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.

[0046] 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).

[0047] 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).

[0048] 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 interval as a closed ring structure, that is, the next node after the value 2³²-1 is 0.

[0049] 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.

[0050] S433: Establish a mapping table between "virtual node hash value and physical node" to store each H vCorresponding original physical node information, including IP address, performance value, current load state, facilitates subsequent through H v Quickly associate physical nodes.

[0051] S44: Locate target virtual node based on hash value: according to the hash value of user request H r , find the corresponding target virtual node on the hash ring, the specific process is: S441: Traverse all virtual nodes on the hash ring H v , and construct an ordered hash value list in ascending order.

[0052] S442: Locate target virtual node using clockwise search rule: in the ordered hash value list, find the first value greater than or equal to H r H v , the H v corresponding virtual node is the target virtual node.

[0053] S443: If H r is greater than the maximum value of all H v on the hash ring, then default to the virtual node with the smallest value on the hash ring H v , because the hash ring is a closed structure, it meets the core logic of clockwise circular search.

[0054] S45: Determine target physical node through target virtual node: based on the association between target virtual node and physical node, finally determine the target physical node of user request.

[0055] Embodiment 3 On the basis of embodiment 1 or embodiment 2, the specific process of step S45 is as follows: S451: Find the "virtual node hash value-physical node" mapping relationship table established in step S43, and through the H v of the target virtual node, obtain the complete information of its corresponding original physical node, including IP address, performance value, and current load state.

[0056] S452: Pre-check the current load state 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, trigger the clockwise suboptimal node search: continue to search for the next virtual node in the clockwise direction on the hash ring, repeat the verification process of steps S451-S452, until a physical node with a load meeting the requirements is found, which is determined as the target physical node, ensuring the rationality of the request allocation.

[0057] In the embodiment, the specific process of step S5 is as follows: S51: Preset load threshold interval 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 decision: S511: Define the load threshold interval: According to the upper limit of the hardware performance and the business carrying capacity of the server cluster, three load intervals are divided, which are low load interval (0-40%), normal load interval (40%-70%), and high load interval (70%-100%), wherein the critical value (70%) of the high load interval is the preset load threshold.

[0058] S512: Define the core evaluation index: associate the real-time load data (current connection number, task processing queue length, and data transmission delay) collected in step S2 with the node performance value calculated in step S3, define the residual load capacity index, and the calculation formula is: Residual load capacity=(1-current load rate) x node performance value; Wherein, the current load rate=(actual load data / load upper limit threshold) x 100%; For example, if the current connection number of a node is 800 and the upper limit of the connection number is 1000, then the current load rate=80%.

[0059] S513: Configure the scheduling trigger condition: set the real-time load data collection period to 10 seconds, and the upper limit of the node reselection retry number to 3 times, to ensure that the scheduling decision is based on the latest load state, and to avoid request blocking caused by unlimited retries.

[0060] S52: Obtain the initial positioning result and real-time load data: S521: Extract the positioning result of step S4: obtain the complete information of the target physical node, including the node IP address, performance value, node identifier, and corresponding virtual node mapping relationship; 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 state monitoring layer, including the current connection number, task processing queue length, data transmission delay, and the current load rate.

[0061] S523: Data consistency verification: verify whether the difference between the collection timestamp of real-time load data and the current scheduling time is within the preset period, such as ≤10 seconds, if it exceeds, reacquire the latest data, ensure the accuracy of load evaluation.

[0062] S53: Determine the target node state based on the load threshold: S531: Calculate the current load rate of the target physical node: according to the core indicators in real-time load data, including current connection number, CPU usage, calculate the comprehensive load rate by weighted average method, the weight configuration is consistent with the performance value calculation weight in step S3, such as CPU usage 0.4, memory occupancy rate 0.3, network bandwidth utilization rate 0.3.

[0063] S532: Match the load threshold interval: match the calculated comprehensive load rate with the preset three load intervals to determine the current load state of the target physical node (low load or normal load or high load); S533: Trigger the corresponding scheduling branch: if the load state is normal load or low load, enter S54 to execute the direct allocation logic; if the load state is high load, i.e. real-time load exceeds the preset threshold, enter step S55 to execute the node reselection logic.

[0064] S54: Request allocation under normal / low load state: When the load state of the target physical node is normal load or low load, complete the request allocation according to the following rules: S541: Normal load state (40%~70%): directly route the user request to the target physical node, and record the request allocation log, including request ID, allocation node IP, allocation time, node current load rate.

[0065] S542: Low load state (0~40%): on the basis of completing request allocation, trigger the virtual node dynamic adjustment mechanism to increase the number of virtual nodes corresponding to the node; Adjustment amplitude = (40%-current load rate) x baseline adjustment amount, such as baseline adjustment amount is 5, and synchronously update the virtual node mapping relationship of the hash ring, expand the allocation range of subsequent requests, and improve the load utilization rate of the node.

[0066] S543: Allocation result feedback: feedback the information of successful request allocation to the cluster state monitoring layer, update the real-time load data of the node, such as current connection number+1, task processing queue length+1, provide the latest state for the next round of scheduling.

[0067] S55: Optimal physical node reselection under high load state: When the load rate of the target physical node ≥ 70% (exceeding the preset threshold), start the node reselection process, and select the optimal node based on the node performance value and the remaining load capacity: S551: Select candidate node pool: traverse all physical nodes in the server cluster, exclude nodes in the fault state and maintenance state, and retain normally operating nodes as candidate nodes; S552: Calculate the priority score of the candidate node: for each candidate node, combine its performance value and remaining load capacity to calculate the priority score (the higher the score, the stronger the node adaptability) according to the following formula: Priority score = node performance value × 0.6 + remaining load capacity × 0.4; For example: the performance value of candidate node A is 80, and the remaining load capacity is 32; The performance value of candidate node B is 70, and the remaining load capacity is 42; Then the priority score of A = 80 × 0.6 + 32 × 0.4 = 48 + 12.8 = 60.8, and the priority score of B = 70 × 0.6 + 42 × 0.4 = 42 + 16.8 = 58.8, i.e. the priority of A is higher than that of B.

[0068] S553: Sort and select the optimal node: sort the candidate nodes in descending order of priority score, and select the node ranked first as the new target physical node; 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 turn according to the sorting result until a node that meets the requirements is found or the upper limit of the number of retries is reached; S555: Upper limit of the number of retries: if all candidate nodes are traversed and no node with a load that meets the requirements is found, temporarily put the request into the buffer queue, the upper limit of the queue length is 1000, and trigger the node reselection every 2 seconds until the request allocation is successful or the buffer queue is timed out, the timeout time is 30 seconds, and after timeout, return a request failure prompt and record abnormal log.

[0069] S56: Final request allocation and scheduling state synchronization: S561: Route the request to the target node: whether direct allocation or node reselection, finally route the data packet of the user request (including request parameters, Session ID, target node identifier) to the determined physical node, and process the request by the node.

[0070] S562: Synchronize the scheduling state to each layer: synchronize the request allocation result (allocate node IP, allocation state, load data) to the cluster state monitoring layer and the cluster high availability layer, and the cluster state monitoring layer updates the node load statistical data, and the cluster high availability layer records the node service state.

[0071] S563: Dynamically optimize the hash ring mapping: if the node reselection is triggered by the current scheduling, adjust the virtual node distribution of the hash ring according to the reselection result, reduce the number of virtual nodes of the original high-load node, and increase the number of virtual nodes of the optimal node. The adjustment range = (current load rate - 70%) x reference adjustment amount), increase the number of virtual nodes of the optimal node, optimize the initial positioning result of the subsequent request, and reduce the probability of load overload.

[0072] Embodiment 4 On the basis of embodiment 1 or embodiment 2 or embodiment 3, the specific process of step S6 is as follows: S61: Initialize the standby node election queue: when the server cluster starts, complete the construction and configuration of the election queue, and provide candidate node basis for subsequent master-standby switching: S611: Collect the hardware performance parameters (consistent with the hardware performance parameters in step S3, including CPU usage, memory occupancy, network bandwidth throughput) and historical service quality data of all standby nodes in the cluster, including historical request processing success rate, average response delay, and fault recovery times.

[0073] S612: Calculate the comprehensive priority score of the standby node: adopt the weighted summation method, wherein the hardware performance value weight accounts for 60% (the calculation method is consistent with the node performance value calculation logic in step S3).

[0074] The historical service quality score weight accounts for 40% (historical request processing success rate x 0.6 + (1- average response delay / reference delay) x 0.2 + (1- fault recovery times / total running days) x 0.2), and the final score range is mapped to 0-100 points.

[0075] S613: Sort all standby nodes in descending order of comprehensive priority score, generate an ordered standby node election queue, and record the complete information of each node in the queue, including IP address, performance value, priority score, current running state, and data synchronization progress.

[0076] S61: Configure the queue dynamic update rule: recalculate the priority score of each standby node every 30 seconds, adjust the queue order; if a new standby node is added or an original node is exited, such as failure offline or maintenance removal, update the queue members in real time to ensure the effectiveness of the queue.

[0077] S62: Real-time monitoring of master node running state: The cluster high availability layer masters the running state of the master node in real time through multi-dimensional monitoring mechanism, and discovers faults in time: S621: Establish a heartbeat detection mechanism: The master node sends heartbeat data packets to the cluster high availability layer at a predetermined period, and the data packets contain core information such as the current CPU load, memory occupation, task processing queue length, data synchronization state (synchronization progress with Redis cluster and standby node).

[0078] S622: Supplementary service availability check: The cluster high availability layer sends service probe requests to the master node every 10 seconds, such as simulating user lightweight requests, interface connectivity detection, to verify whether the master node can normally process requests and return valid responses.

[0079] S623: Set fault judgment threshold: If the heartbeat data packet from the master node is not received for 3 consecutive times, i.e. heartbeat timeout, the cumulative duration is 6 seconds, or the service probe request returns invalid response for 2 consecutive times, such as timeout, error code, connection rejection, the master node is preliminarily judged to be abnormal.

[0080] S624: Secondary confirmation mechanism: To avoid misjudgment, such as network jitter, transient load too high causing heartbeat delay, the cluster high availability layer obtains the real-time load data and network state of the master node through the cluster state monitoring layer, and if it is confirmed that the master node has no data update and the network link is normal, the master node is finally determined to be down, triggering the master-standby switching process.

[0081] S63: Select candidate master nodes from the election queue: Based on the initialized election queue, quickly select candidate master nodes that meet the conditions to ensure switching efficiency: S631: Read the current latest standby node election queue, exclude nodes in the queue that are in fault state, maintenance state or data synchronization progress is lower than the preset threshold (which can be synchronization completion rate < 95%); S632: From the effective queue after screening, select the first ranked standby node as the first candidate master node, and select the second and third ranked nodes as standby candidate nodes for quick switching when the first candidate node fails.

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

[0083] S64: Candidate master node verification and confirmation: Multi-dimensional verification is performed on the selected candidate master nodes to ensure their ability to take over the master node business: S641: Connectivity verification: The cluster high-availability layer establishes a dedicated communication link with the first candidate master node, verifies node network connectivity, and ensures that there is no link interruption, excessively high delay (average delay > 100 ms), etc. 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%), and ensure that there are enough resources to take over the original master node's traffic; S643: Data integrity verification: Through the Redis cluster sentinel mechanism, verify the synchronization completion rate of the candidate master node and the original master node's Session data, which needs to reach 100% synchronization; at the same time, verify the synchronization difference of business data (including user information in the relational database, version control information), to ensure that the data consistency error is ≤0.01%.

[0084] S65: Execute master-slave switchover operation: After determining the new master node, complete role switching, resource configuration, and business takeover to ensure seamless service connection: S651: Role change notification: The cluster high-availability layer sends a role upgrade instruction to the new master node, and sends a role downgrade instruction (becomes a standby node) to the original master node (if it is recovered later), and sends a role maintenance instruction and new master node information to all other standby nodes.

[0085] S652: Resource configuration synchronization: Synchronize the load balancing strategy, API interface configuration, permission control rules, and other core configuration parameters of the original master node 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.

[0086] S653: Business traffic switching: The cluster high-availability layer sends a node role update notification to the load balancing layer, informing the IP address, port, and other information of the new master node, and the load balancing layer immediately routes subsequent user requests to the new master node; at the same time, gradually stops forwarding new requests to the original master node, waits for the original master node to complete the unfinished tasks (if any), and ensures that there is no business interruption and no data loss.

[0087] S654: Redis cluster role synchronization: Notify the Redis cluster to update the master node information, set the new master node as the master node of the Redis cluster, and convert the original master node's Redis instance to a slave node, to ensure that Session data is subsequently synchronized to the new master node and other slave nodes.

[0088] S66: Switching result confirmation and state synchronization: After completing the master-slave switchover, verify the switching effect and synchronize the state to each layer of the cluster to ensure system consistency: S661: Switching effect verification: The cluster high-availability layer monitors the request processing of the new master node (including request success rate and response delay) for 30 seconds. If the request success rate is greater than or equal to 99.9% and the average response delay is less than or equal to 1.2 times of the normal state of the original master node, it is confirmed that the switching is successful.

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

[0090] S663: Election queue update: The new master node is removed from the standby node election queue, and the original master node (if the state is restored) is added to the queue. The priority scores of all nodes in the queue are recalculated, and a new election queue is generated to prepare for the next possible master-standby switching.

[0091] S664: Alarm and log recording: If the switching is successful, the switching log is recorded, including the switching trigger reason, candidate node verification process, switching time consumption, and data synchronization situation. If an exception occurs during the switching process, such as data synchronization delay or temporary request failure, the cluster alarm is triggered to notify the operation and maintenance personnel for troubleshooting.

[0092] In this embodiment, the specific process of step S7 is as follows: S71: Session data initialization generation and storage: When a user first initiates a request to the server cluster, the creation and Redis cluster storage of Session data are completed to lay the foundation for subsequent sharing: S711: After the server cluster receives the user request, the user identity is verified through the user management layer (which can be account password verification or Token verification). After confirming the legality, a unique Session ID is generated in the form of UUID (Universal Unique Identifier) to ensure global uniqueness.

[0093] S712: Encapsulating Session data content: The user identity information (user ID, role permission), request context data (request time, access path, device information), and business state data (shopping cart information, order temporary state, login validity) are encapsulated as Session data according to the preset data structure (such as Key-Value key-value pair).

[0094] S713: Determining the Redis cluster storage location: The load balancing layer determines the Redis cluster storage location according to the hash value of the user request (calculated in step S4 H r) and Redis cluster node mapping relationship, route Session data to the master node of Redis cluster for storage, and the storage Key is defined as Session:{Session ID}, and the Value is the serialized Session data (serialized in JSON format, taking into account readability and storage efficiency).

[0095] S714: Storage confirmation feedback: After the Redis master node successfully writes Session data, it returns a storage success response to the server cluster, and the server cluster returns the Session ID to the user end through Cookie or URL rewriting method for subsequent request identity association.

[0096] S72: Redis cluster Session data redundancy backup: To ensure that Session data is not lost, Redis cluster implements real-time data synchronization through master-slave replication mechanism to build redundancy backup: S721: Redis cluster architecture configuration: adopt one master and multiple slaves architecture, each Redis master node corresponds to at least 2 slave nodes, and the master-slave nodes are distributed on different physical servers to avoid single point failure.

[0097] S722: Real-time synchronization trigger: when the Redis master node completes Session data writing, it triggers the master-slave replication process immediately, and synchronizes Session data to all slave nodes through asynchronous replication; during synchronization, the master node records data write log, and the slave node continuously reads the log through long connection to obtain incremental data and update local storage.

[0098] S723: Synchronization state monitoring: the Redis cluster's Sentinel process monitors the data synchronization progress of master-slave nodes in real time, records the synchronization delay time (the time spent from the master node to the slave node) and the synchronization completion rate (the amount of synchronized Session data / the total Session data amount of the master node); if the synchronization delay exceeds the preset threshold (50ms) or the synchronization completion rate is less than 99.9%, the Sentinel process triggers an alarm and optimizes the synchronization link (adjusts the priority of slave nodes and switches synchronization data source).

[0099] S73: Session data synchronization trigger after master-slave switching: after the cluster high availability layer completes master-slave node switching, it automatically triggers the Session data synchronization process between the new master node and the Redis cluster: S731: Switching state notification: after the cluster high availability layer determines the new master node and completes role change, it sends a master-slave switching completion notification to the Redis cluster's Sentinel process, including the original master node identifier, the new master node IP address, the switching completion time and other key information.

[0100] S732: Synchronization request initiation: After the new master node is started, its built-in Redis data synchronization module automatically sends a Session data synchronization request to the Redis cluster sentinel process, carrying the node identifier, data receiving port, and Session data time range (such as all active Session data within the last hour before switching) of the new master node.

[0101] S733: Synchronization data source determination: The sentinel process selects the optimal data synchronization source based on the synchronization completion rate, network delay, and hardware load state of each slave node in the Redis cluster, preferentially selecting the slave node with a 100% synchronization completion rate and the lowest delay, and returns the address information of the slave node to the new master node; if the synchronization completion rate of all slave nodes does not reach 100%, the node with the highest synchronization completion rate is selected as the data source, and the range of unsynchronized Session data is marked.

[0102] S74: Batch synchronization and verification of Session data: The new master node obtains Session data from the designated Redis slave node, completes batch synchronization and integrity verification: 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 the Session data transmission process and prevent data leakage or tampering.

[0103] S742: Data sharding transmission: The Redis slave node splits the Session data to be synchronized into shards according to the pre-set shard size (1000 Session data per shard), and sends the data to the new master node in shards through the batch transmission protocol (Redis PSYNC2 protocol); during transmission, each data shard carries a checksum (CRC32 checksum) for the new master node to verify data integrity.

[0104] S743: Data reception and storage: The new master node receives Session data in the order of shards, first verifies the integrity of each shard through the checksum, and if the verification is passed, deserializes the data and stores it in the 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 verification is passed S744: Full quantity synchronization confirmation: After all data shards are transmitted, the new master node counts the total amount of Session data received, the number of active Sessions (such as Sessions that have interacted in the last 30 minutes), and compares them with the corresponding data amount of the Redis slave node; if the total amount of data is consistent and the difference in the number of active Sessions is ≤0.1%, it is confirmed that the full quantity synchronization is complete; if the difference exceeds the threshold, the new master node triggers incremental synchronization, and only synchronizes the missing or inconsistent Session data.

[0105] S75: Session sharing takes effect and real-time synchronization maintenance: After completing the initial data synchronization, the new master node enters the real-time synchronization state of Session data, ensuring the consistency of Session data in subsequent business interactions: 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, indicating that it has Session sharing capabilities; after receiving the notification, the load balancing layer starts routing user requests carrying SessionID to the new master node, and the new master node can directly read the corresponding Session data from the local storage without repeated queries to the Redis cluster.

[0106] S752: Real-time data synchronization maintenance: When processing user requests, if the Session data is updated (modify user login status, update shopping cart information), the new master node will synchronize the updated Session data to the Redis cluster master node; the Redis cluster master node synchronizes the updated data to all slave nodes in real time according to the master-slave replication mechanism, ensuring the consistency of Session data in the Redis cluster; at the same time, the Session data stored in the new master node is kept in real-time synchronization with the Redis cluster master node, avoiding data deviation; S753: Expired Session cleaning: The new master node cooperates with the Redis cluster to implement the Session data expiration cleaning mechanism, periodically scans and deletes expired Session data according to the preset Session expiration time (expired after 30 minutes of no interaction); during the cleaning process, the new master node synchronously deletes the expired data stored locally, and the Redis cluster master-slave nodes also synchronously clean the corresponding data, releasing storage resources.

[0107] S76: Synchronization result feedback and exception handling: After the Session data synchronization is completed, the synchronization result is fed back and possible exceptions are handled: S761: Synchronization result reporting: The new master node reports the detailed results of Session data synchronization to the cluster state monitoring layer, including the total amount of synchronized data, synchronization time consumption, the number of successful synchronization, the number of failures, and the range of unsynchronized data. The monitoring layer stores the synchronization log and updates the cluster state information.

[0108] S762: Abnormal processing mechanism: If the synchronization fails due to network interruption, Redis slave node failure, or other abnormalities during the synchronization process, the new master node will initiate a synchronization request again according to the preset retry strategy, such as retrying every 1 second and accumulating 5 retries. If it is still unsuccessful after retrying, it will switch to the suboptimal data synchronization source (the backup slave node recommended by the sentinel process) and try again. If all slave nodes cannot provide valid data, the new master node triggers a cluster alarm and allows users to log in again to generate new Session data, avoiding business interruption.

[0109] S763: Original master node data processing: If the original master node is restored and becomes a standby node later, its locally stored Session data will be subjected to consistency verification with the Redis cluster master node. After synchronizing the missing update data, it will serve as a standby Session data source and participate in the subsequent possible master-standby switching 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 the hardware performance parameters and real-time load data of each node in the server cluster. The hardware performance parameters include CPU utilization, memory usage, and network bandwidth throughput. The 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: 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.

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 2, characterized in that, The specific process of step S3 is as follows: S31: Based on the preprocessed standardized parameters, the weighted summation method is used to calculate the comprehensive performance value of each node; S32: Calculate the performance ratio of a single node based on the performance values ​​of all nodes; 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.

4. The server cluster load balancing method based on improved consistent hashing and Redis according to claim 3, characterized in that, The specific process of step S33 is as follows: S331: Configure the maximum linearity value L for virtual nodes; S332: Configure the preset number of baseline nodes M; 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 an input parameter for hash ring mapping in the improved consistent hashing algorithm.

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 S4 is as follows: S41: Generate a unique identifier for each virtual node: based on the number of virtual nodes corresponding to each physical node obtained through calculation; 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; 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; 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; 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.

6. The server cluster load balancing method based on improved consistent hashing and Redis according to claim 5, characterized in that, The specific process of step S45 is as follows: 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; 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.

7. 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.

8. 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.

9. 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