A processing method and processing system for multiple star node distributed consensus

Abstract

The application relates to the technical field of distributed consensus, and discloses a processing method and a processing system for distributed consensus of multiple star nodes. Star nodes in a star node group are divided into leader nodes and follower nodes, and the star nodes comprise a processing system. The processing system comprises an adaptive heartbeat timing unit and a voting collection engine. The processing method comprises the following steps: obtaining a target timeout parameter value of a first star node based on a current window period coefficient of the first star node and a timeout parameter basic value by the adaptive heartbeat timing unit; based on the target timeout parameter value, in the case where the time of an election operation, a heartbeat interval and / or a log replication delay reaches the target timeout parameter value, the first star node is converted from a follower node to a candidate node by the voting collection engine; a term number is not increased, and pre-vote request information is sent to other star nodes in the star node group; and the method can be applied to an inter-star link environment, and can solve the problem of frequent triggering of meaningless leader election in the case of timeout of election, log replication and the like.

Description

Technical Field

[0001] This application relates to the field of distributed consensus technology in satellite constellation environments, specifically to a method and system for processing distributed consensus across multiple satellite nodes. Background Technology

[0002] In the terrestrial data center field, consistent interconnect technologies, represented by Compute Express Link (CXL), have become a core support for the upgrade of heterogeneous computing architectures. Built on the PCIe physical layer, CXL achieves cache-consistent interconnect and memory pooling sharing among CPUs, GPUs, NPUs, FPGAs, and memory expansion devices through three sub-protocols: CXL.io (I / O protocol), CXL.cache (cache consistency protocol), and CXL.mem (memory semantic protocol). CXL 3.0 supports cross-node global address space mapping, dynamic memory allocation, and hardware-level cache consistency maintenance, with bandwidth reaching 128 GB / s (x16) and latency controlled at the nanosecond level, effectively supporting unified scheduling of large-scale heterogeneous resources in AI training, high-performance computing, and cloud infrastructure.

[0003] However, directly applying terrestrial consistent interconnect technology to spaceborne environments faces fundamental adaptation challenges. Spaceborne computing scenarios have the following essential characteristics that distinguish them from terrestrial data centers: Intermittent link connectivity: Inter-satellite links (laser or microwave) are constrained by orbital geometry, resulting in periodic alternations between visible and invisible states. Link windows and silent periods alternate, making it impossible to provide a continuous and stable two-way communication channel. The visible windows of adjacent satellites in the LEO constellation are typically on the order of several minutes to tens of minutes, during which link quality fluctuates drastically.

[0004] Time-varying topology: The constellation topology is not statically configured by humans, but evolves periodically under strict drive from orbital mechanics. The relative positions of satellites, antenna pointing availability, and link budget change in real time with the orbital phase, resulting in continuous dynamic adjustments to the optimal data migration path and consensus topology.

[0005] Traditional consensus protocols like Raft and Paxos are designed based on continuously available low-latency networks in terrestrial data centers. Their core assumptions include: network partitioning is an abnormal state, not a normal one; node failures and link interruptions can be reliably distinguished through fixed timeout mechanisms; and leader election and log replication rely on continuous and stable bidirectional communication. In an inter-satellite link environment, these fundamental assumptions do not hold: the fixed-period heartbeat mechanism misjudges periods of link invisibility as leader node failures, frequently triggering meaningless leader elections and log rollbacks; the majority voting mechanism fails during inter-satellite link window switching due to node unreachability, leading to a sharp decline in system availability; and the acknowledgment-by-acknowledgment and fixed-timeout strategies cannot utilize the limited bandwidth of the link window, with protocol overhead significantly consuming valuable inter-satellite communication resources. Therefore, traditional consensus protocols like Raft and Paxos are difficult to apply in an inter-satellite link environment.

[0006] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0007] To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general commentary, nor is it intended to identify key / important components or describe the scope of protection of these embodiments, but rather as a prelude to the detailed description that follows.

[0008] This disclosure provides a method and system for processing distributed consensus among multiple star nodes, which can be applied to environments where inter-star links are periodically visible and invisible due to orbital geometric constraints. It solves the problem of frequent and meaningless leader elections being triggered under timeout conditions such as election and log replication.

[0009] In some embodiments, a method for processing distributed consensus among multiple star nodes includes at least two star nodes forming a star node group. The star nodes in the group are divided into leader nodes and follower nodes. Each star node includes a processing system, which comprises an adaptive heartbeat timing unit and a voting collection engine. The processing method includes the adaptive heartbeat timing unit: classifying link states based on link visibility, whereby the link states include a stable window period, a window transition period, and a window boundary period; determining the current link state of the first star node based on its orbital ephemeris information; determining the current window period coefficient of the first star node based on its current link state and a preset correspondence between link states and window period coefficients; and obtaining the target timeout parameter value of the first star node based on its current window period coefficient and a base value for timeout parameters. The voting collection engine, based on the target timeout parameter value, if the election operation, heartbeat interval, and / or log replication delay reaches the target timeout parameter value, the first star node changes from a follower node to a candidate node; it does not increment the term number and sends a pre-voting request to other star nodes in the star node group; if it does not receive response information from more than a predetermined number of star nodes, the first star node reverts to a follower node; if it receives response information from more than a predetermined number of star nodes agreeing that the first star node is a candidate node, it increments the term number and enters the election procedure.

[0010] In some embodiments, a distributed consensus processing system for multiple star nodes includes at least two star nodes forming a star node group. The star nodes in the star node group are divided into leader nodes and follower nodes. The processing system is deployed among the star nodes and includes an adaptive heartbeat timing unit and a voting collection engine. The adaptive heartbeat timing unit is configured to: classify link states based on link visibility, whereby the link states include a stable window period, a window transition period, and a window boundary period; determine the current link state of the first star node based on its orbital ephemeris information; determine the current window period coefficient of the first star node based on its current link state and a preset correspondence between link states and window period coefficients; and obtain the target timeout parameter value of the first star node based on its current window period coefficient and a base value for the timeout parameter. The voting collection engine is configured as follows: based on the target timeout parameter value, if the election operation, heartbeat interval, and / or log replication delay reaches the target timeout parameter value, the first star node changes from a follower node to a candidate node; without incrementing the term number, it sends a pre-voting request message to other star nodes in the star node group; if no response message is received from more than a predetermined number of star nodes, the first star node reverts to a follower node; if a response message is received from more than a predetermined number of star nodes agreeing that the first star node is a candidate node, the term number is incremented and the election procedure begins.

[0011] The distributed consensus processing system and method for multiple star nodes provided in this disclosure distinguishes the different link states of the first star node based on its orbital ephemeris information. Different link states correspond to different window period coefficients, thus allowing different link states to correspond to different target timeout parameter values. The voting collection engine determines whether the election operation, heartbeat interval, and / or log replication delay have reached the target timeout parameter value based on the acquired target timeout parameter value. In cases of intermittent link disconnection, star node topology changes, or star node failures, if the target timeout is reached, a pre-voting process is initiated, i.e., a pre-voting request is sent. Based on the connectivity between the first star node and other star nodes, and the review status of the first star node by other star nodes, it is determined whether the first star node receives a response message. If the first star node is isolated from more than a predetermined number of star nodes or fails the review, no response message is received. This reduces the triggering of meaningless elections and reduces the impact of brief link jitter during intermittent link disconnection on the stability of the star node group.

