Heat supply scheduling method, heat supply scheduling device, computer device and storage medium

Abstract

The application discloses a heat supply scheduling method, a heat supply scheduling device, computer equipment and a storage medium. The heat supply scheduling method comprises the following steps: constructing a scheduling cluster composed of multiple service nodes based on a middleware-free self-organizing cluster protocol; dividing heat supply equipment resources into multiple logical fragments to be distributed to each service node in the scheduling cluster; determining a target logical fragment to which a target heat supply equipment belongs according to the identification of the target heat supply equipment, and routing a heat supply scheduling instruction to a service node responsible for the target logical fragment for execution. In this way, the heat supply scheduling method of the application can realize self-organization and task balanced routing of the heat supply scheduling cluster under the premise of no middleware, reduce deployment and operation and maintenance costs, and improve the stability of the system in a complex heat supply field environment, thereby better adapting to the scheduling needs of heat supply Internet of Things terminals.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a heating scheduling method, a heating scheduling device, a computer device, and a storage medium. Background Technology

[0002] In heating production scheduling, real-time monitoring, load forecasting, and dispatching commands need to be issued for tens of thousands to hundreds of thousands of heating devices (heat exchange stations, temperature control valves, heat meters, and other IoT terminals). Since a single service node cannot handle massive concurrent tasks, task sharding is required to achieve balanced task distribution.

[0003] Currently, mainstream heating dispatching system architectures generally rely on the additional deployment and maintenance of middleware clusters such as distributed message queues, registration centers, and configuration centers to achieve cluster node collaboration, task sharding, and load balancing. However, actual heating production sites commonly face problems such as complex network environments, limited hardware resources, insufficient on-site operation and maintenance capabilities, and high deployment and maintenance costs. The additional middleware clusters significantly increase system complexity and the barrier to implementation. Furthermore, the poor compatibility of heating IoT terminal protocols with different communication protocols further exacerbates the difficulty of system access and dispatching control. Summary of the Invention

[0004] This application provides a heating dispatching method, a heating dispatching device, a computer device, and a storage medium.

[0005] On one hand, embodiments of this application provide a heating scheduling method, including: Based on a middleware-free self-organizing cluster protocol, a scheduling cluster consisting of multiple service nodes is constructed. The heating equipment resources are divided into multiple logical shards and allocated to each service node in the scheduling cluster. Determine the target logical segment to which the target heating equipment belongs based on its identifier; and The heating scheduling command is routed to the service node responsible for the target logical segment for execution.

[0006] In some embodiments, the self-organizing cluster protocol is the JGroups protocol; the service nodes include a scheduling center node deployed in the cloud and / or an edge gateway node deployed in the heating area.

[0007] In some embodiments, dividing the heating equipment resources into multiple logical shards for allocation to service nodes in the scheduling cluster includes: Based on the identifier mapping rules, establish the correspondence between each heating device and the logical segment; According to the preset allocation strategy, each logical shard is allocated to each currently active service node; Obtain the real-time load status of each of the service nodes, wherein the real-time load status includes at least one of CPU utilization, memory utilization, network latency, and task backlog. Based on the real-time load status, the correspondence between the logical shards and the currently active service nodes is dynamically adjusted.

[0008] In some embodiments, the identifier mapping rule includes a hash mapping rule, and establishing the correspondence between each heating device and the logical shard includes: The identification codes of each heating device are mapped to a continuous integer space using a hash function; The continuous integer space is divided into multiple integer intervals, and each integer interval is defined as a logical slice.

[0009] In some embodiments, the preset allocation strategy includes an equal distribution strategy, and the initial allocation of each of the logical shards to the currently active service nodes includes: Based on the number of currently active service nodes, each logical shard is evenly distributed to each service node.

[0010] In some embodiments, dynamically adjusting the correspondence between the logical shards and the currently active service nodes based on the real-time load status includes: Based on the real-time load status of each service node, determine whether there is a load imbalance; When there is a load imbalance, at least a portion of the logical shards handled by the high-load node whose load status meets the first preset condition are redistributed to the low-load node whose load status meets the second preset condition.

[0011] In some embodiments, it also includes: When a service node is detected to be offline or newly added in the cluster, the fault detection mechanism based on the JGroups protocol triggers a cluster membership change event. In response to the cluster member change event, each logical shard is allocated to the currently active service nodes according to a preset allocation strategy.

[0012] In some embodiments, routing the heating scheduling command to the service node responsible for the target logical shard for execution includes: Based on the local cached sharding mapping table, obtain the target service node responsible for the target logical shard; The heating scheduling command is sent to the target service node, so that the target service node can execute the command issuance.

[0013] In some embodiments, the method further includes: Encryption algorithms are used to encrypt communication data between cluster nodes.

[0014] In some embodiments, the method further includes: When an edge gateway node detects a network disconnection from the scheduling center node for a duration exceeding a preset threshold, it switches to local autonomous mode to execute instructions on the managed devices based on the locally cached scheduling policy.

[0015] On the other hand, embodiments of this application provide a heating dispatching device, including: The cluster building module is used to build a scheduling cluster from multiple service nodes based on a middleware-free self-organizing group communication protocol. The sharding scheduling module is used to divide heating equipment resources into multiple logical shards for allocation to each service node in the scheduling cluster. The determination module is used to determine the target logical segment to which the target heating equipment belongs based on its identifier; and The execution module is used to route the scheduled tasks to the service nodes responsible for the target logical shards for execution.

[0016] On the other hand, embodiments of this application provide a computer device, the computer device including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the heating scheduling method.

[0017] On the other hand, embodiments of this application provide a computer-readable storage medium storing a computer program adapted for loading by a processor to execute the heating scheduling method as described above.

