Vehicle cloud control platform distributed database consistency method based on intelligent network connection

Abstract

The invention discloses a vehicle cloud control platform distributed database consistency method based on intelligent network connection, and belongs to the technical field of intelligent network connection vehicles and distributed databases, and the method comprises the steps: a leader node receives a read-write operation request sent by a cloud control platform, generates a target log entry, copies the target log entry to a slave node, and obtains a new log; the leader node detects whether the new log of each slave node is consistent with the new log of the leader node based on an anti-entropy mechanism; if the state of the to-be-sequenced slave nodes is not consistent and the state of the leader node is normal, performing new log sequencing on the to-be-sequenced slave nodes based on an incremental synchronization strategy; and if the state of the leader node is abnormal, each slave node votes to select a new leader node as a target leader node based on a trust management mechanism, and each slave node performs new log sequencing based on a negotiation sequencing mechanism. According to the method, the distributed database system can give consideration to the consistency and availability of data in a high-failure-rate scene of the intelligent networked automobile.

Description

Technical Field

[0001] The present invention belongs to the technical field of intelligent connected vehicles and distributed databases, and specifically relates to a distributed database consistency method for a vehicle cloud control platform based on intelligent connected vehicles. Background Art

[0002] With the rapid development of artificial intelligence, big data, the Internet of Things, and 5G communication technologies, intelligent connected vehicles (ICVs) have become a core force driving transformation in the global automotive industry. The ICV cloud control platform (i.e., the ICV monitoring platform) is a key technology for ICVs, used to monitor and manage the operating status of ICVs. The ICV cloud control platform is a critical system for real-time collection, processing, and analysis of massive amounts of heterogeneous data. It manages and processes multi-source data, including vehicle status data, traffic environment data, and user behavior data, which is characterized by high frequency, large scale, and diverse data. Traditional single-node databases are struggling to cope with the ever-increasing data volumes and real-time requirements. In contrast, distributed databases, through multi-node coordinated storage and access, not only meet the high performance, scalability, and fault tolerance requirements of ICV cloud control platforms, but also provide technical support for the platform's complex task processing. To ensure data consistency in distributed database systems, Lamport proposed the Paxos algorithm in 2003. However, Paxos has been difficult to understand and difficult to implement in engineering. In 2014, Ongaro and Ousterhout introduced the Raft algorithm. While inheriting the core concepts of Paxos, this algorithm simplified its description, significantly improving its readability and implementation efficiency, making it more suitable for engineering scenarios. Consensus algorithms for distributed databases are a hot research topic in the distributed field. However, existing consensus algorithms for distributed databases struggle to achieve both data consistency and availability in high-failure scenarios like intelligent connected vehicles.

[0003] It should be noted that the information disclosed in the above background technology section 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 ordinary technicians in this field. Summary of the Invention

[0004] In order to provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. The summary is not an extensive review, nor is it intended to identify key / critical elements or delineate the scope of protection of these embodiments, but rather serves as a prelude to the detailed description that follows.

[0005] The disclosed embodiments provide a distributed database consistency method for a vehicle cloud control platform based on intelligent connected vehicles, so that the distributed database system can take into account both data consistency and availability in scenarios with high failure rates such as intelligent connected vehicles.

[0006] In some embodiments, the distributed database consistency method for a cloud control platform for intelligently connected vehicles includes: a leader node receiving a read / write operation request sent by the cloud control platform, generating a corresponding target log entry, and copying the target log entry to each slave node to obtain a new log corresponding to the leader node and each slave node; if the copying is successful, the leader node detects whether the new log of each slave node is consistent with the new log of the leader node based on an anti-entropy mechanism; if the new log of any slave node is inconsistent with the new log of the leader node, each slave node detects the status of the leader node; if the status of the leader node is normal, the leader node sequences the new log of each to-be-sequenced slave node based on an incremental synchronization strategy, and after the new log sequencing is successful, the leader node stores and commits the corresponding new log; wherein the to-be-sequenced slave node represents a slave node that is inconsistent with the new log of the leader node; if the status of the leader node is abnormal, each slave node votes to elect a new leader node as the target leader node based on a trust management mechanism, and each slave node sequences the new log based on a negotiated sequencing mechanism, and after the new log sequencing is successful, the target leader node stores and commits the corresponding new log.

[0007] The beneficial effects of the present invention are:

[0008] The generated target log entries are copied to each slave node through the leader node. If the copy is successful, the leader node can quickly detect the new logs of each slave node based on the anti-entropy mechanism to quickly determine whether the new logs of each slave node are consistent with the new logs of the leader node. If the new log of any slave node is not consistent with the new log of the leader node, each slave node will detect the status of the leader node. If the status of the leader node is normal, the leader node will sort the new logs of each slave node to be sequenced based on the incremental synchronization strategy, that is, only the set of log entries in the logs of each node to be sequenced that are inconsistent with the logs of the leader node will be synchronized, so as to efficiently maintain node consistency and ensure data consistency. If the status of the leader node is abnormal, a new leader node will be voted as the target leader node based on the trust management mechanism to ensure data availability, and each slave node will sequence the new logs based on the negotiated sequencing mechanism.

