A cluster management method and device of a spaceflight measurement control system

Abstract

The application provides a kind of cluster management method and device of spaceflight measurement control system, method includes: using multi-thread parallel connection mode has established the connection relationship with Redis cluster, effectively reduce the time delay of cluster management software recovery service when Redis cluster restarts;Realize the competition write-in mechanism of slave priority, effectively avoid the problem of multiple main coexistence of business software, further improve system reliability;Design and implement the passivation cluster management strategy of state reservation, when Redis-Server fails to migrate, cluster agent software can retain business software master-slave state and cluster state, after switching is completed, can write back the original state, effectively solve the problem of frequent switching of business software master-slave state, while avoiding to delete the normal node by mistake as invalid node, thereby causing the problem of frequent change of cluster state occurs, greatly improve the stability and reliability of ground measurement control system software.

Description

Technical Field

[0001] This invention relates to the field of aerospace telemetry and control technology, particularly to the field of artificial intelligence technology, and especially to a cluster management method and device for an aerospace telemetry and control system. Background Technology

[0002] With the continuous development of aerospace technology, the volume of mission data and telemetry, tracking, and command (TT&C) operations has increased dramatically. Distributed clustered architectures have flourished and are widely used in the aerospace TT&C field, making highly reliable cluster management systems increasingly important. The existing cluster management system of the ground flight control center uses Redis as its technical foundation. Cluster agent software writes the master-slave information and cluster information of each distributed clustered architecture software into the Redis database, thus completing the system's cluster management. When the Redis cluster is working normally, this method can effectively support the status management of each cluster in the ground flight control center of the aerospace TT&C system. However, when the cluster agent software needs to re-establish a connection with the Redis cluster (e.g., when restarting the Redis cluster or the cluster agent software), there may be a delay in the cluster agent software's service recovery. When the Redis-Server master node fails, leading to Redis failure migration, it may induce master-slave switching of business software, multi-master coexistence issues, and frequent changes in cluster status. Summary of the Invention

[0003] One objective of this invention is to provide a cluster management method for an aerospace telemetry, tracking, and command (TT&C) system, effectively reducing the latency of cluster management software service recovery when a Redis cluster restarts, and greatly improving the reliability and anomaly response capability of the ground flight control center software system. It implements a slave-first contention write mechanism, effectively avoiding the multi-master coexistence problem of business software due to Redis server failure migration, further improving the stability and reliability of the ground TT&C system software. Another objective of this invention is to provide a cluster management device for an aerospace TT&C system. A further objective of this invention is to provide a computer-readable medium. A final objective of this invention is to provide a computer device.

[0004] To achieve the above objectives, this invention discloses a cluster management method for an aerospace telemetry, tracking, and command (TT&C) system, comprising:

[0005] In response to a cluster restart event in the aerospace telemetry, tracking, and command system, a communication connection is established with the database cluster server of the ground flight control center through a multi-threaded parallel connection method.

[0006] In response to a failure of the master node of the database cluster server, the master-slave status of the business software is written to the database cluster server according to the master-slave status of the stored business software through the configured slave-first contention write mechanism.

[0007] By implementing a passivated cluster management strategy that preserves state, and following the cluster management mode, the database cluster fault migration is completed based on the server master-slave status, the business software master-slave status, and the business software cluster status.

[0008] Preferably, a communication connection is established with the database cluster server of the ground flight control center through a multi-threaded parallel connection method, including:

[0009] A communication connection request is sent to the sentinel of the database cluster using a multi-threaded parallel connection method;

[0010] Receive the connection result returned by the sentry;

[0011] If the connection result indicates a successful connection, a communication connection is established between the server in the database cluster corresponding to the sentinel.

[0012] Preferably, through a slave-first contention-based write mechanism, the master-slave status of the business software is written to the database cluster server according to the master-slave status of the stored business software, including:

[0013] After the updated server master node is determined, it receives the business software's own process information sent by the business software and writes the business software's own process information into the database cluster server.

[0014] Return the slave node identifier to the business software so that the business software remains a slave node during the current read / write cycle;

[0015] By querying the master-slave status of the business software, the business software in the master node state is identified, and a master node identifier is sent to the business software in the master node state, so that the business software can resume normal service in the next read-write cycle.

[0016] Preferably, the cluster management mode includes master-slave mode;

[0017] By employing a state-preserving passivation cluster management strategy, and following the cluster management mode, based on the server master-slave status, business software master-slave status, and business software cluster status, the database cluster fault migration is completed, including:

[0018] Determine if the server's master-slave status indicates that it is the master node;

[0019] If so, obtain the master node identifier corresponding to the business software in the server master node;

[0020] Determine whether the process information in the master node identifier is consistent with the process information of the business software;

[0021] If so, update the timestamp in the master node identifier;

[0022] If not, the process of determining whether the server is in master-slave status as the master node will be repeated according to the preset timer cycle.

[0023] Preferably, the method further includes:

[0024] If the server is in slave status, determine whether the server is in master status or master status according to the preset time period.

[0025] If so, determine whether the business software in the server master node is the master node based on the master-slave status of the business software.

[0026] If so, update the timestamp in the master node identifier corresponding to the business software in the server master node;

[0027] If not, after waiting for the preset waiting time, repeat the step of determining whether the server master-slave status is that of the master node.

[0028] Preferably, the cluster management mode includes a parallel computing mode;

[0029] By employing a state-preserving passivation cluster management strategy, and following the cluster management mode, based on the server master-slave status, business software master-slave status, and business software cluster status, the database cluster fault migration is completed, including:

[0030] Determine if the server's master-slave status indicates that it is the master node;

[0031] If so, determine whether the current business software node exists in the business software cluster based on the business software cluster status;

[0032] If it exists, write the business software identifier and the current timestamp to the server;

[0033] If it does not exist, add a new business software node in the business software cluster and write the corresponding business software identifier and the current timestamp.

[0034] Get the current timestamps of all business software nodes in the business software cluster;

[0035] Compare the current timestamp of each business software node with the timestamp of the previous access period stored in the database, and filter out abnormal business software nodes with a difference of 0.

[0036] Remove the abnormal business software node from the business software cluster.

[0037] This invention also discloses a cluster management device for an aerospace telemetry, tracking, and command system, comprising:

[0038] The connection establishment unit is used to respond to the cluster restart event of the aerospace telemetry, tracking and command system and establish a communication connection with the database cluster server of the ground flight control center through a multi-threaded parallel connection method.

[0039] The contention write unit is used to respond to the failure of the server master node in the database cluster. Through the set slave-first contention write mechanism, it writes the master-slave status of the business software to the server in the database cluster according to the master-slave status of the stored business software.

[0040] The cluster management unit is used to perform fault migration of the database cluster according to the cluster management mode, based on the server master-slave status, business software master-slave status, and business software cluster status, by using the set state retention passivation cluster management strategy.

