Iot device scheduling method and apparatus

Abstract

This invention provides a method and apparatus for scheduling IoT devices. The method includes: when an IoT device powers on or its heartbeat expires, the IoT device initiates a query request to a scheduling service; the scheduling service sequentially filters servers based on attributes at the business dimension and attributes at the regional dimension to obtain a candidate server pool; the scheduling service removes servers from the candidate server pool that do not match attributes at the operator dimension; the scheduling service selects a specified number of servers from the candidate server pool in ascending order of real-time load, and establishes a candidate server sub-pool based on the selected servers; the scheduling service establishes an IP list based on the candidate server sub-pool and sends the IP list to the IoT device; the IoT device connects to the business server based on the IP list. This method can operate stably in production environments with tens of millions of devices, significantly improving the throughput of the scheduling service itself, significantly reducing end-to-end latency, and evenly distributing the pressure on the business server cluster without hotspots.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and in particular to an IoT device scheduling method and apparatus. Background Technology

[0002] Currently, after IoT devices are powered on, they need to establish point-to-point communication with dozens of business nodes, such as streaming media, identity authentication, control plane, and gateways. Regarding business server node addressing (i.e., determining the connected business server and its IP (Internet Protocol) address), the current mainstream standardized implementation solutions mainly include: 1. Traditional Layer 4 / Layer 7 load balancing solutions: With LVS (Linux Virtual Server), Nginx Upstream, HAProxy (High Availability Proxy), F5 (a hardware load balancing product) and other hardware and software load balancing devices as the core, all IoT business traffic is uniformly forwarded through the load balancer (LB). The load balancer uses scheduling algorithms such as source IP hash, minimum number of connections, and weighted round-robin to dynamically select backend business instances and distribute traffic.

[0003] 2. DNS (Domain Name System) Global Load Balancing Solution: By leveraging GeoDNS (Geographic Domain Name System) to implement traffic scheduling at the DNS resolution layer, it can return the nearest business node IP address to IoT devices based on dimensions such as terminal geographical location and carrier affiliation, thereby achieving cross-regional access layer traffic sharing.

[0004] 3. Service discovery solution based on registry: It adopts service registration and discovery components such as Eureka (Eureka Service Registry), Nacos (Dynamic Naming and Configuration Service), and Consul. After each business instance starts up, it actively reports its own address information to the registry center. The upstream access gateway can actively pull the full list of backend service addresses from the registry center and complete autonomous load balancing and node addressing on the client side.

[0005] 4. Anycast / BGP (Border Gateway Protocol) Access Solution: By using the BGP routing protocol to advertise the same service IP on network nodes in multiple regions, and relying on the natural proximity addressing characteristics of public network routing, IoT devices in different regions can automatically access the business node with the closest physical distance, achieving low-latency access without the need for additional forwarding components.

[0006] However, the aforementioned mainstream standardized implementation solutions all have significant compatibility defects when facing complex real-world scenarios such as tens of millions of online IoT terminals, dozens of heterogeneous business services, multi-customer customized access rules, cross-regional deployment, multi-line operator networks, and weak 4G (Fourth Generation Mobile Communication Technology) network environments, and cannot fully meet the requirements for business implementation. Summary of the Invention

[0007] In view of this, the purpose of the present invention is to provide an IoT device scheduling method and apparatus that can operate stably in a production environment with tens of millions of devices, significantly improve the throughput of the scheduling service itself, significantly reduce end-to-end latency, and evenly distribute the pressure of the business server cluster without hotspots.

[0008] In a first aspect, embodiments of the present invention provide an IoT device scheduling method, the method comprising: when an IoT device is powered on or its heartbeat expires, the IoT device initiates a query request to a scheduling service; wherein the query request carries attributes of dimensions including: business dimension, region dimension, and operator dimension; the scheduling service sequentially filters based on the attributes of the business dimension and the attributes of the region dimension to obtain a candidate server pool; the scheduling service removes servers from the candidate server pool that do not match the attributes of the operator dimension; the scheduling service selects a specified number of servers from the candidate server pool in ascending order of real-time load, and establishes a candidate server sub-pool based on the selected servers; wherein the specified number is determined based on the number of servers in the server pool; the scheduling service establishes an IP list based on the candidate server sub-pool and sends the IP list to the IoT device; the IoT device connects to the business server based on the IP list.

[0009] In optional embodiments of this application, the attributes of the above-mentioned business dimension include: serial number, firmware version number, OEM customization ID, product ID, and hardware model; the attributes of the regional dimension include: continent information, country information, and province information; and the attributes of the operator dimension include: operator information.

[0010] In an optional embodiment of this application, the above method further includes: the scheduling service calls the local IP library to resolve the public IP address and obtain the regional dimension attributes and the carrier dimension attributes.

[0011] In an optional embodiment of this application, the step of the scheduling service filtering the candidate server pool based on the attributes of the business dimension and the attributes of the region dimension in sequence includes: the scheduling service filtering the candidate server pool in sequence based on the serial number, firmware version number, OEM customization ID, product ID and hardware model to obtain an initial candidate server pool; and the scheduling service filtering the candidate server pool from the initial candidate server pool in sequence based on the province information, country information and continent information to obtain a final candidate server pool.

[0012] In an optional embodiment of this application, the method further includes: if the query request has at least one data center pre-specified for the IoT device, the scheduling service establishes a pool of candidate servers based on the at least one data center.

[0013] In an optional embodiment of this application, the step of removing servers from the candidate server pool that do not match the carrier-level attributes includes: determining whether the query request is a cross-carrier device request based on the carrier-level attributes; if the query request is a cross-carrier device request, removing servers of the non-border gateway protocol type from the candidate server pool.

[0014] In optional embodiments of this application, the method further includes: assigning a preset initial weight to each service type by the scheduling service; adjusting the virtual load status value and matching count of the server based on the number of times the server is selected when filtering the candidate server pool; obtaining the actual load status value of the server when filtering the candidate server pool again, and determining the actual load increment of the server in a single match based on the actual load status value, the virtual load status value, and the matching count; adjusting the weight of the service type corresponding to the server based on the actual load increment in a single match; and setting the weight of the target service type as the weight lower limit if the weight of the target service type is less than or equal to a preset weight lower limit.

[0015] In optional embodiments of this application, the method further includes: adding target tags to servers in the candidate server pool; retrieving data one by one from the candidate server pool and deleting the target tags of servers included in the retrieved data; and deleting servers with added target tags from the candidate server pool.

[0016] In an optional embodiment of this application, the method further includes: the Internet of Things device storing the IP list until the heartbeat expires.

