Load balancing processing method, device, storage medium, and system

Abstract

Embodiments of the present disclosure provide a load balancing processing method, a device, a storage medium, and a system. The method comprises: obtaining a first number of Internet of Things devices corresponding to each of a plurality of application servers, wherein the first number of Internet of Things devices corresponding to any application server is the number of Internet of Things devices allowed to be accessed when a resource consumption of the application server reaches a set upper limit value; in response to a persistent connection establishment request of a target Internet of Things device, obtaining a second number of Internet of Things devices actually accessed in the plurality of application servers; determining load weights of the plurality of application servers on the basis of the first number of Internet of Things devices and the second number of Internet of Things devices corresponding to each of the plurality of application servers; and on the basis of the load weights of the plurality of application servers, determining a target application server to which the persistent connection establishment request is allocated, so as to establish a persistent connection between the target Internet of Things device and the target application server.

Description

[0001] Load Balancing Processing Method, Device, Storage Medium, and System Cross-Reference This disclosure claims priority to Chinese patent application No. 202410205182.X, filed with the Patent Office of China on February 23, 2024, entitled "Load Balancing Processing Method, Device, Storage Medium, and System," the entire contents of which are incorporated herein by reference. Technical Field This disclosure relates to the field of Internet technology, and more particularly to a load balancing processing method, device, storage medium, and system. Background: IoT devices (such as vehicle-mounted terminals, drive test equipment, and smart home appliances) primarily access IoT platforms through persistent connections, providing stable connections. The IoT platform includes a load balancing server and a cluster of application servers. IoT devices establish persistent connections with the application servers through the load balancing server to access services provided by the application servers, such as data storage services and autonomous driving services. Simply put, a persistent connection allows for the continuous transmission of multiple data packets over a communication connection until one party closes the connection. During this period, if no data packets need to be transmitted, both parties must send link detection packets (such as heartbeat packets) to maintain the connection. The opposite of a persistent connection is a short connection: during data transmission, a communication connection is established only when data is needed and terminated upon completion. This means that each connection only completes a single data transmission. In response to a persistent connection request triggered by an IoT device, a load balancing server can assign an application server to the persistent connection request based on a load balancing policy, establishing a persistent connection between the IoT device and the application server. Load balancing policies can include static and dynamic load balancing. Static load balancing policies, such as round-robin, can result in lightly loaded application servers potentially connecting to fewer IoT devices, while heavily loaded application servers may connect to more IoT devices, resulting in low resource utilization. Therefore, dynamic load balancing policies are often used in practical applications. Traditional dynamic load balancing strategies typically calculate the load weight of application servers based on real-time resource consumption metrics (such as memory utilization and central processing unit (CPU) utilization) after receiving persistent connection requests from IoT devices. These strategies then distribute persistent connection requests based on the load weights of different application servers.However, because IoT devices primarily connect to IoT platforms through stable persistent connections, the activity of connected IoT devices varies across time periods. Consequently, load weights calculated based on real-time resource consumption metrics such as memory and CPU usage can vary significantly across time periods. Load balancing based on load weights calculated based on real-time, fluctuating resource consumption metrics can risk application server overload, resulting in poor balancing and low resource utilization. SUMMARY OF THE INVENTION Embodiments of the present disclosure provide a load balancing method, device, storage medium, and system for improving resource utilization in application server clusters. In a first aspect, an embodiment of the present disclosure provides a load balancing processing method, the method comprising: obtaining a number of first IoT devices corresponding to each of a plurality of application servers, wherein the number of first IoT devices corresponding to any application server is the number of IoT devices allowed to access when resource consumption of any application server reaches a set upper limit; obtaining a number of second IoT devices actually connected to the plurality of application servers in response to a persistent connection establishment request from a target IoT device; determining a load weight corresponding to each of the plurality of application servers based on the number of first IoT devices and the number of second IoT devices corresponding to each of the plurality of application servers; determining a target application server based on the load weights corresponding to each of the plurality of application servers, and allocating the persistent connection establishment request to the target application server to establish a persistent connection between the target IoT device and the target application server. In a second aspect, embodiments of the present disclosure provide a load balancing processing device, comprising: an acquisition component configured to acquire the number of first IoT devices corresponding to each of a plurality of application servers, wherein the first IoT device number corresponding to any application server is the number of IoT devices allowed to connect when the resource consumption of any application server reaches a set upper limit; and, in response to a persistent connection establishment request from a target IoT device, acquiring the number of second IoT devices actually connected to the plurality of application servers; a determination component configured to determine the load weight corresponding to each of the plurality of application servers based on the number of first IoT devices and the number of second IoT devices corresponding to each of the plurality of application servers; and an allocation component configured to determine a target application server based on the load weights corresponding to each of the plurality of application servers, and allocate the persistent connection establishment request to the target application server to establish a persistent connection between the target IoT device and the target application server. In a third aspect, embodiments of the present disclosure provide an electronic device, comprising: a memory, a processor, and a communication interface; wherein the memory stores executable code, which, when executed by the processor, enables the processor to implement at least the load balancing processing method of the first aspect.In a fourth aspect, embodiments of the present disclosure provide a computer-readable storage medium storing executable code. When the executable code is executed by a processor of an electronic device, the processor is enabled to implement at least the load balancing processing method of the first aspect. In a fifth aspect, embodiments of the present disclosure provide a load balancing system, comprising: a load balancing server and multiple application servers scheduled by the load balancing server; the load balancing server is configured to obtain the number of first IoT devices corresponding to each of the multiple application servers; in response to a persistent connection establishment request from a target IoT device, obtain the number of second IoT devices actually connected to the multiple application servers; determine load weights corresponding to each of the multiple application servers based on the number of first IoT devices and the number of second IoT devices corresponding to each of the multiple application servers; determine a target application server based on the load weights corresponding to the multiple application servers; and distribute the persistent connection establishment request to the target application server to establish a persistent connection between the target IoT device and the target application server. The number of first IoT devices corresponding to any application server is the number of IoT devices allowed to connect when the resource consumption of any application server reaches a set upper limit. The load balancing solution provided in the embodiments of the present disclosure utilizes a dynamic load balancing strategy to schedule persistent connection requests from IoT devices. This dynamic load balancing strategy balances the IoT devices connected to different application servers based on the application server's load weight. Unlike traditional methods that determine the application server's load weight based on the application server's time-varying resource consumption metrics (such as memory utilization and CPU utilization), the present embodiments use a metric that does not fluctuate with the behavior of connected IoT devices (application server resource consumption metrics such as CPU utilization can fluctuate significantly with the data transmission activity of connected IoT devices) to calculate the application server's load weight. This metric represents the number of IoT devices that the application server can service. Specifically, the number of IoT devices allowed to connect when the application server's resource consumption reaches a set upper limit is used as the upper limit for the number of IoT devices that can be connected to the application server. In response to a persistent connection establishment request from a target IoT device, the number of IoT devices actually connected to the multiple application servers is obtained. Based on the upper limit of the number of connectable IoT devices corresponding to each of the multiple application servers and the number of IoT devices actually connected, the load weights corresponding to the multiple application servers are determined. A target application server is determined based on the load weights corresponding to the multiple application servers. The persistent connection establishment request is assigned to the target application server to establish a persistent connection between the target IoT device and the target application server.In the embodiments of the present disclosure, the characteristics of IoT scenarios, characterized by frequent and stable device connections (i.e., the fact that an application server consistently connects to a certain number of IoT devices over a period of time), are utilized to map the application server's fluctuating resource consumption indicators to a relatively stable number of connected devices for use in load weight calculation. This mitigates the interference caused by fluctuations in resource consumption values ​​over time on the load weight calculation, improves the stability of the application server's load weight calculation results in scenarios with persistent IoT device connections, and facilitates achieving better load balancing, thereby increasing application server resource utilization and simplifying calculation complexity. To more clearly illustrate the technical solutions in the embodiments of the present disclosure, the following briefly describes the figures used in describing the embodiments. Obviously, the figures described below represent some embodiments of the present disclosure. Persons skilled in the art can derive other figures based on these figures without inventive effort. Figure 1 is a schematic diagram of a load balancing system provided by an embodiment of the present disclosure; Figure 2 is a flowchart of a load balancing processing method provided by an embodiment of the present disclosure; Figure 3 is a flowchart of another load balancing processing method provided by an embodiment of the present disclosure; Figure 4 is a flowchart of a load balancing processing method provided by an embodiment of the present disclosure; Figure 5 is a schematic diagram of the application of another load balancing processing method provided by an embodiment of the present disclosure; Figure 6 is a schematic diagram of the structure of a load balancing processing device provided by an embodiment of the present disclosure; and Figure 7 is a schematic diagram of the structure of an electronic device provided by an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS To further clarify the objectives, technical solutions, and advantages of the embodiments of the present disclosure, the technical solutions of the embodiments of the present disclosure will be described clearly and completely below in conjunction with the accompanying drawings. It should be understood that the described embodiments are only a portion of the embodiments of the present disclosure, but not all of them. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present disclosure without inventive effort are within the scope of protection of the present disclosure. It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display) involved in the embodiments of this disclosure are all authorized by the user or fully authorized by all parties. The collection, use, and processing of relevant data must comply with the relevant laws, regulations, and standards of relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or reject. The following detailed description of some embodiments of the present disclosure is provided in conjunction with the accompanying drawings. The following embodiments and features of the embodiments may be combined unless there is any conflict between them.In addition, the sequence of steps in the following method embodiments is merely illustrative and not strictly limiting. Common load balancing strategies are classified into static and dynamic. Static load balancing strategies include round-robin and weighted round-robin, while common dynamic load balancing strategies include minimum resource usage. Static load balancing strategies cannot calculate load weights in real time based on the resource consumption of application servers, resulting in low resource utilization. Therefore, dynamic load balancing strategies are often used in practical applications. Furthermore, static load balancing strategies can hinder the efficiency of application server releases. Release refers to the functional update or version upgrade of the services provided by application servers. For example, assume that an application server cluster includes application server 1, application server 2, and application server 3. When application server 1 needs to be released (i.e., when application server 1 needs a functional update), application server 1 is first removed from the list of available application servers in the cluster. This prevents subsequent persistent connection establishment requests from being assigned to application server 1, which is currently being released. Next, migrate the IoT devices originally connected to application server 1 to application servers 2 and 3. In this case, if a round-robin strategy is used, for example, half of the IoT devices connected to application server 1 will be assigned to application server 2, and the other half to application server 3. Suppose that before the application server is released, application server 2 has not yet connected to any IoT devices due to its recent release, while application server 3 has already connected a large number of IoT devices, causing its load to reach the upper limit (i.e., its resource consumption has reached the set upper limit). Based on this assumption, half of the IoT devices connected to application server 1 will be assigned to application server 3. Since application server 3's load has already reached the upper limit, the persistent connection requests from these IoT devices will be rejected. At this point, the only option is to wait for the IoT devices connected to Application Server 3 and Application Server 2 to gradually go online and offline (for example, some IoT devices may disconnect from their persistent connections to Application Server 3 and then be assigned to Application Server 2 when they reconnect). Application Server 1 can only be released after the persistent connections are migrated to Application Server 2. This cycle is very long, resulting in a long release time. To improve resource utilization in the application server cluster, a dynamic load balancing strategy is often used.However, traditional load balancing strategies, which calculate application server load weights based on real-time resource consumption, can significantly increase the load weight of newly added application servers when the overall load level of an application server cluster is high (due to the high resource consumption of existing application servers in the cluster). Because resource consumption is linearly correlated with load weight, newly added application servers can become instantaneously hotspots, receiving an excessive number of persistent connection requests from IoT devices. Furthermore, in IoT scenarios, communication connections between IoT devices and the IoT platform (including load balancing servers and application servers) are primarily persistent connections. Under persistent connections, the activity levels of connected IoT devices vary at different times. In some periods, they may need to transmit a large number of data packets, while in other periods, they may only need to transmit a small number of data packets, or even just heartbeat packets. This dynamic activity of connected IoT devices can lead to frequent fluctuations in the resource consumption of the corresponding application servers. Suppose, in response to a persistent connection establishment request triggered by an IoT device, when the load balancing server calculates the load weights of each application server, some application servers have lower resource consumption values. This means that the IoT devices connected to these application servers are inactive. In this case, these application servers will have higher load weights and will be assigned more new persistent connection establishment requests, thereby connecting more new IoT devices. However, after a period of time, if the IoT devices connected to these application servers become active and transmit a large number of data packets, this will cause the resource consumption values ​​of these application servers to increase significantly, posing the risk of overload (exceeding the upper limit of available resources). In other words, a high load weight calculated based on the resource consumption values ​​of an application server during idle time may cause the application server to be overloaded during busy time. The idle time of an application server refers to the period when the IoT devices connected to it are inactive, while the busy time of an application server refers to the period when the IoT devices connected to it are active. The activity of an IoT device is determined by the volume of data packets it transmits. Based on the above analysis, we can conclude that, first, to ensure resource utilization of the application server cluster and application server release efficiency, static load balancing strategies should be avoided and dynamic load balancing strategies should be adopted. Second, traditional dynamic load balancing strategies calculate load weights based on the real-time resource consumption of application servers. This can lead to the aforementioned hotspot issues and the risk of application server overload. Therefore, dynamic load balancing strategies that calculate load weights based on real-time resource consumption should not be used.Based on this, embodiments of the present disclosure provide a new dynamic load balancing strategy. In scenarios where IoT devices have persistent connections, this strategy leverages the fact that resource consumption by a large number of IoT devices connected to different application servers converges over a set period. This strategy replaces a resource consumption metric that fluctuates dynamically with the activity periods of the IoT devices with a new metric that remains constant, used to calculate the application server's load weight. This new metric is the number of IoT devices served by the application server within the set period. The phrase "the number of IoT devices served by an application server within the set period remains constant" means that the number of IoT devices served by an application server within different periods is stable and unaffected by the activity periods of the IoT devices it serves. The load balancing solution provided by embodiments of the present disclosure is described in detail below. Figure 1 is a schematic diagram of a load balancing system provided in accordance with an embodiment of the present disclosure. As shown in Figure 1 , the load balancing system includes a load balancing server 101 and multiple application servers (e.g., 102_1, 102_2, ..., as shown in Figure 1 ) scheduled by the load balancing server 101. In an optional embodiment, the load balancing system may also include an operations and maintenance server 103, which is in communication with each application server. In actual applications, the various servers described above may all be implemented as cloud servers, merely running different programs. In an optional embodiment, the operations and maintenance server 103 is configured to collect load information generated by each application server within a set historical time period and analyze this load information to determine an upper limit on the number of IoT devices allowed to access each application server, i.e., the first IoT device number corresponding to each application server. The first IoT device number corresponding to any application server is the number of IoT devices allowed to access when the resource consumption of that application server reaches a set upper limit. The collected load information may include the resource consumption values ​​of the application servers at different time points during the historical time period, as well as the number of IoT devices actually connected to the application servers during the historical time period. After determining the number of first IoT devices corresponding to each application server, the operation and maintenance server 103 notifies each application server accordingly. Each application server then reports the number of first IoT devices corresponding to each application server to the load balancing server 101. Alternatively, the operation and maintenance server 103 may directly notify the load balancing server 101 of the number of first IoT devices corresponding to each application server. However, in this case, the operation and maintenance server 103 needs to maintain communication connections with each application server and the load balancing server 101.In another optional embodiment, the load balancing server 101 can also be configured to perform the above-mentioned process of determining the number of first IoT devices for each application server. In this case, the system may not include the operation and maintenance server 103. However, the load balancing server 101 is required to provide both load balancing and the above-mentioned analysis functions. The following describes the above-mentioned process of determining the number of first IoT devices and how to calculate the load weight of the application server based on the number of first IoT devices, in conjunction with the following embodiments. Figure 2 is a flow chart of a load balancing processing method provided in an embodiment of the present disclosure. As shown in Figure 2, the method may include the following steps:

[0002] 201. Obtain the number of first IoT devices corresponding to each of a plurality of application servers, wherein the number of first IoT devices corresponding to any application server is the number of IoT devices allowed to access when resource consumption of any application server reaches a set upper limit.

[0003] 202. In response to a persistent connection establishment request from a target IoT device, obtain a number of second IoT devices actually connected to the multiple application servers.

[0004] 203. Determine a load weight corresponding to each of the multiple application servers according to the number of first IoT devices and the number of second IoT devices corresponding to each of the multiple application servers.

[0005] 204. Determine a target application server based on the load weights corresponding to the multiple application servers, and assign the persistent connection establishment request to the target application server to establish a persistent connection between the target IoT device and the target application server. In actual applications, a maximum resource consumption limit may be set for each application server. When the multiple application servers are homogeneous, the upper limit set for each application server may be the same. When the multiple application servers are heterogeneous, the upper limit set for each application server may be different. In addition, in actual applications, the resources provided by an application server may include multiple resources, such as CPU, memory, and bandwidth. Therefore, corresponding upper limits may be set for various resource consumption indicator dimensions, such as CPU utilization, memory utilization, and throughput. For example, multiple application servers are configured with the same CPU utilization upper limit of 40%, memory utilization of 90%, and throughput of 500 MB / s. In step 201, the first number of IoT devices corresponding to each of the multiple application servers is the number of IoT devices allowed to connect when the actual resource consumption reaches the set upper limit. This means that exceeding this first number of IoT devices will cause the corresponding application server to be overloaded. It is understood that when upper limits are set for different resource consumption indicator dimensions, an upper limit for the number of IoT devices allowed to connect can be determined for each resource dimension. In this case, the first number of IoT devices corresponding to an application server can be the minimum value among the upper limits for the number of IoT devices determined for each of the multiple resource consumption indicator dimensions. For example, if an application server determines that the number of IoT devices allowed to connect is 150,000 when the CPU utilization reaches a set upper limit of 40%, determines that the number of IoT devices allowed to connect is 130,000 when the memory utilization reaches a set upper limit of 90%, and determines that the number of IoT devices allowed to connect is 180,000 when the throughput reaches a set upper limit of 500 MB / s, then the first number of IoT devices for the application server is ultimately determined to be 130,000. Specifically, for any application server among the multiple application servers, obtaining the first number of IoT devices corresponding to the application server can be implemented by obtaining the number of third IoT devices connected to the application server and a peak resource consumption value within a set historical time period, where the peak resource consumption value is less than a set upper limit for the corresponding resource; and then determining the first number of IoT devices corresponding to the application server based on the peak resource consumption value, the number of third IoT devices, and the set upper limit.Furthermore, within the dimension of multiple resource consumption indicators, the resource consumption peaks include the resource consumption peaks corresponding to multiple resources, each of which also has a corresponding upper limit. In this case, the process of determining the first number of IoT devices corresponding to any application server includes: determining the number of IoT devices allowed to connect to the target resource based on the resource consumption peak corresponding to the target resource, the third number of IoT devices, and the upper limit corresponding to the target resource; and determining the first number of IoT devices corresponding to any application server based on the number of IoT devices allowed to connect to the target resource. The following example illustrates the calculation process of the first number of IoT devices. For a particular application server, assume that its CPU utilization upper limit is set to 40%, memory utilization to 90%, and throughput to 500 MB / s. A historical time period is set from 00:00 to 24:00 on a particular day. Actual values ​​of the three resource consumption indicators for the application server are collected at each hour, and the total number of IoT devices connected to the application server during that day (the third number of IoT devices) is determined. Assume that the number of third IoT devices is 100,000. Assume that at 2:00 PM, both CPU and memory utilization reach their daily peaks: CPU peak utilization of 26% and memory peak utilization of 70%. Assume that at another time, throughput 10 reaches a peak of 1.6 MB / s. In practical applications, a threshold can be set for the peak resource consumption of each resource. When the peak consumption of a resource falls below the threshold, it is not included in the calculation of the number of first IoT devices. Assuming that the peak throughput 10 falls below the threshold, it is ignored. Based on the application server's daily peak CPU utilization of 26%, the number of third IoT devices of 100,000, and the CPU utilization upper limit of 40%, the upper limit of the number of IoT devices allowed to connect to the application server is calculated as 100,000 * 40% / 26% = 150,000. Based on the application server's peak memory utilization of 70% on that day, the number of third IoT devices at 100,000, and the memory utilization ceiling of 90%, the upper limit of the number of IoT devices allowed to connect to the application server was calculated as 100,000 * 90% / 76% = 130,000. The final number of first IoT devices for the application server was determined to be 130,000. This method for determining the number of first IoT devices is based on the relatively stable and balanced number of IoT devices connected to each application server during each cycle, as well as the fact that in long-term IoT device connection scenarios, a large number of IoT devices connected to different application servers tend to have similar resource consumption during each cycle.The above-mentioned historical time period can be a cycle, such as a day. Based on the above characteristics, during implementation, it can first be determined whether the characteristic of "the number of IoT devices connected to each application server during each cycle is relatively stable and balanced" is met. If so, the load balancing solution provided by the embodiments of the present disclosure is executed. Specifically, if it is determined that the number of IoT devices connected to multiple application servers during multiple historical time periods meets the stable and balanced condition, the step of determining the first number of IoT devices corresponding to each of the multiple application servers is executed. The stable and balanced condition means that, under the conditions that the multiple application servers are operating normally and the total number of IoT devices connected during the multiple historical time periods is stable, the fluctuation in the number of IoT devices connected to each application server during the multiple historical time periods is less than a set threshold, and the difference in the number of IoT devices connected to the multiple application servers during each historical time period is less than a set threshold. For example, assuming the observation period is each day of a historical week (7 days), and assuming that during this period, it is observed that the application server cluster contains N application servers, and that these N application servers are operating normally, i.e., there are no abnormalities such as releases or failures. Furthermore, it is observed that the total number of IoT devices connected to the cluster during this period is M. After allocating persistent connection requests from IoT devices based on a load balancing strategy, assuming observations show that the number of IoT devices connected to each application server fluctuates minimally and remains stable over a seven-day period, and that the ratio of M to N (number of connected devices) fluctuates minimally, then the aforementioned stable balance condition is met. This confirms that the number of IoT devices accessible to each application server within a historical period (a day) is relatively stable and unaffected by the varying activity levels of connected IoT devices at different times. Based on this, as described above, when calculating the number of first IoT devices corresponding to an application server, a historical period can be randomly determined, and the number of third IoT devices connected to the application server during that historical period can be used as the basis for calculating the number of first IoT devices. It should be noted that the aforementioned stable balance condition is based on the assumption that multiple application servers operate normally and the total number of IoT devices is stable during the observation period. However, in reality, if an application server experiences abnormal conditions such as downtime or release, these abnormal conditions will cause uneven load levels on different application servers in the application server cluster. Referring to the relevant explanation above, under the above traditional load balancing strategy, it is difficult or takes a long time for the application server cluster to recover to a load-balanced state.However, the solution provided in the embodiments of the present disclosure for determining load weights based on the number of the first IoT devices can restore the load levels of each application server to a relatively balanced state in a relatively short period of time. Furthermore, the calculation of the number of the first IoT devices utilizes the characteristic that, in persistent IoT device connections, a large number of IoT devices connected to different application servers tend to have similar resource consumption within each cycle. Specifically, the data transmission behavior of individual IoT devices may vary. If the calculation focuses on the amount of application server resources consumed by each IoT device, it is difficult to calculate the maximum number of IoT devices allowed to connect to an application server. For example, if the calculation is based on Class A devices, the result may exceed the upper limit of the application server's allowed resources. If the calculation is based on Class B devices, the result may be a waste of application server resources, indicating very low resource utilization. However, if the number of IoT devices connected to an application server is sufficiently large, the proportion of each type of IoT device connected to it will be relatively stable within each cycle, for example, the total proportion of the two types of devices will remain at a ratio of 4:6. Given that the types and proportions of IoT devices connected to an application server are relatively stable, when calculating the first number of IoT devices for that application server, we only need to focus on the peak resource consumption value, without distinguishing the differences in the contributions of different devices to this peak. For example, if 100,000 IoT devices cause an application server's CPU utilization to reach 26% at a certain moment, there's no need to distinguish the CPU utilization corresponding to different types of IoT devices. Therefore, if the first number of IoT devices for that application server is calculated to be 130,000, the subsequent connection of 30,000 IoT devices may cause the CPU utilization to reach the upper limit of 40%. This is also determined based on this characteristic: there's no need to consider the individual differences among these 30,000 IoT devices. In summary, after obtaining the first number of IoT devices corresponding to multiple application servers, the load weight of the application server can be calculated based on this first number of IoT devices. Specifically, when the load balancing server receives a persistent connection establishment request from a target IoT device, it obtains the number of second IoT devices currently connected to multiple application servers, determines the load weights corresponding to each of the multiple application servers based on the number of first IoT devices and the number of second IoT devices corresponding to each of the multiple application servers, determines a target application server based on the load weights corresponding to each of the multiple application servers, and distributes the persistent connection establishment request to the target application server to establish a persistent connection between the target IoT device and the target application server. In a specific implementation, each application server may optionally periodically report the number of IoT devices actually connected to it to the load balancing server.When the load balancing server receives the persistent connection establishment request, it can determine the number of IoT devices most recently reported by each application server as the second number of IoT devices. Optionally, the load weight of an application server can be determined as the difference between the first number of IoT devices and the second number of IoT devices corresponding to that application server. It is understood that if the load weight of an application server is 0, it means that the number of IoT devices connected to it has reached its corresponding upper limit: the first number of IoT devices. Therefore, no new connection establishment requests will be assigned to that application server to prevent the application server's resource consumption from exceeding the set upper limit and causing overload. In determining the target application server based on the load weights of multiple application servers, simply put, application servers with higher load weights are more likely to receive the persistent connection establishment request. This does not mean that the persistent connection establishment request will be assigned to the application server with the highest load weight based solely on the order of load weight. The method for determining the target application server based on the load weights of multiple application servers can be implemented with reference to existing related technologies and will not be elaborated here. It should also be noted that when an application server determines the number of IoT devices it actually connects to, it does not do so based on the number of persistent connections it has with the load balancing server. Instead, it determines the number of IoT devices it actually connects to after establishing a persistent connection with the IoT device. This determination is based on the results of parsing the data packets sent by the IoT device over the persistent connection, which includes the device identifier. In other words, in this disclosed embodiment, the focus is on the number of "online" IoT devices connected to the application server. Online refers to IoT devices that are actually using the services provided by an application server. This is because, in actual applications, IoT devices that trigger persistent connection establishment requests to a load balancing server fall into two categories: directly connected devices, which do not have connected sub-devices, and gateway devices, which can have connected sub-devices. If N directly connected devices connect to an application server through a load balancing server, then N persistent connections will exist between the application server and the load balancing server, corresponding to these N directly connected devices. However, if a gateway device connected to M sub-devices is connected to an application server through a load balancing server, there is only one long connection between the load balancing server and the application server. Corresponding to the gateway device, that is, each sub-device connected to the gateway device uses the services provided by the application server through this long connection. The application server can determine how many sub-devices are actually connected by parsing the data packets sent by the sub-devices.In summary, the disclosed embodiments leverage the high number of persistent connections and stable device connections in IoT scenarios to provide application servers with a metric (the number of connected devices) that does not fluctuate with the behavior of connected IoT devices for use in load weight calculation. This prevents the interference of time-dependent fluctuations in application server resource consumption on load weight calculation and simplifies computational complexity. Load balancing persistent connection establishment requests based on the application server load weights calculated in this manner can achieve better load balancing—different application servers can handle a more balanced number of IoT devices, improving resource utilization. Furthermore, it is understood that if an application server in an existing application server cluster needs to be published, the IoT devices connected to it will be quickly assigned to other application servers based on the load weights of other application servers, thereby improving application server publishing efficiency. Furthermore, if many application servers have load weights below zero, an alarm can be issued to prompt the expansion of application server capacity. When the application server rejoins the cluster due to completing a release, for example, it will have a high load weight because the number of IoT devices actually connected to it is zero. Therefore, new persistent connection establishment requests can be assigned to this application server, allowing it to quickly handle more connection establishment requests and improve resource utilization. Figure 3 is a flow chart of a load balancing method provided by an embodiment of the present disclosure. As shown in Figure 3, the method may include the following steps:

[0006] 301. Obtain a first number of IoT devices corresponding to each of the multiple application servers, and scale the first number of IoT devices corresponding to each of the multiple application servers based on a set scaling factor to obtain a fourth number of IoT devices corresponding to each of the multiple application servers. The first number of IoT devices corresponding to any application server is the number of IoT devices allowed to connect when resource consumption of any application server reaches a set upper limit.

[0007] 302. In response to a persistent connection establishment request from a target IoT device, obtain a number of second IoT devices actually connected to the multiple application servers.

[0008] 303. Determine a load weight corresponding to each of the multiple application servers according to the number of fourth IoT devices and the number of second IoT devices corresponding to each of the multiple application servers.

[0009] 304. Determine a target application server based on the load weights corresponding to each of the multiple application servers, and assign the persistent connection establishment request to the target application server to establish a persistent connection between the target IoT device and the target application server. In this embodiment, after calculating the first number of IoT devices corresponding to each of the multiple application servers according to the method provided in the preceding embodiment, a scaling factor can be set to scale the first number of IoT devices to obtain a fourth number of IoT devices corresponding to each of the multiple application servers. The scaling factor is a positive number less than or equal to 1. This is equivalent to setting a buffer interval between the fourth number of IoT devices and the first number of IoT devices. In actual applications, for example, after the operation and maintenance server notifies the application servers of the first number of IoT devices corresponding to each of the multiple application servers, the application servers can determine their own fourth number of IoT devices based on the scaling factor and report it to the load balancing server. Optionally, the scaling factor corresponding to each application server can be the same or different. The above scaling process can be understood as follows: the first number of IoT devices is a theoretical upper limit, and the fourth number of IoT devices is an actual upper limit. For example, if it is discovered that the number of IoT devices actually connected to a large number of application servers has reached their respective fourth IoT device counts, an alarm can be issued to facilitate capacity expansion and control the allocation of subsequent new persistent connection establishment requests to these application servers. Furthermore, the above scaling process can also enable idle application servers to more quickly accept more persistent connection establishment requests. For example, assuming that the number of first IoT devices corresponding to application server 1 and application server 2 is 10, and that the number of IoT devices currently actually connected to application server 1 and application server 2 is 2 and 0, respectively, then when calculating the load weight based on the first IoT device count, it can be determined that the load weight of application server 1 = 10 - 2 = 8, and the load weight of application server 2 = 10 - 0 = 10. This means that application server 2 can accept persistent connection establishment requests with a probability of 10 / 8 = 1.25 times that of application server 1. If the first number of IoT devices is scaled by a factor of 0.3, the fourth number of IoT devices corresponding to both application server 1 and application server 2 is 3. Based on the assumption of the actual number of connected devices for the two application servers, the load weight of application server 1 is 3-2 = 1, and the load weight of application server 2 is 3-0 = 3. This means that application server 2 can accept persistent connection establishment requests with a probability of 3 / 1 = 3 times that of application server 1.This allows application servers 2 that are more idle (with fewer access devices) to more quickly handle more persistent connection establishment requests, improving resource utilization and load balancing. FIG4 is a flow chart of a load balancing processing method provided by an embodiment of the present disclosure. As shown in FIG4 , the method may include the following steps:

[0010] 401. Obtain the number of first IoT devices corresponding to each of a plurality of application servers, wherein the number of first IoT devices corresponding to any application server is the number of IoT devices allowed to access when resource consumption of any application server reaches a set upper limit.

[0011] 402. In response to the persistent connection establishment request of the target IoT device, obtain the number of second IoT devices actually connected to the multiple application servers.

[0012] 403. Determine a difference between the number of first IoT devices and the number of second IoT devices corresponding to each of the multiple application servers, smooth the difference corresponding to each of the multiple application servers, and determine a load weight corresponding to each of the multiple application servers as a result of the smoothing of the difference corresponding to each of the multiple application servers.

[0013] 404. Determine a target application server based on the load weights corresponding to each of the multiple application servers, and assign the persistent connection establishment request to the target application server to establish a persistent connection between the target IoT device and the target application server. This embodiment provides a solution for controlling the "hotspot" problem by smoothing the load weights of the application servers. The difference between the number of first IoT devices and the number of second IoT devices corresponding to each of the multiple application servers can be used as the initial load weights of the multiple application servers. The initial load weights of each application server are then smoothed to obtain a target load weight for each application server. Optionally, the smoothing process can include determining a statistical value, such as a minimum or average value, of the initial load weights corresponding to each of the multiple application servers; then determining a ratio between the initial load weights corresponding to each of the multiple application servers and the statistical value; and performing a logarithmic calculation on each of the ratios corresponding to each of the multiple application servers to obtain a target load weight for each of the multiple application servers. The base of the logarithmic calculation can be 10, the natural logarithm e, or other values. The following examples illustrate the effect of controlling hotspots achieved by the above-described smoothing process. Assume that an application server cluster contains five application servers: Application Server 1 through Application Server 5. Assume that the first number of IoT devices connected to these five application servers is the same, 10,000. Assume that the number of IoT devices currently connected to Application Server 1 through Application Server 4 is 9,900, and the number of IoT devices actually connected to Application Server 5 is 0. Therefore, the load weights of Application Servers 1 through 4 are all 10,000 - 9,900 = 100, and the load weight of Application Server 5 is 10,000 - 0 = 10,000. (I) Unsmoothed Processing: Since the load weight of Application Server 5 is 100 times that of the other four application servers, Application Server 5 is 100 times more likely to receive new persistent connection establishment requests than the other four application servers. This makes Application Server 5 a "hotspot," quickly connecting to too many IoT devices and exposing Application Server 5 to a high risk of overload.