[0041] The present invention also discloses a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the method described above.

[0042] The present invention also discloses a computer device, including a memory and a processor, wherein the memory is used to store information including program instructions, and the processor is used to control the execution of the program instructions, wherein the processor executes the program to implement the method described above.

[0043] The present invention also discloses a computer program product, including a computer program / instruction, which, when executed by a processor, implements the method described above.

[0044] This invention designs a high-speed parallel connection model for Redis, establishing a reliable connection with the Redis cluster using a multi-threaded parallel connection method. This effectively reduces the latency of the cluster management software recovering services when the Redis cluster restarts, significantly improving the reliability and anomaly response capabilities of the ground flight control center software system. A slave-first contention write mechanism is implemented, effectively avoiding the multi-master coexistence problem of business software due to Redis-Server failure migration, further enhancing system reliability. A state-preserving passivated cluster management strategy is designed and implemented. When the Redis-Server fails and migrates, the cluster agent software can retain the master-slave state of the business software and the cluster state. After the switchover is complete, the original state can be written back, effectively solving the problem of frequent master-slave state switching of business software after Redis-Server failure migration. It also avoids the problem of mistakenly deleting normal nodes as invalid nodes, thus preventing frequent changes in the cluster state and greatly improving the stability and reliability of the ground measurement and control system software. Attached Figure Description

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

[0046] Figure 1 This is a hierarchical diagram illustrating a cluster management scheme system for handling abnormalities, provided in an embodiment of the present invention.

[0047] Figure 2 This is a schematic diagram illustrating the connection time of a cluster agent software to Sentinel, provided in an embodiment of the present invention.

[0048] Figure 3 This invention provides a schematic diagram of a Redis-Server fault migration state transition.

[0049] Figure 4 This is a schematic diagram of a master-slave mode competitive write provided in an embodiment of the present invention;

[0050] Figure 5 This is a schematic diagram of a parallel computing mode competitive write provided in an embodiment of the present invention;

[0051] Figure 6 A flowchart illustrating a cluster management method for an aerospace telemetry, tracking, and command system provided in this embodiment of the invention;

[0052] Figure 7 A flowchart illustrating another cluster management method for an aerospace telemetry, tracking, and command system provided in this embodiment of the invention;

[0053] Figure 8 A timing diagram of multi-threaded parallel connection to Redis-Sentinel by cluster agent software provided in an embodiment of the present invention;

[0054] Figure 9 A schematic diagram illustrating a slave-first mode contention write operation provided in an embodiment of the present invention;

[0055] Figure 10 A schematic diagram illustrating a cluster management process in a master-slave mode, provided as an embodiment of the present invention;

[0056] Figure 11 A schematic diagram illustrating the state transition of a passivation cluster management strategy in a master-slave mode, provided in an embodiment of the present invention;

[0057] Figure 12A schematic diagram illustrating a cluster management process under a parallel computing mode, provided as an embodiment of the present invention;

[0058] Figure 13 A schematic diagram illustrating the state transition of a passivation cluster management strategy for a parallel computing mode, provided in an embodiment of the present invention;

[0059] Figure 14 This is a schematic diagram of the structure of a cluster management device for an aerospace telemetry, tracking, and command system provided in an embodiment of the present invention;

[0060] Figure 15 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0061] The technical solutions of the embodiments 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, and 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.

[0062] It should be noted that the cluster management method and device for aerospace telemetry, tracking, and command system disclosed in this application can be used in the field of artificial intelligence technology, or in any field other than artificial intelligence technology. The application field of the cluster management method and device for aerospace telemetry, tracking, and command system disclosed in this application is not limited.

[0063] To facilitate understanding of the technical solution provided in this application, the relevant content of the technical solution will be explained below. With the continuous development of aerospace technology, major aerospace missions, such as manned spaceflight, lunar exploration, and deep space exploration, are being carried out one after another, resulting in a surge in mission data volume and telemetry, tracking, and command (TT&C) workload. Distributed clustered architectures have flourished and been widely applied in the aerospace TT&C field. Many key core business software applications in ground flight control centers, such as data distribution, telemetry processing, display and control support, and orbit calculation, have adopted distributed clustered architectures. Therefore, the importance of highly reliable cluster management systems in the aerospace TT&C field is becoming increasingly prominent.

[0064] Remote Dictionary Server (Redis) is a completely open-source, free, high-performance distributed in-memory database based on key-value pairs. It runs in memory and supports data persistence. Redis supports multiple data types, and due to its in-memory nature, it provides high-speed data read and write, making it suitable for high-concurrency applications. The ground flight control center chose Redis as its technical foundation, using cluster agent software to write the master-slave information and cluster information of each distributed clustered architecture software into the Redis database, thus completing the system's cluster management. The specific implementation solution is described below.

[0065] The first step, employed by the Aerospace Measurement and Control Ground Flight Control Center, utilizes a typical Redis cluster application scenario—the Sentinel mode—to ensure the reliability of the in-memory database. The configuration consists of one master and two slave Redis servers. The master server supports read and write operations, while the slave servers only support data retrieval. Slave nodes periodically replicate data from the master node to maintain synchronization. Three Redis Sentinels are run for status monitoring. If the master server fails, the three Sentinels can determine that the master node is objectively offline through a voting mechanism and automatically elect one of the slave nodes in the cluster to become the new master through an election mechanism. They then use a publish-subscribe pattern to notify other slave nodes in the cluster to modify their configurations, thus ensuring the high availability of the Redis system. This process is called Redis failover.

[0066] The second step is to develop cluster agent software, which is deployed alongside the business software to provide periodic read / write services for master-slave or cluster information. After starting, the agent software connects to Redis-Sentinel sequentially according to its configuration information. If a connection fails, it continues to connect to the next Sentinel until a connection is successful; otherwise, it exits with an error. Once a successful connection to Redis-Sentinel is established, it connects to the master server through that Sentinel, thus enabling periodic data read / write operations.

[0067] Currently, the software clusters used by ground flight control centers for management primarily operate in two modes: one is the master-slave mode, where the in-memory database stores master node information in key-value pairs, with the key storing the cluster identifier and the value storing the node identifier (format: process identifier + timestamp); the other is the parallel computing mode, where the in-memory database stores all valid node information in key-value pairs without distinguishing between master and slave, with the key storing the cluster identifier and the value storing all valid node identifiers as formatted strings (format: process identifier 1 + timestamp 1; process identifier 2 + timestamp 2; process identifier 3 + timestamp 3).