[0012] The above general description and the description below are exemplary and illustrative only and are not intended to limit this application. Attached Figure Description

[0013] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations and drawings do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are shown as similar elements. The drawings are not to be scaled. And wherein: Figure 1 A flowchart illustrating a method for processing distributed consensus among multiple star nodes according to an embodiment of the present disclosure is shown. Figure 2 A schematic diagram illustrating the process of reviewing pre-voting request information according to an embodiment of this disclosure is shown; Figure 3 A flowchart illustrating the calculation of star node weight parameter values ​​according to an embodiment of the present disclosure is shown; Figure 4 A flowchart illustrating the updating of star node weight parameter values ​​according to an embodiment of this disclosure is shown; Figure 5 A flowchart illustrating the triggering of a leadership transfer according to an embodiment of this disclosure is shown; Figure 6 A flowchart illustrating link-based communication quality classification and processing according to embodiments of the present disclosure is provided. Figure 7 A schematic diagram of the structure of a processing system for distributed consensus of multiple star nodes according to an embodiment of the present disclosure is shown. Detailed Implementation

[0014] To provide a more detailed understanding of the features and technical content of the embodiments of this disclosure, the implementation of the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. The accompanying drawings are for illustrative purposes only and are not intended to limit the embodiments of this disclosure. In the following technical description, for ease of explanation, several details are used to provide a full understanding of the disclosed embodiments. However, one or more embodiments may still be implemented without these details. In other cases, well-known structures and devices may be simplified in their depiction to simplify the drawings.

[0015] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this disclosure described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0016] Unless otherwise stated, the term "multiple" means two or more.

[0017] In this embodiment of the disclosure, the character " / " indicates that the objects before and after it are in an "or" relationship. For example, A / B means: A or B.

[0018] The term "and / or" describes an association between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or A and B.

[0019] The term "correspondence" can refer to an association or binding relationship. The correspondence between A and B means that there is an association or binding relationship between A and B.

[0020] This disclosure provides a method for processing distributed consensus among multiple star nodes. At least two star nodes form a star node group, and the star nodes in the group are divided into leader nodes and follower nodes. Each star node includes a processing system, which comprises an adaptive heartbeat timing unit and a voting collection engine. Figure 1 As shown, the processing method includes the following steps by the adaptive heartbeat timing unit: Step 101, dividing the link state according to link visibility, the link state including stable window period, window transition period and window boundary period; Step 102, determining the current link state of the first star node based on the orbital ephemeris information of the first star node; Step 103, determining the current window period coefficient of the first star node based on the current link state of the first star node and the preset correspondence between link state and window period coefficient; Step 104, obtaining the target timeout parameter value of the first star node based on the current window period coefficient of the first star node and the base value of the timeout parameter. According to the voting collection engine: Step 105, based on the target timeout parameter value, if the election operation, heartbeat interval and / or log replication delay reaches the target timeout parameter value, the first star node changes from a follower node to a candidate node; Step 106, without incrementing the term number, a pre-voting request message is sent to other star nodes in the star node group; Step 107, if no response message is received from more than a predetermined number of star nodes, the first star node reverts to a follower node; Step 108, if a response message is received from more than a predetermined number of star nodes agreeing that the first star node is a candidate node, a term number is incremented and the election procedure is initiated.

[0021] In a star node group, the roles of star nodes are divided into leader nodes and follower nodes, with the leader node serving as the distributed consensus manager.

[0022] Each satellite node is equipped with an orbital sensing engine, which includes an ephemeris data receiving interface, a hardware ephemeris resolver, an orbital phase controller, and a power mode control output. The ephemeris data receiving interface receives two lines of element-based or precise ephemeris data via a standard aerospace serial interface. The hardware ephemeris resolver incorporates a simplified orbital mechanics hardware pipeline, including a mean anomaly angle iterative solver, a deflection angle converter, a true anomaly angle calculator, and a coordinate rotator, calculating the satellite's three-dimensional position and velocity vector in the geocentric inertial frame at the current moment. Based on the three-dimensional position and velocity vectors, and combined with broadcast ephemeris data from other satellites in the constellation, the orbital phase controller calculates the geometric visibility, antenna pointing availability, relative distance, and link budget between any two satellites, outputting an inter-satellite link visibility prediction matrix for a preset future time period, and generating an early warning signal indicating the impending closure of the inter-satellite link window, a shadow zone status signal, and a time synchronization signal. The power mode control output outputs control signals for full-speed operation, frequency reduction for energy saving, or emergency hibernation mode based on illumination conditions.

[0023] Therefore, the current link status of the first satellite node can be obtained through orbital ephemeris information. During the stable window period, inter-satellite link quality is good, and the topology is predictable. During the window transition period, the topology is about to change, and link quality may fluctuate. During the window boundary period, the old window is about to close, and the new window has not yet been established. Pre-set corresponding timeout parameter values ​​for the stable window period, window transition period, and window boundary period, and using the current timeout parameter value based on the current link status of the node, can better adapt to changes in orbital topology. This avoids triggering frequent and meaningless leader elections, which would lead to a sharp decline in system availability and significantly consume inter-satellite link bandwidth.

[0024] The election operation time is the time during which follower nodes wait for the leader node to send a heartbeat during the election process. The heartbeat interval is the period after the election ends when the leader node sends heartbeats or log replications to follower nodes. The log replication time is the maximum time follower nodes must wait for the leader node to confirm the log replication. Reaching the specified timeout value for one or more of these parameters allows for a better understanding of the current link status.

[0025] Optionally, the base coefficients for election operations, heartbeat intervals, and / or log replication times can be the same or different, while the target timeout parameter values ​​for these operations can be different. For example, the window period coefficient for election operations might be 1, the window period coefficient for heartbeat intervals might be 0.5-1, and the coefficient for log replication might be 3-5. Alternatively, the base values ​​for the timeout parameters for election operations, heartbeat intervals, and / or log replication times can be the same or different. For example, the base value for the heartbeat interval timeout parameter might be twice the predicted average round-trip time delay; the base value for the election operation and log replication timeout parameters might be twice the predicted maximum round-trip time delay. This better accommodates the latency characteristics of different operations.

[0026] The base value for the timeout parameter can be twice the predicted maximum round-trip delay. The window period coefficients for the stable window period, window transition period, and window boundary period are 1.0 (baseline), 1.5~2.0, and 3.0, respectively. Window period coefficient × base value for timeout parameter = target timeout parameter value. This allows for obtaining timeout parameter values ​​for different window periods, enabling switching between timeout parameter values ​​within different window periods. If the base coefficients for election operations, heartbeat intervals, and / or log replication times are different, then the base coefficient × window period coefficient × base value for timeout parameter = target timeout parameter value.