[0014] (2) Logarithmic Smoothing: In the above example, the minimum load weight of the five application servers is 100. The load weights of application servers 1 through 4 are all divided by this minimum, resulting in a ratio of 1. The ratio of the load weight of application server 5 to this minimum is 100. Assuming that the logarithm is calculated to base 10, the logarithmic calculation result for application server 5 is 2, while the logarithmic calculation results for application servers 1 through 4 are all less than 1. Assuming that the logarithmic calculation result is less than 1, the default setting is 1. Based on this, after the logarithmic calculation, application server 5 has a probability of receiving a new persistent connection establishment request that requires allocation that is twice that of the other four application servers, which significantly reduces the load on application server 5. Figure 5 is a schematic diagram of an application of a load balancing method provided in an embodiment of the present disclosure. As shown in Figure 5, this method involves a threshold calculation process, a weight calculation process, and a device connection establishment process. The threshold calculation process involves collecting load information from each application server (application server 1-application server n) during a set historical time period, calculating the first number of IoT devices for each application server (represented as max rs in the figure), scaling each first number of IoT devices according to a set scaling factor to obtain the fourth number of IoT devices for each application server (represented as max lb in the figure), and reporting max lb to the load balancing server. The weight calculation process involves each application server reporting the actual number of connected IoT devices to the load balancing server. The load balancing server calculates the initial load weight for each application server based on the max lb of each application server, and then smoothes the initial load weight to obtain the target load weight. The device connection establishment process involves the load balancing server assigning a persistent connection establishment request triggered by a target IoT device to an application server based on the target load weight of each application server. The load balancing server then establishes a persistent connection between the target IoT device and the application server using its routing service. It is understood that a persistent connection between an IoT device and an application server consists of two segments: the persistent connection between the IoT device and the load balancing server, and the persistent connection between the load balancing server and the application server. The following describes in detail the load balancing processing devices of one or more embodiments of the present disclosure. Those skilled in the art will appreciate that these devices can be constructed using commercially available hardware components and configured according to the steps taught in this solution. Figure 6 is a schematic diagram of the structure of a load balancing processing device provided in an embodiment of the present disclosure, which is applied to a client using a distributed lock service.As shown in Figure 6, the apparatus includes: an acquisition component 11, a determination component 12, and an allocation component 13. The acquisition component 11 is configured to acquire the number of first IoT devices corresponding to each of the multiple application servers, where the first number of IoT devices corresponding to any application server is the number of IoT devices allowed to connect when the resource consumption of any application server reaches a set upper limit; and, in response to a persistent connection establishment request from a target IoT device, acquire the number of second IoT devices actually connected to the multiple application servers. The determination component 12 is configured to determine the load weight corresponding to each of the multiple application servers based on the number of first IoT devices and the number of second IoT devices corresponding to each of the multiple application servers. The allocation component 13 is configured to determine a target application server based on the load weight corresponding to each of the multiple application servers, and allocate the persistent connection establishment request to the target application server to establish a persistent connection between the target IoT device and the target application server. Optionally, the acquisition component 11 is configured to: for any application server among the multiple application servers, obtain the number of third IoT devices connected to the application server and the peak resource consumption value within a set historical time period, wherein the peak resource consumption value is less than a set upper limit; and determine the number of first IoT devices corresponding to the application server based on the peak resource consumption value, the number of third IoT devices, and the set upper limit. Optionally, the acquisition component 11 is configured to: in response to the number of IoT devices connected to the multiple application servers within multiple historical time periods meeting a stable equilibrium condition, obtain the number of third IoT devices connected to the application server within the set historical time period and the peak resource consumption value; wherein the stable equilibrium condition indicates that, under the condition that the multiple application servers are operating normally and the total number of IoT devices connected to the application servers within the multiple historical time periods is stable, the fluctuation in the number of IoT devices connected to each application server within the multiple historical time periods is less than a set threshold, and the difference in the number of IoT devices connected to the multiple application servers within each historical time period is less than a set threshold. Optionally, the peak resource consumption value includes the peak resource consumption value corresponding to each of the multiple resources, and the set upper limit value includes the set upper limit value corresponding to each of the multiple resources. Therefore, the acquisition component 11 is configured to: determine the number of IoT devices allowed to access the target resource based on the resource consumption peak value corresponding to the target resource, the number of third IoT devices, and the set upper limit value corresponding to the target resource, where the target resource is any one of multiple resources; and determine the number of first IoT devices corresponding to any application server based on the number of IoT devices allowed to access each of the multiple resources.Optionally, the acquisition component 11 is configured to: scale the first number of IoT devices corresponding to each of the multiple application servers based on a set scaling factor to obtain a fourth number of IoT devices corresponding to each of the multiple application servers. Based on this, the determination component 12 is configured to: determine the load weight corresponding to each of the multiple application servers based on the fourth number of IoT devices and the second number of IoT devices corresponding to each of the multiple application servers. Optionally, the determination component 12 is configured to: determine the load weight corresponding to each of the multiple application servers based on the difference between the first number of IoT devices and the second number of IoT devices corresponding to each of the multiple application servers. Optionally, the determination component 12 is configured to: smooth the difference corresponding to each of the multiple application servers; determine the load weight corresponding to each of the multiple application servers as the result of the smoothing of the difference corresponding to each of the multiple application servers. Optionally, the determination component 12 is configured to: determine a statistical value of the difference corresponding to each of the multiple application servers; determine a ratio between the difference corresponding to each of the multiple application servers and the statistical value; and perform logarithmic calculation on each of the ratios corresponding to each of the multiple application servers. The apparatus shown in FIG. 6 can execute the steps in the aforementioned embodiments. The detailed execution process and technical effects are described in the aforementioned embodiments and are not further elaborated here. In one possible design, the structure of the load balancing processing device shown in FIG. 6 can be implemented as an electronic device. As shown in FIG. 7 , the electronic device may include a processor 21, a memory 22, and a communication interface 23. Memory 22 stores executable code. When executed by processor 21, processor 21 can at least implement the load balancing processing method provided in the aforementioned embodiments. Furthermore, embodiments of the present disclosure provide a non-transitory machine-readable storage medium storing executable code. When executed by a processor of the electronic device, the processor can at least implement the load balancing processing method provided in the aforementioned embodiments. The device embodiments described above are merely illustrative. The network elements described as separate components may or may not be physically separate. Some or all of these components can be selected based on actual needs to achieve the objectives of the present embodiments. Persons of ordinary skill in the art can understand and implement these embodiments without inventive effort. Through the above description of the embodiments, persons of ordinary skill in the art can clearly understand that each embodiment can be implemented using a necessary general-purpose hardware platform, or alternatively, through a combination of hardware and software.Based on this understanding, the essence of the above-mentioned technical solutions, or the portion that contributes to the prior art, can be embodied in the form of a computer product. The present disclosure can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. Finally, it should be noted that the above embodiments are merely illustrative of the technical solutions of the present disclosure, and are not intended to limit them. Although the present disclosure has been described in detail with reference to the aforementioned embodiments, persons of ordinary skill in the art will understand that the technical solutions described in the aforementioned embodiments may be modified, or some of the technical features thereof may be replaced by equivalents. Such modifications or replacements do not deviate from the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present disclosure. Industrial Applicability: The solution provided by the embodiments of the present disclosure can be applied to the load balancing process of a server cluster. By leveraging the characteristics of IoT scenarios, which often involve frequent and stable device connections (i.e., the fact that an application server will stably connect to a certain number of IoT devices over a period of time), the solution maps the application server's resource consumption indicators that fluctuate over time to a relatively stable number of connected devices for use in load weight calculation. This eliminates the interference caused by temporal fluctuations in resource consumption values ​​on the load weight calculation, improves the stability of the application server's load weight calculation results in scenarios with persistent IoT device connections, and helps achieve better load balancing results, thereby increasing application server resource utilization and simplifying calculation complexity.