[0068] The existing cluster management solution mainly consists of three layers: business software, cluster agent software, and the underlying Redis cluster. The business software reads and writes master-slave information and cluster information to the Redis cluster through the cluster agent software. The cluster agent software and the Redis cluster jointly provide cluster management services for the business software, with the cluster agent software acting as a bridge for interaction between them. During long-term task execution, we found that when the Redis cluster is functioning normally, this method can effectively support the status management of various clusters in the ground flight control center of the aerospace telemetry and control system. However, when the cluster agent software needs to re-establish its connection with the Redis cluster (e.g., when restarting the Redis cluster or the cluster agent software), there may be a delay in the cluster agent software's service recovery. Furthermore, when the Redis-Server master node fails, leading to Redis fault migration, it may induce master-slave switching, multi-master coexistence issues, and frequent changes in cluster status within the business software. Figure 1 This is a hierarchical diagram illustrating a cluster management scheme system for handling anomalies, as provided in an embodiment of the present invention. Figure 1 As shown, the cluster management solution system includes three layers: business software, cluster agent software, and the underlying Redis cluster. The cluster agent software provides proxy services for the business software, and the business software interacts with the Redis cluster through the cluster agent software. In case of abnormal situations, such as Redis connection failure or Redis cluster failure, the cluster agent software needs to re-establish the connection with the Redis cluster and perform fault migration. In this process, there are the following two technical problems.

[0069] Figure 2 This is a schematic diagram illustrating the connection time of a cluster agent software to Sentinel provided in an embodiment of the present invention, as shown below. Figure 2As shown, when the Redis cluster deployment server is restarted, or the cluster agent software is restarted, the cluster agent software needs to re-establish a connection with the Redis cluster. At this time, the cluster agent software selects the first Sentinel connection configuration from the initialization configuration file and attempts to connect. When the connection fails, the cluster agent software sequentially selects the next Sentinel connection configuration according to the configuration file and attempts to connect until a successful connection is established with the master node. During this process, it cannot provide read / write services for cluster information to the business software. Under the conditions of a Redis cluster deployed on a hardware server with a CPU frequency of 3.10GHz, 144 cores, and 512GB of memory, and a 10 Gigabit LAN, testing revealed that: when the cluster agent software successfully connects to Redis-Sentinel, the time from connection start to successful return is less than 1 millisecond; when the cluster agent software fails to connect to Redis-Sentinel, the time from connection start to failure is approximately 1.6 seconds. With three Redis-Sentinels deployed, in an extreme case, the cluster agent software attempted to connect to two invalid addresses before finally connecting to an available Sentinel, a process that took approximately 3.2 seconds. This resulted in the cluster agent software service taking 3.2 seconds to recover. Furthermore, as the Redis cluster itself expanded, the connection speed decreased linearly. This is unacceptable in the aerospace telemetry and control field, where data volume is large, business density is high, and reliability requirements are stringent.

[0070] Figure 3 This invention provides a schematic diagram of a Redis-Server fault migration state transition, as shown in the embodiment of the invention. Figure 3 As shown, during the Redis-Server failure migration period, i.e., from the failure of the master node (T0) to the successful election of a new master node (T0+2000ms), business software cannot write information to the Redis cluster through the cluster agent software. At this time, the cluster agent software can maintain the state before the master node failure and return it to the business software, but the key-value pairs written to Redis have all been deleted due to the "expiration mechanism (default expiration time 300ms)". When the new master node is successfully elected, since there is no relevant key-value information in the Redis database, each business software competes to write to the Redis database through the cluster agent software, causing a large number of master-slave processes to switch masters (multiple masters may occur in a short period), while parallel computing processes obtain an incorrect cluster state for a short time. Assume that the Redis-Server master node failure occurs at T0, the expiration time of key-value pairs in Redis is 300ms, the successful re-election of the Server master node takes 2000 milliseconds, and a single read / write cycle is 50 milliseconds. Under these conditions, the transition relationships between the Server master node state, the key-value pairs in Redis, the cluster agent software state, and the business software state are as follows: Figure 3As shown, the cluster agent software failure occurs within the first read / write cycle after a new master node is successfully elected (from T0+2000ms to T0+2050ms). Specifically: in master-slave mode, the cluster agent software state experiences contention for writing within the first read / write cycle, and the business software state undergoes master-slave switching within the first read / write cycle; in parallel computing mode, the cluster agent software state undergoes sequential writing within the first read / write cycle, and the business software state experiences a failure to acquire incomplete state information within the first read / write cycle. These issues of master-slave switching, multi-master coexistence, and frequent cluster state changes not only needlessly consume system computing resources but also pose a significant threat to the reliability of the ground flight control center software system within the aerospace telemetry and control system.

[0071] The following analysis examines the contention for write operations in master-slave mode. Figure 4 This is a schematic diagram of a master-slave mode contention write provided in an embodiment of the present invention, as shown below. Figure 4 As shown, after the master node election is successful (T1), the Server master node status returns to normal. Because the key-value pairs in a certain cluster within Redis have been deleted due to the expiration mechanism, and multiple business software programs within the same cluster obtain a state of no key-value pairs in Redis through the cluster agent software, each business software program (Business Software 1, Business Software 2, and Business Software 3) sequentially writes its own process information as the master node flag (key-value pair) to the Redis-Server through its respective cluster agent software (Cluster Agent Software 1, Cluster Agent Software 2, and Cluster Agent Software 3). Simultaneously, the cluster agent software returns 1 to the business software (i.e., the local machine is the master node). Under these conditions, the status of all the aforementioned business software programs is set to master, and the key-value pair information in Redis is the key-value pair written by the last business software program within this read / write cycle (from T1 to T1+50ms) (this key-value pair may be different from the value before the Redis fault migration), thus leading to the multi-master anomaly and master-slave switchover issues. During the next read / write cycle (from T1+50ms to T1+100ms), the key-value pairs in Redis for this cluster become valid (the key-value pair status is business software 3 as the master node), and the cluster agent software resumes normal service.

[0072] The following analysis examines the contention-based write process in parallel computing mode. Figure 5 This is a schematic diagram of a parallel computing mode contention write provided in an embodiment of the present invention, as shown below. Figure 5As shown, during the period from the failure of the Redis-Server master node to the successful election of a new master node, the business software cannot write / read information to / from the Redis cluster. During this time, the cluster agent software can maintain the cluster group state before the master node failure and return it to the business software. Once the master node election is successful (T1), the Server master node state returns to normal. In parallel computing mode, each business software (Business Software 1, Business Software 2, and Business Software 3) can write its application software identifier and corresponding timestamp to Redis through its respective cluster agent software (Cluster Agent Software 1, Cluster Agent Software 2, and Cluster Agent Software 3). Simultaneously, it can read the state of its cluster group from Redis. Since the read and write operations of each node are performed independently without temporal order, and Redis uses a single-threaded response processing method, there is a situation where node 3's key-value state (updating timestamp) has not yet been written, while node 2 has already read the cluster group state (1 new, 2 new, and 3 old). At this time, in the cluster group... In the current state, node 3's timestamp is not updated (3 old), which is the same as the timestamp of node 3 in the cluster group state saved by node 2 in the previous period (1 old, 2 old, and 3 old). At this point, node 2 will determine that node 3 is malfunctioning and remove node 3 from the cluster group; similarly, node 3 will also remove itself from the cluster group. In the subsequent process (not shown in the diagram), node 3 writes its application software identifier and corresponding timestamp to Redis, and other nodes re-add node 3 to the cluster group, restoring the cluster group to normal. During this process, the business software node 3 continues to function normally, but the cluster group state has undergone an abnormal change.