[0027] Optionally, in this application, the predetermined number of star nodes exceeding a predetermined number can be 50%, 60%, or 70% of the total number of star nodes in the star node group, etc. To prevent excessive jitter in half of the nodes, 60% or 70% can be set.

[0028] The first star node may be changed from a follower node to a candidate node due to poor link status of the normal leader node or a failure of the leader node, requiring a change of leader node. It may also be due to short-term events such as temporary fluctuations in link quality, or the follower node itself moving to a location with poor communication quality. Even with different coefficients depending on the window period, timeouts may occur. The pre-voting request process can eliminate abnormal issues as much as possible and reduce meaningless elections.

[0029] If the pre-voting request does not receive a response from the star node, the following situations may occur: First, the first star node is isolated from more than a predetermined number of star nodes (e.g., the partition initiator is an isolated node). In this case, the pre-voting request sent by the first node cannot reach the predetermined number of star nodes. Since the first star node cannot collect a response within the timeout window, its adaptive heartbeat timing unit is reset, and it waits for the next timeout to retry. Because it has not entered the formal election, the term numbers of other nodes in the cluster are not disturbed, avoiding the "term number inflation" problem in traditional Raft where isolated nodes repeatedly increment their term numbers and cause cluster oscillations after partition recovery. This prevents isolated star nodes from initiating leader elections. Second, the first star node is isolated from a few other star nodes, for example, if the link to the second star node is interrupted. This does not affect the pre-voting judgment; as long as the predetermined number of star nodes' responses are received, the first star node can forward the voting request to a relay node. Therefore, the isolation status of the first star node can be identified through the pre-voting process.

[0030] If the timeout is due to a temporary fluctuation in link quality, such as during window switching, even if the timeout parameter values ​​differ across different window periods, some star nodes may still time out. In this case, they will be converted into candidate nodes and initiate a pre-voting request. Through the pre-election process, other star nodes in the star node group can review the request and determine whether the first star node is suitable to be the leader node. If more than a predetermined number of star nodes agree that the first star node is a candidate node, it will enter the election process. At this point, it means that the first star node has gained the trust of more than a predetermined number of star nodes to become the leader node. If a star node does not gain the trust of more than a predetermined number of star nodes to become the leader node, it will not receive a response and will not enter the election process; the current leader node will continue to be competent.

[0031] If the link quality fluctuates for a long time, the pre-voting request initiated by the first star node may not be received by more than a predetermined number of star nodes, nor will it receive a response. As a result, it will not enter the election and will recover normally through heartbeat information after the fluctuation is resolved.

[0032] This approach ensures the superiority and stability of the leader node while avoiding meaningless leader elections and increasing the term number. Therefore, the pre-voting mechanism can significantly reduce invalid elections caused by brief link jitter, identify the isolation status of star nodes, and greatly improve system stability in scenarios with frequent inter-star link fluctuations and changing orbital topologies.

[0033] like Figure 2As shown, in some embodiments, the pre-voting request information includes the term number and weight information of the first star node, which is collected by the voting engine of the second star node: in step 201, the pre-voting request information is obtained; in step 202, if the term number of the first star node is greater than or equal to the term number of the second star node, and the weight value of the first star node is greater than or equal to the first threshold, a response message agreeing that the first star node is a candidate node is sent to the first star node; in step 203, if the term number of the first star node is less than the term number of the second star node, and / or the weight value of the first star node is less than the first threshold, no response message is sent to the first star node.

[0034] It is understood that the first star node in this application is any star node in the star node group, and the second star node can be a star node other than the first star node in the star node group.

[0035] If the term number of the first star node is greater than or equal to the term number of the second star node, and the weight value of the first star node is greater than or equal to the first threshold, it indicates that the candidate node is a node with high weight and can maintain smooth communication and a fresh term number within the current time period. In this case, the second star node will trust the candidate node as the next leader node. If either or both of the term number and weight value do not meet the conditions, it means that the candidate node's review by the second star node has failed, and the second star node will not send a response message. Here, the second star node is any star node in the star node group other than the first star node. If more than a predetermined number of star nodes fail to send a response message, it means that the first star node's communication smoothness and weight do not meet or exceed the predetermined number of star nodes, and therefore cannot meet the requirements to become a leader node.

[0036] In some embodiments, the adaptive heartbeat timing unit: Get the latest target timeout parameter value; Based on the latest target timeout parameter value and a historical target timeout parameter value, one or more dynamic transition timeout parameter values ​​are calculated, wherein the dynamic transition timeout parameter values ​​fall within the range of the latest target timeout parameter value and a historical target timeout parameter value; The timing is executed sequentially in ascending order of one or more dynamic transition timeout parameter values ​​and the latest target timeout parameter value, and switching is performed based on the first time interval.

[0037] Optionally, based on the latest target timeout parameter value and a historical target timeout parameter value, one or more dynamic transition timeout parameter values ​​are calculated, including: Load value _t = Load value _(t-1) + min(|target value - Load value _(t-1)|, 0.2 × Load value _(t-1)) × Direction sign.

[0038] The direction sign is positive or negative, indicating that the timeout parameter value increases or decreases, respectively.

[0039] A gradual approach strategy is adopted, moving one step closer to the latest target value with each switch (first time interval, such as 20 minutes), and the adjustment range of a single step does not exceed 20% of the current value (min function limit), avoiding consensus state oscillation caused by sudden changes in timeout parameters; the dynamic transition value always lies within the range between the historical target value and the latest target value. The direction sign is determined by the positive or negative sign of "latest target value - historical target value". For example: if the historical target timeout parameter value is 10s and the latest target value is 20s, then the first loading value = 10 + min(10, 2) × (+1) = 12s, the second loading value = 12 + min(8, 2.4) = 14.4s, and so on, increasing until 20s.

[0040] This allows the timeout parameter value of the star node to transition smoothly, avoiding abrupt changes in the timeout parameter that could cause consensus state oscillations.

[0041] like Figure 3 As shown, in some embodiments, the voting collection engine calculates the weight parameter values ​​for each star node, including: Obtain the orbital ephemeris parameters 301, health status parameters 302, log status parameters 303, and energy status parameters 304 for each star node; in step 305, calculate and normalize the orbital connectivity centrality assessment value, node reliability score value, data freshness contribution value, energy efficiency ratio value, and historical management role statistics value. In step 306, scoring weights are assigned to the orbital connectivity centrality assessment value, node reliability score value, data freshness contribution value, energy efficiency ratio value, and historical management role statistics value, and the weight parameter values ​​of each star node are obtained by weighted synthesis.

[0042] The weight value of each star node can be independently calculated by the dynamic weight calculator of the voting collection engine. The voting collection engine not only calculates the weight of its own star node, but also the weight values ​​of other star nodes. Furthermore, the calculation algorithm and input parameters are identical, ensuring consistency in the calculated weight values ​​for different star nodes.