Claims

Claims 1. A load balancing method, comprising: Obtaining the number of first IoT devices corresponding to each of a plurality of application servers, wherein the number of first IoT devices corresponding to any of the application servers is the number of IoT devices allowed to access when the resource consumption of any of the application servers reaches a set upper limit; obtaining the number of second IoT devices actually accessed by the plurality of application servers in response to a persistent connection establishment request from a target IoT device; determining the load weight corresponding to each of the plurality of application servers based on the number of the first IoT devices and the number of the second IoT devices corresponding to each of the plurality of application servers; determining a target application server based on the load weight corresponding to each of the plurality of application servers, and allocating the persistent connection establishment request to the target application server to establish a persistent connection between the target IoT device and the target application server.

2. The method according to claim 1, wherein: The obtaining of the number of first Internet of Things devices corresponding to each of the multiple application servers includes: obtaining, for any application server among the multiple application servers, the number of third Internet of Things devices connected to the any application server within a set historical time period and a peak resource consumption value, wherein the peak resource consumption value is less than the set upper limit value; and determining the number of first Internet of Things devices corresponding to the any application server based on the peak resource consumption value, the number of third Internet of Things devices, and the set upper limit value.

3. The method according to claim 2, wherein: The obtaining of the third number of IoT devices connected to any one of the application servers within the set historical time period and the peak value of resource consumption includes: in response to the number of IoT devices respectively connected to the multiple application servers within the multiple historical time periods meeting a stable equilibrium condition, obtaining the third number of IoT devices connected to any one of the application servers within the set historical time period and the peak value of resource consumption; wherein the stable equilibrium condition is used to indicate that, under the condition that the multiple application servers operate normally and the total number of IoT devices respectively connected within the multiple historical time periods is stable, the degree of fluctuation in the number of IoT devices respectively connected to each application server within the multiple historical time periods is less than a set threshold, and the degree of difference in the number of IoT devices respectively connected to the multiple application servers in each historical time period is less than a set threshold.