[0073] To address the aforementioned technical issues, this invention designs a high-speed parallel connection model for Redis. It establishes a reliable connection with the Redis cluster using a multi-threaded parallel connection method, effectively reducing the latency of the cluster management software recovering services when the Redis cluster restarts. This significantly improves the reliability and anomaly response capabilities of the ground flight control center software system. A slave-first competitive write mechanism is implemented, effectively avoiding the multi-master coexistence problem of business software due to Redis-Server failure migration, further enhancing system reliability. A state-preserving passivated cluster management strategy is designed and implemented. When the Redis-Server fails and migrates, the cluster agent software can retain the master-slave state of the business software and the cluster state. After the switchover is complete, the original state can be written back, effectively solving the problem of frequent master-slave state switching of business software after Redis-Server failure migration. It also avoids the problem of mistakenly deleting normal nodes as invalid nodes, thus preventing frequent changes in the cluster state and greatly improving the stability and reliability of the ground measurement and control system software.

[0074] The following uses a cluster management device of an aerospace telemetry, tracking, and command (TT&C) system as an example to illustrate the implementation process of the cluster management method for an aerospace TT&C system provided in this embodiment of the invention. It is understood that the execution entity of the cluster management method for an aerospace TT&C system provided in this embodiment of the invention includes, but is not limited to, the cluster management device of the aerospace TT&C system.

[0075] Figure 6 A flowchart illustrating a cluster management method for an aerospace telemetry, tracking, and command system provided in this embodiment of the invention is shown below. Figure 6 As shown, the method includes:

[0076] Step 101: In response to the cluster restart event of the aerospace telemetry and control system, establish a communication connection with the server of the database cluster of the ground flight control center through a multi-threaded parallel connection method.

[0077] Step 102: In response to a failure of the master node of the database cluster server, the master-slave status of the business software is written to the database cluster server according to the master-slave status of the stored business software through the set slave priority contention write mechanism.

[0078] In this embodiment of the invention, aerospace telemetry, tracking, and command (TT&C) missions place extremely high demands on the reliability of ground software systems. When a system failure occurs, the software system's response logic malfunctions. In this situation, users generally want to pause program functionality until the fault is repaired. Figure 4 It is known that when a Redis-Server master node fails and triggers a failover, it can lead to multiple master nodes coexisting in business software, which is unacceptable in aerospace telemetry and control systems. For example, if a remote control command to rotate a spacecraft's solar panel by 90 degrees is sent out through the display control cluster, and there are two master nodes in this cluster, the command will be sent twice. Without other fault tolerance mechanisms, the spacecraft's solar panel will rotate 90 degrees twice, leading to a serious failure that does not meet expectations.

[0079] To avoid the above problems, a slave-first contention write mechanism is designed and implemented: When the Redis-Server fails and migrates, the key values ​​of the cluster in the memory database are all deleted due to the expiration mechanism. The key values ​​obtained by the cluster agent software in Redis are invalid. At this time, the business software writes its own process information into Redis as the master node flag through the cluster agent software. At the same time, the cluster agent software returns 0 to the business software (that is, the local machine is the slave node).

[0080] Step 103: By using the set state retention passivation cluster management strategy, and in accordance with the cluster management mode, complete the fault migration of the database cluster based on the server master-slave status, business software master-slave status, and business software cluster status.

[0081] In this embodiment of the invention, the cluster management mode includes master-slave mode or parallel computing mode.

[0082] The technical solution provided in this invention includes a high-speed parallel connection model for Redis, which establishes a reliable connection with the Redis cluster using a multi-threaded parallel connection method. This effectively reduces the latency of the cluster management software in restoring services when the Redis cluster restarts, significantly improving the reliability and anomaly response capabilities of the ground flight control center software system. A slave-first competitive write mechanism is implemented, effectively avoiding the multi-master coexistence problem of business software due to Redis-Server failure migration, further enhancing system reliability. A state-preserving passivated cluster management strategy is designed and implemented. When Redis-Server fails and migrates, the cluster agent software can retain the master-slave state of the business software and the cluster state. After the switchover is complete, the original state can be written back, effectively solving the problem of frequent master-slave state switching of business software after Redis-Server failure migration. It also avoids the problem of mistakenly deleting normal nodes as invalid nodes, thus preventing frequent changes in the cluster state and greatly improving the stability and reliability of the ground measurement and control system software.

[0083] Figure 7 A flowchart of another cluster management method for an aerospace telemetry, tracking, and command system provided in this embodiment of the invention is shown below. Figure 7 As shown, the method includes:

[0084] Step 201: In response to the cluster restart event of the aerospace telemetry and control system, a communication connection request is sent to the Sentinel (Redis-Sentinel) of the database cluster through a multi-threaded parallel connection method.

[0085] In this embodiment of the invention, each step is executed by the cluster management device of the aerospace telemetry, tracking and command system.

[0086] In this embodiment of the invention, cluster restart events include, but are not limited to, restarting the Redis cluster or restarting the cluster agent software.

[0087] In this embodiment of the invention, the original single-threaded processing method of the cluster agent software serially connecting to Sentinel according to the configuration file is modified to multi-threaded parallel connection. Through multiple connection threads, communication connection requests are sent to multiple Sentinels at the same time to attempt to establish communication connections. The number of connection threads is dynamically determined according to the connection configuration of Sentinel in the configuration file.

[0088] Step 202: Receive the connection results returned by Redis-Sentinel. If the connection results include connection success, proceed to step 203; if the connection results all indicate connection failure, the process ends.

[0089] In this embodiment of the invention, each sentinel returns a connection result, which includes connection success or connection failure. If the connection is successful, it indicates that the cluster agent software has successfully established a communication connection with the Redis-Sentinel, and step 203 continues. If each connection fails, it indicates that the cluster agent software has failed to connect with each Redis-Sentinel, and the process ends.

[0090] Step 203: Establish a communication connection between the servers of the database cluster corresponding to the sentinel.