[0018] The heating scheduling method, heating scheduling device, computer equipment, and computer-readable storage medium provided in this application construct a scheduling cluster through a middleware-free self-organizing cluster protocol, eliminating the deployment and maintenance of traditional middleware clusters, reducing system complexity and on-site deployment costs, and enabling stable operation under conditions of limited resources and complex environments at the heating site. By logically sharding heating equipment resources and implementing task routing, massive heating scheduling instructions can be evenly distributed to various service nodes for parallel execution, effectively improving the system's ability to handle concurrent access, real-time monitoring, and scheduling instructions for tens of thousands to hundreds of thousands of heating IoT terminals. At the same time, it simplifies the system architecture, improves reliability and scalability, and better adapts to the access and scheduling needs of various heating IoT terminals. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram of a heating dispatching system provided in an embodiment of this application.

[0021] Figure 2 This is a schematic diagram of the hierarchical architecture of a heating dispatching system provided in an embodiment of this application.

[0022] Figure 3-11 This is a flowchart illustrating the heating scheduling method provided in an embodiment of this application.

[0023] Figure 12 This is a schematic diagram of the heating dispatching device provided in the embodiments of this application.

[0024] Figure 13 A schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0025] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] In centralized heating production scheduling, real-time monitoring, load forecasting, and dispatching commands are required for tens to hundreds of thousands of IoT terminals, including heat exchange stations, temperature control valves, and heat meters. Faced with massive concurrent access from terminals and high-frequency data processing demands, a single service node cannot handle the load; therefore, a cluster architecture is needed to achieve balanced task distribution and parallel processing.

[0027] Currently, mainstream heating dispatching solutions heavily rely on registry middleware such as Zookeeper (a distributed coordination service used to solve coordination, consistency, and state management problems in distributed systems). This requires the additional deployment and maintenance of dedicated middleware clusters, resulting in complex system architectures and high operation and maintenance costs. Heating sites are often located in heat exchange station server rooms and edge computing nodes, which generally suffer from complex network environments, limited hardware resources, and weak operation and maintenance conditions. This makes middleware cluster deployment difficult and operational stability hard to guarantee. Furthermore, heating IoT terminals and embedded gateways generally have limited computing and storage resources, making them difficult to adapt to heavy middleware clients. On-site networks are also prone to partitioning, bandwidth fluctuations, and other issues. Traditional middleware heartbeat keep-alive mechanisms are prone to connection jitter and terminal disconnections, resulting in poor IoT terminal adaptability.

[0028] Furthermore, existing task allocation methods mostly employ polling or static sharding strategies, failing to perceive the real-time load status of each service node. When a node's processing capacity decreases due to network fluctuations or data congestion, scheduling instructions can easily accumulate, severely impacting the timeliness and accuracy of heating regulation. Regarding business continuity, when a service node fails, traditional solutions rely on middleware session timeout mechanisms to trigger task reassignment. This results in high switching latency and slow convergence, easily causing localized heating terminal disconnections and scheduling interruptions, posing significant risks to heating safety and stable operation.

[0029] In view of this, embodiments of this application provide a heating dispatching method, a heating dispatching device, a computer device, and a storage medium. The heating dispatching method is used for intelligent heating production dispatching operations.

[0030] Specifically, the heating scheduling method in this application embodiment can be executed by a computer device, which can be a terminal or a server. The terminal can be a personal computer, tablet computer, laptop computer, or other similar device. The terminal can also include a client, which can be a user client, browser client, instant messaging client, or mini-program, etc.

[0031] A server can be a standalone physical server, a server cluster or a distributed system composed of multiple physical servers, and can also provide cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, and content delivery networks. ContentDeliveryNetwork , CDN Cloud servers that provide basic cloud computing services such as big data and artificial intelligence platforms.

[0032] It should be noted that, in the embodiments of this application, the executing entity of the heating scheduling method can be a terminal device or a server. The terminal device can be a local terminal device or the aforementioned client device. This application does not limit the type of executing entity.

[0033] For example, in conjunction with the above description, Figure 1 This application illustrates a heating dispatching system 1000 for implementing a heating dispatching method. The heating dispatching system 1000 may include at least one terminal 1001, at least one server 1002, at least one database 1003, and a network. The user-held terminal 1001 can connect to different servers via the network. The terminal can be any device with computing hardware capable of supporting and executing queries for corresponding software application tools.

[0034] In the aforementioned heating dispatch system 1000, terminal 1001 is used to install and run the heating dispatch client, receive user instructions, and submit them to server 1002. In some cases, terminal 1001 may not need to have the heating dispatch client pre-installed; instead, it can directly access the heating cloud platform through a browser or mini-program. After logging into the heating cloud platform with a registered account, the user can control that account and experience the heating dispatch methods. When a user logs into the heating cloud platform, terminal 1001 sends a login request to server 1002. Server 1002 verifies the user's account and determines the corresponding query mechanism based on the login request. If the verification is successful, server 1002 returns a login success notification to terminal 1001. During the process of users accessing the heating cloud platform, terminal 1001 and server 1002 interact with each other. Terminal 1001 sends various information to server 1002. Server 1002 determines the display data of terminal 1001 based on the stored query mechanism and the received information, and sends the display data to terminal 1001 so that terminal 1001 can display the display data sent by server 1002 to the user.

[0035] In possible application scenarios, different terminals 1001 may be served by different servers 1002. Therefore, in order to distinguish the servers 1002 corresponding to different terminals 1001, the embodiments of this application will use the first and second methods for description. In fact, the servers 1002 corresponding to different terminals 1001 can be the same server 1002.

[0036] Furthermore, when the heating dispatch system 1000 includes multiple terminals, multiple servers, and multiple networks, different terminals can connect to each other through different networks and different servers. The network can be a wireless network or a wired network; for example, the wireless network could be a wireless local area network (WLAN). WLAN ),local area network( LAN ), cellular network, 2 G Network, 3 G Network, 4 G Network, 5G G Networks, etc. Additionally, different terminals can connect to other terminals or servers using their own Bluetooth networks or hotspot networks. Furthermore, the system 100 can include multiple databases, each coupled to different servers.