[0009] In this way, when the leader node is in a normal state, new logs are sequenced for each node to be sequenced based on the anti-entropy mechanism and incremental synchronization strategy to ensure data consistency. When the leader node is in an abnormal state, each slave node votes to elect a new leader node as the target leader node based on the trust management mechanism to ensure data availability, and each slave node sequences new logs based on the negotiated sequencing mechanism to ensure data consistency, thereby achieving a distributed database system that can take into account both data consistency and availability in high-failure-rate scenarios such as smart connected vehicles.

[0010] The above general description and the following description are exemplary and explanatory only and are not intended to limit the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] One or more embodiments are exemplarily described by corresponding drawings. These exemplary descriptions and drawings do not limit the embodiments. Elements with the same reference numerals in the drawings are shown as similar elements. The drawings do not constitute a scale limitation. In addition,

[0012] Figure 1 This is a schematic diagram of the architecture of a distributed data storage system for intelligent connected vehicles provided by the present invention;

[0013] Figure 2 This is a flow chart of a distributed database consistency method for a vehicle cloud control platform based on intelligent networking provided by the present invention;

[0014] Figure 3 This is a schematic diagram of a node log list structure provided by the present invention;

[0015] Figure 4 This is a flow chart of a log sorting process provided by the present invention;

[0016] Figure 5 This is a flow chart of determining a leader node based on a trust management mechanism provided by the present invention;

[0017] Figure 6 This is a flowchart of another distributed database consistency method for a vehicle cloud control platform based on intelligent networking provided by the present invention. DETAILED DESCRIPTION

[0018] In order to be able to understand the features and technical content of the embodiments of the present disclosure in more detail, the implementation of the embodiments of the present disclosure is described in detail below in conjunction with the accompanying drawings. The accompanying drawings are for reference only and are not used to limit the embodiments of the present disclosure. In the following technical description, for the sake of convenience of explanation, a full understanding of the disclosed embodiments is provided through multiple details. However, one or more embodiments can still be implemented without these details. In other cases, to simplify the drawings, well-known structures and devices can be simplified for display.

[0019] In the description and claims of the embodiments of the present disclosure, as well as in the accompanying drawings, the terms "first," "second," and the like are used to distinguish similar items and are not necessarily used to describe a particular order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate to describe the embodiments of the present disclosure herein. In addition, the terms "including," "having," and any variations thereof are intended to cover non-exclusive inclusions.

[0020] Unless otherwise stated, the term "plurality" means two or more.

[0021] In the embodiment of the present disclosure, the character " / " indicates that the preceding and following objects are in an "or" relationship. For example, A / B means: A or B.

[0022] 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.

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

[0024] With the rapid development of artificial intelligence, big data, the Internet of Things, and 5G communication technologies, intelligent connected vehicles (ICVs) have become a core force driving transformation in the global automotive industry. By connecting multiple factors, such as vehicles, roads, and the environment, through intelligent and networked means, ICVs have achieved the leap from "single-vehicle intelligence" to "collaborative intelligence." However, as technology continues to advance, how to effectively monitor and manage the operating status of ICVs to ensure system security, stability, and efficiency remains a critical challenge. To this end, the ICV cloud control platform (i.e., the ICV monitoring platform) has emerged, dedicated to providing integrated monitoring, management, and data analysis solutions, becoming a key technical support for the intelligent vehicle industry ecosystem.

[0025] The cloud-based control platform for intelligent connected vehicles (ICVs) is a critical system for collecting, processing, and analyzing massive amounts of heterogeneous data in real time. Its core mission is to manage and process multi-source data, including vehicle status data, sensor data, traffic environment data, and user behavior data. These data are characterized by high frequency, large scale, and diverse data. Traditional single-node databases are struggling to cope with the ever-increasing data volumes and real-time requirements. In contrast, distributed databases, through multi-node coordinated storage and access, not only meet the high-performance, scalability, and fault-tolerance requirements of the ICV cloud-based control platform, but also provide the technical support for the platform's complex task processing.

[0026] In distributed database systems, data consistency is a core component for ensuring system reliability, availability, and performance. This issue is particularly critical for complex systems like intelligent connected vehicle cloud control platforms that rely on real-time performance and multi-source data processing. In such scenarios, the system must be able to acquire and process vehicle status and environmental data from diverse regions in real time, requiring the database system to ensure high consistency. However, current technologies still face significant challenges in dealing with high latency, network fluctuations, and regional node failures, especially in the context of global deployments. Improving data transmission efficiency while ensuring system consistency and user experience is a pressing technical challenge that needs to be overcome. If these issues are not effectively addressed, data inaccuracy or lag can result, severely impacting the platform's real-time decision-making and fault response capabilities, and potentially posing serious safety risks, threatening the stable operation of the entire intelligent connected vehicle ecosystem.

[0027] Distributed systems differ significantly from stand-alone software. Their unique operating environment introduces numerous potential issues, often leading to system failures. Unlike the Byzantine Generals' Problem, where malicious nodes can tamper with data, distributed storage systems typically assume that all nodes strictly adhere to established communication protocols, thus preventing malicious tampering. The primary challenges in such systems lie in node failure and network outages. To address these challenges, distributed storage systems have introduced replicated state machine technology. While this technology effectively mitigates these challenges, it can still pose data consistency risks. Distributed consensus algorithms have proven to be highly effective in addressing this data consistency issue.

