Automatic load balancing distribution method and system

Abstract

The present disclosure discloses an automatic load balancing distribution method and system, in which a distribution server registers Zookeeper on a calling server to monitor the nodes of the calling server; the calling server registers in Zookeeper and saves or updates the calling server information; Zookeeper pushes the calling server information to the distribution server; the distribution server updates the locally saved calling server information and sets a hash slot data structure; the data request end sends an address acquisition request to the distribution server; the distribution server queries the calling server address corresponding to the address acquisition request through a slot query and feeds it back to the data request end, which then makes a data call to the corresponding calling server based on the fed-back calling server address. The present disclosure realizes full automation of load balancing, solves the problem of manual allocation of hash slots, and can automatically achieve efficient hash slot migration for scenarios where distributed nodes are added or deleted, minimizing the impact of data migration that occurs when ordinary hash algorithms are sharded.

Description

Technical Field

[0001] The present disclosure relates to the field of electronic technology, and in particular to an automatic load balancing distribution method and system. Background Art

[0002] Currently, there are two main data hashing algorithms for distributed environments: 1. Consistent hashing algorithm; 2. Hash slot algorithm.

[0003] The hash slot algorithm is commonly used in cluster expansion and contraction in Redis. The implementation method of hash slot in Redis is as follows: In the Redis cluster environment, data is stored in shards, so the hash slot value assigned to the Redis node can be specified at startup. Assuming the hash slot value is 0-1000, when the Redis client performs an operation, it first performs CRC16 on the key to be operated (convert the key to int first), then takes the modulus, calculates the slot position, and then forwards the request to the corresponding Redis node, thus completing the sharded storage and management of the data. If Redis needs to be scaled down or expanded, hash slots can be manually allocated. For example: redis-1 is allocated {0-7000}, redis-2 is allocated {7001-16383}. If redis-3 needs to be added, the hash slots of redis-1 and redis-2 are split and allocated to redis-3; similarly, if redis-1 is removed from the cluster, {0-7000} of redis-1 is allocated to redis-2 and redis-3. However, the current hash slot algorithm in Redis requires users to manually allocate hash slots, which results in the uniformity of data nodes relying on the allocation results of hash slots, and cannot achieve automatic data migration when server nodes are expanded or reduced, resulting in poor real-time performance.

[0004] Therefore, how to realize the automation of hash slot has become a problem that technicians in this field urgently need to solve. Summary of the Invention

[0005] In view of this, the present disclosure provides the following technical solutions:

[0006] An automatic load balancing distribution method is applied to an automatic load balancing distribution system, wherein the automatic load balancing distribution system includes: a distribution server, a call server, a zookeeper, and a data request end; the method includes:

[0007] The distribution server registers the zookeeper on the calling server to monitor the node of the calling server;

[0008] The calling server saves or updates the calling server information in the zookeeper;

[0009] When the calling server information is saved or updated, the zookeeper pushes the calling server information to the server;

[0010] The distribution server updates the locally stored calling server information based on the received calling server information;

[0011] The distribution server sets a hash slot data structure based on the locally stored calling server information;

[0012] The data requesting end sends an address acquisition request to the distribution server;

[0013] The distribution server queries the calling server address corresponding to the address acquisition request through the slot and feeds back to the data request end;

[0014] The data requesting end makes a data call to the corresponding calling server based on the fed-back calling server address.

[0015] Preferably, the calling server information includes the IP address of the calling server, a weight representing the number of requests that the calling server can carry, and geographical distribution information of the calling server.

[0016] Preferably, the weight representing the number of requests that the call server can carry is determined by the number of CPU cores of the distribution server, the memory of the distribution server, the network bandwidth of the distribution server, the free memory of the distribution server, the free CPU load of the distribution server and the total number of CPU cores of the distribution server.

[0017] Preferably, the weight representing the number of requests that the call server can carry is calculated based on the formula weight = number of distribution server CPU cores * 0.5 + distribution server memory * 0.2 + distribution server network bandwidth / 100 * 0.5 + distribution server free memory * 0.5 + distribution server idle CPU load * total number of distribution server CPU cores.

[0018] Preferably, the distribution server sets the hash slot data structure based on the locally stored calling server information, including:

[0019] The distribution server compares the received calling server information with the locally stored calling server information to determine the changed scenario;

[0020] The distribution server updates the locally stored calling server information based on the changed scenario and the received calling server information.

[0021] Preferably, the method further comprises:

[0022] The calling server periodically sends calling server operation information to Zookeeper;

[0023] The zookeeper updates the corresponding calling server information based on the calling server running information and pushes it to the distribution server.

[0024] An automatic load balancing distribution system includes: a distribution server, a call server, a zookeeper and a data request terminal, wherein:

[0025] The distribution server is used to register Zookeeper on the calling server to monitor the nodes of the calling server;

[0026] The calling server is used to save or update the calling server information in the zookeeper;

[0027] The zookeeper is used to push the calling server information to the distribution server when the calling server information is saved or updated;

[0028] The distribution server is further configured to update the locally stored calling server information based on the received calling server information;

[0029] The distribution server is further configured to set a hash slot data structure based on the locally stored calling server information;