[0037] like Figure 2 As shown, the intelligent heating dispatch system 1000 adopts a layered architecture, which may include at least a business layer 10, a cluster layer 20, and a device layer 30.

[0038] The business layer 10 is the upper-layer architecture of the system, which includes at least the heating cloud platform. The business layer 10 is mainly used to store heating scheduling plans and related configuration information, and to trigger the generation of heating scheduling instructions based on scheduling needs. The business layer 10 can receive cluster status information reported by the cluster layer 20 via UDP multicast, automatically trigger task resharding processing based on the cluster status, and broadcast the resharding results to all service nodes in the cluster layer 20. Simultaneously, the business layer 10 is also used to distribute task sharding results and control instructions to specified service nodes in the cluster layer 20.

[0039] The cluster layer 20 is located between the service layer 10 and the device layer 30, and includes at least a scheduling center node and an edge gateway node. The scheduling center node and the edge gateway node can automatically discover and build a communication cluster through a self-assembly clustering protocol. The cluster layer 20 is used to receive task fragmentation and heating scheduling instructions from the service layer 10, and execute corresponding scheduling operations according to the heating scheduling instructions, while forwarding the heating scheduling instructions to the corresponding device layer 30.

[0040] Device layer 30 is the lowest execution unit of the system, used to receive heating scheduling instructions from the edge gateway or host computer in cluster layer 20, and execute corresponding heating adjustment actions according to the heating scheduling instructions to complete the heating scheduling process.

[0041] It should be noted that, Figure 1 and Figure 2 The schematic diagram of the heating dispatch system 1000 shown is merely an example. The heating dispatch system 1000 described in this application embodiment is intended to more clearly illustrate the technical solutions of this application embodiment and does not constitute a limitation on the technical solutions provided in this application embodiment. As those skilled in the art will know, with the evolution of heating dispatch systems and the emergence of new business scenarios, the technical solutions provided in this application embodiment are also applicable to similar technical problems.

[0042] The technical solution of this application will be described in detail below through specific embodiments. It should be noted that the following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0043] Please see Figure 3 , Figure 3 This is a flowchart illustrating a heating scheduling method provided in an embodiment of this application. It should be noted that the steps shown may be executed in a logical order different from that shown in the flowchart. The method may include the following steps: Step 110: Based on the middleware-free self-organizing cluster protocol, construct a scheduling cluster consisting of multiple service nodes.

[0044] Among them, the self-organizing cluster protocol is a communication and collaboration protocol in which distributed nodes, without central control, can automatically complete neighbor discovery, topology construction, node joining / leaving, fault detection, role election and task collaboration through agreed communication rules and negotiation mechanisms, thereby quickly forming a stable, self-healing and scalable autonomous cluster and providing unified services to the outside world.

[0045] For example, self-assembling cluster protocols can be, but are not limited to, routing protocols based on ad-hoc networks (such as on-demand routing protocols, link-state routing protocols, dynamic source routing protocols, destination sequence distance vector routing protocols), JGroups protocols, or other self-assembling cluster protocols (such as MAVLink, DDS (Data Distribution Service), Wi-Fi Mesh, etc.).

[0046] In this embodiment, the self-organizing cluster protocol can be the JGroups protocol. That is, a scheduling cluster consisting of multiple service nodes is built using the JGroups protocol. Service nodes can automatically discover and maintain membership relationships via multicast (UDP) or point-to-point (TCP) without deploying any external middleware. In essence, the JGroups protocol is an open-source Java reliable group communication toolkit. Its core functionality is to achieve self-organizing cluster building, member management, reliable message passing (unicast / multicast), fault detection, and self-healing for distributed nodes through a flexibly configurable layered protocol stack. This provides distributed systems with decentralized, scalable, and highly available underlying communication and cluster collaboration capabilities (jgroups.org).

[0047] Service nodes can include dispatch center nodes deployed in the cloud and / or edge gateway nodes deployed in the heating area. Among them, dispatch center nodes refer to high-computing-power service nodes deployed in the heating dispatch center, which are responsible for global policy calculation, regional collaborative scheduling, and big data analysis; edge gateway nodes refer to lightweight service nodes deployed at heat exchange stations, buildings, or units, which are responsible for local device access, real-time data acquisition, edge policy execution, and rapid fault response.

[0048] The scheduling center node and edge gateway node can automatically build a scheduling cluster through the JGroups TCP / UDP protocol. The overall construction process can be divided into three stages: edge gateway self-organizing network, scheduling center cluster construction, and full network cluster integration.

[0049] During the self-organizing phase of the edge gateway, after the heat exchanger station's edge gateway is powered on, it automatically starts the JGroups channel, loads the UDP protocol stack configuration, and sends node probe packets via the UDP multicast address 228.8.8.8. Other gateways in the same area automatically respond and complete node discovery. Local edge sub-clusters can be quickly built without manual configuration of IP lists, and member information is synchronized in real time, flexibly adapting to scenarios such as adding or relocating heat exchangers. Thus, no manual configuration of IP lists is required, adapting to heat exchanger addition / relocation scenarios.

[0050] During the cluster construction phase of the scheduling center, when a scheduling node starts, it loads the tcp.xml configuration (built-in TCP protocol stack configuration: initial-hosts contains the pre-configured IPs of several core scheduling nodes). Each scheduling node first attempts to connect to the nodes in initial-hosts. JGroups' GMS protocol automatically elects a coordinator—the first node to successfully connect and survive becomes the master node. Subsequent scheduling nodes only need to connect to the coordinator to automatically join the scheduling center cluster. In this way, single points of failure can be avoided when deploying across data centers, and dynamic scaling can be supported.