[0017] Secondly, embodiments of the present invention also provide an IoT device scheduling apparatus, comprising: a query request initiation module, used to initiate a query request to a scheduling service when the IoT device is powered on or its heartbeat expires; wherein the query request carries attributes of dimensions including: business dimension, region dimension, and operator dimension; a candidate server pool filtering module, used to filter the candidate server pool sequentially based on the attributes of the business dimension and the attributes of the region dimension; a candidate server pool elimination module, used to eliminate servers from the candidate server pool that do not match the attributes of the operator dimension; a candidate server sub-pool establishment module, used to select a specified number of servers from the candidate server pool in ascending order of real-time load, and establish a candidate server sub-pool based on the selected servers; wherein the specified number is determined based on the number of servers in the server pool; an IP list establishment module, used to establish an IP list based on the candidate server sub-pool and send the IP list to the IoT device; and a server connection module, used to connect the IoT device to a business server based on the IP list.

[0018] The embodiments of the present invention bring the following beneficial effects: This invention provides an IoT device scheduling method and apparatus. When an IoT device powers on or its heartbeat expires, the IoT device initiates a query request to a scheduling service. The query request carries attributes in the following dimensions: business dimension, region dimension, and operator dimension. The scheduling service sequentially filters servers based on the attributes of the business dimension and the region dimension to obtain a candidate server pool. The scheduling service removes servers from the candidate server pool that do not match the operator dimension attributes. The scheduling service selects a specified number of servers from the candidate server pool in ascending order of real-time load, and establishes a candidate server sub-pool based on the selected servers. The specified number is determined based on the number of servers in the server pool. The scheduling service establishes an IP list based on the candidate server sub-pool and sends the IP list to the IoT device. The IoT device connects to the business server based on the IP list. This method can operate stably in production environments with tens of millions of devices, significantly improving the throughput of the scheduling service itself, significantly reducing end-to-end latency, and evenly distributing the pressure on the business server cluster without hotspots.

[0019] Other features and advantages of this disclosure will be set forth in the following description, or some features and advantages may be inferred from the description or determined without doubt, or may be learned by practicing the techniques described above.

[0020] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0021] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0022] Figure 1 A flowchart of an IoT device scheduling method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of an IoT device scheduling method provided in an embodiment of the present invention; Figure 3 This is a schematic diagram illustrating a server filtering method provided in an embodiment of the present invention. Figure 4 This is a schematic diagram illustrating an online learning method for weighting service types, provided as an embodiment of the present invention. Figure 5 A schematic diagram of a three-stage synchronization mechanism provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of an Internet of Things (IoT) device scheduling device provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

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

[0024] Currently, existing mainstream standardized implementation solutions in the industry all have some shortcomings when facing complex real-world scenarios such as tens of millions of online IoT terminals, dozens of heterogeneous business services, multi-customer customized access rules, cross-regional deployment, multi-line operator networks, and weak 4G network environments: 1. Architectural bottlenecks of traditional Layer 4 / Layer 7 load balancing solutions: Traditional load balancing architectures, such as LVS, Nginx Upstream, HAProxy, and F5, require all business traffic to be forwarded through the load balancer. In scenarios with tens of millions of terminals and multiple long-lived connections, the bandwidth capacity, session table limit, and concurrent connection count of the load balancing cluster will become the system bottlenecks, and the risk of a single point of failure will propagate to the entire access cluster. These solutions are natively designed for internet business scenarios with "a small number of clients and high traffic per connection," not for IoT scenarios with "tens of millions of concurrent terminals and long-tail traffic per connection," and therefore cannot support the current scale of business operations.

[0025] 2. Lack of capabilities in traditional intelligent DNS global load balancing solutions: GeoDNS can only perform resolution and distribution based on geographical location, completely lacking device attribute awareness capabilities and unable to identify core identifiers such as the terminal's OEM manufacturer, firmware version, product model, activation status, and compliant region. In IoT services, "customized customer A accessing the IP-1 cluster, customized customer B accessing the IP-2 cluster, older firmware accessing the compatible IP-3 cluster, and European region terminals accessing the compliant IP-4 cluster" are common access rules. The homogeneous IP pool return mechanism of DNS is completely inadequate for such fine-grained scheduling needs. Furthermore, DNS generally suffers from minute- to hourly cache activation delays, meaning changes to scheduling policies do not immediately take effect across the entire network. Moreover, the persistent DNS hijacking problem at the public network operator level further reduces the controllability of scheduling results.

[0026] 3. Mismatch in scenarios for registry-based service discovery solutions: Service discovery components such as Eureka, Nacos, and Consul are natively designed for backend microservice clusters, with the core assumption of "a small number of upstream gateway nodes and a large number of backend service instances." The gateway side pulls the full list of services to achieve client load balancing. However, the architecture of IoT scenarios is completely reversed. The access side consists of tens of millions of terminal nodes. Requiring each terminal to pull the full list of backend service addresses would generate unacceptable signaling overhead, making it completely impractical for implementation.

[0027] 4. Scheduling blind spots in Anycast / BGP access solutions: Anycast / BGP access solutions can only achieve nearest-neighbor access based on BGP routing topology, completely unaware of device attributes and the real-time load status of backend service nodes. Even if a service server in the same data center is overloaded, the router will still continue to distribute traffic to that node. Furthermore, this solution cannot guarantee consistent access for ISPs (Internet Service Providers) across multiple carrier networks, and cannot achieve accurate traffic allocation and scheduling for China Telecom, China Unicom, and China Mobile.

[0028] 5. The ISP consistency challenge in multi-carrier networks: All traditional, mainstream, standardized implementation solutions in the industry cannot guarantee the consistency of ISP access for terminals: when a telecom operator's terminal accesses a service node in a Unicom data center across networks, the traffic must be forwarded through the inter-operator network interconnection nodes. In a weak 4G network environment, this will directly lead to a significant increase in packet loss rate, seriously affecting the stability of terminal communication. Traditional load balancing, DNS scheduling, and Anycast routing do not have fine-grained ISP awareness and scheduling capabilities, and cannot fundamentally avoid the weak network losses caused by cross-network access.

[0029] Based on this, the present invention provides an IoT device scheduling method and apparatus, specifically providing an IoT device scheduling method based on a two-stage decision-making process with multi-dimensional attributes. It adopts the core paradigm of "scheduling service returning target IP and IoT device directly connecting to service node", and is equipped with a two-stage IP selection mechanism with multi-dimensional attributes and a candidate pool differential label removal synchronization mechanism. It solves all existing problems at the architecture level at once, and achieves efficient, accurate and stable access scheduling for tens of millions of IoT terminals.