[0091] Figure 8 A timing diagram for multi-threaded parallel connections to Redis-Sentinel, a cluster agent software, provided in an embodiment of the present invention is shown below. Figure 8 As shown, the cluster agent software uses a multi-threaded parallel connection method to simultaneously send communication connection requests to Redis-Sentinel(1), Redis-Sentinel(2), and Redis-Sentinel(3), attempting to establish a communication connection with each Redis-Sentinel. If Redis-Sentinel(3) successfully connects, it immediately returns the successful connection result to the cluster agent software and then terminates the thread, taking less than 1 millisecond. If Redis-Sentinel(1) and Redis-Sentinel(2) fail to connect, they return the failed connection result to the cluster agent software and then terminate the corresponding thread, both taking 1.6 seconds. Therefore, this scheme achieves a successful connection in less than 1 millisecond, increasing the connection speed by more than 3000 times, and the connection speed remains unchanged as the Redis cluster itself expands. The multi-threaded parallel connection method effectively reduces the latency of the cluster management software in restoring services when the Redis cluster restarts, greatly improving the reliability and anomaly response capabilities of the ground flight control center software system.

[0092] Step 204: In response to a failure of the server master node in the database cluster, after the updated server master node is determined, receive the business software's own process information sent by the business software, and write the business software's own process information into the server of the database cluster.

[0093] In this embodiment of the invention, during the first read / write cycle after the server master node is successfully elected and updated, the cluster agent software sequentially writes its own process information as the master node identifier to the Redis-Server.

[0094] It is worth noting that the read / write cycle can be set according to actual needs, and this embodiment of the invention does not limit this. As an option, the read / write cycle is 50ms.

[0095] Step 205: Return the slave node identifier to the business software so that the business software remains a slave node during the current read / write cycle.

[0096] In this embodiment of the invention, the slave node identifier is 0, and the master node identifier is 1. Specifically, the cluster agent software returns 0 to the business software, indicating that the business software is a slave node.

[0097] Step 206: Query the business software whose status is master node through the master-slave status of the business software, and send the master node identifier to the business software whose status is master node, so that the business software can resume normal service in the next read-write cycle.

[0098] In this embodiment of the invention, the cluster agent software stores the master-slave status of the business software and the cluster status. In the next read / write cycle, the master node of the business software is queried through the master-slave status; 1 is returned to the business software, indicating that the business software is the master node, and other business software remain in the slave node state. The key-value pairs of this cluster in Redis-Server are valid in the next read / write cycle.

[0099] Figure 9 This is a schematic diagram of a slave-first mode contention write provided in an embodiment of the present invention, as shown below. Figure 9 As shown, in the first read / write cycle after the successful election of the server master node (T1), i.e., from T1 to T1+50ms, the server master node is normal. Key-value states are deleted due to the expiration mechanism. Business software 1, business software 2, and business software 3 fail to obtain key-values. Based on the priority competition among slaves, they write their own process information as key-values ​​and respond to slave node identifier 0, maintaining their state as business software slave nodes. At this time, the business software has no master node and does not provide service. In the next read / write cycle, i.e., from T1+50ms to T1+100ms, business software 1, business software 2, and business software 3 obtain the key-value of business software 3. Business software 1 and business software 2 respond to slave node identifier 0, maintaining their state as business software slave nodes; business software 3 responds to master node identifier 1, maintaining its state as business software master node, and the business software returns to normal.

[0100] In this embodiment of the invention, the slave-first contention write mechanism effectively avoids the problem of multiple masters coexisting in business software due to Redis-Server failure migration, thereby further improving the reliability of the system.

[0101] Step 207: By using the set state retention passivation cluster management strategy, and in accordance with the cluster management mode, complete the fault migration of the database cluster based on the server master-slave status, the business software master-slave status, and the business software cluster status.

[0102] In this embodiment of the invention, a passivated cluster management strategy with state retention is designed to ensure that when a Redis-Server fails and migrates, the cluster agent software can retain the master-slave state of the business software and the cluster state. Once the switch is complete, the original state can be written back, so as to achieve the purpose of not causing a switch in the state of the business software during the Redis-Server failure migration.

[0103] Figure 10 This is a flowchart illustrating a cluster management process in a master-slave mode, as provided in an embodiment of the present invention. If the cluster management mode is a master-slave mode, step 207 specifically includes:

[0104] Step 2071: Determine if the Redis-Server master-slave status is the master node. If yes, proceed to step 2072; otherwise, proceed to step 2075.

[0105] In this embodiment of the invention, the master-slave status of the Redis-Server is obtained. If it is a Master, it indicates that the Redis-Server is a master node, and step 2072 is executed. If it is a Slave, it indicates that the Redis-Server is a slave node, and step 2075 is executed.

[0106] Furthermore, according to a preset timer period, it is determined whether the server master-slave status is that of the master node, so as to realize the periodic read and write management of the cluster.

[0107] It is worth noting that the timing period can be set according to actual needs, and this embodiment of the invention does not limit it. As an optional solution, the timing period is 50 milliseconds (ms).

[0108] Step 2072: Obtain the master node identifier corresponding to the business software in the server master node.

[0109] In this embodiment of the invention, the value corresponding to the business software key in the Server node is obtained, namely: the master node identifier.

[0110] Step 2073: Determine whether the process information in the master node identifier is consistent with the process information of the business software. If yes, proceed to step 2074; otherwise, proceed to step 2071.

[0111] In this embodiment of the invention, if the process information in the master node identifier is consistent with the process information of the business software, it indicates that the node is not abnormal and step 2074 is executed. If the process information in the master node identifier is inconsistent with the process information of the business software, it indicates that the node is abnormal and step 2071 is executed according to the preset timer control.

[0112] It is worth noting that the timing period can be set according to actual needs, and this embodiment of the invention does not limit it. As an optional solution, the timing period is 50ms.

[0113] Step 2074: Update the timestamp in the master node identifier. This step is now complete.

[0114] Specifically, update the timestamp in the master node identifier to the current time.

[0115] Step 2075: Stop periodic writing and, according to the preset timer period, determine whether the server master-slave status is the master node. If yes, execute step 2076; otherwise, repeat step 2075.

[0116] In this embodiment of the invention, if the master-slave status of the Redis-Server is Slave, periodic writes are stopped, and timer control is performed to obtain the master-slave status of the Redis-Server according to the timer period. It is determined whether the master-slave status of the Redis-Server is the master node. If yes, it indicates that the Redis-Server fault migration is complete, and step 2076 is executed. If no, it indicates that the Redis-Server fault migration is not complete, and step 2075 is executed until the master-slave status of the Redis-Server changes from Slave to Master, that is, from a slave node to a master node.

[0117] It is worth noting that the read / write cycle for periodic writes can be set according to the actual read / write cycle used in the flight control center mission, and this embodiment of the invention does not limit this. As an optional solution, the read / write cycle for periodic writes is 50ms.