[0030] The data request end is used to send an address acquisition request to the distribution server;

[0031] The distribution server is further configured to query the calling server address corresponding to the address acquisition request through the slot and feed it back to the data requesting end;

[0032] The data requesting end is further used to make data calls to the corresponding calling server based on the fed-back calling server address.

[0033] An automatic load balancing distribution device includes at least one processor and a memory;

[0034] The memory stores computer-executable instructions;

[0035] The instructing a processor to execute the computer-executable instructions stored in the memory enables the at least one processor to perform the automatic load balancing distribution method as described above.

[0036] A computer-readable storage medium stores computer-executable instructions. When a processor executes the computer-executable instructions, the automatic load balancing distribution method described above is implemented.

[0037] A computer program product includes a computer program, wherein when the computer program is executed by a processor, the automatic load balancing distribution method described above is implemented.

[0038] It can be seen from the above technical solution that the present disclosure discloses an automatic load balancing distribution method and system, wherein the distribution server registers Zookeeper on the calling server to monitor the nodes of the calling server; the calling server saves or updates the calling server information in Zookeeper; when the calling server information is saved or updated, Zookeeper pushes the calling server information to the distribution server; the distribution server updates the locally saved calling server information based on the received calling server information; the distribution server sets the hash slot data structure based on the locally saved calling server information; the data request end sends an address acquisition request to the distribution server; the distribution server queries the calling server address corresponding to the address acquisition request through the slot and feeds it back to the data request end, and the data request end makes a data call to the corresponding calling server based on the fed-back calling server address. The present disclosure realizes the full automation of hash slots, solves the problem of manual allocation of hash slots, and can automatically achieve efficient hash slot migration for scenarios where distributed nodes are added and deleted, minimizing the impact of data migration that occurs when ordinary hash algorithms are sharded. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the embodiments of the present disclosure or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0040] Figure 1 This is a method flow chart of embodiment 1 of an automatic load balancing distribution method disclosed in the present disclosure;

[0041] Figure 2 This is a method flow chart of embodiment 2 of an automatic load balancing distribution method disclosed in the present disclosure;

[0042] Figure 3 This is a structural diagram of an automatic load balancing distribution system embodiment 1 disclosed in the present disclosure;

[0043] Figure 4 This is a structural diagram of an automatic load balancing distribution system embodiment 2 disclosed in the present disclosure;

[0044] Figure 5 This is a structural diagram of an automatic load balancing distribution device disclosed in the present invention. DETAILED DESCRIPTION

[0045] The following will be combined with the drawings in the embodiments of the present disclosure to clearly and completely describe the technical solutions in the embodiments of the present disclosure. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, rather than all of the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present disclosure. The following will be combined with the drawings in the embodiments of the present disclosure to clearly and completely describe the technical solutions in the embodiments of the present disclosure. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, rather than all of the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present disclosure.

[0046] like Figure 1 FIG. 1 is a flow chart of an automatic load balancing distribution method embodiment 1 disclosed in the present invention.

[0047] Specifically:

[0048] S101. The distribution server registers Zookeeper on the calling server to monitor the node of the calling server;

[0049] First, the distribution servers monitor ZooKeeper's call server nodes and receive callback notifications from ZooKeeper if the number of nodes registered on the call server increases or decreases, or if the configured weight changes. This ensures that all distribution servers can simultaneously and promptly receive changes to the call server cluster, ensuring that hash slots can be adjusted in a timely manner.

[0050] S102. The calling server saves or updates the calling server information in Zookeeper;

[0051] S103. When the calling server information is saved or updated, Zookeeper pushes the calling server information to the distribution server;

[0052] S104. The distribution server updates the locally stored calling server information based on the received calling server information;

[0053] S105. The distribution server sets the hash slot data structure based on the locally stored calling server information;

[0054] S106. The data requester sends an address acquisition request to the distribution server;

[0055] S107. The distribution server queries the calling server address corresponding to the address acquisition request through the slot and feeds back to the data requesting end.

[0056] First, the distribution server converts the request input parameter into an int value by performing a CRC16 operation. Then, it performs a hash modulo operation on the total number of hash slots to retrieve the actual slot index. The group ID corresponding to this index is then queried through the array. The group ID is then used to retrieve information such as the IP address of the actual calling server. Because CRC16 differs from other hash algorithms in that it has a higher execution rate and a higher degree of hashing, it is also used in clustered distribution requests in Redis. Furthermore, due to the use of array and Map data structures, both queries are O(1)-level, resulting in high query efficiency. Given that the same request is assigned to the same execution server, the efficiency of the query distribution can be further improved by leveraging local cache middleware such as Guava. Similar to general caching concepts, a data structure using request parameters as keys and the calling server's IP address as the value is used for storage. A cache layer is added before returning the server IP address from the hash slot query data structure. If a match is found, the server IP address is returned directly. If not, the server IP address is retrieved through the hash slot query and written to the local cache before being returned. To ensure the validity of cached data, a common practice is also adopted, that is, when the cached data changes, all caches are directly deleted. The advantages of doing so are as follows: 1. The cache memory can be quickly invalidated. If other threads exist, dirty reads will not be performed, and the actual query and write process will be repeated; 2. Direct deletion does not update the cache. The design concept is based on lazy loading, and the update process takes longer than the direct deletion process, which is likely to continue to cause dirty reads.