[0030] In this embodiment, the paradigm has been changed, and business traffic does not go through intermediate forwarding. After the IoT device powers on, it first queries the "scheduling service" to report its business dimension, region dimension, and operator dimension attributes. The scheduling service calculates the business servers that each business service (streaming media / authentication / control plane / gateway, etc.) of this device connects to in one go, and returns the IP list directly to the IoT device. After receiving the IP list, the IoT device directly connects to the business server, and the scheduling service is no longer on the data path.

[0031] The paradigm provided in this embodiment has four direct advantages over the traditional LB forwarding mode: (1) The scheduling service has no bandwidth bottleneck - only query traffic passes through, and the scheduling service business traffic bypasses the scheduling service; (2) The business traffic of IoT devices is directly connected to the business server, with low end-to-end latency; (3) The scheduling service can make multi-dimensional decisions that are far more complex than traditional LB; (4) The scheduling results can be cached locally on the IoT device, so there is no need to query again before the next heartbeat.

[0032] However, the above paradigm needs to be considered in its implementation: (1) accurately determine which IP to return to based on the multi-dimensional attributes of IoT devices; (2) the selection of candidates in the server pool should be biased towards low load, avoid single point of shock, and the weight should be able to keep up with the actual business load; (3) the current status of each server in the server pool must be accurate, with no dead node residues or synchronization gaps.

[0033] To facilitate understanding of this embodiment, a detailed description of an IoT device scheduling method disclosed in this embodiment of the invention will be provided first.

[0034] Example 1: This invention provides an IoT device scheduling method, see [link to relevant documentation]. Figure 1 The flowchart shown illustrates an IoT device scheduling method, which includes the following steps: Step S102: When the IoT device is powered on or the heartbeat expires, the IoT device initiates a query request to the scheduling service; the dimensions of the attributes carried in the query request include: business dimension, region dimension and operator dimension.

[0035] See Figure 2 The diagram illustrates an IoT device scheduling method. IoT devices can initiate query requests, and the scheduling service collects multi-dimensional attributes.

[0036] When an IoT device is powered on or its heartbeat expires, it can send a query request (HTTPquery) to the scheduling service.

[0037] In some embodiments, the attributes of the business dimension include: serial number, firmware version number, OEM (Original Equipment Manufacturer) customization ID, product ID, and hardware model; the attributes of the region dimension include: continent information, country information, and province information; and the attributes of the operator dimension include: operator information.

[0038] In this embodiment, the query request carries the following attribute dimensions: 5 business dimensions (serial number / firmware version number / OEM customization ID / product ID / hardware model) + 3 regional dimensions (continent information / country information / province information) + 1 operator dimension (operator information), for a total of 9 attribute dimensions.

[0039] In some embodiments, the scheduling service can also call the local IP library to resolve public IP addresses and obtain regional and carrier-level attributes.

[0040] In this embodiment, the scheduling service can call the local IP library to resolve public IP addresses, thereby obtaining attributes in three regional dimensions and attributes in the carrier dimension.

[0041] In step S104, the scheduling service sequentially filters candidates based on attributes of the business dimension and attributes of the region dimension to obtain a pool of candidate servers.

[0042] In this embodiment, the scheduling service can select candidate server pools based on business dimension attributes and regional dimension attributes, according to the dimension attribute priority chain + OEM / General (general pool) fallback + three-level descending regional selection.

[0043] In some embodiments, the scheduling service filters the initial candidate server pool based on the serial number, firmware version number, OEM customization ID, product ID, and hardware model in that order; the scheduling service then filters the final candidate server pool based on the province information, country information, and continent information in that order.

[0044] Currently, existing load balancers (LBs) and DNS systems in the industry all adopt a one-stage direct backend selection model. All traffic first enters the load balancer node, completes the backend server selection in one go within a single node, and directly forwards the traffic. There is no attribute filtering or multi-dimensional layered screening process, which is inherently unable to support the carrying capacity of tens of millions of long connections. After receiving a resolution request, it directly returns an IP pool based on the IP library, which can only perform single-round coarse-grained distribution based on geographical location. It is completely unaware of multi-dimensional attributes such as device OEM, firmware version, ISP, and load, and cannot meet the business needs of finely customized access.

[0045] See Figure 3 The diagram shown illustrates a method for filtering enterprise servers, where a pool of candidate servers can be obtained through multi-dimensional attribute filtering.

[0046] In this embodiment, the corresponding configuration can be obtained according to the prior priority of 5 business dimensions (serial number > firmware version number > OEM customization ID > product ID > hardware model). After that, the candidate server pool is selected and the candidate server pool is obtained by filtering through three channels: "OEM channel + regional dimension channel + multi-DC rollback".

[0047] In addition to the priority chain of serial number > firmware version number > OEM customization ID > product ID > hardware model, other dimensions can be added in this embodiment, which are not limited in this embodiment.

[0048] 1. OEM Channel: First, filter the server associated with the OEM in the server pool according to the OEM customization ID of the device to obtain the initial candidate server pool; if no server is matched in the OEM channel, it will fall back to the general pool as a backup - this step ensures that the differentiated distribution at the manufacturer / product line level will not crash because an OEM has not configured a server separately.

[0049] In this embodiment, in addition to using the General pool as a fallback, any "general pool" convention string (Default, Common, Public, etc.) can be used, and this embodiment does not limit this.

[0050] 2. Regional Channel: In the initial candidate server pool selected by the OEM channel, the system continues to match servers in the three-level descending order of "province information → country information → continent information" according to the device's location. Servers in the same province are matched first to obtain the final candidate server pool. If no server matches the same country information, the system will fall back to the same continent information to ensure physical proximity.

[0051] In this embodiment, in addition to the three-level descending fallback according to "province information → country information → continent information", the descending fallback can also be two-level or four-level. This embodiment does not limit this.

[0052] 3. DC (Data Center) level rollback: In some embodiments, if the query request has at least one data center pre-specified for the IoT device, the scheduling service establishes a pool of candidate servers based on at least one data center.

[0053] If the query request finds at least one data center pre-specified for the IoT device, a pool of candidate servers can be created based on that pre-specified data center. If the query request does not find a specified data center, multiple data centers can be traversed, and services can be stopped as soon as a match is found—naturally forming cross-data center disaster recovery.

[0054] In this embodiment, in addition to DC-level rollback, rollback can also be performed by weighted scoring, proximity priority, or RTT (Round-Trip Time) detection sorting.

[0055] The multi-level descending fallback structure of "OEM channel + regional dimension channel + multi-DC fallback" provided in this embodiment of the invention can cover all edge scenarios with missing long-tail configurations through layered and progressive rule matching logic: when there is no matching result for a certain level of scheduling rule, it automatically and smoothly descends to the next level of general rule, without directly jumping to the global fallback pool. From the architectural level, it completely avoids the problem of sudden drop in scheduling accuracy caused by "no matching and a one-size-fits-all return to the default IP pool" in traditional scheduling schemes, ensuring that tens of millions of IoT terminals can obtain the optimal access node with low latency that meets the requirements in any edge scenario.