[0028] In 2003, Lamport proposed the Paxos algorithm, which divides nodes into proposers and acceptors. A proposal must have a number greater than the maximum number in the local log and be approved by a majority of acceptors before it can be submitted to the system. The Paxos algorithm uses a majority voting principle to tolerate the failure of fewer than half of the nodes and incorporates a node role switching mechanism to prevent system congestion caused by proposer failures. Researchers have developed a series of improvements and optimizations based on specific scenarios and requirements to enhance its applicability and performance. For example, DiskPaxos addresses the resource limitations of traditional memory communication by using disk as the medium for inter-process communication, saving memory overhead and enhancing data persistence between nodes. Cheap Paxos optimizes system performance by reducing the number of acceptors. While maintaining the algorithm's core functionality, it significantly reduces resource overhead, making it suitable for low-cost hardware environments. Fast Paxos optimizes communication rounds, reducing the original three-round message transmission process to two, significantly reducing communication latency and making it particularly suitable for response time-sensitive scenarios.

[0029] Paxos suffers from difficulties in understanding and engineering implementation. In 2014, Ongaro and Ousterhout introduced the Raft algorithm. While inheriting the core concepts of Paxos, this algorithm simplifies the algorithm description, significantly improving its readability and implementation efficiency, making it more suitable for engineering scenarios. Raft achieves data consistency through a leader election mechanism and log replication process, with a communication complexity of O(n). Using formal methods, Ongaro further developed the theoretical framework of the Raft algorithm and verified its correctness in handling termination failure scenarios. Research and improvements on Raft continue to grow. For example, PamlelRaft improves system throughput by supporting out-of-order commits, but this comes at the cost of some security. BRaft incorporates Byzantine fault tolerance. Although its fault tolerance ratio drops from 49% to 33%, it enhances its resistance to Byzantine faults. The dynamic Raft algorithm was proposed, enabling flexible configuration updates by introducing an online member voting mechanism. Furthermore, the Raft team designed a lease mechanism to optimize performance and explored ways to achieve linearizability in distributed environments. Researchers have continued to verify and improve Raft. For example, Doug Woos et al. ensured the safety of the state machine through formal verification; Heidi Howard et al. analyzed extreme scenarios that could lead to algorithm inactivation. Wang Rihong et al. utilized BLS signature technology to improve Raft's message authentication mechanism in log replication and leader election. Raft has demonstrated strong adaptability in practical applications. For example, CoreOS leveraged Raft to develop the high-performance key-value storage engine Etcd, providing reliable consistency guarantees for distributed systems. Consensus algorithms for distributed databases are a hot research topic in the distributed field. However, many existing consensus algorithms for distributed databases are designed for specific scenarios and lack adaptability to emerging distributed applications, such as connected vehicles and the Internet of Things. In scenarios with high failure rates, such as connected vehicles, distributed database systems struggle to achieve both data consistency and availability. Therefore, for the distributed database of the vehicle cloud control platform of intelligent connected vehicles, how the distributed database system can balance data consistency and availability is an urgent problem that needs to be solved.