[0057] S108. The data requesting end makes a data call to the corresponding calling server based on the fed-back calling server address.

[0058] Compared with the existing technology, the present disclosure solves the pain point that traditional hash slots need to be manually allocated, provides a weight-based allocation strategy, and greatly improves the allocation efficiency (see Table 1 and Table 2 for a comparison with the rate of consistent hashing). The algorithm can be deployed in a decentralized manner to avoid single points of failure.

[0059] Table 1 The number of hash slots is 16383 (total time consumption of 4 million times)

[0060]

[0061] Table 2 The number of hash slots is 16383 (average single time consumption)

[0062]

[0063] In one implementation, in step S102, the calling server information includes the server IP, weight, and geographical distribution information. Assume that there are 4 deployed calling servers, with IP addresses of 192.168.100.0, 192.168.100.1, 192.168.100.2, and 192.168.100.3, and each server has its own specific server parameter differences (for example, 64G memory, 24 CPU logical cores, 1G network bandwidth, and a computer room located in North China, etc.). A weight is calculated based on the performance and geographical distribution of each server. The larger the weight, the more requests the server can handle, which can make the hash slot allocation more tilted.

[0064] The weight representing the number of requests that the call server can handle = the number of CPU cores on the distribution server * the first value + the memory on the distribution server * the second value + the network bandwidth on the distribution server / 100 * the third value + the free memory on the distribution server * the fourth value + the free CPU load on the distribution server * the total number of CPU cores on the distribution server. The first value can be 0.5, the second value can be 0.2, the third value can be 0.5, and the fourth value can be 0.5.

[0065] The weights can be calculated for the following groups of server configurations:

[0066] Number of CPU cores Memory Network bandwidth Free memory Idle load Weight 24 16 1000 8 50％ 36.2 32 24 500 16 30％ 40.9 64 64 1000 48 60％ 112.2 64 32 800 16 50％ 82.4

[0067] Since Zookeeper is a tree-like storage format and provides persistent mutual exclusion features, the server IP is used as the stored key value, and the weight and geographical distribution are used as the stored value.

[0068] Taking the above calculation results as an example, the server node information finally saved to Zookeeper is as follows:

[0069] Server IP address Weight Geographical distribution 192.168.100.0 36.2 North China 192.168.100.1 40.9 northwest 192.168.100.2 112.2 southeast 192.168.100.3 82.4 North China

[0070] Combining multiple server operating parameters, the actual server load capacity is calculated based on a formula to make request distribution more reasonable.

[0071] In one implementation, the method further includes:

[0072] The calling server periodically sends the calling server running information to Zookeeper;

[0073] The calling server regularly reports its own server status at the time interval set according to actual needs, including changing parameters such as CPU load, network status, remaining memory, as well as benchmark parameters such as the number of CPU cores and total memory, and updates the corresponding node information to Zookeeper.

[0074] The reason for regular reporting is that the server's operating status can directly reflect its ability to carry services. By updating this data, the server's weight can be further dynamically updated, and ultimately the number of requests allocated to the server can be dynamically adjusted.

[0075] If the calculated weight information does not change, it will not be updated.

[0076] Zookeeper updates the corresponding calling server information based on the calling server's running information and pushes it to the distribution server.

[0077] After the calling server information is pushed to the distribution server, the distribution server updates the data according to the method of step S105.

[0078] On the basis of the above method embodiment 1, as Figure 2 FIG. 1 is a flow chart of a method for automatic load balancing distribution according to Embodiment 2 of the present disclosure.

[0079] Specifically:

[0080] S201. The distribution server registers Zookeeper on the calling server to monitor the node of the calling server;

[0081] First, the distribution servers monitor ZooKeeper's call server nodes and receive callback notifications from ZooKeeper if the number of nodes registered on the call server increases or decreases, or if the configured weight changes. This ensures that all distribution servers can simultaneously and promptly receive changes to the call server cluster, ensuring that hash slots can be adjusted in a timely manner.

[0082] S202. The calling server registers in Zookeeper and saves or updates the calling server information;

[0083] S203. When the calling server information is saved or updated, Zookeeper pushes the calling server information to the distribution server;

[0084] S204. The distribution server updates the locally stored calling server information based on the received calling server information;

[0085] S205. The distribution server compares the received calling server information with the locally stored calling server information to determine the change scenario;

[0086] The distribution server uses a unified SDK to maintain the hash slot data structure. There are four scenarios for changing the hash slot:

[0087] 1. Initialization group (only one group calls the server and the hash slot is initialized);

[0088] 2. Add a group (the number of calling server nodes is greater than or equal to 2, and the hash slot needs to be migrated);

[0089] 3. Delete the group (the number of calling server groups is reduced and the hash slots are partially merged);

[0090] 4. The weight information of any group changes (hash slots need to be split or merged).

[0091] S206. The distribution server updates the locally stored calling server information based on the changing scenario and the received calling server information;

[0092] Scenario 1: Initializing a Group

[0093] First, for the initialization phase, you need to define the number of hash slots (the default is 16383, converted to hexadecimal HEX: 3FFF).