[0056] Step S106: The scheduling service removes servers from the candidate server pool that do not match the attributes of the operator dimension.

[0057] In this embodiment, ISP constraints can be enforced through operator-level attributes in a three-line network scenario.

[0058] In some embodiments, it can be determined whether a query request is a cross-carrier device request based on carrier-level attributes; if the query request is a cross-carrier device request, servers of the non-border gateway protocol type are removed from the candidate server pool.

[0059] For three-line network scenarios involving China Telecom, China Unicom, and China Mobile, filtering can be performed on the candidate server pool: each business server completes attribute marking in Redis metadata through the isBgp field. Non-BGP type servers are only exposed to devices with the same operator information. Servers that do not match the operator-level attributes can be removed from the candidate server pool, such as servers across ISPs.

[0060] In this embodiment, the method for determining ISP consistency can be based not only on the isBgp field, but also on more refined topology matching according to ASN (Autonomous System Number), operator prefix tree, and BGP announcement. This embodiment does not limit this method.

[0061] In this embodiment, the device ISP (i.e., operator information) is obtained by the scheduling service using a local IP2Location (an offline IP library) / GeoIP (an offline IP address library) database based on public IP resolution (China Telecom / China Unicom / China Mobile). If the server load of the local ISP in the candidate server pool does not reach the load threshold LoadThreshold, the local server is returned first; if it exceeds the load threshold LoadThreshold, it is downgraded to a cloud-based BGP type server as a fallback.

[0062] In step S108, the scheduling service selects a specified number of servers from the candidate server pool in ascending order of real-time load, and establishes a candidate server sub-pool based on the selected servers.

[0063] The specified number is determined based on the number of servers in the server pool. The number of servers in the server pool is N, which can be between 10 and 100; the specified number can be N / 2, i.e., 5 to 50. In this embodiment, a "top N / 2 random" load balancing based on load sorting can be performed, that is, selecting the "top N / 2" number of servers in order of real-time load from low to high to establish a candidate server sub-pool.

[0064] like Figure 3 As shown, after filtering to obtain the candidate server pool, the candidate server sub-pool can be further filtered to obtain the candidate server sub-pool.

[0065] Generally, a candidate server pool can include 5-50 servers. At this scale, further selection within the pool is performed. A common implementation logic for traditional load balancing in the industry is to directly select the single server with the lowest global load value as the scheduling target. This strategy triggers a typical "Thundering Herd" effect in scenarios with tens of millions of concurrent client connections: a large number of concurrent clients simultaneously identify the same server with the "lowest current global load" and initiate access requests within the same scheduling cycle. This node will be overloaded in a very short time. In the next scheduling cycle, all clients will collectively switch to the new "lowest current load" node, causing servers within the cluster to take turns being overloaded, resulting in continuous and violent fluctuations in overall load, severely impacting system stability.

[0066] To avoid the thundering herd effect, this embodiment sorts the servers in the candidate server pool in ascending order of real-time load from low to high; the top N / 2 of the sorted servers are used to create a "low-load sub-pool" as a candidate server sub-pool, and the remaining N / 2 servers with higher loads are directly eliminated; one server is randomly selected from the candidate server sub-pool with equal probability and returned.

[0067] The method provided in this embodiment can perform low-load biased screening from a candidate server sub-pool established based on the top N / 2 servers in terms of load. The servers in the candidate server sub-pool can be randomly selected with equal probability, allowing concurrent requests to be distributed naturally and not all sent to the same "currently lowest" server, thereby avoiding the thundering herd effect.

[0068] In this embodiment, in addition to establishing a candidate server sub-pool by selecting servers through "first N / 2 random" selection, the candidate server sub-pool can also be established by weighted round-robin, Power of Two (power of 2), least connections, consistent hashing, or lowest latency selection. This embodiment does not limit this method.

[0069] This embodiment also provides a dynamic adaptive weight learning mechanism to achieve accurate alignment between candidate pool ranking and real business load.

[0070] There is an inherently non-uniform mapping between the load status value (Status) stored in Redis for each business server and the actual resource increment brought about by terminal access requests: the single connection resource consumption varies greatly among different business types. For example, a single access to a streaming media push service will increase the server load by about 30 units, while a single access to a command channel service will only increase the load by about 1 unit, and the single connection resource consumption of control plane services falls within the range of the two. If a uniform constant is used to estimate the load increment of all services, significant scheduling bias will inevitably occur.

[0071] Traditional load balancing solutions in the industry generally adopt a static weight configuration model: operations and maintenance personnel manually set a fixed weight for each backend server based on experience, and this weight is not adjusted after deployment. This model has two inherent and unsolvable drawbacks: 1. The deviation between manually configured static weights and actual business load cannot be quantified and verified, and scheduling accuracy depends entirely on operational experience. 2. The fluctuations in traffic during peak and off-peak hours and the changes in single-connection resource consumption caused by service version upgrades cannot be dynamically adapted by static weights, and the accuracy of load sorting will continue to deteriorate after long-term operation.

[0072] In some embodiments, the scheduling service pre-sets an initial weight for each service type; when filtering the candidate server pool, it adjusts the virtual load status value and the number of matches based on the number of times the server is selected; when filtering the candidate server pool again, it obtains the actual load status value of the server, and determines the actual load increment of a single match based on the actual load status value, the virtual load status value, and the number of matches; it adjusts the weight of the service type corresponding to the server based on the actual load increment of a single match; if the weight of the target service type is less than or equal to a preset weight lower limit, the weight of the target service type is set to the weight lower limit.

[0073] In this embodiment, the weights of service types can be learned online and converged towards the actual business load. (See also...) Figure 4 The diagram illustrates an online learning approach to weighting service types.

[0074] In this embodiment, the scheduling weights can be continuously driven to approximate the characteristics of the actual business load through a closed-loop logic of observation-calibration-convergence, thus completely solving the adaptability defects of traditional static weights. The specific execution process is as follows: 1. Experience-based initial weight cold start: Based on historical business operation data, preset initial weights are assigned to different types of services: DSSStream streaming media service initial weight = 30, RpsAV audio / video service initial weight = 25, RpsVoIP voice call service initial weight = 20, RpsCmd command channel service initial weight = 10, and other general services initial weight = 1. This ensures the rationality of the basic scheduling logic during the cold start phase when there is no historical observation data.