[0043] Each star node can directly obtain its own orbital ephemeris parameters locally and can obtain the orbital ephemeris parameters of other star nodes through inter-star broadcast. Health status parameters are stored locally; the health status of other star nodes can be obtained through heartbeat messages. Log status parameters are obtained directly locally; the log status parameters of other nodes can be obtained by receiving logs sent by other star nodes. Energy status parameters are obtained directly locally; the energy status parameters of other star nodes can be obtained through heartbeat messages.

[0044] Optionally, the orbital connectivity centrality factor is calculated as follows: based on visibility prediction from the orbital sensing engine, the cumulative visible time of the first star node and all other nodes in the star node group within a preset future time period is calculated and divided by the sum of the cumulative visible times of all node pairs. Nodes located at the geometric center of the constellation, with moderate orbital altitude and wide orbital inclination coverage, have a higher factor. Nodes located at the edge of the constellation, with excessively low orbital altitude (severe atmospheric attenuation) or excessively high orbital altitude (excessive delay) have a lower factor. Connectivity centrality also considers link stability prediction. If the link between two nodes is frequently interrupted and restored (e.g., due to orbital precession), even with a long cumulative visible time, the stability discount reduces the factor. Stability is comprehensively evaluated based on historical link statistics and orbital mechanics predictions.

[0045] Optionally, the node reliability scoring factor is calculated using a decay memory model, scoring four sub-factors: cumulative radiation effect, single-event history, energy health status, and link historical stability, to obtain the node reliability scoring factor value. Recent events have a higher weight than distant events. If a node experiences a severe single-event event or energy alarm within the past orbital cycle, its score drops significantly and requires multiple event-free cycles to gradually recover.

[0046] The decay memory model includes at least one of the following: an exponentially weighted moving average model, an exponentially decaying window model, or a piecewise linear decay model.

[0047] For example: (1) Exponentially weighted moving average (EWMA) model: The historical scores of each sub-factor are summed by exponential decay, R = Σ α(1-α)^(T-ti)·si, with higher weight for recent events and lower weight for distant events, and α is the decay coefficient; (2) Exponential decay window model: Only events within the most recent orbital period are counted, and the impact of events decays exponentially over time; (3) Piecewise linear decay model: The history is divided into three segments: near / medium / distant, each assigned a fixed weight that decreases progressively. Any one of these can be chosen for implementation.

[0048] Optionally, the data freshness factor is calculated by comparing the latest logs stored locally by the first star node with the latest logs of the star node group to obtain the number of log skew entries; and determining the value of the data freshness factor based on the correspondence between the number of log skew entries and the data freshness factor. This factor measures the degree to which a node holds the latest system state information. Star nodes that were the previous leader node, or those that frequently synchronized with the leader node in the past, hold newer logs and data, resulting in a higher factor. Nodes that have been in partition isolation or dormant state for a long time may have outdated data, resulting in a lower factor.

[0049] The latest logs of a star node group can be obtained through heartbeat messages or log replication messages carrying the commit index (i.e., the largest log index that the leader node has been confirmed by a majority). The leader node carries its current commit index in each heartbeat / append log message; any node (including the first star node itself when it is the former leader) compares its local last log index (lastLogIndex) with this commit index, and the difference is the number of log skew entries.

[0050] Optionally, the energy efficiency ratio factor can be calculated as the ratio of the first star node's current available power to the system power. Available power considers solar panel illumination angle, battery state of charge, and energy subsystem efficiency. System power is based on historical measurements, including CPU computation, communication transmission and reception, and storage access. This reflects the energy sustainability of the node in maintaining consensus operations. Nodes with sufficient energy can handle more communication and computational loads and are suitable as leader nodes. Nodes with limited energy (such as those in the later stages of the shadow region or with aging batteries) should have their weight reduced to avoid excessive consumption that could affect core tasks.

[0051] "The available power is directly fed back by the power management unit hardware, and is the product of the current output power of the solar panels and the efficiency of the energy subsystem, plus the discharge power of the battery; the system power is the total onboard power consumed by the power management unit within the historical statistical period, including CPU computing, communication transmission and reception, and storage access." The calculation method for the historical management role factor includes: using a sliding window to statistically analyze the historical management role indicators, with a window length of one to three track cycles; and obtaining the historical management role factor value based on the historical management role indicator results and a pre-defined historical management role factor lookup table. Historical management role indicators include: duration as a leadership node, number of switches, log replication latency, member change success rate, and / or fault recovery response time. The historical management role factor lookup table can include the historical management role factor values ​​corresponding to different ranges of leadership node duration, the number of switches in the most recent track cycle, average log replication latency, member change success rate, and fault recovery response time. This factor helps prevent system instability caused by frequent leadership node switches. Nodes that have recently served as leadership nodes and performed well (no frequent switches, timely log replication, successful member changes) have a higher factor, supporting re-election. Nodes that have recently switched frequently or experienced management failures have a lower factor, inhibiting their re-election.

[0052] Membership change success rate = The percentage of times a node initiates or participates in a membership change (configuration change log) and successfully submits it with a majority vote in the star node group within a predetermined time, out of the total number of times it initiates or participates in such changes. Fault recovery response time = The time interval from when a node recovers from a fault and comes back online to when the node rejoins the star node group and successfully responds to a heartbeat message or voting request for the first time. This metric measures how quickly a node reintegrates into the consensus process after a fault recovery.

[0053] The historical factors for each management role are shown below. Specific values ​​can be determined through simulation. Each indicator is normalized and categorized into 0-1 values. When combining multiple indicators, the average or weighted value of each category can be used.

[0054] Table 1: Comparison of the Percentage of Time Serving as a Leader

[0055] Table 2 Comparison of the Number of Switching Times in the Nearest Orbital Cycle

[0056] Table 3 Average Log Replication Latency

[0057] Table 4 Member Change Success Rate

[0058] Table 5 Fault Recovery Response Time

[0059] Optionally, the weights in the weighted synthesis of the normalized values ​​of the track connectivity centrality factor, node reliability score factor, data freshness factor, energy efficiency ratio factor, and management role history factor can be pre-configured. Each factor is normalized to the [0-1] interval, and the resulting node weight W is within the [0-1] range. The weight range can be preset according to the importance of the factors. The weight ranges for the track connectivity centrality factor, node reliability score factor, data freshness factor, energy efficiency ratio factor, and management role history factor are 0.2-0.3, 0.2-0.3, 0.15-0.25, 0.1-0.2, and 0.1-0.2, respectively, and the sum of the weights is 1. For example, the weights for the track connectivity centrality factor C, node reliability score factor R, data freshness factor D, energy efficiency ratio factor E, and management role history factor H are 0.25, 0.25, 0.2, 0.15, and 0.15, respectively. The weight W = 0.25C + 0.25R + 0.2D + 0.15E + 0.15H.