[0094] Let’s redefine the main data structures. There are five data structures in this solution:

[0095] 1. Store all hash slot numbers and their corresponding group numbers. The map used in the above design uses an array instead of a map because the actual number of hash slots is determined when the program starts. The array index is the hash slot number (hash slot numbers start at 0), and the array value is the number of groups. The advantages of using an array instead of a map are: arrays use less memory than maps; although the query complexity is O(1), maps are approximately O(1), and because arrays have continuous memory, they can benefit from the operating system's data page cache optimization, making them faster overall.

[0096] 2. A map is needed to store the hash slot numbers in multiple groups. For example, if there are two groups with 4 hash slots, the storage structure may be: {Group 1: [slot0, slot2], Group 2: [slot1, slot3]}. To ensure that the internally stored hash slots are ordered (to ensure that the addition, deletion, and adjustment of hash slots are consistent in all environments), a TreeMap is used for storage;

[0097] 3. In order to quickly calculate the added group numbers (the group numbers will be discontinuous after multiple additions and deletions. In order to efficiently reuse the group numbers, it is necessary to calculate the minimum unused group number), a LinkedList is used to record the existing group numbers;

[0098] 4. In order to facilitate the calculation of the hash slots that need to be moved when adding or deleting groups, the number of current groups is stored;

[0099] 5. Since the group number is data used internally by the function, in order to facilitate expansion, the group information can be passed in when adding groups, so a map is added to store the relationship between the group number and the actual group information;

[0100] The above five data structures can quickly describe the correspondence between groups and hash slots (forward and reverse), two of which are key data structures and three are auxiliary data structures.

[0101] Since there is only one service provider group at initialization, no matter what the weight of the server is, it can occupy all the hash slots (that is, all 16383 slots are written with the ID of group 1), and group 1 saves all the hash slots (16383).

[0102] Scenario 2: Adding a Group

[0103] Take the process of adding from one group to two groups as an example. Under the premise of scenario 1, there is only one group before adding the group (192.168.100.0 with a weight of 100), and now group 2 (192.168.100.1 with a weight of 100) needs to be added. Because the permission of the added group is also 100, the added group is allocated exactly half of the hash slots (if the weights are inconsistent, if the added group 2 has a weight of 300, then group 1 accounts for 1 / 4 and group 2 accounts for 3 / 4).

[0104] The calculation formula for the hash slots that need to be migrated when adding a group is:

[0105] Total slots * (own weight / sum of original weights – own weight / (sum of original weights + weight of new node))

[0106] Therefore, the number of nodes that need to be migrated from group 1 is 8191. Since the data structure that stores hash slots is a TreeMap data structure (which will be sorted according to the key), we only need to delete the last 8191 hash slots and add these slots to group 2. At the same time, we change the group corresponding to the moved hash slots to group 2.

[0107] Scenario 3: Deleting a Group

[0108] The process of deleting a group is the opposite of adding a group. Take the process of deleting group 2 from two groups to become one group as an example.

[0109] In scenario 2, before the group is deleted, there are two groups (192.168.100.0 and 192.168.100.1), and the weights of these two servers are the same, so the hash slots allocated to the two groups are the same. Now, after receiving a notification from Zookeeper that group 2 needs to go offline, the hash slots of group 2 need to be transferred to group 1. The process is exactly the reverse of adding a group. The number of slots to be moved is calculated as follows:

[0110] Total slots * (own weight / (the sum of the original weights – the weight of the deleted node) – own weight / (the sum of the original weights))

[0111] Allocate all slots of group 2 to group 1, and then modify the group ID pointed to by the original slot to group 1.

[0112] Scenario 4: Changes in weight information of any group

[0113] If the weight of the calling server changes, the allocated slots need to be adjusted.

[0114] Under the premise of scenario 2, the weights of calling server 1 (192.168.100.0) and calling server 2 (192.168.100.1) are the same, so the number of hash slots in group 1 and group 2 is evenly divided. At this time, if Zookeeper notifies the calling server 2 that its weight has increased from 100 to 300, it triggers the reallocation of hash slots. The calculation formula for the moved slots is similar to the formula for adding and deleting nodes. After calculation, group 1 changes from occupying 1 / 2 of the slots to occupying 1 / 4 of the slots, and group 2 changes from occupying 1 / 2 of the slots to occupying 3 / 4 of the slots. Therefore, 1 / 4 of the slots need to be moved from group 1 to group 2.

[0115] After the slot migration, group 1 (192.168.100.0) occupies 4095 slots, and group 2 (192.168.100.1) occupies 12288 slots.

[0116] Assuming that the weight of group 1 is also adjusted to 300 at this time, then according to the migration formula, group 2 will return the 4095 slots previously migrated. In the end, group 1 and group 2 will evenly divide all the slots. The process is the same as scenario 4.

[0117] S207. The data requester sends an address acquisition request to the distribution server;

[0118] S208. The distribution server queries the calling server address corresponding to the address acquisition request through the slot and feeds back to the data requesting end.