[0075] 2. Local Status Preview and Counting: After each server scheduling selection operation is completed, the scheduling service performs a pre-accumulation operation on the virtual load status value of the server in local memory: virtual Status += weight; where virtual Status is the virtual load status value and weight is the initial weight. At the same time, the number of matches in the current scheduling cycle of the server is incremented synchronously: MatchCnt += 1; where MatchCnt is the number of matches.

[0076] 3. Real Load Increment Reverse Deduction: In the next round of synchronization, the latest real load status value (i.e., real Status) of the server is pulled, and the difference is calculated with the virtual load status value (i.e., virtual Status) retained locally in the previous round. Combined with the cumulative number of matches MatchCnt in this round, the actual load increment of a single match is deduced: Load Increment = (Real Status - Virtual Status) / MatchCnt, which quantifies the macro-level status change into the micro-level single-request load characteristics.

[0077] 4. Weight Adaptive Calibration Iteration: Adjust the weight of the service type corresponding to the server based on the actual load increment of a single match: If the actual status is lower than the virtual status, it means that the current weight underestimates the resource consumption of the service, and the weight is slightly adjusted upward by the preset calibration amount (weigh←weight+calibration amount, the calibration amount can be a preset value, such as 1-5); If the actual status is higher than the virtual status, it means that the current weight overestimates the resource consumption, and the weight is slightly adjusted downward by the preset calibration amount (weigh←weight-calibration amount, the calibration amount can be a preset value, such as 1-5). Through multiple rounds of iteration, the deviation between the weight and the actual load characteristics is gradually reduced.

[0078] 5. Optimization of scheduling accuracy with positive feedback: When the weights converge to the error range of the actual business load, the load ranking result of the next round of scheduling will perfectly match the actual resource usage of the server. The accuracy of the selected top N / 2 low-load sub-pools will be greatly improved, further reducing the probability of overall cluster load imbalance.

[0079] 6. Robustness protection of weight lower limit: This embodiment can configure an insurmountable weight lower limit for each type of service, i.e., weight=max(weight, lower limit value), for example: DSSStream weight ≥30, RpsAV weight ≥25, RpsVoIP weight ≥20, RpsCmd weight ≥10, to avoid extreme traffic fluctuations and abnormal monitoring data causing the weight to converge excessively to 0, and to ensure that the self-learning logic will not fail from the mechanism level.

[0080] The online learning mechanism for service type weights provided in this embodiment can transform the load balancing weight values ​​from static configurations into online learning parameters. Without any offline training or external feedback channels, the weights can naturally converge to the actual single-time matching load of the service.

[0081] In this embodiment, the feedback sources for weight learning, in addition to "local virtual Status + incremental back-pushing from the next round of real Redis", can also be active reporting from business servers, Prometheus metric retrieval, APM (Application Performance Monitoring) link tracking, etc. This embodiment does not limit these sources.

[0082] In this embodiment, in addition to the direct accumulation of average increments, other methods such as EMA (Exponential Moving Average), PID (Proportional-Integral-Derivative) controller, and simple bandit algorithm of reinforcement learning can also be used. This embodiment does not limit the specific methods used.

[0083] In some embodiments, target tags may be added to servers in the candidate server pool; data may be retrieved one by one based on the candidate server pool, and the target tags of the servers included in the retrieved data may be deleted; servers with added target tags may be deleted from the candidate server pool.

[0084] In this embodiment, the real-time status maintenance of the candidate pool can also be performed through a three-stage periodic synchronization of differential marker removal.

[0085] The end-to-end decision-making of the above-mentioned methods in this embodiment, including level screening, load sorting, and ISP affinity scheduling, is based on a core premise: the real-time status (load value, online / offline status, data center affiliation, OEM attribute, and region label) of each server in the local memory candidate pool must be 100% accurate.

[0086] Because the authoritative data source for the candidate pool is stored in a Redis cluster, the scheduling service must periodically pull all data to local memory to build a high-frequency read cache to support microsecond-level scheduling responses for tens of millions of connected terminals. In this scenario, how to promptly, without residue, and without gaps in the local memory cache clean up entries deleted from Redis after a server is taken offline for maintenance is a long-standing common technical challenge in the industry. All four mainstream solutions have inherent flaws that cannot be avoided: 1. Overwrite + TTL (Time To Live) expiration scheme: Deleted entries that are not retrieved in this round of synchronization will remain permanently in the local cache; setting the TTL too short will greatly increase the Redis synchronization pressure, while setting the TTL too long will result in an excessively large window of invalid entries remaining, causing the scheduling system to return invalid IPs that have gone offline for a long time.

[0087] 2. Solution of clearing the entire database and then writing all data: During the time window from the execution of the clearing operation to the completion of the writing of the new full data, the local cache is completely empty. All access read requests will hit the cache invalidation. Either the request will directly penetrate to Redis and crash the cluster, or it will directly return a scheduling error and cause a business avalanche.

[0088] 3. Dual Buffer Switching Scheme: The candidate pool cache itself is already in the hundreds of MB range. Maintaining an additional backup buffer will directly exhaust the scheduling server's memory resources. At the same time, the atomic switching operation also requires the introduction of complex concurrency control logic such as RCU (Read-Copy Update) mechanism and reference counting, which is extremely costly to implement.

[0089] 4. Redis keyspace notification event-driven solution: This solution relies entirely on Redis's keyspace notification mechanism to listen for deletion events. In the event of network jitter, connection reconnection, or event interruption and loss, deleted entries will remain silently in the local cache. This type of hidden dirty data is difficult to monitor and detect, which can lead to long-term scheduling anomalies.

[0090] This embodiment provides a three-stage synchronization mechanism for "differential tag removal"—tag marking before start, tag removal during process, and scanning and retrieval at the end. (See also...) Figure 5 The diagram shows a three-stage synchronization mechanism.

[0091] 1. `sync_begin` – Marking before starting: At the start of each synchronization round, it iterates through all existing entries in memory and marks them with a "to be reclaimed" target (or increments the global generation number by 1, which is equivalent). No data is deleted, and no read paths are blocked – read paths can continuously read valid data from the previous round throughout the entire synchronization process.

[0092] 2. Tagging during the process: The main loop pulls data from Redis one by one (or in batches via pipeline). For each piece of data pulled: write / overwrite the corresponding entry in memory by key (data update) + remove the "to be reclaimed" target mark for this entry; new entries are added normally without any mark.

[0093] 3. `sync_end` – Scan and Reclaim: After the main synchronization loop finishes running, `sync_end()` is called. It iterates through memory, removing entire segments marked as "to be reclaimed"—these are the old entries in Redis that were deleted but not retrieved in this round. At this point, the memory usage is strictly equal to the full snapshot of Redis in this round.