[0051] During the network-wide cluster integration phase, the scheduling center node proactively initiates TCP connection requests to the "seed nodes" of each regional edge sub-cluster. JGroups automatically detects and merges all sub-cluster member views through the MERGE3 protocol, ultimately forming a unified logical scheduling cluster covering 3 scheduling nodes and 200 edge gateways.

[0052] In addition, the JGroups protocol also includes a simplified protocol stack, which includes a UDP protocol for member discovery, an FD_SOCK protocol for fault detection, and a VERIFY_SUSPECT protocol for member authentication. Edge gateway nodes run the simplified JGroups protocol stack in resource-constrained environments.

[0053] For example, for ARM Cortex The heat exchange station gateway hardware, with its low configuration (A7, 256MB memory, etc.), only loads a simplified JGroups protocol stack consisting of UDP, FD_SOCK, and VERIFY_SUSPECT. The memory usage is less than 15MB, and the peak CPU usage is less than 10%, meeting the requirements for stable operation of embedded devices.

[0054] Thus, by using the JGroups protocol to build a scheduling cluster consisting of multiple service nodes, decentralized automatic node discovery, member maintenance, and fault self-healing can be achieved without relying on external middleware. It supports flexible networking of UDP multicast and TCP point-to-point and can adapt to different deployment environments of edge gateways and scheduling centers. At the same time, it has the characteristics of customizable protocol stack and low resource consumption, which can meet the operating requirements of resource-constrained terminals. This enables the scheduling cluster to have the technical effects of networking upon power-on, dynamic expansion, weak network self-healing, high availability, and low overhead, providing stable and reliable distributed scheduling support for heating systems.

[0055] Step 120: Divide the heating equipment resources into multiple logical shards and allocate them to each service node in the scheduling cluster.

[0056] The heating equipment resources include heating terminals (heat exchange stations, temperature control valves, heat meters), heat exchange station controllers, room temperature data acquisition devices, and other heating equipment. These resources can range from tens of thousands to hundreds of thousands of heating devices, with no specific quantity limit. For example, heating equipment resources could include 50 temperature control valves in area A of the heat exchange station, 32 heat meters in area B, and 18 room temperature data acquisition devices in area C.

[0057] Logical sharding refers to the virtual partitioning of nodes within a unified cluster without changing the physical nodes and network topology, using only software rules to form multiple independently managed and scheduled logical units, thereby improving system efficiency and achieving load balancing and fault isolation.

[0058] The system can logically divide the entire network's heating equipment resources into multiple independent logical segments according to a preset allocation strategy. Each logical segment corresponds to a set of heat exchange station gateways and related heating terminals. These logical segments are then assigned to different service nodes in the scheduling cluster for segmented management and scheduling. This allows each service node to be responsible only for collecting equipment status, calculating load, and issuing commands within its corresponding segment, achieving distributed parallel scheduling, load balancing, and fault isolation, thereby improving the overall system processing capacity and stability. For example, the system can logically divide the entire network's heating equipment resources into multiple independent logical segments based on dimensions such as heating area, heat load distribution, pipeline topology, and terminal location.

[0059] Please see Figure 4Optionally, step 120 can be implemented by steps 121-124, specifically as follows: Step 121: Based on the identifier mapping rules, establish the correspondence between each heating device and the logical segment; In this context, the identifier mapping rule refers to the rule that maps the identifiers of heating equipment to a digital area space. The identifier mapping rule can be a preset mapping rule based on, but is not limited to, the heating equipment's number, area code, pipeline topology, installation location, or heat load attributes. For example, an identifier mapping rule can be set based on the heating equipment's device ID.

[0060] Identifier mapping rules may include hash mapping rules, range mapping rules, etc.; among them, hash mapping rules refer to mapping device IDs to a fixed integer space through a hash function, and range mapping rules refer to mapping heating device IDs to a fixed integer space according to a numerical range.

[0061] Based on the identifier mapping rules, each heating device is uniquely identified and classified for matching, and a stable correspondence between each heating device and its corresponding logical segment is automatically established. Understandably, through this mapping relationship, the system can quickly locate the logical segment to which any heating device belongs, and accurately route tasks such as device status acquisition, data processing, and scheduling command issuance to the service node that manages the segment, thereby realizing segmented management, distributed scheduling, and load balancing of devices, and improving system scheduling efficiency and reliability.

[0062] Please see Figure 5 Optionally, the identifier mapping rule may include a hash mapping rule, and step 121 may be implemented by steps 1211 and 1212, specifically as follows: Step 1211: Map the identification code of each heating device to a continuous integer space using a hash function; For example, assign a unique ID (e.g., HEAT_STATION_00123) to the heating equipment in each heating area and map the heating equipment in each heating area to a continuous integer range (e.g., 0-9999) by ID hash.

[0063] Step 1212: Divide the continuous integer space into multiple integer intervals, and define each integer interval as a logical slice.

[0064] For example, if the continuous integer space is 0-9999, it can be divided into 100 intervals, each interval corresponding to a logical shard (0-99, 100-199...9900-9999). Each interval constitutes a logical shard, corresponding to a unique service node; the number of shards is dynamically adapted to the number of cluster nodes.

[0065] Step 122: According to the preset allocation strategy, allocate each logical shard to each currently active service node.

[0066] Among them, the preset allocation strategy refers to the allocation strategy set in the system in advance. The preset allocation strategy may include, but is not limited to, load balancing allocation strategy, node capacity allocation strategy, hot composite feature allocation strategy, regional allocation strategy or equal distribution strategy.

[0067] Currently active service nodes refer to all service nodes that have now been successfully added to the scheduling cluster, are online, are working, are not experiencing any faults, and are not offline. Online gateway nodes can be detected and confirmed in real time through the JGroups cluster protocol.

[0068] Please see Figure 6 Optionally, the preset allocation strategy includes an equal distribution strategy, and step 122 can be implemented by step 1221, specifically as follows: Step 1221: Distribute each logical shard equally to each service node based on the number of currently active service nodes.