[0060] Therefore, calculating the weight parameters of star nodes comprehensively considers orbital position, communication capability, reliability, and energy status to better select consensus managers and ensure the stable tenure of leadership nodes during their term. It also differentiates high-quality and low-quality star nodes based on connectivity and other factors, preventing low-quality nodes from competing equally with high-quality nodes. The weights are adjusted according to orbital motion and node state changes, but drastic fluctuations that could lead to frequent re-elections are avoided. Weight calculations are based on verifiable objective parameters to prevent manipulation by malicious nodes.

[0061] In some embodiments, the orbital ephemeris parameters, health status parameters, log status parameters, and energy status parameters are accompanied by timestamps and star node source identifiers; The voting collection engine adjusts the scoring weight of any parameter based on the timestamps of the orbital ephemeris parameters, health status parameters, log status parameters, and energy status parameters of each star node, when the time interval between the timestamp corresponding to any parameter and the calculation time point is greater than or equal to a second threshold, so that the adjusted scoring weight is less than the original scoring weight.

[0062] By attaching a timestamp, expired parameters (those that have not been updated for more than two orbital cycles) can be marked as obsolete. This indicates that the weight of the expired parameter should be reduced, or the expired parameter can be removed when calculating the weight.

[0063] In some embodiments, an adaptive heartbeat timing unit is used: Based on the weight value of the first star node, the weight level of the first star node is determined, and the weight level includes high weight node, medium weight node and low weight node. Based on the weight level of the first star node and the preset correspondence between the weight level and the weight coefficient, the current weight coefficient of the first star node is obtained; based on the current weight coefficient, window period coefficient and timeout parameter base value of the first star node, the target timeout parameter value of the first star node is obtained.

[0064] Optionally, the timeout parameters for high-weight nodes, medium-weight nodes, and low-weight nodes are set from smallest to largest. This allows high-weight nodes to initiate elections more quickly and gain majority support, ensuring that high-quality star nodes are prioritized as leader nodes, thus improving overall system stability. It also suppresses the tendency of low-weight nodes to initiate elections, preventing low-quality nodes from competing for the leader node and causing system degradation. Low-weight nodes primarily participate in log replication as follower nodes, providing fault tolerance. Medium-weight nodes are designated as potential leader node candidates, but with lower priority than high-weight nodes. If high-weight nodes fail simultaneously, medium-weight nodes can promptly fill the gap.

[0065] For example, the weight coefficients for high-weight nodes, medium-weight nodes, and low-weight nodes are 0.7, 1.0, and 1.5, respectively. The target timeout parameter value for high-weight nodes during the window transition period is calculated as: base timeout parameter value × 1.5 × 0.7.

[0066] The adaptive heartbeat timing unit internally maintains multiple sets of hardware programmable counters, with the following structure as an example: Counter 0: Election timeout counter (composite result loading); Counter 1: Heartbeat interval counter (composite result loading); Counter 2: Log replication timeout counter (composite result loading); Register A: Current window period coefficient (output by the track phase controller); Register B: Current weight level coefficient (output by the dynamic weight calculator); Multiplier: Real-time calculation of base value × Register A × Register B.

[0067] In some embodiments, the voting collection engine: in step 401, obtains the orbital ephemeris information, star node group member change information, and fault information of each star node; in step 402, triggers the calculation of the weight parameter value of the star node when the cycle of each star node ends, the star node group member changes, or a fault occurs in each star node.

[0068] In step 403, after calculating the new weight parameter values, the weight vectors are exchanged with other star nodes in the star node group; the weight vectors are the weight parameter values ​​of each star node; in step 404, if the weight parameter values ​​of each star node calculated by the first star node correspond to the weight parameter values ​​of the weight vectors sent by other star nodes in the star node group, the weight parameter values ​​of the first star node are updated.

[0069] When a cycle ends, a new visibility prediction window is entered, star node members join or leave the group, or a star node experiences a major failure, updating the star node weights makes it easier to select a leader node that is more suitable for the new situation.

[0070] Optionally, the first star node can exchange weight vectors with other star nodes in the star node group via heartbeat information; compare the weight parameter values ​​of each star node calculated by the first star node with the weight parameter values ​​of the weight vectors sent by other star nodes in the star node group, and trigger a diagnosis if the difference between any weight vectors is greater than a threshold. Investigate the source of parameter differences, such as clock skew.

[0071] Each star node independently calculates its weight vector based on the same algorithm and input parameters, and theoretically the results should be consistent. However, in practice, differences arise due to variations in parameter acquisition time and data version. The main reasons for these differences are threefold: (1) The timestamps for acquiring orbital ephemeris / health / energy parameters differ among nodes, resulting in inconsistent input snapshots; (2) There is a broadcast delay in ephemeris data version updates, causing some nodes to temporarily use older ephemeris versions; (3) There are deviations in the onboard clocks of each node, leading to inconsistent timing of calculations at the end of the cycle. The solution is to set a tolerance threshold. When the difference in weight vectors is within the threshold, the local calculation result is used directly. When the difference exceeds the threshold, the weights are not updated temporarily, and a diagnosis is triggered—the parameter source identifier and timestamp are compared, the weight vectors are re-exchanged, and synchronization is completed based on the weight vectors consistent with the majority of nodes in the star node group. After eliminating anomalies, the weights are updated.

[0072] In some embodiments, where the first star node is the leader node, the voting collection engine: In step 501, based on the orbital ephemeris information of the first star node, it is predicted that the first star node will enter a long-term invisible window period after the second time interval. Alternatively, in step 502, based on the orbital ephemeris information of the first and second star nodes, it is determined that the communication quality of the orbital position of the second star node is better than that of the orbital position of the first star node after the third time interval, triggering step 503, leadership transfer assessment; the assessment items of the leadership transfer assessment include the weight of the second star node, data freshness, and the cost of leadership transfer; in step 504, if the weight and data freshness values ​​of the second star node are greater than or equal to the weight and data freshness values ​​of the first star node, and the leadership transfer cost value is greater than the third threshold, the leadership transfer process is triggered.

[0073] Long-term invisible windows can include the Earth's shadow region or attitude maneuvering periods. Areas with better communication quality can include locations such as the constellation's geometric center.

[0074] The overhead of leadership transfer includes the amount of unsynchronized log data and transmission time, service interruption time, interaction overhead of rebuilding heartbeat synchronization, and additional control message overhead, which can be quantified as: Overhead value = number of unreplicated log entries × average size of a single log entry ÷ predicted available link bandwidth + fixed handshake delay (some round-trip delay).

[0075] The weight of the first star node is calculated internally within this node. Data freshness can be obtained by comparing the difference between the commit index (or the last log entry sequence number) of the local logs of the first star node (the current leader node) and the second star node. The smaller the difference, the newer the data in the second star node, and the less data needs to be supplemented during the transfer. The leadership transfer overhead is calculated based on the amount of log data to be supplemented in the target star node (second star node), the available bandwidth of the link between the first star node and the second star node during the current and prediction window, and / or the visible window duration—the larger the amount of data to be supplemented, the smaller the available bandwidth, and the shorter the remaining window, the greater the overhead.