[0094] The three-stage synchronization mechanism of "differential marker removal" provided in this embodiment has the following advantages: 1. Zero Residue: Entries not retrieved in this round will be uniformly recycled, completely eradicating the problem of old entries remaining in the overwrite + TTL solution.

[0095] 2. Zero-window operation: Only the flag bit is modified, and no data is deleted throughout the entire process. The synchronous full-cycle read path is lock-free, has no clearing operation, and has no buffer switching action, so there will be no service interruption.

[0096] 3. Zero memory doubling: All marking and update operations are performed in the original memory space without the need to allocate additional spare cache. Compared with the double buffer scheme, it saves half the memory and is suitable for large candidate pool scenarios.

[0097] 4. No data source binding: It does not rely on dedicated event capabilities such as Redis key space notifications. As long as the data source supports full data retrieval, it can be used and is compatible with various mainstream data sources such as Redis, MySQL, Etcd, and HTTP API.

[0098] 5. Self-recovery from anomalies: If an anomaly such as network interruption or process crash occurs during synchronization, the recycling operation will not be triggered as long as sync_end() is not executed, and the existing data will be fully available; when the next round of synchronization starts, it will automatically re-mark the data without manual intervention or additional compensation logic, and automatically restore it to a consistent initial state.

[0099] The "differential marker removal" three-stage synchronization mechanism provided in this embodiment is the underlying support for the entire candidate server pool decision-making process. Without this mechanism, there would be dead nodes or synchronization gaps in the candidate server pool, which would reduce the accuracy of the previous OEM region screening, the first N / 2 randomization, and weight learning. The mechanism itself is also universal and not limited to this scenario; it can be applied to any caching scenario involving "periodic full fetching and cleanup".

[0100] In step S110, the scheduling service establishes an IP list based on the candidate server sub-pool and sends the IP list to the IoT device.

[0101] like Figure 2 As shown, the scheduling service can generate an IP list and send the created IP list to IoT devices.

[0102] In this embodiment, the scheduling service can concatenate the target IPs of each business service into a unified JSON and return it as an IP list response to the IoT device.

[0103] Step S102: The IoT device connects to the business server based on the IP list.

[0104] like Figure 2 As shown, IoT devices can directly connect to the business server based on the IP list, and business traffic does not go through the scheduling service.

[0105] In some embodiments, IoT devices store a list of IP addresses until the heartbeat expires.

[0106] In this embodiment, the IoT device caches the IP list, so it doesn't need to retrieve the IP list again before the next heartbeat. Device information (registration time, initial public IP address, MAC address (Media Access Control Address), and the currently assigned IP list, etc.) is asynchronously written to Redis for future scheduling reference and operational auditing.

[0107] In this embodiment, the cached IP list can also be discarded when the fixed TTL, heartbeat trigger, or server-initiated push fails. This embodiment does not limit this.

[0108] This invention provides an IoT device scheduling method. When an IoT device powers on or its heartbeat expires, the IoT device initiates a query request to a scheduling service. The query request carries attributes in the following dimensions: business dimension, region dimension, and operator dimension. The scheduling service sequentially filters servers based on the attributes of the business dimension and the region dimension to obtain a candidate server pool. The scheduling service removes servers from the candidate server pool that do not match the operator dimension attributes. The scheduling service selects a specified number of servers from the candidate server pool in ascending order of real-time load, and establishes a candidate server sub-pool based on the selected servers. The specified number is determined based on the number of servers in the server pool. The scheduling service creates an IP list based on the candidate server sub-pool and sends the IP list to the IoT device. The IoT device connects to the business server based on the IP list. This method can operate stably in production environments with tens of millions of devices, significantly improving the throughput of the scheduling service itself, significantly reducing end-to-end latency, and evenly distributing the pressure on the business server cluster without hotspots.

[0109] The IoT device scheduling method provided in this embodiment mainly includes the following: 1. A two-stage IP selection paradigm based on multi-dimensional attribute perception: Traditional industry practices for load balancing / DNS / service discovery involve a single phase of backend selection. This implementation, for the first time, splits IP selection into two phases: Phase A uses a 9-dimensional attribute + 6-dimensional priority chain to stop selection upon hit, plus OEM / General fallback, a three-tiered regional descending selection, and multiple DC fallbacks to filter out a candidate pool; Phase B performs "top N / 2 random selection" within the pool. Simultaneously, the entire system operates under the paradigm of "scheduling service returns IP, client connects directly," with no business traffic being forwarded. This is the core of the entire solution.

[0110] 2. Dynamic adaptive weight learning closed loop: This embodiment uses a local pre-incrementing status for the scheduling service, pulls the real status in the next round to deduce the "actual single-match load increment," and calibrates the weights online using observations—transforming the load balancing weights from static configurations into online learning parameters. This eliminates the need for offline training and active reporting from business servers. Different services (streaming media / control plane / authentication) converge to their respective real load curves, and an initial lower limit protects against abnormal fluctuations that could render the mechanism ineffective. This mechanism represents a paradigm shift compared to the industry's traditional static weighting approach for load balancing.

[0111] 3. Phase B "First N / 2 Random" Anti-panic Group Load Balancing: In this embodiment, the candidate server pool is sorted in ascending order by real-time load, and the first half is selected as a low-load sub-pool. Within the sub-pool, random selection is conducted with equal probability—this approach both favors low-load servers and avoids single-point thundering herd errors through randomization. Compared to "picking the smallest machine" to avoid load oscillations, and compared to "random selection across the entire pool" to favor low-load machines, this is a compromise design that balances load bias and anti-thundering herd errors.

[0112] 4. Three-stage synchronization of differential flag removal for real-time status of candidate server pool: In this embodiment, before each round of synchronization, `sync_begin` marks all existing entries as "pending recycling" without deleting the data; during the process, tags are delimited by key; and at the end, `sync_end` scans and clears outdated entries that still bear the tags—transforming "outdated node identification" into "tag scanning" in an observable intermediate state, ensuring consistency between the candidate pool and Redis. Compared to the four mainstream approaches in the industry—"overwrite + TTL", "full database clear and rewrite", "double buffer", and "event-driven"—this embodiment simultaneously achieves five attributes: zero residue, zero empty window, zero memory doubling, no reliance on event notifications, and self-recovery from anomalies. This is the underlying support for the near real-time data acquisition achieved by the load balancer and dynamic weight learning within the candidate server sub-pool, and it is also a general mechanism that can be reused in any "periodic full fetch and cleanup" caching scenario, detached from this specific scenario.

[0113] 5. ISP Consistency Embedding Candidate Pool Screening: This embodiment targets a three-line network scenario. By resolving the client's ISP through a local IP database and combining it with the server's isBgp field, non-BGP servers are only exposed to devices within the same ISP, significantly improving lag issues in weak cross-ISP networks.