[0118] Step 2076: Based on the master-slave status of the business software, determine whether the business software in the server master node is a master node. If yes, proceed to step 2077; otherwise, proceed to step 2078.

[0119] In this embodiment of the invention, based on the master-slave status of the business software, it is determined whether the business software corresponding to the Redis-Server master node is a master node. If it is, the cluster agent software corresponding to the business software master node resumes periodic writing and continues to execute step 2077; if not, it indicates that there is no write permission, normal periodic access is restored, and continues to execute step 2078.

[0120] Step 2077: Update the timestamp in the master node identifier corresponding to the business software in the server master node.

[0121] Specifically, update the timestamp in the master node identifier to the current time.

[0122] Step 2078: Wait for the preset waiting time, and then execute step 2071.

[0123] In this embodiment of the invention, the business software needs to wait for a certain period of time from the cluster agent software corresponding to the node to resume normal periodic access and repeat step 2071.

[0124] It is worth noting that the waiting time can be set according to actual needs, and this embodiment of the invention does not limit this. As an optional solution, the waiting time is 3 timing periods, i.e., 150ms.

[0125] Figure 11 This is a schematic diagram illustrating the state transition of a passivation cluster management strategy in master-slave mode, as provided in an embodiment of the present invention. Figure 11 As shown, time T0 is the moment the Server master node fails. Before time T0, the Server state, key-value state, cluster agent software state, and business software state are all normal. The expiration time of key-values ​​in Redis is 300ms. Before T0+300ms, the key-values ​​are in a valid state. After T0+300ms, the key-values ​​expire and are deleted, and the key-values ​​are in an invalid state. The Server master node re-election takes 2000ms. From T0 to T0+2000ms, the cluster agent software state is in a write failure and hold state, and the business software state is in a hold state. At T0+2000ms, the Server master node re-election is successful, the Server state returns to normal, the key-value state is writeable, the cluster agent software state is master node write and slave nodes wait, and the business software state is in a hold state. After T0+2150ms, the Server state, key-value state, cluster agent software state, and business software state all return to normal.

[0126] In this embodiment of the invention, the cluster agent software retains the original business node state when a Redis-Server failure occurs, and delays the write time of the business software slave nodes after the fault migration is completed, thereby ensuring the priority write of the business software master node. (Comparison) Figure 11 and Figure 4 As can be seen, throughout the entire process from the Redis-Server host working normally, to the occurrence of a fault, host failure, and then recovery, the master-slave state of the business software remains stable. Therefore, this design effectively solves the problem of frequent master-slave state switching of the business software after the Redis-Server fault migration is completed, greatly improving the stability and reliability of the ground measurement and control system software.

[0127] Figure 12This is a flowchart illustrating cluster management in a parallel computing mode according to an embodiment of the present invention. If the cluster management mode is a parallel computing mode, step 207 specifically includes:

[0128] Step 3071: Determine if the server is in master-slave status and is the master node. If yes, proceed to step 3072; otherwise, proceed to step 3078.

[0129] In this embodiment of the invention, the master-slave status of the Redis-Server is obtained. If it is a Master, it indicates that the Redis-Server is a master node, and step 3072 is executed. If it is a Slave, it indicates that the Redis-Server is a slave node, and step 3078 is executed.

[0130] Step 3072: Based on the status of the business software cluster, determine whether the current business software node exists in the business software cluster. If it exists, proceed to step 3073; if it does not exist, proceed to step 3074.

[0131] In this embodiment of the invention, the current business software node is matched with the business software nodes in the stored business software cluster status. If the match is successful, it indicates that the current business software node exists in the business software cluster, and step 3073 is executed. If the match fails, it indicates that the current business software node does not exist in the business software cluster, and step 3074 is executed.

[0132] Step 3073: Write the business software identifier and the current timestamp into the server, and continue to step 3075.

[0133] In this embodiment of the invention, if a current business software node exists in the business software cluster, the business software identifier and the current timestamp of the business software are written into the Redis-Server to indicate that the current node in this cluster is in a normal state.

[0134] Step 3074: Add a new business software node in the business software cluster and write the corresponding business software identifier and the current timestamp.

[0135] In this embodiment of the invention, if the current business software node does not exist in the business software cluster, a new business software node will be added to the business software cluster, and the corresponding business software identifier and the current timestamp will be written to the business software node, and the business software cluster status will be increased by one node compared to before.

[0136] Step 3075: Obtain the current timestamp of all business software nodes in the business software cluster.

[0137] Specifically, the cluster agent software reads the current timestamps of all business software nodes within the cluster from the Redis database.

[0138] Step 3076: Compare the current timestamp of each business software node with the timestamp of the previous access period stored in the database, and filter out abnormal business software nodes with a difference of 0.

[0139] In this embodiment of the invention, if the difference between the current timestamp of a business software node and the timestamp of the previous access period is 0, it indicates that the business software node is an abnormal business software node, and the business software node is determined to be an abnormal business software node; if the difference between the current timestamp of a business software node and the timestamp of the previous access period is not 0, it indicates that the business software node is a normal business software node.

[0140] Step 3077: Remove the abnormal business software node from the business software cluster. This step is now complete.

[0141] Specifically, abnormal business software nodes are removed from the business software cluster of the Redis database. The number of nodes reduced from the previous business software cluster is equal to the number of abnormal business software nodes.

[0142] Step 3078: Stop periodic writing and, according to the preset timer period, determine whether the server master-slave status is the master node. If yes, execute step 3079; otherwise, repeat step 3078.

[0143] In this embodiment of the invention, if the master-slave state of the Redis-Server is Slave, periodic writes are stopped, and the current business software cluster state is returned to the business software. A timer is used for periodic control, and the master-slave state of the Redis-Server is obtained according to the timer period. It is determined whether the master-slave state of the Redis-Server is that of a master node. If yes, it indicates that the Redis-Server fault migration is complete, and step 3079 continues. If no, it indicates that the Redis-Server fault migration is not complete, and step 3078 continues until the master-slave state of the Redis-Server changes from Slave to Master, that is, from a slave node to a master node.

[0144] It is worth noting that the read / write cycle for periodic writes can be set according to the actual read / write cycle used in the flight control center mission, and this embodiment of the invention does not limit this. As an optional solution, the read / write cycle for periodic writes is 50ms.

[0145] Step 3079: Wait for the preset waiting time, and then execute step 3071.

[0146] In this embodiment of the invention, the Redis-Server master node needs to wait for a certain period of time to resume normal periodic read and write operations before continuing to execute step 3071.

[0147] It is worth noting that the waiting time can be set according to actual needs, and this embodiment of the invention does not limit this. As an optional solution, the waiting time is 3 timing periods, i.e., 150ms.