[0076] The proactive leadership transfer assessment is completed solely by the leading node, without the involvement of other star nodes, reducing processing time for them and lowering power consumption. This facilitates the pre-selection of a leading node in special circumstances, ensuring system stability.

[0077] In some embodiments, the leadership transfer process includes: the first star node (the current leader node) stops receiving new requests and continues to complete the process of the items being processed; the first star node copies all uncommitted logs to the second star node (the next leader node); the first star node sends a timeout message to the second star node; upon receiving the timeout message, the second star node initiates an election; after a successful election, it becomes the next leader node; after the second star node becomes the next leader node, the first star node becomes a follower node.

[0078] The uncommitted logs include logs that have been written locally but not yet replicated to the second star node and have not been committed and confirmed by a majority vote.

[0079] During the leadership transfer process, the first star node is read-only and does not accept write requests. The second star node, after becoming the leader node, broadcasts a heartbeat and regains write capabilities. The first star node replicates all uncommitted logs to the second star node, ensuring that the second star node's data is up-to-date. The entire transfer process typically completes within a few round-trip delays, minimizing the impact on business operations.

[0080] Optionally, the voting collection engine includes a voting register array, where each register corresponds to the voting response status of a star node other than the first star node. The voting collection engine is further configured to: receive voting information from all star nodes other than the current star node and write it to the corresponding register location; accumulate the voting results of each register; and, if the number of affirmative votes for the first star node is greater than or equal to the majority threshold, trigger the first star node to become the leader node. This role switching is completed by a hardware state machine. The voting result writing process does not require the central processing unit to parse and poll each result individually, and requires no intervention from the central processing unit throughout the process; only after the state transition is completed does the processing system send a single interrupt signal to the central processing unit to notify that the leader election is complete, thereby reducing the election latency from the millisecond level of traditional software implementation to the microsecond level of hardware clock cycles, ensuring the determinism of the election latency, and avoiding election timeout drift caused by software task scheduling jitter.

[0081] In software implementation, elections involve tasks such as message parsing and state machine transitions, which are affected by operating system scheduling jitter, with typical latency in the millisecond range. This application uses a voting register array and a hardware state machine to complete vote counting and role switching, with a latency of several clock cycles (within microseconds at the kilohertz to megahertz level) and no latency jitter.

[0082] The central processing unit (CPU) is integrated inside the star node, and the CPU and the processing system are independent of each other.

[0083] In some embodiments, the processing system further includes a log replication engine. When the first star node is the leader node, the log replication engine classifies the logs according to their importance level into critical configuration logs and ordinary monitoring logs. The log replication timeout parameter value corresponding to the critical configuration logs is less than the log replication timeout parameter value corresponding to the ordinary monitoring logs. The system sends critical configuration logs to each high-weight node in the star node group, and after receiving confirmation of the previous critical configuration log, it starts sending the next critical configuration log; after receiving confirmation of more than a preset number of star nodes among the high-weight nodes, it sends a commit message to the central processing unit. Without waiting for confirmation from the following nodes, multiple ordinary monitoring logs are continuously sent to the following nodes with connected links.

[0084] Critical configuration logs include virtual switch domain creation and destruction, memory device binding and unbinding, node joining and leaving, and security policy changes. These logs affect the core state of the system and must be strongly consistent. Optionally, for critical configuration logs, a smaller coefficient value (e.g., 3) can be selected from the log replication coefficient range of 3-5. A coefficient of 3 corresponds to 3 times the predicted maximum round-trip latency. If no acknowledgment is received within a timeout period, the following node is marked as lagging.

[0085] Regular monitoring logs include performance statistics, resource usage, link quality measurements, and health status reports. These logs are used for system optimization and fault diagnosis, allowing for eventual consistency. The replication timeout for regular monitoring logs is lenient; for regular monitoring logs, a midpoint or larger coefficient value (e.g., 4) is selected from the log replication coefficient range of 3-5. Logs are cached locally during link unavailability and resent upon recovery.

[0086] Optionally, the log replication engine is configured to categorize logs according to their importance level and also include local diagnostic logs. Local diagnostics include internal node debugging information, detailed error tracking, and performance profiling data. These logs are stored locally only and are not replicated to other nodes. They are periodically compressed and uploaded to ground persistence (e.g., every orbital cycle or when visible to the ground station). Local diagnostic logs do not participate in consensus and are only used for post-event analysis.

[0087] Using different replication strategies, timeout parameters, and consistency requirements for different logs helps to ensure strong consistency and timeliness of critical configuration logs while reducing the replication overhead and acknowledgment waiting of ordinary monitoring logs, preventing non-critical messages from crowding out the limited bandwidth of inter-satellite links, improving bandwidth utilization during the link window period, and ensuring the replication priority of critical configuration logs.

[0088] In some embodiments, the log replication engine is configured as follows: When the first star node is the leader node, protocol metadata is added to the local log file to obtain the log file to be sent. The protocol metadata includes term number, verification information, sequence number and matching index, and the log file to be sent is sent to the sending queue. Receive log confirmation information sent by the following nodes, and after all the copying and confirmation operations of multiple logs are completed, send a batch completion interrupt information to the central processing unit; When the first star node is a follower node, the received log file is parsed, the protocol metadata is extracted, and the local matching index is automatically updated by the hardware based on the parsing results.

[0089] The log replication engine of the following node parses the protocol metadata (term number, verification information, sequence number and matching index) in the received log entries at the hardware level, compares it with the matching index (matchIndex) stored locally, and automatically writes the larger value to the local matching index register. The entire process does not require CPU intervention, ensuring the consistency of the log synchronization status between the leader node and the following nodes and the real-time processing.

[0090] The log replication engine's hardware auto-encapsulation logic then appends protocol metadata such as term number, checksum, and sequence number to each log entry, and sends the encapsulated logs in batches to the inter-satellite link's first-in-first-out (FIFO) queue through a direct memory access batch transmission mechanism.

[0091] The star node that receives the logs compares the sequence number and matching index parsed from the logs with the matching index stored locally, and updates the local matching index to maintain log synchronization between the leader node and the follower nodes.

[0092] Once a batch of logs has been copied and confirmed, the engine sends a batch completion interrupt to the central processing unit (CPU). The CPU only needs to perform the final status commit operation during interrupt handling. This design frees the CPU from frequent message encapsulation, index maintenance, and timeout retries, allowing it to focus on task computation and scheduling decisions. Simultaneously, the hardware batch transmission mechanism significantly improves inter-satellite link bandwidth utilization.

[0093] In some embodiments, where the first star node is the leader node, the log replication engine: In step 601, based on the orbital ephemeris information of the first star node, the communication quality of the links between the first star node and each follower node is evaluated, and based on the communication quality of each link, each link is divided into different link levels; the link levels include high-quality link 602, medium-quality link 603 and low-quality link 604. For high-quality links, in step 605, after receiving confirmation of the previous heartbeat and / or log, the sending of the next heartbeat and / or log is initiated.

[0094] For medium-quality links, in step 606, without waiting for acknowledgment information from the following nodes, multiple heartbeats and / or logs are sent continuously.