[0114] 5. The paradigm of dispatch service returning IP and direct client connection: In this embodiment, the service traffic does not exceed the scheduling service, the scheduling service itself has no bandwidth bottleneck, and a single scheduling service can support tens of millions of devices.

[0115] The IoT device scheduling method provided in this embodiment solves the following problem: 1. It solves the problem that "traditional load balancing forwarding mode cannot handle the scale of IoT".

[0116] The scheduling service's return IP address and direct client connection paradigm in this embodiment allows business traffic to bypass the scheduling service. A single scheduling service can handle tens of millions of device queries without bandwidth bottlenecks or single points of failure. This represents a paradigm-level difference compared to LVS / Nginx upstream / HAProxy / F5.

[0117] 2. Resolved the issue of "DNS / traditional LB not being aware of device attributes".

[0118] In this embodiment, the 10-dimensional attribute two-stage decision-making + 6-dimensional priority chain hit-and-stop + OEM / General fallback + three-level regional descent + multiple DC rollback can drive differentiated deployment in any one dimension; long-tail scenarios can also be reasonably fallbacked instead of being cut off to Default.

[0119] 3. Solved the problem of "slow network performance when crossing ISPs in three-line networks".

[0120] In this embodiment, the ISP consistency constraint is embedded in the candidate pool screening process. Non-BGP servers are only exposed to devices within the same ISP. In a three-line network, devices are always connected to the ISP server, which greatly reduces cross-network intersection traffic.

[0121] 4. Solved the problem of "single point thundering herd due to picking the lowest load in the pool".

[0122] In this embodiment, "sort by load + randomize the first N / 2" is used instead of "pick the smallest machine", which is biased towards low load and randomly distributed, resulting in a stable and oscillating cluster load distribution.

[0123] 5. Resolved the issue of "old node residue and synchronization gap caused by candidate pool data source synchronization".

[0124] In this embodiment, the differential tag removal uses a three-stage synchronous process—`sync_begin` tagging, `sync_end` process tagging, and `sync_end` scan and recycling—to ensure strict consistency between the candidate pool and the full Redis data: zero stale node remnants (compared to overwrite + TTL), zero read path empty windows (compared to clearing the entire database and then writing again), zero memory doubling (compared to dual buffers), no reliance on external event notifications (compared to event-driven systems), and automatic recovery in the next round without compensation after an abnormal crash. This mechanism is a prerequisite for the reliable operation of B-sorting in the S4 stage and weight learning in the S5 stage.

[0125] 6. Solved the problem of "large deviation between traditional LB static weights and actual business load".

[0126] The dynamic adaptive weight learning closed loop in this embodiment—local pre-incrementing Status and back-calculating the calibration based on the real increment observed in the next round—allows the weights to converge online to the real single-time matching load without offline training or external feedback channels. Different services (streaming media / control plane / authentication) converge to their own curves.

[0127] In summary, the method provided in this embodiment can run stably in a production environment with tens of millions of devices. Compared with the traditional "DNS + real-time Redis" approach, the throughput of the scheduling service itself is significantly improved, the end-to-end latency is significantly reduced, and the pressure on the business server cluster is evenly distributed without hotspots.

[0128] Example 2: Corresponding to the above method embodiments, this invention provides an IoT device scheduling apparatus, see [link to relevant documentation]. Figure 6 The diagram shown illustrates the structure of an IoT device scheduling device, which includes: The query request initiation module 61 is used to initiate a query request from an IoT device to the scheduling service when the IoT device is powered on or when the heartbeat expires; the dimensions of the attributes carried in the query request include: business dimension, region dimension and operator dimension. The candidate server pool filtering module 62 is used to filter the scheduling service based on the attributes of the business dimension and the attributes of the region dimension to obtain the candidate server pool. The candidate server pool elimination module 63 is used to schedule services to eliminate servers from the candidate server pool that do not match the attributes of the operator dimension. The candidate server sub-pool establishment module 64 is used to schedule the service to select a specified number of servers from the candidate server pool in order of real-time load from low to high, and establish a candidate server sub-pool based on the selected servers; wherein, the specified number is determined based on the number of servers in the server pool. IP list creation module 65 is used to create an IP list based on the candidate server sub-pool for scheduling services and send the IP list to IoT devices; Server connection module 66 is used for IoT devices to connect to the business server based on an IP list.

[0129] This invention provides an IoT device scheduling device. When an IoT device powers on or its heartbeat expires, the IoT device initiates a query request to a scheduling service. The query request carries attributes in the following dimensions: business dimension, region dimension, and operator dimension. The scheduling service sequentially filters servers based on the attributes of the business dimension and the region dimension to obtain a candidate server pool. The scheduling service removes servers from the candidate server pool that do not match the operator dimension attributes. The scheduling service selects a specified number of servers from the candidate server pool in ascending order of real-time load, and establishes a candidate server sub-pool based on the selected servers. The specified number is determined based on the number of servers in the server pool. The scheduling service establishes an IP list based on the candidate server sub-pool and sends the IP list to the IoT device. The IoT device connects to the business server based on the IP list. This device can operate stably in production environments with tens of millions of devices, significantly improving the throughput of the scheduling service itself, significantly reducing end-to-end latency, and evenly distributing the pressure on the business server cluster without hotspots.

[0130] The attributes for the above business dimensions include: serial number, firmware version number, OEM customization ID, product ID, and hardware model; the attributes for the regional dimension include: continent information, country information, and province information; and the attributes for the operator dimension include: operator information.

[0131] The aforementioned device also includes: a region-dimensional and operator-dimensional attribute determination module, used for scheduling services to call the local IP library to resolve public IP addresses and obtain region-dimensional and operator-dimensional attributes.

[0132] The candidate server pool filtering module is used to filter the scheduling service in the order of serial number, firmware version number, OEM customization ID, product ID and hardware model to obtain the initial candidate server pool; the scheduling service then filters from the initial candidate server pool in the order of province information, country information and continent information to obtain the final candidate server pool.

[0133] The aforementioned apparatus further includes: a data center designation module, used to establish a candidate server pool based on at least one data center if the query request has at least one data center pre-designated for the IoT device.

[0134] The aforementioned candidate server pool elimination module is used to determine whether a query request is a cross-carrier device request based on carrier-level attributes; if the query request is a cross-carrier device request, servers of the non-border gateway protocol type are eliminated from the candidate server pool.