[0148] Figure 13 This is a schematic diagram illustrating the state transition of a passivation cluster management strategy for a parallel computing mode, as provided in an embodiment of the present invention. Figure 13 As shown, time T0 is the moment the Server master node fails. Before time T0, the Server state, key-value state, cluster agent software state, and business software state are all normal. The expiration time of key-values ​​in Redis is 300ms. Before T0+300ms, the key-values ​​are in a valid state. After T0+300ms, the key-values ​​expire and are deleted, and the key-values ​​are in an invalid state. The Server master node re-election takes 2000ms. From T0 to T0+2000ms, the cluster agent software state is in a write failure and hold state, and the business software state is in a hold state. At T0+2000ms, the Server master node re-election is successful, the Server state returns to normal, the key-value state is writeable, the cluster agent software state is in a sequential write and hold state, and the business software state is in a hold state. After T0+2150ms, the Server state, key-value state, cluster agent software state, and business software state all return to normal.

[0149] After the Redis-Server failover is complete, each business application can update its status once via the cluster agent software within one read / write cycle (50ms). Further considering network jitter, each business application can write its identifier and timestamp to Redis within three read / write cycles (150ms), ensuring that the timestamps of all healthy nodes in Redis are updated. During these three read / write cycles, due to the passivation read strategy, the cluster agent software does not read the cluster state from Redis but maintains the original state and returns it to each business application until the information of each healthy node is stably written to Redis. This avoids mistakenly deleting healthy nodes as invalid nodes, which could lead to frequent changes in the cluster state. (Comparison) Figure 13 and Figure 5 It can be seen that the business software cluster remains stable throughout the entire process from the Redis-Server host working normally, to the occurrence of a fault, host failure, and then recovery.

[0150] It is worth noting that the acquisition, storage, use, and processing of data in the technical solution of this application all comply with relevant laws and regulations. The user information in the embodiments of this application was obtained through legal and compliant means, and the acquisition, storage, use, and processing of user information have been authorized and agreed upon by the client.

[0151] It is worth noting that the information collected in this application is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with the relevant laws, regulations and standards of the relevant countries and regions, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding operation portals are provided for users to choose to authorize or refuse.

[0152] It is worth noting that the technical solution provided in this application provides users with a corresponding operation entry point, allowing users to choose to agree to or reject the automated decision-making result; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0153] The technical solution of the cluster management method for aerospace telemetry, tracking, and command (TT&C) systems provided in this invention includes a high-speed parallel connection model for Redis. A reliable connection to the Redis cluster is established using a multi-threaded parallel connection method, effectively reducing the latency of the cluster management software in restoring services when the Redis cluster restarts. This significantly improves the reliability and anomaly response capabilities of the ground flight control center software system. A slave-first competitive write mechanism is implemented, effectively avoiding the multi-master coexistence problem of business software due to Redis-Server failure migration, further enhancing system reliability. A state-preserving passivated cluster management strategy is designed and implemented. When Redis-Server fails and migrates, the cluster agent software can retain the master-slave state of the business software and the cluster state. After the switchover is complete, the original state can be written back, effectively solving the problem of frequent master-slave state switching of business software after Redis-Server failure migration. It also avoids the problem of mistakenly deleting normal nodes as invalid nodes, thus preventing frequent changes in the cluster state and greatly improving the stability and reliability of the ground TT&C system software.

[0154] Figure 14 This is a schematic diagram of a cluster management device for an aerospace telemetry, tracking, and command (TT&C) system, provided in an embodiment of the present invention. This device is used to execute the aforementioned cluster management method for the aerospace TT&C system. Figure 14 As shown, the device includes: a connection establishment unit 11, a contention writing unit 12, and a cluster management unit 13.

[0155] The connection establishment unit 11 is used to establish a communication connection with the database cluster server of the ground flight control center in response to the cluster restart event of the aerospace telemetry and control system through a multi-threaded parallel connection method.

[0156] The contention write unit 12 is used to respond to the failure of the server master node of the database cluster. Through the set slave priority contention write mechanism, it writes the master-slave status of the business software to the server of the database cluster according to the master-slave status of the stored business software.

[0157] The cluster management unit 13 is used to complete the fault migration of the database cluster according to the cluster management mode, based on the server master-slave status, business software master-slave status, and business software cluster status, by using the set state retention passivation cluster management strategy.

[0158] In this embodiment of the invention, the connection establishment unit 11 is specifically used to send a communication connection request to the sentinel of the database cluster through a multi-threaded parallel connection method; receive the connection result returned by the sentinel; and if the connection result includes a successful connection, establish a communication connection between the server of the database cluster corresponding to the sentinel.

[0159] In this embodiment of the invention, the contention writing unit 12 is specifically used to receive the business software's own process information sent by the business software after the updated server master node is determined, and write the business software's own process information into the server of the database cluster; return a slave node identifier to the business software so that the business software's state remains as a slave node in the current read and write cycle; query the business software whose state is a master node through the master-slave state of the business software, and send a master node identifier to the business software whose state is a master node so that the business software can resume normal service in the next read and write cycle.

[0160] In this embodiment of the invention, the cluster management mode includes a master-slave mode; the cluster management unit 13 is specifically used to determine whether the server master-slave status is a master node; if so, obtain the master node identifier corresponding to the business software in the server master node; determine whether the process information in the master node identifier is consistent with the process information of the business software; if so, update the timestamp in the master node identifier; if not, repeat the step of determining whether the server master-slave status is a master node according to a preset time period.

[0161] In this embodiment of the invention, the cluster management unit 13 is specifically used to determine whether the server master-slave status is a master node according to a preset time period if the server master-slave status is a slave node; if yes, determine whether the status of the business software in the server master node is a master node based on the business software master-slave status; if yes, update the timestamp in the master node identifier corresponding to the business software in the server master node; if no, wait for a preset waiting time and then repeat the step of determining whether the server master-slave status is a master node.

[0162] In this embodiment of the invention, the cluster management mode includes a parallel computing mode; the cluster management unit 13 is specifically used to determine whether the server master-slave status is a master node; if so, based on the business software cluster status, determine whether the current business software node exists in the business software cluster; if it exists, write the business software identifier and the current timestamp into the server; if it does not exist, add a new business software node in the business software cluster and write the corresponding business software identifier and the current timestamp; obtain the current timestamps of all business software nodes in the business software cluster; compare the difference between the current timestamp of each business software node and the timestamp of the previous access period stored in the database, and filter out abnormal business software nodes with a difference of 0; delete the abnormal business software nodes from the business software cluster.