[0095] For low-quality links, in step 607, when the link is unavailable, heartbeats and / or logs are sent to the relay node or cached locally, and then forwarded in batches when the link becomes available.

[0096] A track-aware engine is used to predict and classify the communication quality of links between the leader node and each follower node. High-quality links are characterized by low latency, low bit error rate, and high stability. Low-quality links are characterized by high latency and intermittent availability. This distinguishes links with different communication qualities.

[0097] High-quality replication links employ synchronous real-time replication. The leader node sends logs and immediately awaits confirmation, resulting in low confirmation latency and high replication efficiency. This type of follower node is suitable as a majority member for synchronizing critical configuration logs.

[0098] For medium-quality links, pipelined asynchronous replication is used. The leader node continuously sends multiple logs without waiting for individual acknowledgments, using pipelined replication to bridge link latency. Follower nodes acknowledge sequentially, while the leader node processes acknowledgments in batches. This type of follower node is suitable as an asynchronous replication target for ordinary monitoring logs.

[0099] For low-quality links (high latency, intermittent availability), store-and-forward replication is used. The leader node sends logs to relay nodes or caches them locally, forwarding them in batches when the link becomes available. These follower nodes do not participate in the majority decision-making process for critical issues; they serve only as backups for eventual consistency.

[0100] According to embodiments of this application, a processing system for distributed consensus among multiple star nodes is also provided. For example... Figure 7 As shown, at least two star nodes form a star node group. The star nodes in the star node group are divided into leader nodes and follower nodes. The processing system is arranged on the star nodes. The processing system 700 includes an adaptive heartbeat timing unit 701 and a voting collection engine 702.

[0101] The adaptive heartbeat timing unit 701 is configured to: classify link states based on link visibility, the link states including stable window period, window transition period and window boundary period; determine the current link state of the first star node based on the orbital ephemeris information of the first star node; determine the current window period coefficient of the first star node based on the current link state of the first star node and the preset correspondence between link states and window period coefficients; and obtain the target timeout parameter value of the first star node based on the current window period coefficient of the first star node and the base value of the timeout parameter. The voting collection engine 702 is configured as follows: based on the target timeout parameter value, if the election operation, heartbeat interval, and / or log replication delay reaches the target timeout parameter value, the first star node changes from a follower node to a candidate node; without incrementing the term number, it sends a pre-voting request message to other star nodes in the star node group; if no response message is received from more than a predetermined number of star nodes, the first star node reverts to a follower node; if a response message is received from more than a predetermined number of star nodes agreeing that the first star node is a candidate node, the term number is incremented and the election procedure begins.

[0102] In some embodiments, the pre-voting request information includes the term number and weight information of the first star node, and the voting collection engine of the second star node is configured to: compare the term number of the first star node and the term number of the second star node based on the received pre-voting request information; if the term number of the first star node is greater than or equal to the term number of the second star node, and the weight value of the first star node is greater than or equal to a first threshold, send a response message agreeing that the first star node is a candidate node to the first star node; if the term number of the first star node is less than the term number of the second star node, and / or the weight value of the first star node is less than the first threshold, do not send a response message to the first star node.

[0103] In some embodiments, the adaptive heartbeat timing unit is further configured to: obtain the latest target timeout parameter value; calculate one or more dynamic transition timeout parameter values ​​based on the latest target timeout parameter value and a historical target timeout parameter value, wherein the dynamic transition timeout parameter values ​​fall within the range of the latest target timeout parameter value and a historical target timeout parameter value; and execute timing sequentially in ascending order of the values ​​of the one or more dynamic transition timeout parameter values ​​and the latest target timeout parameter value, and switch based on a first time interval.

[0104] In some embodiments, the voting collection engine is further configured to calculate the weight parameter values ​​of each star node, including: obtaining the orbital ephemeris parameters, health status parameters, log status parameters, and energy status parameters of each star node; calculating and normalizing these parameters to obtain the orbital connectivity centrality assessment value, node reliability score value, data freshness contribution value, energy efficiency ratio, and historical management role statistics value; assigning scoring weights to the orbital connectivity centrality assessment value, node reliability score value, data freshness contribution value, energy efficiency ratio, and historical management role statistics value respectively; and obtaining the weight parameter values ​​of each star node through weighted synthesis.

[0105] In some embodiments, the orbital ephemeris parameters, health status parameters, log status parameters, and energy status parameters are accompanied by timestamps and star node source identifiers; the voting collection engine is further configured to: based on the timestamps of the orbital ephemeris parameters, health status parameters, log status parameters, and energy status parameters of each star node, if the time interval between the timestamp corresponding to any parameter and the calculation time point is greater than or equal to a second threshold, adjust the scoring weight of that parameter so that the adjusted scoring weight is less than the unadjusted scoring weight.

[0106] In some embodiments, the adaptive heartbeat timing unit is further configured to: determine the weight level of the first star node based on its weight value, wherein the weight level includes high-weight nodes, medium-weight nodes, and low-weight nodes; obtain the current weight coefficient of the first star node based on its weight level and a preset correspondence between weight level and weight coefficient; and obtain the target timeout parameter value of the first star node based on its current weight coefficient, window period coefficient, and timeout parameter base value.

[0107] In some embodiments, the voting collection engine is further configured to: acquire orbital ephemeris information, star node group member change information, and fault information of each star node; trigger the calculation of weight parameter values ​​of star nodes when the period of each star node ends, the star node group member changes, or each star node fails; after calculating new weight parameter values, exchange weight vectors with other star nodes in the star node group, wherein the weight vectors are the weight parameter values ​​of each star node; and update the weight parameter values ​​of the first star node if the weight parameter values ​​of each star node calculated by the first star node correspond to the weight parameter values ​​of the weight vectors sent by other star nodes in the star node group.

[0108] In some embodiments, where the first star node is the leader node, the voting collection engine is further configured to: Based on the orbital ephemeris information of the first star node, it is predicted that the first star node will enter a long-term invisible window period after the second time interval. Alternatively, based on the orbital ephemeris information of the first and second star nodes, it is determined that the communication quality of the orbital position of the second star node is better than that of the orbital position of the first star node after the third time interval, triggering a leadership transfer assessment. The assessment items of the leadership transfer assessment include the weight of the second star node, data freshness, and the cost of leadership transfer. If the weight and data freshness values ​​of the second star node are greater than or equal to the weight and data freshness values ​​of the first star node, and the cost of leadership transfer is greater than a third threshold, the leadership transfer process is triggered.

[0109] In some embodiments, the processing system further includes a log replication engine. When the first star node is the leader node, the log replication engine is configured to: classify logs according to their importance level into critical configuration logs and ordinary monitoring logs, wherein the log replication timeout parameter value corresponding to the critical configuration log is less than the log replication timeout parameter value corresponding to the ordinary monitoring log; send the critical configuration log to each high-weight node in the star node group, and after receiving confirmation information of the previous critical configuration log, start sending the next critical configuration log; after receiving confirmation information from more than a preset number of star nodes among the high-weight nodes, send a commit message to the central processing unit; and continuously send multiple ordinary monitoring logs to the linked follower nodes without waiting for confirmation information from the follower nodes.