[0135] The aforementioned device further includes: a service type weight adjustment module, used to schedule services and pre-set corresponding initial weights for each service type; when filtering the candidate server pool, adjusting the virtual load status value and matching count of the server based on the number of times the server is selected; when filtering the candidate server pool again, obtaining the actual load status value of the server, and determining the actual load increment of the server in a single match based on the actual load status value, virtual load status value, and matching count; adjusting the weight of the service type corresponding to the server based on the actual load increment of a single match; if the weight of the target service type is less than or equal to a preset weight lower limit, setting the weight of the target service type as the weight lower limit.

[0136] The aforementioned apparatus further includes: a server deletion module for a candidate server pool, used to add target tags to servers in the candidate server pool; pull data one by one from the candidate server pool and delete the target tags of servers included in the pulled data; and delete servers with added target tags from the candidate server pool.

[0137] The aforementioned device also includes an IP list caching module, used by IoT devices to store IP lists until the heartbeat expires.

[0138] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the IoT device scheduling device described above can be referred to the corresponding process in the aforementioned embodiments of the IoT device scheduling method, and will not be repeated here.

[0139] Example 3: This invention also provides an electronic device for running the above-described IoT device scheduling method; see [link to previous document]. Figure 7 The diagram shows the structure of an electronic device, which includes a memory 100 and a processor 101. The memory 100 is used to store one or more computer instructions, which are executed by the processor 101 to implement the above-mentioned IoT device scheduling method.

[0140] Furthermore, Figure 7 The electronic device shown also includes a bus 102 and a communication interface 103, with the processor 101, the communication interface 103 and the memory 100 connected via the bus 102.

[0141] The memory 100 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 103 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus 102 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0142] Processor 101 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 101 or by instructions in software form. Processor 101 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a readily available storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 100, and processor 101 reads information from memory 100 and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments.

[0143] This invention also provides a computer-readable storage medium storing computer-executable instructions. When these computer-executable instructions are invoked and executed by a processor, they cause the processor to implement the above-described IoT device scheduling method. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0144] The computer program product of the IoT device scheduling method and apparatus provided in the embodiments of the present invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.

[0145] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and / or device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0146] Furthermore, in the description of the embodiments of the present invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in the present invention based on the specific circumstances.

[0147] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0148] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0149] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for scheduling Internet of Things (IoT) devices, characterized in that, The method includes: When an IoT device is powered on or its heartbeat expires, the IoT device initiates a query request to the scheduling service; wherein, the dimensions of the attributes carried in the query request include: business dimension, region dimension, and operator dimension; The scheduling service sequentially filters candidates based on the attributes of the business dimension and the attributes of the region dimension to obtain a pool of candidate servers. The scheduling service removes servers from the candidate server pool that do not match the attributes of the operator dimension. The scheduling service selects a specified number of servers from the candidate server pool in ascending order of real-time load, and establishes a candidate server sub-pool based on the selected servers; wherein, the specified number is determined based on the number of servers in the server pool. The scheduling service establishes an IP list based on the candidate server sub-pool and sends the IP list to the IoT device; The IoT device connects to the service server based on the IP list; The method further includes: the scheduling service pre-setting an initial weight for each service type; when filtering the candidate server pool, adjusting the virtual load status value and matching count of the server based on the number of times the server is selected; when filtering the candidate server pool again, obtaining the actual load status value of the server, and determining the actual load increment of the server per matching based on the actual load status value, the virtual load status value, and the matching count; adjusting the weight of the service type corresponding to the server based on the actual load increment of the single matching; if the weight of the target service type is less than or equal to a preset weight lower limit, setting the weight of the target service type to the weight lower limit.

2. The method according to claim 1, characterized in that, The attributes of the business dimension include: serial number, firmware version number, OEM customization ID, product ID, and hardware model; The attributes of the regional dimension include: continent information, country information, and province information; The attributes of the operator dimension include: operator information.

3. The method according to claim 1, characterized in that, The method further includes: The scheduling service calls the local IP library to resolve public IP addresses, obtaining the attributes at the region level and the attributes at the carrier level.

4. The method according to claim 2, characterized in that, The step of the scheduling service sequentially filtering candidates for a server pool based on the attributes of the business dimension and the attributes of the region dimension includes: The scheduling service filters servers sequentially based on the serial number, firmware version number, OEM customization ID, product ID, and hardware model to obtain an initial candidate server pool. The scheduling service sequentially selects from the initial candidate server pool based on the province information, the country information, and the continent information to obtain the final candidate server pool.

5. The method according to claim 1, characterized in that, The method further includes: If the query request has at least one data center pre-specified for the IoT device, the scheduling service establishes the candidate server pool based on at least one of the data centers.

6. The method according to claim 1, characterized in that, The step of removing servers from the candidate server pool that do not match the attributes of the operator dimension includes: Based on the attributes of the carrier dimension, determine whether the query request is a cross-carrier device request; If the query request is for a device across different carriers, remove servers of the non-border gateway protocol type from the candidate server pool.

7. The method according to claim 1, characterized in that, The method further includes: Add target tags to the servers in the candidate server pool; Data is retrieved one by one from the candidate server pool, and the target marker of the server included in the retrieved data is deleted. Remove the server with the target tag added from the candidate server pool.

8. The method according to claim 1, characterized in that, The method further includes: The IoT device stores the IP list until the heartbeat expires.

9. An Internet of Things (IoT) device scheduling device, characterized in that, The device includes: The query request initiation module is used to initiate a query request to the scheduling service when the IoT device is powered on or when the heartbeat expires; wherein, the dimensions of the attributes carried by the query request include: business dimension, region dimension and operator dimension; The candidate server pool filtering module is used by the scheduling service to filter the candidate server pool based on the attributes of the business dimension and the attributes of the region dimension in turn. The candidate server pool elimination module is used by the scheduling service to eliminate servers from the candidate server pool that do not match the attributes of the operator dimension. The candidate server sub-pool establishment module is used by the scheduling service to select a specified number of servers from the candidate server pool in ascending order of real-time load, and establish a candidate server sub-pool based on the selected servers; wherein, the specified number is determined based on the number of servers in the server pool. The IP list creation module is used by the scheduling service to create an IP list based on the candidate server sub-pool and send the IP list to the IoT device. The server connection module is used by the IoT device to connect to the business server based on the IP list; The aforementioned apparatus further includes: a service type weight adjustment module, used to pre-set an initial weight for each service type by the scheduling service; when filtering the candidate server pool, adjusting the virtual load status value and matching count of the server based on the number of times the server is selected; when filtering the candidate server pool again, obtaining the actual load status value of the server, determining the actual single-match load increment of the server based on the actual load status value, the virtual load status value, and the matching count; adjusting the weight of the service type corresponding to the server based on the actual single-match load increment; if the weight of the target service type is less than or equal to a preset weight lower limit, setting the weight of the target service type to the weight lower limit.

Images