[0069] For example, when a cluster of 5 nodes corresponds to 10,000 logical shards, node A gets 2,000, node B gets 2,000, node C gets 2,000, node D gets 2,000.

[0070] Additionally, it's worth noting that if the distribution cannot be even, the remainder will be rounded up. For example, if there are currently 3 active service nodes corresponding to 10,000 logical shards, node A will receive 3,334, node B will receive 3,333, and node C will receive 3,333.

[0071] It should also be noted that the allocation results can be broadcast to all service nodes via the JGroups cluster, and each service node caches the sharding mapping table locally. Therefore, after caching the sharding mapping table locally, each service node can respond to device command routing requests in real time without needing to query across nodes.

[0072] In this way, by evenly distributing logical shards to each service node, instruction routing latency can be significantly reduced. At the same time, combined with the JGroups multicast synchronization mechanism, it is ensured that shard mapping changes are globally consistent within milliseconds, avoiding instruction missending or loss due to inconsistent caching, and improving the real-time response of the system and the accuracy of instruction execution.

[0073] Step 123: Obtain the real-time load status of each service node; The system can maintain a list of active service nodes in real time or periodically through the JGroups protocol, and each service node can actively report its real-time load status information according to a preset period, so that the system can obtain the actual load status of each service node.

[0074] Real-time load status includes, but is not limited to, at least one of CPU utilization, memory utilization, network latency, and task backlog.

[0075] In one example, the service node collects CPU utilization, network latency, and task backlog every 5 seconds and reports them to the system.

[0076] Step 124: Dynamically adjust the correspondence between logical shards and currently active service nodes based on real-time load status.

[0077] Specifically, based on the real-time load status of each service node collected by the scheduling cluster, the system can continuously monitor the operating pressure of each node through preset load balancing thresholds and business awareness algorithms: when the load of a service node exceeds the threshold or an overload warning occurs, the logical sharding dynamic adjustment process is automatically triggered to migrate some logical shards hosted by the service node (prioritizing shards with lower loads or shards geographically adjacent to other nodes) to the currently active service node with lower load.

[0078] Furthermore, when a new service node is added to the scheduling cluster or a faulty node recovers and comes back online, the system will split some logical shards from other high-load nodes and allocate them to the new nodes according to the load replacement principle, and re-optimize the number and distribution of shards hosted by each node.

[0079] It is worth noting that the adjustment process strictly adheres to the business rule that equipment belonging to the same heat exchange station should not be split across nodes, ensuring the continuity of regional management and the consistency of scheduling instructions. Ultimately, this achieves dynamic load balancing of each service node, avoiding scheduling delays or system failures caused by single-point overload, and improving the overall processing capacity and stability of the cluster.

[0080] In addition, the results of shard redistribution are broadcast to all service nodes in the cluster through the cluster communication mechanism, so that each service node can update the mapping relationship between the shards and nodes in its local cache.

[0081] Please see Figure 7 Preferably, step 124 can be implemented by step 1241, specifically as follows: Step 1241: Determine whether there is a load imbalance based on the real-time load status of each service node; For example, when the load on a service node exceeds a threshold (such as CPU utilization ≥80% or memory usage ≥75%) or an overload warning is issued, it is determined that there is a load imbalance.

[0082] Step 1242: When there is a load imbalance, at least a portion of the logical shards that are handled by the high-load node whose load status meets the first preset condition are redistributed to the low-load node whose load status meets the second preset condition.

[0083] For example, the first preset condition is CPU ≥ 80% or memory ≥ 75%, and the second preset condition is CPU ≤ 30% and memory ≤ 40%. Some logical shards of high-load nodes with CPU ≥ 80% or memory ≥ 75% are migrated to low-load nodes with CPU ≤ 30% and memory ≤ 40%.

[0084] In addition, the allocation results can be broadcast to all nodes through the JGroups cluster, and each node caches the sharding mapping table locally.

[0085] This achieves dynamic balancing of processing pressure among service nodes, avoids overload of individual nodes, and improves the overall stability and scheduling efficiency of the cluster.

[0086] Please see Figure 8 Optionally, after step 124, the heating dispatching method further includes: Step 125: When a service node is detected to be offline or newly added in the scheduling cluster, the fault detection mechanism based on the JGroups protocol triggers a scheduling cluster member change event. The JGroups protocol can include the JGroups FD_SOCK protocol. The FD_SOCK protocol is a fault detection mechanism based on TCP sockets in the JGroups framework. This protocol establishes persistent TCP socket connections between cluster nodes and detects node liveness through heartbeat detection and connection status monitoring. Nodes periodically send heartbeat packets to other nodes in the cluster and listen to the read and write status of socket connections. When a node's heartbeat times out or the socket connection is abnormally disconnected, the FD_SOCK protocol can quickly determine that the node is offline and trigger a cluster fault event. Compared to pure UDP heartbeat detection, FD_SOCK, based on the reliable connection characteristics of TCP, can effectively avoid false faults caused by network jitter and packet loss, thus improving the accuracy and reliability of fault detection.

[0087] For example, based on the JGroups FD_SOCK protocol, if a service node in the scheduling cluster is detected to be disconnected within 3 seconds, a ClusterChangeEvent is triggered.

[0088] The scheduling cluster can detect new service nodes based on the JGroups protocol. After a new node starts up, it actively initiates a join request through multicast or point-to-point methods. Existing service nodes in the scheduling cluster are automatically identified and their legality is verified through the node detection and member management mechanism. The node is then included in the cluster member view and synchronized to all active service nodes, thereby triggering a cluster member change event, thus realizing the automatic discovery and rapid management of new nodes.

[0089] Step 126: In response to the cluster member change event, allocate each logical shard to the currently active service nodes according to the preset allocation strategy.