4. The method according to claim 2, wherein: The resource consumption peak value includes resource consumption peak values ​​corresponding to a plurality of resources, and the set upper limit value includes the set upper limit value corresponding to the plurality of resources; Determining the number of first IoT devices corresponding to any one of the application servers based on the resource consumption peak value, the third number of IoT devices, and the set upper limit value includes: determining the number of IoT devices allowed to access the target resource based on the resource consumption peak value corresponding to the target resource, the third number of IoT devices, and the set upper limit value corresponding to the target resource, wherein the target resource is any one of the multiple resources; Determine the first number of Internet of Things devices corresponding to any one of the application servers according to the number of Internet of Things devices allowed to access corresponding to each of the multiple resources.

5. The method according to claim 1, wherein: After determining the number of first IoT devices corresponding to each of the multiple application servers, the method further includes: scaling the number of first IoT devices corresponding to each of the multiple application servers based on a set scaling factor to obtain a fourth number of IoT devices corresponding to each of the multiple application servers; determining the load weight corresponding to each of the multiple application servers based on the first number of IoT devices and the second number of IoT devices corresponding to each of the multiple application servers includes: determining the load weight corresponding to each of the multiple application servers based on the fourth number of IoT devices and the second number of IoT devices corresponding to each of the multiple application servers.