[0030] In view of the characteristics of data storage and access in intelligent connected vehicles, combined with Figure 1 As shown, the embodiment of the present disclosure provides a distributed data storage system architecture for intelligent connected vehicles to meet the challenges of large-scale data processing and real-time collaboration. The system consists of multiple modules, including the intelligent connected vehicle layer (i.e. Figure 1 The distributed database system consists of a network of intelligent connected vehicles (ICVs), a monitoring platform (i.e., a cloud control platform), and a distributed database layer (i.e., master management nodes, data nodes, etc.). ICVs upload real-time data to the monitoring platform via their onboard systems. The monitoring platform then stores the data in the distributed database using a load balancing algorithm. The distributed database system implements data consistency management using an improved Raft algorithm. This improved version optimizes transaction submission and conflict resolution efficiency, balances data consistency and availability, and improves system performance.

[0031] Combine Figure 2As shown, the embodiment of the present disclosure provides a distributed database consistency method for a vehicle cloud control platform based on intelligent networking. The method is applied to a distributed database system, where the system cluster includes multiple nodes, one of which is a leader node and the remaining nodes are slave nodes. The client corresponding to the distributed database is the cloud control platform. The method is applicable to monitoring and management scenarios of various intelligent connected vehicles, including but not limited to autonomous driving vehicles, commercial transport vehicles, and shared vehicle management systems (i.e., distributed database systems) in smart city environments. The method includes:

[0032] In step S101, the leader node receives the read and write operation request sent by the cloud control platform, generates a corresponding target log entry, and copies the target log entry to each slave node to obtain a new log corresponding to the leader node and each slave node.

[0033] Specifically, the leader node replicates the target log entry to each slave node, including: the leader node distributes the target log entry to each slave node and receives responses from each slave node based on the target log entry; if the leader node determines whether it has received responses from a majority of slave nodes; if it has received responses from a majority of slave nodes, the leader node considers the replication successful; if it has not received responses from a majority of slave nodes, the leader node considers the replication failed and feeds back replication failure information to the cloud control platform (i.e., the client). The majority or majority refers to more than half of all nodes in the cluster.

[0034] Step S102: If the replication is successful, the leader node detects whether the new log of each slave node is consistent with the new log of the leader node based on the anti-entropy mechanism.

[0035] Step S103: If the new log of any slave node is not consistent with the new log of the leader node, each slave node detects the status of the leader node.

[0036] It is understood that the disclosed embodiments utilize a heartbeat mechanism to detect the status of the leader node. Specifically, each slave node periodically receives heartbeat messages from the leader node. If a majority of slave nodes do not receive heartbeat messages within a certain period of time, the leader node is considered to be in an abnormal state.

[0037] In step S104, if the leader node is in a normal state, the leader node sequences the new log for each slave node to be sequenced based on the incremental synchronization strategy. After the new log is successfully sequenced, the leader node stores and commits the corresponding new log. A slave node to be sequenced is a slave node that is inconsistent with the leader node's new log. The corresponding new log is the sequenced log.

[0038] In some embodiments, the leader node, based on an incremental synchronization strategy, controls each slave node to be sequenced to synchronize only those log entries that are inconsistent with the leader node's new log. Upon completion of synchronization, the leader node sends a corresponding confirmation message to the leader node. Upon receiving the confirmation messages from each slave node, the leader node deems the new log sequenced successfully.

[0039] In step S105, if the leader node is abnormal, each slave node votes to elect a new leader node as the target leader node based on the trust management mechanism. Each slave node then sequences new logs based on the consensus sequencing mechanism. After the new logs are successfully sequenced, the target leader node stores and commits the corresponding new logs. The corresponding new logs are now sequenced.

[0040] In some embodiments, each slave node performs new log sequencing based on a negotiated sequencing mechanism, including: each slave node sorts unsequenced log entries, that is, each slave node determines a sorting scheme for unsequenced log entries (such as target log entries or other inconsistent log entries) through voting statistics to achieve new log sequencing (that is, the slave nodes determine the order of unsequenced log entries through communication and voting, each slave node proposes its own sorting scheme for the unsequenced log entries, and the final sorting scheme is determined through a voting mechanism). The criterion for judging the success of the sequencing is: when an unsequenced log entry is unanimously confirmed by more than half of the nodes in the cluster and inserted into the same position in the log list, the log entry can be considered to have been sequenced, and the above process is repeated until all unsequenced log entries are sequenced.

[0041] The implementation of the negotiation sequencing algorithm requires the following prerequisites:

[0042] (1) Flexibility of log list: The log list allows for the existence of empty log entries, which is significantly different from the requirement in the Raft protocol that the log list must be continuous.

[0043] (2) Success criteria for log entry sequencing: If a log entry is consistently located at the same index position by more than half of the nodes in the cluster, the log entry is considered sequenced. At the same time, each index position in the log list can only store a unique and fixed log entry.

[0044] (3) The relationship between log entries and nodes: When a log entry is stored by most nodes in the cluster, the position of the log entry can be determined through negotiated sequencing; conversely, when a log entry is successfully sequenced through negotiated sequencing, most nodes in the cluster must have stored the log entry.

[0045] The data structure of the log list in the cluster node is designed by combining arrays and linked lists. The array is used to store normal log entries, while the linked list records the log entries that conflict at a specific index position. Each unit of this data structure contains not only the actual command of the log, but also Log_Id (a unique number that identifies the log), Log_Time (a timestamp that records the log, used to identify the generation time of the log), and Log_Num (indicates the number of log entries that conflict with the current log during the sequencing process, and its default value is initialized to 0). The node log list structure in the cluster is shown in the attached figure. Figure 3 shown.

[0046] In this embodiment, combined with Figure 4 As shown, Figure 4 A flow chart of log sorting is provided. First, the status of the leader node is confirmed. If the leader node is in normal status, the new log is sorted directly; if the leader node is abnormal, the consensus sequencing mechanism is triggered, and each slave node determines whether the new log can be sorted through a voting mechanism (that is, each slave node votes to sequence the unsequenced log entries). The voting result (if the voting result is that the majority agrees on the sequencing result, the log is submitted; otherwise, the log is temporarily cached) determines whether the log is submitted (that is, when each slave node completes the sequencing of the unsequenced log entries through consensus through voting) or is temporarily cached. When the new log is successfully sorted, the new leader node stores the sequenced new log in the persistent storage and notifies the client (that is, the cloud control platform).

[0047] The distributed database consistency method of the vehicle cloud control platform based on intelligent networking according to the embodiment of the present disclosure is adopted. The generated target log entries are copied to each slave node through the leader node. If the copy is successful, the leader node can quickly detect the new logs of each slave node based on the anti-entropy mechanism, so as to quickly determine whether the new logs of each slave node are consistent with the new logs of the leader node. If the new log of any slave node is not consistent with the new log of the leader node, each slave node detects the status of the leader node. If the status of the leader node is normal, the leader node sorts the new logs of each slave node to be sequenced based on the incremental synchronization strategy, that is, only synchronizes the set of log entries in the logs of each node to be sequenced that are inconsistent with the logs of the leader node, so as to efficiently perform node consistency maintenance and ensure data consistency. If the status of the leader node is abnormal, a new leader node is voted as the target leader node based on the trust management mechanism to ensure data availability, and each slave node sequences the new logs based on the negotiated sequencing mechanism.

[0048] In this way, when the leader node is in a normal state, new logs are sequenced for each node to be sequenced based on the anti-entropy mechanism and incremental synchronization strategy to ensure data consistency. When the leader node is in an abnormal state, each slave node votes to elect a new leader node as the target leader node based on the trust management mechanism to ensure data availability, and each slave node sequences new logs based on the negotiated sequencing mechanism to ensure data consistency, thereby achieving a distributed database system that can take into account both data consistency and availability in high-failure-rate scenarios such as smart connected vehicles.

[0049] In addition, when dealing with high-load data consistency synchronization, the existing related Raft algorithm has problems such as the leader node becoming a performance bottleneck, low log synchronization efficiency, and high data consistency check overhead, making it difficult to meet the consistency requirements of the intelligent connected platform for high availability and high performance. The disclosed embodiment optimizes the Raft algorithm and combines a segmented log synchronization method based on negotiated sorting and anti-entropy mechanism with a trust management mechanism to improve the consistency guarantee of distributed databases in the intelligent connected monitoring platform. The system achieves strong consistency guarantees across nodes, effectively improving data reliability and system stability in high concurrency and network partitioning scenarios. Consistency management between edge nodes, regional nodes and central nodes is implemented in a multi-layer architecture, providing strong data support capabilities for the platform's real-time monitoring, intelligent scheduling and security management, and promoting the application and development of intelligent connected vehicle monitoring platforms in complex distributed environments.

[0050] Preferably, the leader node detects whether the new log of each slave node is consistent with the new log of the leader node based on the anti-entropy mechanism, including: the leader node sends a first hash value to each slave node; wherein the first hash value represents the hash value of the log summary of the leader node's new log; each slave node compares the corresponding second hash value with the first hash value respectively to obtain the comparison result corresponding to each slave node; wherein the second hash value represents the hash value of the log summary of the slave node's new log; for each slave node, if the comparison result is consistent, the first information is fed back to the leader node, and if the comparison result is inconsistent, the second information is fed back to the leader node; the leader node determines the new log of the slave node that feeds back the first information as consistent with the new log of the leader node, and determines the new log of the slave node that feeds back the second information as inconsistent with the new log of the leader node.

[0051] In a distributed database system, maintaining the consistency of node logs is an important part of ensuring system reliability and data consistency. Traditional full log comparison methods are inefficient, especially in large-scale log synchronization scenarios, where the overhead of data transmission and comparison is significant. However, the anti-entropy mechanism based on hash checksum and log summary comparison technology can quickly detect and repair the consistency between log entries. In this way, based on hash checksum and log summary comparison technology, each slave node compares the first hash value with its own second hash value and feeds back the corresponding comparison result to the leader node, allowing the leader node to quickly determine the slave node that needs to perform new log sequencing and the log entries that the slave node needs to synchronize.

[0052] In some embodiments, the log summary is a simplified representation of the log content, typically including key information such as the index of the log entry, the term number (ie, the version number), and the like.

[0053] Preferably, the leader node sequences the new log for each slave node to be sequenced based on the incremental synchronization strategy, including: the leader node determines the set of log entries to be synchronized for each slave node to be sequenced, and sends each set of log entries to be synchronized to the corresponding slave node to be sequenced; wherein the set of log entries to be synchronized represents a collection of inconsistent log entries in the new log of the leader node and the new log of the slave node to be sequenced; each slave node to be sequenced is synchronized based on the corresponding set of log entries to be synchronized.

[0054] In this way, through incremental synchronization, each slave node to be sequenced only synchronizes the set of log entries that are inconsistent with the leader node, thereby effectively reducing the data transmission overhead during the log synchronization process.

[0055] In some embodiments, assuming that the hash value of a log entry is represented by S, the log digest maintained by the slave node is S follower

[0056] , the log summary of the leader node is S leader , then the log consistency check condition is: S follower =S leader That is, if the log summary S maintained by the slave node follower The log summary of the leader node is S leader If they are consistent, the log of the slave node is considered consistent with the log of the leader node and no further processing is required; if they are inconsistent, only the inconsistent log entries are synchronized based on the incremental synchronization strategy. Assuming that the set of inconsistent log entries is ΔL, the cost of its incremental synchronization is C sync It can be expressed as:

[0057]

[0058] In this way, by synchronizing only the incremental log entries ΔL, the data transmission overhead during the log synchronization process can be effectively reduced.

[0059] Preferably, the distributed database system also includes a trust manager. Each slave node votes to elect a new leader node as the target leader node based on the trust management mechanism, including: the trust manager calculates the malicious behavior score of each slave node respectively, and selects multiple first target nodes from each slave node based on each malicious behavior score; the trust manager calculates the global trust of each first target node respectively, and determines the voting priority of each first target node based on the malicious behavior score and global trust of each first target node; each first target node spontaneously converts to a corresponding candidate node; each first target node elects a new leader node as the target leader node from multiple candidate nodes according to the voting priority.

[0060] In the traditional Raft algorithm, the system (i.e., the distributed database system) triggers leader re-election when the leader node fails (i.e., the state is abnormal), which brings costs such as system deactivation, log and snapshot replication, and there will be a significant decrease in availability in harsh or fluctuating network environments. Based on the original Raft algorithm, the disclosed embodiment introduces a malicious node detection mechanism based on the trust management mechanism of node trust and calculates the global trust of each first target node, optimizes the leader election voting and trust evaluation process, and enhances the algorithm's adaptability to node failures, malicious attacks and network fluctuations in a distributed environment. Therefore, when electing a new leader node as the target leader node, the stability and reliability of the election results can be ensured to ensure the availability of data.

[0061] Preferably, the malicious behavior score of each slave node is calculated separately, including: for each slave node: obtaining the number of successful and failed interactions between each second target node and the slave node within time t, wherein the second target node represents the node in the cluster other than the current slave node, and based on the number of successful and failed interactions between each second target node and the slave node, calculating the malicious behavior score of the slave node by the following formula:

[0062]

[0063] Among them, M j (t) is the malicious behavior score of node j within time t, F ij (t) is the number of failed interactions between the second target node i and the slave node j within time t, S ij (t) is the number of successful interactions between the second target node i and the slave node j within time t.

[0064] In some embodiments, a cluster contains nodes 1, 2, 3, 4, and 5. Node 1 is the leader node (currently in an abnormal state), and the remaining nodes (i.e., nodes 2, 3, 4, and 5) are slave nodes. Therefore, the second target nodes corresponding to slave 2 include nodes 1, 3, 4, and 5; the second target nodes corresponding to slave 3 include nodes 1, 2, 4, and 5; the second target nodes corresponding to slave 4 include nodes 1, 3, 4, and 5; and the second target nodes corresponding to slave 5 include nodes 1, 3, 4, and 2. That is, for slave node j, its corresponding second target node i includes the leader node and the remaining slave nodes except slave node j.

[0065] In this way, the malicious behavior score is calculated based on the interaction between the slave node and the corresponding second target nodes within time t, which makes it easier to identify whether the slave node has abnormal behavior (such as frequent failures, forged recommendation trust, etc.) within the time t, and dynamically update the malicious behavior score of each slave node to dynamically determine the credibility of each slave node.

[0066] Preferably, multiple first target nodes are selected from each slave node based on each malicious behavior score, including: marking the slave nodes with malicious behavior scores greater than a preset threshold as malicious nodes; and taking the slave nodes other than the malicious nodes as the first target nodes to obtain multiple first target nodes.

[0067] In this way, slave nodes with malicious behavior scores greater than a preset threshold are marked as exhibiting abnormal behavior and are marked as malicious. These malicious nodes are then removed from all slave nodes, resulting in multiple first-target nodes. Specifically, the first-target nodes are those that exhibit no abnormal behavior when interacting with other nodes. This ensures that malicious nodes cannot become new leader nodes, ensuring the stability and reliability of leader node elections.

[0068] In some embodiments, if (M j (t)>δ), the slave node j is marked as a malicious node and removed from the global trust calculation, where δ is a preset threshold.

[0069] Preferably, the global trust of each first target node is calculated separately, including: obtaining the recommendation weight of each third target node; wherein the third target node represents the nodes in the cluster except the current first target node and each malicious node; for each first target node: obtaining the number of successful and failed interactions between each third target node and the first target node within time t, and determining the local trust of each third target node to the first target node based on the number of successful and failed interactions between each third target node and the first target node, and determining the recommended trust of the first target node based on each local trust and each recommendation weight, and calculating the global trust of the first target node based on each local trust and the recommended trust.

[0070] In this way, when calculating the global trust, the interaction between each malicious node and the first target node is removed, thereby obtaining a more credible local trust and trust evaluation, so as to improve the reliability of the global trust.

[0071] In some embodiments, a cluster contains nodes 1, 2, 3, 4, and 5. Node 1 is the leader node (currently in an abnormal state), the remaining nodes (i.e., nodes 2, 3, 4, and 5) are slave nodes, and node 2 is a malicious node. The first target nodes include nodes 3, 4, and 5. The third target nodes corresponding to the first target node 3 include nodes 1, 4, and 5. The third target nodes corresponding to the first target node 4 include nodes 1, 3, and 5. The third target nodes corresponding to the first target node 5 include nodes 1, 3, and 4. The original leader node (node 1) cannot serve as the first target node, but can serve as the third target node.

[0072] In some embodiments, obtaining the recommendation weight of each third target node includes: determining the recommendation weight of each third target node based on one or more of historical performance, resource contribution, and global trust of each third target node.

[0073] For example, historical performance: The behavior and performance of the third target node in the past can be used to evaluate its reliability. If a third target node has been stable and rarely failed in the past, it may be given a higher recommendation weight. Alternatively, resource contribution: The recommendation weight of the third target node is determined based on its computing power, storage capacity or network bandwidth, that is, nodes with large resource contributions may be given a higher recommendation weight. Alternatively, global trust: Third target nodes with high global trust indicate that they are more trustworthy and have greater influence in the recommendation trust calculation, that is, third target nodes with high global trust may be given a higher recommendation weight.

[0074] Preferably, determining the local trust of each third target node in the first target node based on the number of successful interactions and the number of failed interactions between each third target node and the first target node includes:

[0075]

[0076] in, S is the local trust of the third target node m to the first target node n within time t, representing the trust evaluation of the third target node m to the first target node n within time t; mn (t) is the number of successful interactions between the third target node m and the first target node n within time t; F mn (t) is the number of failed interactions between the third target node m and the first target node n within time t.

[0077] In this way, local trust is defined based on the direct interaction results between nodes. It is the trust evaluation of the third target node m on the first target node n within time t, so that a more reliable local trust can be obtained.

[0078] Preferably, determining the recommendation trust of the first target node based on each local trust and each recommendation weight includes:

[0079]

[0080] in, is the recommendation trust of the first target node n within time t, is the local trust of the third target node m to the first target node n within time t; w m is the recommendation weight of the third target node m. Z=NM, where N is the set of nodes in the distributed database system cluster and M is the set of malicious nodes.

[0081] In this way, by calculating the recommendation trust of each first target node, the recommendation trust integrates the recommendation opinions of multiple nodes in a weighted average manner, which can effectively reduce the trust error caused by insufficient direct interaction between nodes and improve the comprehensiveness and stability of the evaluation.

[0082] Preferably, the global trust of the first target node is calculated based on the local trust and the recommended trust: Based on the local trust and the recommended trust, the global trust of the first target node is calculated by the following formula:

[0083]

[0084] in, is the global trust of the first target node n within time t, Z = NM, N is the set (number) of nodes in the distributed database system cluster, and M is the set (number) of malicious nodes; is the local trust of the third target node m to the first target node n within time t; is the recommendation trust of the first target node n within time t; v(t) represents the current network volatility, θ is the threshold that controls the weight balance, and β is the adjustment parameter that controls the sensitivity of weight changes.

[0085] In this way, by dynamically adjusting the value of α(t), the weight distribution of local trust and recommended trust can be adaptively adjusted according to the network status, which can better reflect the credibility of nodes in a dynamic network environment.

[0086] It can be understood that trust is defined as a quantitative indicator of the credibility of a node in a distributed system. The trust management mechanism provided by the embodiment of the present disclosure combines the local trust based on direct interaction and the recommended trust recommended by third-party nodes, and at the same time enhances the adaptability and robustness of the model through a dynamic weight adjustment mechanism.

[0087] Preferably, determining the voting priority of each first target node based on the malicious behavior score and the global trust of each first target node includes: determining the voting priority of each first target node based on the malicious behavior score and the global trust of each first target node by the following formula:

[0088]

[0089] Among them, P n (t) is the voting priority of the first target node n, is the global trust of the first target node n, M n (t) is the malicious behavior score of the first target node n.

[0090] In this way, the leader node election process is optimized by combining a dynamic trust calculation algorithm; during the election, all first target nodes vote according to voting priority, and the candidate node with the highest votes becomes the new leader node.

[0091] Preferably, each first target node is converted into a corresponding candidate node, including: using a machine learning algorithm to predict the node trust trend of each first target node; based on the trust trend of each node, selecting each first target node that meets the preset trend conditions as the fourth target node; and converting each fourth target node into a corresponding candidate node.

[0092] In this way, based on trend prediction, potential high-credibility points can be identified in advance, thereby accelerating the election process while ensuring the stability and reliability of the election results.

[0093] In some embodiments, using a machine learning algorithm to predict the node trust trend of each first target node includes: using a machine learning algorithm to predict the global trust of each first target node; for each target node, based on the predicted global trust and the current global trust, calculating the node trust trend using the following formula:

[0094]

[0095] Where, ΔT m (t) is the node trust trend of the first target node n, is the global trust of the predicted first target node n, is the global trust of the current first target node n, γ is the adjustment coefficient, and Δt is the time interval.

[0096] In some embodiments, the preset trend condition is that the node trust trend is greater than a preset trend threshold. Each first target node selects a new leader node as the target leader node from a plurality of candidate nodes according to a voting priority, including: each fourth target node selects a new leader node as the target leader node from a plurality of candidate nodes according to a voting priority.

[0097] It is understandable that the trust management mechanism provided by the embodiment of the present disclosure, by dynamically adjusting the trust weight, introduces a malicious node detection mechanism, expands the complexity of the trust model, and optimizes the voting and trust evaluation process. Through the improved design of the formula, the algorithm is enhanced to adapt to node failure, malicious attacks and network fluctuations in the distributed environment. The specific process is as follows Figure 5 As shown, Figure 5 A flowchart for determining a leader node based on a trust management mechanism.

[0098] For ease of understanding, combined Figure 6 As shown, the embodiment of the present disclosure provides a flowchart of another method for distributed database consistency of a vehicle cloud control platform based on intelligent networking (this embodiment only shows the log replication step and subsequent steps), the method including:

[0099] Step S201: The leader node distributes the target log entry to each slave node.

[0100] Step S202: Does the leader node receive responses from the majority of slave nodes? If yes, proceed to step S204; otherwise, proceed to step S203.

[0101] Step S203: Log replication fails, and the leader node feeds back failure information to the cloud control platform.

[0102] In step S204, the log is successfully copied, and the leader node sends a feedback of success information to the cloud control platform. Then, step S205 is executed.

[0103] In step S205, the leader node detects that the log of a slave node is inconsistent with that of the leader node based on the hash check and log digest comparison, and then executes step S206.

[0104] In step S206, each slave node detects the status of the leader node. If the status is normal, step S208 is executed; if the status is abnormal, step S207 is executed.

[0105] In step S207, the slave nodes in the cluster negotiate and perform log sequencing, and then execute step S209.

[0106] Step S208: The leader node sequences the new log.

[0107] Step S209: Count the voting information corresponding to the negotiated log ordering to see if it is supported by a majority of slave nodes (the voting information can be counted by the cluster manager of the distributed database system or by a specific node, such as the new leader node). If yes, execute step S210; otherwise, execute step S211.

[0108] Step S210: The logs are sequenced successfully, and the new leader node stores and submits the successfully sequenced logs.

[0109] Step S211: The log is stored in the cache and waits for retry.

[0110] Finally, it should be noted that the above preferred embodiments are only used to illustrate the technical solutions of the present invention and are not limiting. Although the present invention has been described in detail through the above preferred embodiments, those skilled in the art should understand that various changes can be made in form and details without departing from the scope defined by the claims of the present invention.

Claims

1. A distributed database consistency method for a vehicle cloud control platform based on intelligent networking, characterized in that: include: The leader node receives the read and write operation requests sent by the cloud control platform, generates corresponding target log entries, and copies the target log entries to each slave node to obtain new logs corresponding to the leader node and each slave node; If the replication is successful, the leader node detects whether the new log of each slave node is consistent with the new log of the leader node based on the anti-entropy mechanism; If the new log of any slave node is inconsistent with the new log of the leader node, each slave node detects the status of the leader node; If the leader node is in a normal state, the leader node sequences the new logs of each slave node to be sequenced based on the incremental synchronization strategy. After the new logs are sequenced successfully, the leader node stores and submits the corresponding new logs. The slave node to be sequenced represents a slave node that is inconsistent with the new log of the leader node. If the status of the leader node is abnormal, each of the slave nodes votes to elect a new leader node as the target leader node based on the trust management mechanism, and each of the slave nodes sequences the new logs based on the negotiated sequencing mechanism. After the new logs are sequenced successfully, the target leader node stores and submits the corresponding new logs.

2. The method according to claim 1, characterized in that The leader node detects whether the new log of each of the slave nodes is consistent with the new log of the leader node based on the anti-entropy mechanism, including: The leader node sends a first hash value to each of the slave nodes; wherein the first hash value represents a hash value of a log digest of a new log of the leader node; Each of the slave nodes compares the corresponding second hash value with the first hash value to obtain a comparison result corresponding to each of the slave nodes; wherein the second hash value represents a hash value of a log digest of a new log of the slave node; For each of the slave nodes, if the comparison result is consistent, the first information is fed back to the leader node; if the comparison result is inconsistent, the second information is fed back to the leader node; The leader node determines that the new log of the slave node that feeds back the first information is consistent with the new log of the leader node, and determines that the new log of the slave node that feeds back the second information is inconsistent with the new log of the leader node.

3. The method according to claim 2, characterized in that The leader node then sequences new logs for each slave node to be sequenced based on the incremental synchronization strategy, including: The leader node determines a set of log entries to be synchronized for each of the slave nodes to be sequenced, and sends each set of log entries to be synchronized to the corresponding slave node to be sequenced; wherein the set of log entries to be synchronized represents a collection of log entries that are inconsistent between the new log of the leader node and the new log of the slave node to be sequenced; Each of the to-be-sequenced slave nodes is synchronized based on a corresponding set of log entries to be synchronized.

4. The method according to any one of claims 1 to 3, characterized in that Each of the slave nodes votes to elect a new leader node as the target leader node based on the trust management mechanism, including: Calculating malicious behavior scores of the slave nodes respectively, and selecting a plurality of first target nodes from the slave nodes based on the malicious behavior scores; Calculating the global trust of each first target node respectively, and determining the voting priority of each first target node based on the malicious behavior score and the global trust of each first target node; Each of the first target nodes is spontaneously converted into a corresponding candidate node; Each of the first target nodes selects a new leader node as the target leader node from multiple candidate nodes according to the voting priority.

5. The method according to claim 4, characterized in that The respectively calculating the malicious behavior score of each slave node includes: For each of the slave nodes: Obtain the number of successful and failed interactions between each second target node and the slave node within time t, wherein the second target node represents a node in the cluster other than the current slave node, and Based on the number of successful and failed interactions between each of the second target nodes and the slave node, the malicious behavior score of the slave node is calculated using the following formula: Among them, the M j (t) is the malicious behavior score of node j within time t, F ij (t) is the number of failed interactions between the second target node i and the slave node j within time t, S ij (t) is the number of successful interactions between the second target node i and the slave node j within time t.

6. The method according to claim 4, characterized in that The selecting a plurality of first target nodes from each of the slave nodes based on each of the malicious behavior scores includes: Mark slave nodes whose malicious behavior scores are greater than a preset threshold as malicious nodes; The slave nodes except the malicious node are taken as first target nodes to obtain multiple first target nodes.

7. The method according to claim 6, characterized in that The respectively calculating the global trust of each first target node includes: Obtaining a recommendation weight for each third target node; wherein the third target node represents a node in the cluster other than the current first target node and each of the malicious nodes; For each of the first target nodes: Obtain the number of successful and failed interactions between each third target node and the first target node within time t, and Determining the local trust of each third target node to the first target node based on the number of successful interactions and the number of failed interactions between each third target node and the first target node, and Determining the recommendation trust of the first target node based on each of the local trusts and each of the recommendation weights, and The global trust of the first target node is calculated based on the local trusts and the recommended trusts.

8. The method according to claim 4, characterized in that The determining the voting priority of each first target node based on the malicious behavior score and the global trust of each first target node includes: The voting priority of each first target node is determined based on the malicious behavior score and global trust of each first target node using the following formula: Among them, P n (t) is the voting priority of the first target node n, is the global trust of the first target node n, M n (t) is the malicious behavior score of the first target node n.

9. The method according to claim 4, characterized in that Converting each of the first target nodes into a corresponding candidate node includes: Predicting the node trust trend of each of the first target nodes using a machine learning algorithm; Based on the trust trends of the nodes, selecting the first target nodes that meet the preset trend conditions as the fourth target nodes; Each of the fourth target nodes is converted into a corresponding candidate node.

Images