[0090] For example, after a cluster member change event occurs, the sharding interval is recalculated according to the equal distribution strategy and fine-tuned based on the real-time load of the nodes: if node A goes offline, the shards 0–3,333 originally managed by it will be taken over by nodes B and C according to the equal distribution principle, and then the high-load subsets will be migrated to low-load nodes according to the S23 load fine-tuning rule; the updated sharding mapping table is broadcast synchronously to ensure zero error in instruction routing.

[0091] Thus, when a service node is detected to be offline or newly added in the scheduling cluster, the cluster member change event is triggered in real time through the fault detection mechanism of the JGroups protocol. In response to the event, each logical shard is reallocated to the currently active service node according to the preset allocation strategy. This enables automatic detection of node faults, rapid refresh of cluster members, and dynamic reallocation of logical shards, ensuring that heating scheduling instructions are not interrupted or lost. It effectively improves the high availability, fault self-healing capability, and horizontal scalability of the scheduling cluster, ensuring that the system can still stably and evenly undertake scheduling business in scenarios with dynamic changes in nodes.

[0092] Step 130: Determine the target logical segment to which the target heating equipment belongs based on its identifier; The target heating equipment refers to the heating equipment such as heat exchange stations, temperature control valves, or heat meters to be scheduled in the heating dispatch instruction (heating dispatch task). Each heating dispatch instruction corresponds to a specific target heating equipment. Therefore, each instruction carries the equipment ID of that equipment. The system can only determine which segment and service node should process this instruction by using the equipment ID.

[0093] For example, the system first extracts the unique identifier (device ID) of the target heating device corresponding to the scheduling command, and uses the CRC32 hash algorithm to perform a hash operation on the device ID to generate a long integer hash value, deviceHash. The characteristics of the CRC32 algorithm can ensure that the deviceHash value is evenly distributed in the long integer value space, avoiding uneven partition load caused by concentrated hash values. Subsequently, the partition number partitionId corresponding to the device is calculated by the modulo operation (deviceHash % totalPartitions), where totalPartitions is the total number of logical partitions preset by the system. This achieves a stable and even mapping of each heating device to a logical partition, providing an accurate basis for device affiliation for subsequent partitioned scheduling.

[0094] Step 140: The heating scheduling command is routed to the service node responsible for the target logical segment for execution.

[0095] Among them, heating dispatch instructions are instructions issued by the dispatch cluster or edge gateway to the heating equipment, including but not limited to control instructions, parameter adjustment instructions, status query instructions or execution commands, such as adjusting valve opening, adjusting water supply temperature, starting / stopping equipment, querying operating status, issuing timing strategies, etc.

[0096] Optional, such as Figure 9 As shown, step 140 can be implemented through steps 141 to 142, specifically as follows: Step 141: Based on the locally cached sharding mapping table, obtain the target service node responsible for the target logical sharding; That is, by querying the local sharding mapping table, the service node information where the target logical shard is located can be obtained. The service node information may include the service node's IP address, port number, key, and other information.

[0097] Step 142: Send the heating dispatch instruction to the target service node so that the target service node can execute the instruction issuance.

[0098] The system can send heating scheduling commands to target nodes by calling the command issuance interface. This ensures that commands for the same device are always processed by a fixed node, avoiding concurrent control conflicts across multiple nodes and guaranteeing the atomicity and consistency of command execution.

[0099] For example, the cloud platform issues a "heating command for the western part of the city" → scheduling node B identifies the target segment range (3,334–6,666), and the scheduling command is routed to node B through the cluster layer → node B breaks down the command into specific equipment commands, and executes the local commands through the gateway of its heat exchange station to send them to terminals such as temperature control valves.

[0100] In this way, the target service node responsible for the target logical shard can be quickly located through the sharding mapping table based on local caching, and the heating scheduling instructions can be directly and accurately sent to the corresponding node to execute the instruction, effectively reducing the time spent on scheduling route lookup and the forwarding pressure on the central node, improving task distribution efficiency and response speed, while ensuring the stability and reliability of scheduling routes, and realizing efficient sharding and distributed heating scheduling.

[0101] Please see Figure 10 Optionally, after step 110, the heating regulation method further includes: Step 150: Encrypt the communication data between service nodes in the scheduling cluster using an encryption algorithm.

[0102] Specifically, an encryption layer (such as the SYM_ENCRYPT layer) can be added to the protocol stack of the self-organizing cluster protocol to encrypt the communication data between service nodes in the scheduling cluster using encryption algorithms.

[0103] The encryption algorithm can be the national cryptographic algorithm SM4. Those skilled in the art will understand that the national cryptographic algorithm SM4 refers to the commercial cryptographic algorithm standard issued by the State Cryptography Administration, which has a 128-bit key length and high-efficiency encryption and decryption performance, and is suitable for low-resource environments on the edge. After the encryption layer is embedded with a self-organizing cluster protocol (such as the JGroups protocol stack), all communication content such as cluster signaling, fragment mapping table synchronization, and instruction broadcasting is automatically encrypted. The key is uniformly generated by the scheduling center and distributed through a secure channel to ensure end-to-end confidentiality and integrity.

[0104] Thus, by using encryption algorithms to encrypt the communication data between service nodes in the scheduling cluster, the confidentiality, integrity, and tamper-proof nature of member information, load data, sharding allocation instructions, and scheduling control messages between nodes can be effectively guaranteed during transmission. This prevents data from being illegally stolen, eavesdropped on, or maliciously tampered with, improves the communication security and operational reliability of the heating scheduling system, and meets the secure communication requirements in the industrial Internet of Things scenario.

[0105] Please see Figure 11 Optionally, the heating regulation method also includes: Step 160: When the edge gateway node detects that it is disconnected from the network of the scheduling center node for a period of time exceeding a preset threshold, it switches to local autonomous mode to execute instructions on the managed devices according to the local cached scheduling policy.