[0119] First, the distribution server converts the request input parameter into an int value by performing a CRC16 operation. Then, it performs a hash modulo operation on the total number of hash slots to retrieve the actual slot index. The group ID corresponding to this index is then queried through the array. The group ID is then used to retrieve information such as the IP address of the actual calling server. Because CRC16 differs from other hash algorithms in that it has a higher execution rate and a higher degree of hashing, it is also used in clustered distribution requests in Redis. Furthermore, due to the use of array and Map data structures, both queries are O(1)-level, resulting in high query efficiency. Given that the same request is assigned to the same execution server, the efficiency of the query distribution can be further improved by leveraging local cache middleware such as Guava. Similar to general caching concepts, a data structure using request parameters as keys and the calling server's IP address as the value is used for storage. A cache layer is added before returning the server IP address from the hash slot query data structure. If a match is found, the server IP address is returned directly. If not, the server IP address is retrieved through the hash slot query and written to the local cache before being returned. To ensure the validity of cached data, a common practice is also adopted, that is, when the cached data changes, all caches are directly deleted. The advantages of doing so are as follows: 1. The cache memory can be quickly invalidated. If other threads exist, dirty reads will not be performed, and the actual query and write process will be repeated; 2. Direct deletion does not update the cache. The design concept is based on lazy loading, and the update process takes longer than the direct deletion process, which is likely to continue to cause dirty reads.

[0120] S209. The data requesting end makes a data call to the corresponding calling server based on the fed-back calling server address.

[0121] like Figure 3 FIG. 1 is a structural diagram of an automatic load balancing distribution system embodiment 1 disclosed in the present invention.

[0122] Specifically:

[0123] The distribution server 101 is used to register the zookeeper 103 on the calling server 102 to monitor the node of the calling server;

[0124] First, the distribution server 101 monitors the call server 102 node of Zookeeper 103. Once the number of nodes registered on the call server 102 increases or decreases, or the configured weight changes, it can receive a callback notification from Zookeeper 103. The purpose of this is to ensure that all distribution servers 101 can obtain changes in the call server 102 cluster simultaneously and in a timely manner, which can ensure the premise of timely adjustment of hash slots.

[0125] The calling server 102 is used to register with the zookeeper 103 and save or update the calling server information;

[0126] Zookeeper 103 is used to push the calling server information to the distribution server 101 when the calling server information is saved or updated;

[0127] The distribution server 101 is further configured to update the locally stored calling server information based on the received calling server information;

[0128] The distribution server 101 is further configured to set a hash slot data structure based on the locally stored calling server information;

[0129] The data requesting terminal 104 sends an address acquisition request to the distribution server 101;

[0130] The data request terminal 104 is used to send an address acquisition request to the distribution server 101;

[0131] The distribution server 101 is further configured to query the calling server address corresponding to the address acquisition request through the slot and feed back the address to the data requesting end 104 .

[0132] First, the distribution server 101 performs a CRC16 conversion on the request input parameter to an int value. It then performs a hash modulo operation on the total number of hash slots to retrieve the actual slot index. The group ID corresponding to the index is then searched through an array. The group ID is then used to search for information such as the IP address of the actual calling server 102. Because CRC16 differs from other hash algorithms in that it has a higher execution rate and a higher degree of hashing, it is also used in clustered distribution requests in Redis. Furthermore, due to the use of array and Map data structures, both queries are O(1)-level, resulting in high query efficiency. Given that the same request is assigned to the same execution server, the efficiency of the query distribution can be further improved by leveraging local cache middleware such as Guava. Similar to general caching concepts, a data structure using request parameters as keys and the IP address of the calling server 102 as the value is used for storage. A cache layer is added before the hash slot data structure is queried to return the server IP address. If a match is found, the server IP address is returned directly. If not, the server IP address is queried through the hash slot and written to the local cache before being returned. To ensure the validity of cached data, a common practice is also adopted, that is, when the cached data changes, all caches are directly deleted. The advantages of doing so are as follows: 1. The cache memory can be quickly invalidated. If other threads exist, dirty reads will not be performed, and the actual query and write process will be repeated; 2. Direct deletion does not update the cache. The design concept is based on lazy loading, and the update process takes longer than the direct deletion process, which is likely to continue to cause dirty reads.

[0133] The data requesting end 104 is further configured to perform data calls on the corresponding calling server 102 based on the fed-back calling server address.

[0134] Compared with the existing technology, the present disclosure solves the pain point that traditional hash slots need to be manually allocated, provides a weight-based allocation strategy, and greatly improves the allocation efficiency (see Table 1 and Table 2 for a comparison with the rate of consistent hashing). The algorithm can be deployed in a decentralized manner to avoid single points of failure.

[0135] Table 1 The number of hash slots is 16383 (total time consumption of 4 million times)

[0136]

[0137] Table 2 The number of hash slots is 16383 (average single time consumption)

[0138]

[0139]

[0140] In one implementation, in the above step S102, the calling server information includes the server IP, weight and geographical distribution information. Assume that there are 4 deployed calling servers 102, with IP addresses of 192.168.100.0, 192.168.100.1, 192.168.100.2, and 192.168.100.3, and each server has its own specific server parameter differences (for example, 64G memory, 24 CPU logical cores, 1G network bandwidth, computer room location in North China, etc.). A weight is calculated based on the performance and geographical distribution of each server. The larger the weight, the more requests the server can carry, which can make the hash slot allocation more tilted.