[0110] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0111] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for processing distributed consensus across multiple star nodes, characterized in that, A star node group consists of at least two star nodes. The star nodes in the group are divided into leader nodes and follower nodes. Each star node includes a processing system, which includes an adaptive heartbeat timing unit and a voting collection engine. The processing method includes: The adaptive heartbeat timing unit: classifies the link state based on link visibility, the link state including stable window period, window transition period and window boundary period; determines the current link state of the first star node based on the orbital ephemeris information of the first star node; determines the current window period coefficient of the first star node based on the current link state of the first star node and the preset correspondence between link state and window period coefficient; and obtains the target timeout parameter value of the first star node based on the current window period coefficient of the first star node and the base value of the timeout parameter. The voting collection engine, based on the target timeout parameter value, if the election operation, heartbeat interval, and / or log replication delay reaches the target timeout parameter value, the first star node changes from a follower node to a candidate node; it does not increment the term number and sends a pre-voting request to other star nodes in the star node group; if it does not receive response information from more than a predetermined number of star nodes, the first star node reverts to a follower node; if it receives response information from more than a predetermined number of star nodes agreeing that the first star node is a candidate node, it increments the term number and enters the election procedure.

2. The processing method according to claim 1, characterized in that, The pre-voting request information includes the term number and weight information of the first star node, which is collected by the voting engine of the second star node: based on the received pre-voting request information, the term number of the first star node and the term number of the second star node are compared. If the term number of the first star node is greater than or equal to the term number of the second star node, and the weight value of the first star node is greater than or equal to the first threshold, send a response message agreeing to the first star node as a candidate node to the first star node. If the term number of the first star node is less than the term number of the second star node, and / or the weight value of the first star node is less than the first threshold, no response information will be sent to the first star node.

3. The processing method according to claim 1, characterized in that, The processing method further includes the adaptive heartbeat timing unit: Get the latest target timeout parameter value; Based on the latest target timeout parameter value and a historical target timeout parameter value, one or more dynamic transition timeout parameter values ​​are calculated, wherein the dynamic transition timeout parameter values ​​fall within the range of the latest target timeout parameter value and a historical target timeout parameter value; The timing is executed sequentially in ascending order of one or more dynamic transition timeout parameter values ​​and the latest target timeout parameter value, and switching is performed based on the first time interval.

4. The processing method according to claim 1, characterized in that, The voting collection engine calculates the weight parameter values ​​for each star node, including: The orbital ephemeris parameters, health status parameters, log status parameters, and energy status parameters of each star node are obtained. After calculation and normalization, the orbital connectivity centrality assessment value, node reliability score value, data freshness contribution value, energy efficiency ratio value, and historical management role statistics value are obtained. The orbital connectivity centrality assessment value, node reliability score value, data freshness contribution value, energy efficiency ratio value, and historical management role statistics value are assigned scoring weights, and the weight parameter values ​​of each star node are obtained by weighted synthesis.

5. The processing method according to claim 4, characterized in that, Orbital ephemeris parameters, health status parameters, log status parameters, and energy status parameters are accompanied by timestamps and star node source identifiers; The voting collection engine adjusts the scoring weight of any parameter based on the timestamps of the orbital ephemeris parameters, health status parameters, log status parameters, and energy status parameters of each star node, when the time interval between the timestamp corresponding to any parameter and the calculation time point is greater than or equal to a second threshold, so that the adjusted scoring weight is less than the original scoring weight.

6. The processing method according to claim 4, characterized in that, The processing method further includes the adaptive heartbeat timing unit: Based on the weight value of the first star node, the weight level of the first star node is determined, and the weight level includes high weight node, medium weight node and low weight node. Based on the weight level of the first star node and the preset correspondence between the weight level and the weight coefficient, the current weight coefficient of the first star node is obtained; based on the current weight coefficient, window period coefficient and timeout parameter base value of the first star node, the target timeout parameter value of the first star node is obtained.

7. The processing method according to claim 4, characterized in that, The processing method further includes the following steps: the voting collection engine obtains the orbital ephemeris information, star node group member change information, and fault information of each star node. The weight parameter values ​​of each star node are calculated when the cycle of each star node ends, the members of the star node group change, or each star node fails. After the new weight parameter values ​​are calculated, the weight vectors are exchanged with other star nodes in the star node group. The weight vectors are the weight parameter values ​​of each star node. If the weight parameter values ​​of each star node calculated by the first star node correspond to the weight parameter values ​​of the weight vectors sent by other star nodes in the star node group, the weight parameter values ​​of the first star node are updated.

8. The processing method according to claim 4, characterized in that, When the first star node is the leader node, the voting collection engine is used: Based on the orbital ephemeris information of the first star node, it is predicted that the first star node will enter a long-term invisible window period after the second time interval. Alternatively, based on the orbital ephemeris information of the first and second star nodes, it is determined that the communication quality of the orbital position of the second star node is better than that of the orbital position of the first star node after the third time interval, triggering a leadership transfer assessment. The assessment items of the leadership transfer assessment include the weight of the second star node, data freshness, and the cost of leadership transfer. If the weight and data freshness values ​​of the second star node are greater than or equal to the weight and data freshness values ​​of the first star node, and the cost of leadership transfer is greater than a third threshold, the leadership transfer process is triggered.

9. The processing method according to claim 6, characterized in that, The leadership transfer process includes: the first star node stops receiving new requests and continues to complete the processes of the tasks it is currently handling; the first star node copies all uncommitted logs to the second star node and sends timeout information to the second star node; upon receiving the timeout information, the second star node initiates an election.

10. A processing system for distributed consensus across multiple star nodes, characterized in that, At least two star nodes form a star node group. The star nodes in the star node group are divided into leader nodes and follower nodes. The processing system is deployed on the star nodes and includes an adaptive heartbeat timing unit and a voting collection engine. The adaptive heartbeat timing unit is configured to: divide the link state according to the link visibility, the link state including the stable window period, the window transition period and the window boundary period; and determine the current link state of the first star node based on the orbital ephemeris information of the first star node; Based on the current link status of the first star node and the preset correspondence between link status and window period coefficient, the current window period coefficient of the first star node is determined; based on the current window period coefficient of the first star node and the base value of the timeout parameter, the target timeout parameter value of the first star node is obtained. The voting collection engine is configured as follows: based on the target timeout parameter value, if the election operation, heartbeat interval, and / or log replication delay reaches the target timeout parameter value, the first star node changes from a follower node to a candidate node; without incrementing the term number, it sends a pre-voting request message to other star nodes in the star node group; if no response message is received from more than a predetermined number of star nodes, the first star node reverts to a follower node; if a response message is received from more than a predetermined number of star nodes agreeing that the first star node is a candidate node, the term number is incremented and the election procedure begins.

Images