[0106] For example, if the edge gateway detects a disconnection from the dispatch center node for more than 5 minutes, it automatically switches to local autonomous mode, caches instructions according to a preset strategy, and performs incremental synchronization after the network is restored, ensuring basic heating safety.

[0107] In this way, control commands can be executed independently on the managed equipment based on the locally cached scheduling strategy when the central dispatch is not in operation. This effectively avoids business interruptions caused by network outages, dispatch center failures, or weak network fluctuations, ensuring the continuous and stable operation of heating equipment and improving system reliability.

[0108] In summary, the heating scheduling method provided in this application constructs a scheduling cluster through a middleware-free self-organizing cluster protocol, eliminating the need for deployment and maintenance of traditional middleware clusters, reducing system complexity and on-site deployment costs, and enabling stable operation under conditions of limited resources and complex environments at the heating site. Furthermore, by logically sharding heating equipment resources and implementing task routing, massive heating scheduling instructions can be evenly distributed to various service nodes for parallel execution, effectively improving the system's ability to handle concurrent access, real-time monitoring, and scheduling instructions for tens of thousands to hundreds of thousands of heating IoT terminals. At the same time, it simplifies the system architecture, improves reliability and scalability, and better adapts to the access and scheduling needs of various heating IoT terminals.

[0109] To facilitate better implementation of the heating dispatching method of this application, this application also provides a heating dispatching device. Please refer to... Figure 12 , Figure 12 This is a schematic diagram of the structure of a heating dispatching device provided in an embodiment of this application. The heating dispatching device 200 can provide a graphical user interface through a terminal device, and the heating dispatching device 200 may include: Cluster building module 210 is used to build a scheduling cluster from multiple service nodes based on a middleware-free self-organizing group communication protocol. The sharding scheduling module 220 is used to divide the heating equipment resources into multiple logical shards for allocation to each service node in the scheduling cluster. Module 230 is used to determine the target logical segment to which the target heating equipment belongs based on the identifier of the target heating equipment; and The execution module 240 is used to route the scheduled task to the service node responsible for the target logical shard for execution.

[0110] Each unit in the aforementioned heating dispatching device can be implemented entirely or partially through software, hardware, or a combination thereof. These units can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each unit.

[0111] The heating dispatching device 200 can be integrated into a terminal or server that has storage and a processor and thus computing capabilities, or the heating dispatching device 200 can be the terminal or server. The heating dispatching device 200 can also be deployed on a heating cloud platform or an edge computing gateway.

[0112] Optionally, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0113] Figure 13 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. The computer device may be a terminal or a server. Figure 13 As shown, the computer device 300 includes a processor 301 with one or more processing cores, a memory 302 with one or more computer-readable storage media, and a computer program stored in the memory 302 and executable on the processor. The processor 301 is electrically connected to the memory 302.

[0114] Those skilled in the art will understand that the computer device structure shown in the figures does not constitute a limitation on the computer device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0115] The processor 301 is the control center of the computer device 300. It connects various parts of the computer device 300 through various interfaces and lines. By running or loading software programs and / or modules stored in the memory 302, and calling data stored in the memory 302, it performs various functions of the computer device 300 and processes data, thereby performing overall processing of the computer device 300.

[0116] In this embodiment, the processor 301 in the computer device 300 loads the instructions corresponding to the processes of one or more computer programs into the memory 302 according to the following steps, and the processor 301 runs the computer programs stored in the memory 302 to realize various functions: Based on a middleware-free self-organizing cluster protocol, a scheduling cluster consisting of multiple service nodes is constructed; heating equipment resources are divided into multiple logical shards and allocated to each service node in the scheduling cluster; the target logical shard is determined according to the identifier of the target heating equipment; and heating scheduling instructions are routed to the service node responsible for the target logical shard for execution.

[0117] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0118] Optional, such as Figure 13 As shown, the computer device 300 also includes: a display screen 303, a radio frequency circuit 304, an audio circuit 305, an input unit 306, and a power supply 307. The processor 301 is electrically connected to the display screen 303, the radio frequency circuit 304, the audio circuit 305, the input unit 306, and the power supply 307. Those skilled in the art will understand that... Figure 13 The computer device structure shown does not constitute a limitation on the computer device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0119] The radio frequency circuit 304 can be used to transmit and receive radio frequency signals to establish wireless communication with network devices or other computer devices, and to transmit and receive signals with network devices or other computer devices.

[0120] Audio circuitry 305 can be used to provide an audio interface between a user and a computer device via a speaker and a microphone. Audio circuitry 305 converts received audio data into electrical signals, transmits them to the speaker, and the speaker converts them into sound signals for output. Conversely, the microphone converts collected sound signals into electrical signals, which are then received by audio circuitry 305, converted back into audio data, and output to processor 301 for processing. The audio data is then transmitted via radio frequency circuitry 304 to, for example, another computer device, or output to memory 302 for further processing. Audio circuitry 305 may also include an earphone jack to facilitate communication between peripheral headphones and the computer device.

[0121] The input unit 306 can be used to receive input numbers, characters, or object feature information (such as fingerprints, irises, facial information, etc.), and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control.

[0122] Power supply 307 is used to supply power to various components of computer device 300. Optionally, power supply 307 can be logically connected to processor 301 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. Power supply 307 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0123] although Figure 13 As not shown in the diagram, computer equipment 300 may also include a camera, sensor, wireless fidelity module, Bluetooth module, etc., which will not be described in detail here.

[0124] This application also provides a computer-readable storage medium for storing a computer program. This computer-readable storage medium can be applied to a computer device, and the computer program causes the computer device to execute the corresponding processes in the heating scheduling method of the embodiments of this application; for brevity, these will not be elaborated further here.

[0125] This application also provides a computer program product including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the heating scheduling method and corresponding processes within the heating scheduling method as described in the embodiments of this application. For simplicity, these details are not elaborated here.