[0141] The weight representing the number of requests that the call server can handle = the number of CPU cores on the distribution server * the first value + the memory on the distribution server * the second value + the network bandwidth on the distribution server / 100 * the third value + the free memory on the distribution server * the fourth value + the free CPU load on the distribution server * the total number of CPU cores on the distribution server. The first value can be 0.5, the second value can be 0.2, the third value can be 0.5, and the fourth value can be 0.5.

[0142] The weights can be calculated for the following groups of server configurations:

[0143] Number of CPU cores Memory Network bandwidth Free memory Idle load Weight 24 16 1000 8 50％ 36.2 32 24 500 16 30％ 40.9 64 64 1000 48 60％ 112.2 64 32 800 16 50％ 82.4

[0144] Since Zookeeper 103 is a tree-like storage format and provides persistent mutual exclusion features, the server IP is used as the stored key value, and the weight and geographical distribution are used as the stored value.

[0145] Taking the above calculation results as an example, the server node information finally saved to zookeeper103 is as follows:

[0146] Server IP address Weight Geographical distribution 192.168.100.0 36.2 North China 192.168.100.1 40.9 northwest 192.168.100.2 112.2 southeast 192.168.100.3 82.4 North China

[0147] Combining multiple server operating parameters, the actual server load capacity is calculated based on a formula to make request distribution more reasonable.

[0148] In one implementation, the method further includes:

[0149] The calling server 102 is also used to periodically send calling server operation information to the zookeeper 103;

[0150] The calling server 102 regularly reports its own server status, including changing parameters such as CPU load, network status, remaining memory, and benchmark parameters such as number of CPU cores and total memory, at the time interval set according to actual needs, and updates the corresponding node information to zookeeper 103.

[0151] The reason for regular reporting is that the server's operating status can directly reflect its ability to carry services. By updating this data, the server's weight can be further dynamically updated, and ultimately the number of requests allocated to the server can be dynamically adjusted.

[0152] If the calculated weight information does not change, it will not be updated.

[0153] Zookeeper 103 is also used to update the corresponding calling server information based on the calling server running information and push it to the distribution server 101.

[0154] After the calling server information is pushed to the distribution server 101 , the distribution server 101 updates the data according to the method of step S105 .

[0155] like Figure 4 , which is a structural diagram of Example 2 of an automatic hash slot allocation system disclosed in the present invention.

[0156] Specifically:

[0157] The distribution server 101 is used to register the zookeeper 103 listener on the calling server 102;

[0158] First, the distribution server 101 monitors the call server 102 node of Zookeeper 103. Once the number of nodes registered on the call server 102 increases or decreases, or the configured weight changes, it can receive a callback notification from Zookeeper 103. The purpose of this is to ensure that all distribution servers 101 can obtain changes in the call server 102 cluster simultaneously and in a timely manner, which can ensure the premise of timely adjustment of hash slots.

[0159] The calling server 102 is used to register with the zookeeper 103 and save or update the calling server information;

[0160] Zookeeper 103 is used to push the calling server information to the distribution server 101 when the calling server information is saved or updated;

[0161] The distribution server 101 is further configured to update the locally stored calling server information based on the received calling server information;

[0162] A comparing unit 1011 is configured to compare the received calling server information with the locally stored calling server information to determine a changed scenario;

[0163] The distribution server 101 uses a unified SDK to maintain the hash slot data structure. There are four scenarios for changing the hash slot:

[0164] 1. Initialization group (only one group calls server 102, hash slots initialized);

[0165] 2. Add a group (the number of nodes in the calling server 102 is greater than or equal to 2, and the hash slot needs to be migrated);

[0166] 3. Delete the group (the number of groups in the calling server 102 is reduced, and the hash slots are partially merged);

[0167] 4. The weight information of any group changes (hash slots need to be split or merged).

[0168] The updating unit 1012 is configured to update the locally stored calling server information based on the changed scenario and the received calling server information;

[0169] Scenario 1: Initializing a Group

[0170] First, for the initialization phase, you need to define the number of hash slots (the default is 16383, converted to hexadecimal HEX: 3FFF).

[0171] Let’s redefine the main data structures. There are five data structures in this solution:

[0172] 1. Store all hash slot numbers and their corresponding group numbers. The map used in the above design uses an array instead of a map because the actual number of hash slots is determined when the program starts. The array index is the hash slot number (hash slot numbers start at 0), and the array value is the number of groups. The advantages of using an array instead of a map are: arrays use less memory than maps; although the query complexity is O(1), maps are approximately O(1), and because arrays have continuous memory, they can benefit from the operating system's data page cache optimization, making them faster overall.

[0173] 2. A map is needed to store the hash slot numbers in multiple groups. For example, if there are two groups with 4 hash slots, the storage structure may be: {Group 1: [slot0, slot2], Group 2: [slot1, slot3]}. To ensure that the internally stored hash slots are ordered (to ensure that the addition, deletion, and adjustment of hash slots are consistent in all environments), a TreeMap is used for storage;