6. The method according to claim 1, wherein: Determining the load weight corresponding to each of the multiple application servers based on the first number of Internet of Things devices and the second number of Internet of Things devices corresponding to each of the multiple application servers includes: determining the load weight corresponding to each of the multiple application servers based on the difference between the first number of Internet of Things devices and the second number of Internet of Things devices corresponding to each of the multiple application servers.

7. The method according to claim 6, wherein: Determining the load weights corresponding to each of the multiple application servers based on the difference between the number of the first IoT devices and the number of the second IoT devices corresponding to each of the multiple application servers includes: smoothing the difference corresponding to each of the multiple application servers; and determining the load weights corresponding to each of the multiple application servers as a result of the smoothing of the difference corresponding to each of the multiple application servers.

8. The method according to claim 7, wherein: The smoothing of the difference values ​​corresponding to each of the multiple application servers includes: determining a statistical value of the difference values ​​corresponding to each of the multiple application servers; determining a ratio between the difference values ​​corresponding to each of the multiple application servers and the statistical value; and performing logarithmic calculation on the ratios corresponding to each of the multiple application servers.

9. A load balancing system, comprising: A load balancing server and multiple application servers scheduled by the load balancing server; The load balancing server is configured to obtain the number of first IoT devices corresponding to each of a plurality of application servers, obtain the number of second IoT devices actually connected to the plurality of application servers in response to a persistent connection establishment request from a target IoT device, determine the load weight corresponding to each of the plurality of application servers based on the number of first IoT devices and the number of second IoT devices corresponding to each of the plurality of application servers, determine a target application server based on the load weight corresponding to each of the plurality of application servers, and distribute the persistent connection establishment request to the target application server to establish a persistent connection between the target IoT device and the target application server. The number of first IoT devices corresponding to any application server is the number of IoT devices allowed to connect when resource consumption of the any application server reaches a set upper limit. 17 10. The system according to claim 9, wherein: The system further includes an operation and maintenance server; the operation and maintenance server is configured to obtain, for any application server among the multiple application servers, the number of third IoT devices connected to the any application server within a set historical time period and a peak resource consumption value, wherein the peak resource consumption value is less than the set upper limit; And, determining the number of first Internet of Things devices corresponding to any application server according to the resource consumption peak, the number of third Internet of Things devices and the set upper limit, and providing the number of first Internet of Things devices corresponding to any application server to the load balancing device.

11. An electronic device, wherein include: A memory, a processor, and a communication interface; wherein the memory stores executable code, and when the executable code is executed by the processor, the processor executes the load balancing processing method according to any one of claims 1 to 8.

12. A computer-readable storage medium, wherein: The computer-readable storage medium stores executable code, and when the executable code is executed by a processor of an electronic device, the processor is caused to execute the load balancing processing method according to any one of claims 1 to 8.

13. A computer program product, wherein: The method comprises a computer program, wherein when the computer program is executed by a processor, the load balancing processing method according to any one of claims 1 to 8 is implemented.

14. A computer program product, wherein The system comprises a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the load balancing processing method according to any one of claims 1 to 8 is implemented.

15. A computer program, wherein When the computer program is executed by a processor, the load balancing processing method according to any one of claims 1 to 8 is implemented.

Images