[0126] This application also provides a computer program comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the heating scheduling method and corresponding processes within the heating scheduling method described in this application. For brevity, these details are not elaborated here.

[0127] It should be understood that the processor in this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by software instructions. The processor described above may be a general-purpose processor, a digital signal processor (DSP), or a digital signal processor (DSP). DigitalSignalProcessor , DSP Application-Specific Integrated Circuits (ASICs) ApplicationSpecificIntegratedCircu it , ASIC Ready-made programmable gate arrays (OPGs) FieldProgrammableGateArray , FPGA The processor can be a programmable logic device, discrete gate or transistor logic device, or discrete hardware component. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above methods.

[0128] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory may be a read-only memory (ROM). Read - OnlyMemory , ROM Programmable read-only memory (PROM) ProgrammableROM , PROM Erasable programmable read-only memory (EPROM) ErasablePROM , EPROM Electrically erasable programmable read-only memory (EEPROM) Electrically EPROM , EEPROM ) or flash memory. Volatile memory can be random access memory (RAM) RandomAccessMemory , RAM It is used as an external cache. Many forms of this are illustrated, but not limited to, descriptions. RAM Available, for example, static random access memory (SRAM) StaticRAM , SRAM Dynamic Random Access Memory (DRAM) DynamicRAM , DRAM Synchronous Dynamic Random Access Memory (SDRAM) SynchronousDRAM , SDRAM Double Data Rate Synchronous Dynamic Random Access Memory (DRAM) DoubleDataRateSDRAM , DDR SDRAM Enhanced Synchronous Dynamic Random Access Memory (ESR) Enhanced SDRAM , ESDRAM Synchronous Link Dynamic Random Access Memory (SRAM) Synchlink DRAM , SLDRAM ) and Direct Memory Bus Random Access Memory (DRAM) DirectRambusRAM , DRRAM It should be noted that the memory of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0129] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0130] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0131] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0132] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0133] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0134] In addition, the functional units in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0135] 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 application, in essence, 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 or a server) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes: U disk, external hard drive, ROM , RAM Various media that can store program code, such as magnetic disks or optical discs.

[0136] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A heating dispatching method, characterized in that, include: Based on a middleware-free self-organizing cluster protocol, a scheduling cluster consisting of multiple service nodes is constructed. The heating equipment resources are divided into multiple logical shards and allocated to each service node in the scheduling cluster. Determine the target logical segment to which the target heating equipment belongs based on its identifier; and The heating scheduling command is routed to the service node responsible for the target logical segment for execution.

2. The method according to claim 1, characterized in that, The self-organizing cluster protocol is the JGroups protocol; the service nodes include a scheduling center node deployed in the cloud and / or an edge gateway node deployed in the heating area.

3. The method according to claim 1, characterized in that, The step of dividing the heating equipment resources into multiple logical shards for allocation to each service node in the scheduling cluster includes: Based on the identifier mapping rules, establish the correspondence between each heating device and the logical segment; According to the preset allocation strategy, each logical shard is allocated to each currently active service node; Obtain the real-time load status of each of the service nodes, wherein the real-time load status includes at least one of CPU utilization, memory utilization, network latency, and task backlog. Based on the real-time load status, the correspondence between the logical shards and the currently active service nodes is dynamically adjusted.

4. The method according to claim 3, characterized in that, The identifier mapping rule includes a hash mapping rule, and the establishment of the correspondence between each heating device and the logical segment includes: The identification codes of each heating device are mapped to a continuous integer space using a hash function; The continuous integer space is divided into multiple integer intervals, and each integer interval is defined as a logical slice.

5. The method according to claim 3, characterized in that, The preset allocation strategy includes an equal distribution strategy, wherein the initial allocation of each logical shard to each currently active service node includes: Based on the number of currently active service nodes, each logical shard is evenly distributed to each service node.

6. The method according to claim 3, characterized in that, The step of dynamically adjusting the correspondence between the logical shards and the currently active service nodes based on the real-time load status includes: Based on the real-time load status of each service node, determine whether there is a load imbalance; When there is a load imbalance, at least a portion of the logical shards handled by the high-load node whose load status meets the first preset condition are redistributed to the low-load node whose load status meets the second preset condition.

7. The method according to claim 3, characterized in that, Also includes: When a service node is detected to be offline or newly added in the scheduling cluster, the fault detection mechanism based on the JGroups protocol triggers a member change event in the scheduling cluster. In response to the cluster member change event, each logical shard is allocated to the currently active service nodes according to the preset allocation strategy.

8. The method according to claim 1, characterized in that, The step of routing the heating scheduling command to the service node responsible for the target logical shard for execution includes: Based on the local cached sharding mapping table, obtain the target service node responsible for the target logical shard; The heating scheduling command is sent to the target service node, so that the target service node can execute the command issuance.

9. The method according to claim 1, characterized in that, The method further includes: An encryption algorithm is used to encrypt the communication data between service nodes in the scheduling cluster.

10. The method according to claim 1, characterized in that, The method further includes: When an edge gateway node detects a network disconnection from the scheduling center node for a duration exceeding a preset threshold, it switches to local autonomous mode to execute instructions on the managed devices based on the locally cached scheduling policy.

11. A heating dispatching device, characterized in that, include: The cluster building module is used to build a scheduling cluster consisting of multiple service nodes based on a middleware-free self-organizing cluster protocol. The sharding scheduling module is used to divide heating equipment resources into multiple logical shards for allocation to each service node in the scheduling cluster. The determination module is used to determine the target logical segment to which the target heating equipment belongs based on the identifier of the target heating equipment. and The execution module is used to route heating scheduling instructions to the service node responsible for the target logical segment for execution.

12. A computer device, characterized in that, The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the heating scheduling method according to any one of claims 1 to 10.

13. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the heating scheduling method as described in any one of claims 1 to 10.

Images