[0174] 3. In order to quickly calculate the added group numbers (the group numbers will be discontinuous after multiple additions and deletions. In order to efficiently reuse the group numbers, it is necessary to calculate the minimum unused group number), a LinkedList is used to record the existing group numbers;

[0175] 4. In order to facilitate the calculation of the hash slots that need to be moved when adding or deleting groups, the number of current groups is stored;

[0176] 5. Since the group number is data used internally by the function, in order to facilitate expansion, the group information can be passed in when adding groups, so a map is added to store the relationship between the group number and the actual group information;

[0177] The above five data structures can quickly describe the correspondence between groups and hash slots (forward and reverse), two of which are key data structures and three are auxiliary data structures.

[0178] Since there is only one service provider group at initialization, no matter what the weight of the server is, it can occupy all the hash slots (that is, all 16383 slots are written with the ID of group 1), and group 1 saves all the hash slots (16383).

[0179] Scenario 2: Adding a Group

[0180] Take the process of adding from one group to two groups as an example. Under the premise of scenario 1, there is only one group before adding the group (192.168.100.0 with a weight of 100), and now group 2 (192.168.100.1 with a weight of 100) needs to be added. Because the permission of the added group is also 100, the added group is allocated exactly half of the hash slots (if the weights are inconsistent, if the added group 2 has a weight of 300, then group 1 accounts for 1 / 4 and group 2 accounts for 3 / 4).

[0181] The calculation formula for the hash slots that need to be migrated when adding a group is:

[0182] Total slots * (own weight / sum of original weights – own weight / (sum of original weights + weight of new node))

[0183] Therefore, the number of nodes that need to be migrated from group 1 is 8191. Since the data structure that stores hash slots is a TreeMap data structure (which will be sorted according to the key), we only need to delete the last 8191 hash slots and add these slots to group 2. At the same time, we change the group corresponding to the moved hash slots to group 2.

[0184] Scenario 3: Deleting a Group

[0185] The process of deleting a group is the opposite of adding a group. Take the process of deleting group 2 from two groups to become one group as an example.

[0186] In scenario 2, before the group is deleted, there are two groups (192.168.100.0 and 192.168.100.1), and the weights of these two servers are the same, so the hash slots allocated to the two groups are the same. Now, after receiving a notification from Zookeeper that group 2 needs to go offline, the hash slots of group 2 need to be transferred to group 1. The process is exactly the reverse of adding a group. The number of slots to be moved is calculated as follows:

[0187] Total slots * (own weight / (the sum of the original weights – the weight of the deleted node) – own weight / (the sum of the original weights))

[0188] Allocate all slots of group 2 to group 1, and then modify the group ID pointed to by the original slot to group 1.

[0189] Scenario 4: Changes in weight information of any group

[0190] If the weight of the calling server 102 is changed, the allocated slot needs to be adjusted.

[0191] Under the premise of scenario 2, the weights of calling server 102 (192.168.100.0) and calling server 102 (192.168.100.1) are the same, so the number of hash slots of group 1 and group 2 is evenly divided. At this time, if Zookeeper notifies the calling server 102 (192.168.100.1) that its weight has increased from 100 to 300, it triggers the reallocation of hash slots. The calculation formula for the moved slots is similar to the formula for adding and deleting nodes. After calculation, group 1 changes from occupying 1 / 2 of the slots to occupying 1 / 4 of the slots, and group 2 changes from occupying 1 / 2 of the slots to occupying 3 / 4 of the slots, so 1 / 4 needs to be moved from group 1 to group 2.

[0192] After the slot migration, group 1 (192.168.100.0) occupies 4095 slots, and group 2 (192.168.100.1) occupies 12288 slots.

[0193] Assuming that the weight of group 1 is also adjusted to 300 at this time, then according to the migration formula, group 2 will return the 4095 slots previously migrated. In the end, group 1 and group 2 will evenly divide all the slots. The process is the same as scenario 4.

[0194] The data requesting terminal 104 sends an address acquisition request to the distribution server 101;

[0195] The data request terminal 104 is used to send an address acquisition request to the distribution server 101;

[0196] The distribution server 101 is further configured to query the calling server address corresponding to the address acquisition request through the slot and feed back the address to the data requesting end 104 .

[0197] First, the distribution server 101 performs a CRC16 conversion on the request input parameter to an int value. It then performs a hash modulo operation on the total number of hash slots to retrieve the actual slot index. The group ID corresponding to the index is then searched through an array. The group ID is then used to search for information such as the IP address of the actual calling server 102. Because CRC16 differs from other hash algorithms in that it has a higher execution rate and a higher degree of hashing, it is also used in clustered distribution requests in Redis. Furthermore, due to the use of array and Map data structures, both queries are O(1)-level, resulting in high query efficiency. Given that the same request is assigned to the same execution server, the efficiency of the query distribution can be further improved by leveraging local cache middleware such as Guava. Similar to general caching concepts, a data structure using request parameters as keys and the IP address of the calling server 102 as the value is used for storage. A cache layer is added before the hash slot data structure is queried to return the server IP address. If a match is found, the server IP address is returned directly. If not, the server IP address is queried through the hash slot and written to the local cache before being returned. To ensure the validity of cached data, a common practice is also adopted, that is, when the cached data changes, all caches are directly deleted. The advantages of doing so are as follows: 1. The cache memory can be quickly invalidated. If other threads exist, dirty reads will not be performed, and the actual query and write process will be repeated; 2. Direct deletion does not update the cache. The design concept is based on lazy loading, and the update process takes longer than the direct deletion process, which is likely to continue to cause dirty reads.