[0163] In this embodiment of the invention, a high-speed parallel connection model for Redis is designed. A reliable connection to the Redis cluster is established using a multi-threaded parallel connection method, effectively reducing the latency of the cluster management software in restoring services when the Redis cluster restarts. This significantly improves the reliability and anomaly response capabilities of the ground flight control center software system. A slave-first competitive write mechanism is implemented, effectively avoiding the multi-master coexistence problem of business software due to Redis-Server failure migration, further enhancing system reliability. A state-preserving passivated cluster management strategy is designed and implemented. When Redis-Server fails and migrates, the cluster agent software can retain the master-slave state of the business software and the cluster state. After the switchover is complete, the original state can be written back, effectively solving the problem of frequent master-slave state switching of business software after Redis-Server failure migration. It also avoids the problem of mistakenly deleting normal nodes as invalid nodes, thus preventing frequent changes in the cluster state and greatly improving the stability and reliability of the ground measurement and control system software.

[0164] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer device, specifically, a computer device can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0165] This invention provides a computer device, including a memory and a processor. The memory is used to store information including program instructions, and the processor is used to control the execution of the program instructions. When the program instructions are loaded and executed by the processor, they implement the steps of the above-described embodiment of the cluster management method for aerospace telemetry and control system. For a detailed description, please refer to the above-described embodiment of the cluster management method for aerospace telemetry and control system.

[0166] The following is for reference. Figure 15 It shows a schematic diagram of the structure of a computer device 600 suitable for implementing the embodiments of this application.

[0167] like Figure 15 As shown, the computer device 600 includes a central processing unit (CPU) 601, which can perform various appropriate tasks and processes based on programs stored in read-only memory (ROM) 602 or programs loaded from storage section 608 into random access memory (RAM) 603. The RAM 603 also stores various programs and data required for the operation of the computer device 600. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0168] The following components are connected to I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal feedback (LCD), etc., and speakers, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 610 as needed so that computer programs read from it can be installed in storage section 608 as needed.

[0169] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program tangibly embodied on a machine-readable medium, the computer program including program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611.

[0170] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0171] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0172] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0173] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0174] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0175] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0176] The acquisition, storage, use, and processing of data in this application all comply with the relevant provisions of national laws and regulations.

[0177] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0178] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0179] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0180] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0181] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A cluster management method for an aerospace telemetry, tracking, and command system, characterized in that, The method includes: In response to a cluster restart event in the aerospace telemetry, tracking, and command system, a communication connection is established with the database cluster server of the ground flight control center through a multi-threaded parallel connection method. In response to a failure of the master node of the database cluster, the master-slave status of the business software is written to the server of the database cluster according to the master-slave status of the stored business software through a slave-first competitive write mechanism. By implementing a passivated cluster management strategy that preserves state, and following the cluster management mode, the database cluster fault migration is completed based on the server master-slave status, the business software master-slave status, and the business software cluster status.

2. The cluster management method for aerospace telemetry, tracking, and command system according to claim 1, characterized in that, The process of establishing a communication connection with the database cluster server of the ground flight control center via a multi-threaded parallel connection method includes: A communication connection request is sent to the sentinel of the database cluster using a multi-threaded parallel connection method; Receive the connection result returned by the sentinel; If the connection result includes a successful connection, a communication connection is established between the server of the database cluster corresponding to the sentinel.

3. The cluster management method for aerospace telemetry, tracking, and command system according to claim 1, characterized in that, The step of writing the master-slave status of the business software to the database cluster server through a slave-first competitive write mechanism includes: After the updated server master node is determined, the system receives the business software's own process information sent by the business software and writes the business software's own process information into the server of the database cluster. Return the slave node identifier to the business software so that the business software remains a slave node during the current read / write cycle; By querying the master-slave status of the business software, the business software in the master node state is identified, and a master node identifier is sent to the business software in the master node state, so that the business software can resume normal service in the next read-write cycle.

4. The cluster management method for aerospace telemetry, tracking, and command system according to claim 1, characterized in that, The cluster management mode includes master-slave mode; The passivated cluster management strategy, which preserves the set state, completes the database cluster fault migration according to the cluster management mode, based on the server master-slave status, the business software master-slave status, and the business software cluster status. This includes: Determine whether the server's master-slave status indicates that it is the master node; If so, obtain the master node identifier corresponding to the business software in the server master node; Determine whether the process information in the master node identifier is consistent with the process information of the business software; If so, update the timestamp in the master node identifier; If not, the step of determining whether the server master-slave status is that of the master node is repeated according to the preset time period.

5. The cluster management method for an aerospace telemetry, tracking, and command system according to claim 4, characterized in that, The method further includes: If the server is in a master-slave state and is a slave node, determine whether the server is in a master-slave state and is a master node according to a preset time interval. If so, based on the master-slave status of the business software, determine whether the status of the business software in the server master node is that of the master node; If so, update the timestamp in the master node identifier corresponding to the business software in the server master node; If not, after waiting for the preset waiting time, repeat the step of determining whether the server master-slave status is that of the master node.

6. The cluster management method for an aerospace telemetry, tracking, and command system according to claim 1, characterized in that, The cluster management mode includes a parallel computing mode; The passivated cluster management strategy, which preserves the set state, completes the database cluster fault migration according to the cluster management mode, based on the server master-slave status, the business software master-slave status, and the business software cluster status. This includes: Determine whether the server's master-slave status indicates that it is the master node; If so, determine whether the current business software node exists in the business software cluster based on the business software cluster status; If it exists, write the business software identifier and the current timestamp to the server; If it does not exist, add a new business software node in the business software cluster and write the corresponding business software identifier and the current timestamp. Obtain the current timestamps of all business software nodes within the business software cluster; Compare the current timestamp of each business software node with the timestamp of the previous access period stored in the database, and filter out abnormal business software nodes with a difference of 0. Remove the abnormal business software node from the business software cluster.

7. A cluster management device for an aerospace telemetry, tracking, and command system, characterized in that, The device includes: The connection establishment unit is used to respond to the cluster restart event of the aerospace telemetry, tracking and command system and establish a communication connection with the database cluster server of the ground flight control center through a multi-threaded parallel connection method. The contention write unit is used to respond to the failure of the server master node of the database cluster by writing the master-slave status of the business software to the server of the database cluster according to the master-slave status of the stored business software through a contention write mechanism with slave priority. The cluster management unit is used to perform fault migration of the database cluster according to the cluster management mode, based on the server master-slave status, business software master-slave status, and business software cluster status, by using the set state retention passivation cluster management strategy.

8. A computer-readable medium having a computer program stored thereon, characterized in that, When executed by the processor, the program implements the cluster management method of the aerospace telemetry, tracking and command system as described in any one of claims 1 to 6.

9. A computer device comprising a memory and a processor, the memory for storing information including program instructions, and the processor for controlling the execution of the program instructions, characterized in that, When the program instructions are loaded and executed by the processor, the cluster management method of the aerospace telemetry, tracking and command system according to any one of claims 1 to 6 is implemented.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the cluster management method of the aerospace telemetry, tracking and command system according to any one of claims 1 to 6.

Images