[0198] The data requesting end 104 is further configured to perform data calls on the corresponding calling server 102 based on the fed-back calling server address.

[0199] Figure 5Schematic diagram of the hardware structure of the automatic load balancing distribution device provided by the embodiment of the present invention. Figure 5 As shown, the automatic load balancing distribution device 500 of this embodiment includes: a processor 501 and a memory 502;

[0200] The memory 502 is used to store computer-executable instructions;

[0201] The processor 501 is configured to execute computer-executable instructions stored in the memory to implement the various steps performed by the automatic load balancing distribution system in the above embodiment. For details, please refer to the relevant description in the above method embodiment.

[0202] Optionally, the memory 502 may be independent or integrated with the processor 501 .

[0203] When the memory 502 is independently provided, the electronic device further includes a bus 503 for connecting the memory 502 and the processor 501 .

[0204] An embodiment of the present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions. When a processor executes the computer-executable instructions, the automatic load balancing distribution method described above is implemented.

[0205] An embodiment of the present invention further provides a computer program product, including a computer program. When the computer program is executed by a processor, the automatic load balancing distribution method as described above is implemented.

[0206] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between the various embodiments can be referred to in conjunction with each other. For device or system embodiments, since they are generally similar to method embodiments, their description is relatively simple, and relevant parts can be referred to the partial description of the method embodiments.

[0207] It should also be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.

[0208] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0209] The above description of the disclosed embodiments is intended to enable one skilled in the art to implement or use the present disclosure. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present disclosure. Therefore, the present disclosure is not limited to the embodiments shown herein, but is intended to be construed in the widest manner consistent with the principles and novel features disclosed herein.

Claims

1. An automatic load balancing distribution method, characterized in that: Applied to an automatic load balancing distribution system, the automatic load balancing distribution system includes: a distribution server, a call server, a zookeeper and a data request end; the method includes: The distribution server registers the zookeeper on the calling server to monitor the node of the calling server; The calling server saves or updates the calling server information in the zookeeper; When the calling server information is saved or updated, the zookeeper pushes the calling server information to the distribution server; The distribution server updates the locally stored calling server information based on the received calling server information; The distribution server sets a hash slot data structure based on the locally stored calling server information; The data requesting end sends an address acquisition request to the distribution server; The distribution server queries the calling server address corresponding to the address acquisition request through the slot and feeds back to the data request end; The data requesting end makes a data call to the corresponding calling server based on the fed-back calling server address.

2. The method according to claim 1, wherein The calling server information includes the IP address of the calling server, a weight representing the number of requests that the calling server can carry, and geographical distribution information of the calling server.

3. The method according to claim 2, wherein The weight representing the number of requests that the call server can carry is determined by the number of CPU cores of the distribution server, the memory of the distribution server, the network bandwidth of the distribution server, the free memory of the distribution server, the free CPU load of the distribution server and the total number of CPU cores of the distribution server.

4. The method according to claim 3, characterized in that The weight representing the number of requests that the call server can carry is calculated based on the formula weight = distribution server CPU core number * 0.5 + distribution server memory * 0.2 + distribution server network bandwidth / 100 * 0.5 + distribution server free memory * 0.5 + distribution server idle CPU load * distribution server total number of CPU cores.

5. The method according to claim 1, wherein The distribution server sets the hash slot data structure based on the locally stored calling server information, including: The distribution server compares the received calling server information with the locally stored calling server information to determine the changed scenario; The distribution server updates the locally stored calling server information based on the changed scenario and the received calling server information.

6. The method according to any one of claims 1 to 5, characterized in that Also includes: The calling server periodically sends calling server operation information to Zookeeper; The zookeeper updates the corresponding calling server information based on the calling server running information and pushes it to the distribution server.

7. An automatic load balancing distribution system, characterized in that: include: Distribution server, call server, zookeeper and data request end, where: The distribution server is used to register Zookeeper on the calling server to monitor the nodes of the calling server; The calling server is used to save or update the calling server information in the zookeeper; The zookeeper is used to push the calling server information to the distribution server when the calling server information is saved or updated; The distribution server is further configured to update the locally stored calling server information based on the received calling server information; The distribution server is further configured to set a hash slot data structure based on the locally stored calling server information; The data request end is used to send an address acquisition request to the distribution server; The distribution server is further configured to query the calling server address corresponding to the address acquisition request through the slot and feed it back to the data requesting end; The data requesting end is further used to make data calls to the corresponding calling server based on the fed-back calling server address.

8. An automatic load balancing distribution device, characterized in that: comprising at least one processor and memory; The memory stores computer-executable instructions; The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the automatic load balancing distribution method according to any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions. When the processor executes the computer-executable instructions, the automatic load balancing distribution method according to any one of claims 1 to 7 is implemented.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the automatic load balancing distribution method according to any one of claims 1 to 7 is implemented.

Images