Precise time service distributed transaction consistency guarantee method and terminal

Abstract

The invention provides a distributed transaction consistency guaranteeing method for precise time service and a terminal. Comprising the steps of obtaining a transaction request of a distributed system; receiving a standard time signal sent by an external precision event source, and generating a global timestamp of the transaction request based on the standard time signal; based on the global timestamp, establishing a strict partial order relationship of transactions corresponding to the transaction request, and performing global sorting on the transactions according to the strict partial order relationship to obtain a target transaction sequence; performing consistency verification with the target transaction sequence based on the strict partial order relationship; and on the basis of the target transaction sequence and the verification result, submission or rollback operation corresponding to the transaction request is executed in sequence. Through external precise timing and strict partial sequence theories, the distributed transaction clock and delay problems are solved, and the system performance is improved while high consistency is guaranteed.

Description

Technical Field

[0001] This invention relates to the field of distributed database transaction processing technology, and in particular to a method and terminal for ensuring consistency of distributed transactions with precise time synchronization. Background Technology

[0002] Currently, distributed database systems primarily rely on mechanisms such as logical clocks and vector clocks to ensure transaction consistency. However, these methods suffer from clock drift and network latency uncertainties in large-scale distributed environments, leading to inaccurate transaction ordering and failing to guarantee strong consistency. While traditional two-phase commit and three-phase commit protocols can guarantee consistency, they incur significant performance overhead and are prone to blocking in network partitioning scenarios. GPS-based time synchronization solutions are limited by GPS signal coverage and accuracy, and cannot provide reliable time synchronization services in indoor environments and specific geographical locations. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a method and terminal for ensuring the consistency of distributed transactions with precise time synchronization, so as to achieve efficient and reliable consistency guarantee of database transactions in a distributed environment.

[0004] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A method for ensuring consistency in distributed transactions with precise time synchronization includes: Obtain transaction requests from a distributed system; Receive a standard time signal sent from an external precision time source, and generate a global timestamp for the transaction request based on the standard time signal; Based on the global timestamp, a strict partial order relationship is established for the transactions corresponding to the transaction request, and the transactions are globally sorted according to the strict partial order relationship to obtain the target transaction sequence; Consistency verification is performed based on the strict partial order relation and the target transaction sequence; Based on the target transaction sequence and the verification results, the commit or rollback operations corresponding to the transaction requests are executed sequentially.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A precision time-synchronized distributed transaction consistency guarantee terminal includes a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, it implements the various steps in the aforementioned precision time-synchronized distributed transaction consistency guarantee method.

[0006] The beneficial effects of this invention are as follows: By introducing an external precise time source as a globally reliable timing benchmark and combining strict partial order theory with an adaptive verification mechanism, high determinism and high performance transaction consistency guarantees are achieved in distributed systems. A strict partial order relationship between transactions is established using global timestamps to achieve global sorting, ensuring that all nodes form a completely consistent and logically serializable global view of the transaction execution order. An innovative dynamic adaptive mechanism, rather than a fixed strategy, is adopted, which can adaptively reduce verification overhead under high system load and guarantee the highest level of consistency under low load. An architectural paradigm of "global sorting and adjudication first, then deterministic execution" is formed. This design completely avoids distributed coordination and conflict rollback during the transaction execution phase, simplifies system complexity, and provides a clear log replay basis for fault recovery, improving system reliability and operational efficiency. Therefore, in scenarios with stringent consistency requirements, a distributed transaction processing solution with high performance, high reliability, and high scalability is provided. Attached Figure Description

[0007] Figure 1 A flowchart illustrating the steps of a distributed transaction consistency guarantee method with precise time synchronization provided in an embodiment of the present invention; Figure 2 A schematic diagram illustrating the working principle of a distributed transaction consistency guarantee method with precise time synchronization provided in an embodiment of the present invention; Figure 3 A schematic diagram of the structure of a distributed transaction consistency guarantee terminal with precise time synchronization provided in an embodiment of the present invention; Figure 4 A schematic diagram of a distributed transaction consistency guarantee system with precise time synchronization provided in an embodiment of the present invention; Label Explanation: 1. A distributed transaction consistency guarantee system with precise time synchronization; 2. Processor; 3. Memory. Detailed Implementation

[0008] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0009] Please refer to Figure 1 A method for ensuring consistency of distributed transactions with precise time synchronization, comprising steps 110 to 150.

[0010] Step 110: Obtain transaction requests from the distributed system. For example, obtain transaction requests from the database.

[0011] Step 120: Receive the standard time signal sent by an external precise event source, and generate a global timestamp for the transaction request based on the standard time signal. For example, receive the standard time signal sent by the external precise event source through a Beidou time service receiver, and generate a global timestamp for the transaction request according to the standard time signal.

[0012] Step 130: Based on the global timestamp, establish a strict partial order relationship for the transactions corresponding to the transaction requests, and perform a global sorting on the transactions according to the strict partial order relationship to obtain the target transaction sequence. For example, the strict partial order relationship refers to a binary relationship between transactions that satisfies irreflexivity, antisymmetry, and transitivity. Specifically, for any two transactions Ti and Tj, if the global timestamp of transaction Ti is earlier than the global timestamp of transaction Tj, then Ti is defined to precede Tj, denoted as Ti < Tj, and this relationship satisfies: irreflexivity, that is, there does not exist Ti < Ti; antisymmetry, that is, if Ti < Tj, then there does not exist Tj < Ti; transitivity, that is, if Ti < Tj and Tj < Tk, then Ti < Tk. The process of global sorting includes: First, obtain the set of global timestamps of all pending transactions; then, sort the transactions in the order of the time sequence of the global timestamps. Specifically, compare the global timestamps of any two transactions, and place the transaction with the earlier timestamp in the front; for transactions with the same time part of the timestamp, further compare the node identifiers, and place the transaction with the smaller node identifier in the front; for transactions with the same time part of the timestamp and the same node identifier, then compare the transaction sequence numbers, and place the transaction with the smaller sequence number in the front; through the above multi-level comparison rules, ensure that a unique and definite order can be established between any two transactions; finally, generate the target transaction sequence according to the sorting result, and the arrangement order of the transactions in this sequence strictly follows the strict partial order relationship determined by the global timestamp, ensuring the consistent understanding of the transaction execution order by all distributed nodes.

[0013] Step 140: Perform consistency verification based on the strict partial order relationship and the target transaction sequence. For example, according to the established strict partial order relationship and the obtained target transaction sequence, perform consistency verification on the transactions to verify the consistency of the transactions.

[0014] Step 150: Based on the target transaction sequence and the verification result, sequentially execute the commit or rollback operation corresponding to the transaction request. For example, according to the determined order of the target transaction sequence and the above verification result, sequentially send the operation instructions of commit or rollback to the corresponding nodes.

[0015] As described above, the beneficial effects of this invention are as follows: By introducing an external precise time source as a globally reliable timing benchmark, and combining strict partial order theory with an adaptive verification mechanism, high determinism and high-performance consistency assurance are achieved for distributed transactions. A strict partial order relationship is established using global timestamps to determine the global order, ensuring that all nodes form a completely consistent and serializable execution view, thus eliminating the ordering uncertainty caused by clock drift at the source. A dynamic adaptive verification strategy is adopted to intelligently balance verification overhead and consistency strength according to system load. A reliable architecture of "global order determination first, then conflict-free execution" is formed, completely avoiding distributed coordination and conflict rollback during the execution phase, simplifying system complexity, improving fault recovery efficiency and operational reliability, thereby providing a distributed transaction processing solution with high performance, high reliability, and high scalability for demanding scenarios such as financial transactions and real-time billing.

[0016] Further, step 120 includes steps 121 to 123.

[0017] Step 121: Receive the standard time signal sent by an external precision time source through the time synchronization receiving module. For example, each distributed node receives the standard time signal sent by the satellite in real time through the BeiDou or GPS (Global Positioning System) time synchronization receiver. This signal contains high-precision UTC (Universal Time Coordinated) time information, providing the original time reference for subsequent time synchronization.

[0018] Step 122: Generate a standard time reference based on the standard time signal. For example, decode and correct the received standard time signal to eliminate inherent delays and jitter during signal transmission, and extract a stable and reliable nanosecond-level time reference value as the node's local time reference.

[0019] Step 123: Generate a global timestamp based on the standard time base, the node identifier in the transaction request, and the transaction sequence number. For example, the global timestamp is generated by concatenating the standard time base, node identifier, and transaction sequence number according to a predetermined format. Specifically, the global timestamp structure includes three parts: the first part is the standard time base, occupying the high-order bits and representing the precise time the transaction request was generated; the second part is the node identifier, occupying the middle bit and used to distinguish different distributed nodes; the third part is the transaction sequence number, occupying the low-order bits and used to distinguish different transactions generated by the same node at the same time. The generation process includes: first, obtaining the current standard time base and converting it into a 64-bit integer representing a nanosecond-level timestamp; then, obtaining the node identifier that initiated the transaction request and converting it into a 16-bit integer; next, obtaining the transaction sequence number within that node and converting it into a 16-bit integer; finally, concatenating the above three parts in the order of "time base - node identifier - transaction sequence number" to form a 96-bit global timestamp. For example, assuming the standard time base is 1735689600000000000 nanoseconds, the node identifier is 5, and the transaction sequence number is 128, the generated global timestamp is as follows: convert 1735689600000000000 to 64-bit binary, 5 to 16-bit binary, and 128 to 16-bit binary, then concatenate them sequentially to obtain a 96-bit global timestamp, which can be represented in decimal as 1735689600000000000-5-128. This structured combination method ensures the global uniqueness and strict order of the global timestamp, making transactions generated at different nodes and at different times have a comparable time order across the entire distributed system.

[0020] As described above, by introducing an external, precise time source and establishing a standardized time reference generation process, a unified and reliable time reference is provided for distributed transactions. The composite timestamp generation mechanism, combining node identifiers and transaction sequence numbers, not only ensures the global uniqueness of timestamps but also establishes a clear temporal relationship between transactions from the source, laying a precise temporal foundation for subsequent global sorting and consistency verification. This design fundamentally solves the time inconsistency problem caused by local clock drift and network latency in traditional distributed systems, achieving uniformity and reliability of the time reference in a distributed environment.

[0021] Furthermore, before step 123 generates the global timestamp, steps 1231 to 1233 are included.

[0022] Step 1231: Collect network status parameters in real time and obtain the current network transmission delay based on the network status parameters. For example, the system continuously collects network status parameters, including current bandwidth utilization, packet round-trip time, packet loss rate, and link congestion level, and obtains the end-to-end transmission delay under the current network conditions based on these network status parameters.

[0023] Step 1232: Calculate the compensation value for the current network transmission delay by combining historical delay data. For example, the calculation process includes: First, extracting historical network transmission delay data within a preset time window from the historical delay database. The historical delay data includes the network transmission delay value at a historical moment and the corresponding network status parameters. Then, establishing a delay prediction model based on the historical delay data. The delay prediction model uses a weighted moving average algorithm or a time series prediction algorithm to predict the expected network transmission delay at the current moment. Next, comparing the current network transmission delay obtained in step 1231 with the expected network transmission delay predicted by the delay prediction model, and calculating the delay deviation value. The delay deviation value is equal to the current network transmission delay minus the expected network transmission delay. Finally, calculating the compensation value based on the delay deviation value. The compensation value is equal to the product of the delay deviation value and a preset compensation coefficient. The compensation coefficient is dynamically adjusted according to the stability of the network status. When the network status is stable, the compensation coefficient is smaller; when the network status fluctuates greatly, the compensation coefficient is larger. Specifically, the calculation formula for the compensation value is: Compensation value = (Current network transmission delay - Expected network transmission delay) × Compensation coefficient. The inputs include: historical latency data, current network transmission latency, and network status parameters; the output is: compensation value, in nanoseconds. Through the above calculation process, the system can dynamically calculate the network transmission latency compensation value required at the current moment to offset the time error introduced by network jitter and path changes.

[0024] Step 1233: Correct the standard time base using the compensation value to obtain the corrected time base. For example, the global timestamp is generated by concatenating the standard time base, node identifier, and transaction sequence number according to a predetermined format. Specifically, the structure of the global timestamp includes three parts: the first part is the standard time base, occupying the high-order field, representing the precise time when the transaction request was generated; the second part is the node identifier, occupying the middle field, used to distinguish different distributed nodes; the third part is the transaction sequence number, occupying the low-order field, used to distinguish different transactions generated by the same node at the same time. The generation process includes: first, obtaining the current standard time base and converting it into a nanosecond-level timestamp represented by a 64-bit integer; then, obtaining the node identifier that initiated the transaction request and converting it into a 16-bit integer; next, obtaining the transaction sequence number within that node and converting it into a 16-bit integer; finally, concatenating the above three parts in the order of "time base - node identifier - transaction sequence number" to form a 96-bit global timestamp. For example, assuming the standard time base is 1735689600000000000 nanoseconds, the node identifier is 5, and the transaction sequence number is 128, the generated global timestamp is as follows: convert 1735689600000000000 to 64-bit binary, 5 to 16-bit binary, and 128 to 16-bit binary, then concatenate them sequentially to obtain a 96-bit global timestamp, which can be represented in decimal as 1735689600000000000-5-128. This structured combination method ensures the global uniqueness and strict order of the global timestamp, making transactions generated at different nodes and at different times have a comparable time order across the entire distributed system.

[0025] As described above, by introducing a dynamic monitoring and compensation mechanism for network latency, the effectiveness and accuracy of global timestamps in real network environments are improved. This mechanism can adaptively track changes in network state and perform real-time corrections at the time reference level, thereby overcoming the accuracy loss problem caused by network uncertainties and fluctuations during the transmission of satellite time signals. This not only ensures the global comparability of timestamps but also provides a highly reliable timing foundation for subsequent establishment of strict partial order relationships and global transaction sorting, enhancing the robustness of distributed transaction processing to complex network environments at the system level.

[0026] Furthermore, step 1232 includes steps 1234 to 1236.

[0027] Steps 1234: Obtain a baseline latency model based on historical latency data. For example, the baseline latency model uses an Autoregressive Moving Average (ARIMA) model, which is used to predict the baseline value of network latency. The input to the model is a historical latency data sequence, including network transmission latency values ​​and corresponding timestamps arranged chronologically within a preset time period (e.g., 24 hours); the output is the predicted baseline latency value, representing the expected latency under normal network conditions. The model establishment process includes: First, extracting the latency data sequence within the preset time period from the historical latency database and preprocessing the data, including removing outliers and smoothing; then, performing a stationarity test on the preprocessed latency data sequence, and if the data is non-stationary, performing differencing to make it stationary; next, determining the parameters of the ARIMA model through autocorrelation function and partial autocorrelation function analysis, including the autoregressive order p, differencing order d, and moving average order q; subsequently, estimating the model parameters using the maximum likelihood estimation method and training to obtain the baseline latency model; finally, evaluating the model's prediction accuracy using a validation dataset, and completing the model establishment when the prediction error meets a preset threshold. The established baseline latency model can reflect the periodic patterns and long-term trends of network latency changes with time, load, etc., providing a benchmark reference for current latency estimation.

[0028] Step 1235: Monitor real-time changes in network status parameters. For example, the system continuously tracks real-time network status parameters, including instantaneous fluctuations in bandwidth utilization, queue length, packet loss event frequency, and route change notifications, to capture transient changes and abnormal events in the network environment.

[0029] Step 1236: Dynamically calculate the compensation value based on the baseline delay model and the real-time changes in network state parameters. For example, using the real-time monitored network state parameters as input, combined with the normal delay level predicted by the baseline delay model, a precise network transmission delay compensation value is dynamically calculated using a preset compensation algorithm. This compensation value reflects the deviation between the current actual network conditions and the predicted value of the baseline model.

[0030] As described above, by constructing a dynamic compensation mechanism that combines baseline latency modeling with real-time monitoring, accurate prediction and adaptive correction of network latency are achieved. This not only effectively smooths the periodic fluctuations of inherent network latency but also enables rapid response to sudden changes in network status, ensuring the timeliness and accuracy of time base calibration. The system can optimize time synchronization accuracy from both historical patterns and real-time states, enhancing the adaptability and robustness of distributed transaction processing in complex and dynamic network environments, and providing a solid guarantee for the reliable establishment of global transaction sequences.

[0031] Further, step 130 includes steps 131 to 134.

[0032] Step 131: Perform total order sorting on transactions based on the global timestamp to obtain the initial transaction sequence. For example, the global timestamp is generated by concatenating the standard time base, node identifier, and transaction sequence number according to a predetermined format. Specifically, the structure of the global timestamp includes three parts: the first part is the standard time base, occupying the high-order field, representing the precise time when the transaction request was generated; the second part is the node identifier, occupying the middle field, used to distinguish different distributed nodes; the third part is the transaction sequence number, occupying the low-order field, used to distinguish different transactions generated by the same node at the same time. The generation process includes: first, obtaining the current standard time base and converting it into a nanosecond-level timestamp represented by a 64-bit integer; then, obtaining the node identifier that initiated the transaction request and converting it into a 16-bit integer; next, obtaining the transaction sequence number within that node and converting it into a 16-bit integer; finally, concatenating the above three parts in the order of "time base - node identifier - transaction sequence number" to form a 96-bit global timestamp. For example, assuming the standard time base is 1735689600000000000 nanoseconds, the node identifier is 5, and the transaction sequence number is 128, the generated global timestamp is as follows: convert 1735689600000000000 to 64-bit binary, 5 to 16-bit binary, and 128 to 16-bit binary, then concatenate them sequentially to obtain a 96-bit global timestamp, which can be represented in decimal as 1735689600000000000-5-128. This structured combination method ensures the global uniqueness and strict order of the global timestamp, making transactions generated at different nodes and at different times have a comparable time order across the entire distributed system.

[0033] Step 132: Analyze the data dependencies between transactions in the initial transaction sequence and construct a causal dependency graph. For example, the system analyzes the data dependencies between each transaction in the initial transaction series and identifies data access associations between transactions. If transaction A writes a certain data item, and transaction B subsequently reads or writes the same data item, a directed edge is established between A and B, representing "A happens before B", thus constructing a directed graph reflecting the causal dependencies between transactions.

[0034] Step 133: Detect and handle conflicts in the causal dependency graph. For example, the system traverses the causal dependency graph to detect conflicting structures that violate serializability constraints, especially circular dependencies that may be caused by read-write dependencies and write-write dependencies. For detected conflicts, the system makes a decision according to preset rules, which may require interrupting certain dependency edges or marking specific transactions as needing to be rolled back, to ensure the acyclicity and logical consistency of the graph.

[0035] Step 134: Perform topological sorting on the causal dependency graph after conflict resolution to generate the target transaction sequence. For example, topological sorting is a linear sorting of nodes in a directed acyclic graph, such that for each directed edge (from node A to node B), node A is always ranked before node B in the sorting result. The specific sorting process includes: First, counting the in-degree of each transaction node in the causal dependency graph, where the in-degree refers to the number of directed edges pointing to that node, representing the number of predecessor transactions that the transaction depends on; then, adding all transaction nodes with an in-degree of 0 to the processing queue, these nodes represent independent transactions that do not depend on any other transactions; next, removing a transaction node with an in-degree of 0 from the processing queue and adding it to the target transaction sequence; for the removed transaction node, traversing all its successor transaction nodes, decrementing the in-degree of these successor nodes by 1, indicating the removal of a dependency; if the in-degree of a successor node becomes 0, then adding that node to the processing queue; repeating the above process of removing nodes, updating in-degree, and adding to the queue until the processing queue is empty. When selecting a transaction node from the queue, if there are multiple nodes with an in-degree of 0, the selection is based on the global timestamp of the transactions corresponding to these nodes, prioritizing transactions with earlier timestamps to ensure that the physical time order is followed as much as possible while satisfying causal dependencies. Through the above topological sorting process, a linear sequence of target transactions is obtained. This sequence not only respects the order of global timestamps but, more importantly, fully conforms to the logical causal dependencies between transactions, representing the final execution plan agreed upon by all distributed nodes.

[0036] As described above, through a multi-stage process from physical time sorting to logical causal relationship verification, a global target transaction sequence is constructed that respects objective temporal order while ensuring logical correctness. This process deeply integrates the physical time benchmark with transaction logical dependencies, utilizing not only the objective temporal basis provided by global timestamps but also ensuring the serializability of the execution sequence through causal dependency analysis and conflict resolution mechanisms. This effectively solves the logical conflict problems that may arise from relying solely on timestamp sorting, providing a reliable transaction ordering mechanism for distributed systems and strictly maintaining data consistency semantics while ensuring performance.

[0037] Further, step 133 includes steps 1331 and 1332.

[0038] Step 1331: Check if there is any intersection between the write operation set of the preceding transaction and the read operation set or write operation set of the following transaction in the causal dependency graph. For example, the system traverses each directed edge in the causal dependency graph and extracts the read and write operation sets of the two transactions connected by the edge. For each edge, the system checks the set of data items involved in the write operations of the preceding transaction (the starting point of the edge) and compares it with the set of read and write operations of the following transaction (the ending point of the edge). If there is at least one common data item, the conflict detection logic is triggered.

[0039] Step 1332: If an intersection exists, a conflict is identified. For example, when the above intersection is detected, the system marks the edge as a "potential conflict edge". For the intersection of read sets, a "read-write conflict" may occur; for the intersection of write sets, a "write-write conflict" may occur. The system records such transaction pairs and their conflict types in the conflict transaction list and triggers the subsequent conflict resolution process to ensure that the final constructed causal dependency graph satisfies the asymmetry and acyclicity requirements of strict partial order relations.

[0040] As described above, by accurately identifying the dependencies and overlaps in read and write operations between transactions, potential concurrent conflicts are detected automatically and accurately. It not only captures typical conflict patterns that violate the serializability isolation level, but also provides clear evidence for conflict resolution at the data structure level through fine-grained comparisons at the operation set level. This design transforms conflict management, which traditionally relies on empirical judgment or runtime deadlock detection, into a predictable and formally verifiable process, improving the determinism and reliability of distributed transaction processing.

[0041] Further, step 140 includes steps 141 to 144.

[0042] Step 141: Dynamically divide the time window for consistency checks based on transaction requests. For example, the system adopts a dynamic windowing strategy based on the timestamp distribution density of current transactions, the complexity of transaction operations, and the real-time load of the system. By analyzing the temporal locality of transactions and the system's processing capacity, transactions with consecutive or similar timestamps are grouped into the same time window.

[0043] Step 142: Within the time window, verify whether the transaction operations corresponding to the transaction request meet the preset consistency constraints. For example, the system performs parallel verification on all transactions within each time window, checking whether their read and write operations meet preset consistency constraints such as the serializable isolation level. The verification process includes version conflict checks on the transaction read and write sets, and verification of data dependencies between transactions, ensuring that the execution results of transactions within the window are logically equivalent to a certain serial execution sequence.

[0044] Step 143: Within adjacent time windows, verify the consistency of the causal order of transactions across time windows. For example, for transactions spanning adjacent time windows, the system checks whether the happens-before causal dependency between them is consistent with the strict partial order relationship established based on the global timestamp. By comparing the timestamp order and data dependencies of transactions spanning windows, it ensures that the global causal order of transactions between windows has not been disrupted by window partitioning, maintaining the logical correctness of the overall transaction flow.

[0045] Step 144: Determine the transaction status based on the verification results and preset business rules. For example, the system combines the verification results with preset business priorities, data sensitivity rules, and the current service level agreement to make a final decision on each transaction. If the transaction passes all consistency constraint checks and conforms to the business rules, it is marked as "committable"; if it violates constraints or conflicts with business rules, it is marked as "requires rollback". This decision will serve as the clear basis for subsequent execution steps.

[0046] As described above, a transaction consistency verification mechanism that balances efficiency and correctness is constructed by employing a strategy combining dynamic time window partitioning and cross-window causal verification. This method not only improves verification throughput through parallel processing within the window but also ensures global logical consistency through cross-window causal order verification, effectively solving the dilemma of inefficiency in traditional serial verification methods and the potential disruption of causal relationships by fixed window partitioning. Combined with a multi-dimensional adjudication mechanism based on business rules, the system's flexibility and applicability in real-world application scenarios are further enhanced, providing a rigorous yet efficient verification solution for distributed transaction processing in complex business environments.

[0047] Furthermore, step 141 includes steps 145 and 146.

[0048] Step 145: Evaluate the window size of the time window based on the transaction type and data access pattern. For example, the system first analyzes the type characteristics of the transaction to be verified, such as read transactions, write transactions, or mixed transactions, and their data access patterns, such as sequential access, random access, or range access. For read-intensive windows with locality of access patterns, the system can appropriately increase the window size to improve batch processing efficiency; for write-intensive windows or windows dominated by random access, a smaller window size is used to reduce the probability of collisions and verification complexity.

[0049] Step 146: Dynamically adjust the window size based on real-time system performance metrics. For example, the system continuously monitors key performance indicators such as current CPU utilization, memory usage, I / O throughput, and network latency. When the system load is light, the system can automatically increase the time window size to improve parallel processing efficiency and system throughput; when the system load increases or resources approach saturation, the system dynamically reduces the window size to ensure timely response of consistency verification and prevent system overload.

[0050] As described above, by integrating transaction characteristic analysis and system state awareness, intelligent dynamic adjustment of the consistency verification time window is achieved. This not only fully considers the logical characteristics of the transaction itself, ensuring that window partitioning can effectively utilize data locality and control conflict risks, but also responds in real time to changes in the system's operating state, achieving the optimal balance between resource utilization efficiency and verification processing performance. This dynamically adaptive window management strategy enables the system to maintain a highly efficient and stable working state in complex and ever-changing operating environments, improving the overall performance and robustness of the distributed transaction processing system.

[0051] Furthermore, step 144 also includes steps 1441 to 1443.

[0052] Step 1441: Predefine multi-level consistency guarantee strategies. For example, the system pre-configures a set of consistency guarantee strategies, including strong consistency, sequential consistency, and causal consistency, based on business requirements. Each strategy clearly defines different strength requirements in areas such as transaction read / write operation verification, data visibility guarantees, and concurrency conflict handling, forming a strategy framework that the system can flexibly choose from under different operating conditions.

[0053] Step 1442: Real-time assessment of system performance and resource utilization. For example, the system continuously monitors key performance indicators such as transaction throughput, average response time, CPU and memory utilization, and network bandwidth utilization. Through real-time analysis and trend prediction of these indicators, the system can accurately assess the current operating load, resource pressure status, and potential performance bottlenecks.

[0054] Step 1443: Based on the evaluation results, dynamically select an appropriate consistency level from the multi-level consistency guarantee strategy to determine the transaction status. For example, when the system is under high load and the response time is close to the threshold, the system can automatically downgrade to the causal consistency level for non-core business transactions to reduce verification overhead and improve processing throughput; when the system load is light or when processing critical financial transactions, it automatically upgrades to the strong consistency level to ensure absolute data correctness. Based on the dynamically selected consistency level, the system's logic for judging the transaction status is also adjusted accordingly to achieve the optimal balance between performance and consistency.

[0055] As described above, by constructing a configurable multi-level consistency strategy framework and a system-state-aware intelligent selection mechanism, dynamic adaptive adjustment of the transaction consistency guarantee strength is achieved. This enables the system to flexibly balance the relationship between data consistency and processing performance under different operating environments, based on actual business needs and system load. This not only avoids the resource waste or performance bottlenecks that may result from traditional fixed consistency levels, but also provides a highly elastic and intelligent consistency management solution for distributed systems facing complex and ever-changing business scenarios and operating conditions, improving the overall adaptability and service availability of the system.

[0056] Please refer to Figure 2 The following describes specific application examples of this application. This application can apply the above-mentioned solution to various distributed mission-critical systems with extreme requirements for data consistency, especially in fields such as financial transactions, real-time billing, and distributed ledgers involving multi-node concurrent operations, cross-regional data synchronization, and highly reliable transaction processing.

[0057] Taking a financial institution's distributed core trading system as an example, its transaction processing involves multiple business processes such as account management, transaction execution, and clearing and reconciliation. The specific implementation includes the following steps: S1. Obtain transaction requests from each node in the distributed database system. When processing interbank transfer requests from users, the transaction involves deducting funds from the sending account and adding funds to the receiving account. These two operations may be located on data nodes in different geographical regions. The system receives the client's transfer request, parses the transaction type and the data object being operated on, extracts its consistency requirements and constraints, and aggregates the transaction information to the control center. This is equivalent to step 110 above.

[0058] S2. Utilizing the BeiDou satellite authorization system, a precise nanosecond-level global timestamp is generated for each transaction. Each database node acquires the nanosecond-level UTC standard time signal through a deployed BeiDou time receiver and dynamically supplements it based on network transmission latency. For this transfer transaction, the system combines the node identifier, transaction sequence number, and performs real-time network latency dynamic compensation calculations on the standard time signal to generate a globally unique and precise timestamp. This is equivalent to steps 120 and 121 to 123 above.

[0059] S3. Establish a strict partial order relationship for transactions based on global timestamps to achieve global sorting of transactions in a distributed environment. Within a short period, the system receives hundreds of concurrent transfer and query transactions from different nodes. First, the system performs a total order sort based on the global timestamps of all transactions to obtain an initial transaction sequence and establishes happens-before relationships. Next, it analyzes data dependencies between transactions, checking for read-write conflicts and write-write conflicts, such as consecutive operations on the same account, and constructs a causal dependency graph. The system detects a "write-write conflict" between two transactions attempting to simultaneously modify the balance of the same account, and makes a decision based on timestamp priority, interrupting the dependent edges of the interrupted transactions. Finally, it performs a topological sort on the conflict-free causal dependency graph to generate a linear target transaction sequence recognized by all nodes. This is equivalent to steps 130 and 131 to 134 above.

[0060] S4. The system utilizes a time-window consistency check mechanism to verify the causal relationships and consistency constraints of transactions. It dynamically divides verification time windows based on the current load, grouping similar transactions together. Within each window, it checks in parallel whether each transaction satisfies consistency constraints such as "account balance cannot be negative." Simultaneously, it verifies the causal order of transactions across windows. Combining preset business rules, such as prioritizing strong consistency for large transfers, the system makes a final decision on this batch of transactions, marking all transactions that meet the constraints as "committable," while marking the conflicting transaction that attempted to cause an overdraft as "requires rollback." This is equivalent to steps 140 and 141 to 144 above.

[0061] S5. Based on the consistency verification results of the global sorting, execute transaction commit or rollback operations. The system strictly follows the pre-ordered target transaction sequence, sending instructions to relevant nodes sequentially: executing deduction or addition operations for all "committable" transactions, and performing rollback operations for transactions marked as "requiring rollback." All execution results and corresponding timestamps are recorded in the distributed write-ahead log, and finally, the transaction status update is broadcast to relevant nodes, and the clock offset parameters are synchronously corrected. The system broadcasts the final status to all participating nodes, completing the processing cycle for this batch of transactions. This is equivalent to step 150 above.

[0062] Through the above application examples, this solution implements a complete, accurate, and reliable distributed transaction consistency guarantee system, completing a closed-loop management system from high-precision time synchronization, global ordering, intelligent verification to deterministic execution. This solution effectively addresses core pain points in financial-grade distributed systems, such as disordered sorting caused by clock asynchrony, low performance of traditional distributed transaction protocols, and complex fault recovery. It has significant engineering practical value in ensuring absolute data correctness, improving system throughput, and enhancing operational reliability.

[0063] Please refer to Figure 3A precision time-synchronized distributed transaction consistency guarantee terminal 1 includes a memory 3, a processor 2, and a computer program stored in the memory 3 and running on the processor 2. When the processor 2 executes the computer program, it implements the various steps of a precision time-synchronized distributed transaction consistency guarantee method.

[0064] Please refer to Figure 4 The processor 11 can be a CPU, which can realize BeiDou time synchronization processing, timestamp generation, transaction sorting algorithm, consistency check and conflict detection analysis. The memory 22 can be RAM, which can be used to implement transaction data storage, timestamp caching, dependency graph storage, log record storage, and correction parameter caching. External interfaces include the BeiDou satellite timing receiving interface, the distributed database node communication interface, the transaction request processing interface, and the network latency monitoring interface.

[0065] The beneficial effects of a distributed transaction consistency guarantee terminal based on precise time synchronization are the same as those of the distributed transaction consistency guarantee method based on precise time synchronization mentioned above, and will not be repeated here.

[0066] In summary, this invention constructs a distributed transaction consistency guarantee method and terminal with precise time synchronization. By deeply integrating a high-precision global time benchmark provided by an external precise time source into the entire process of distributed transaction processing, a transaction consistency guarantee system with an external trusted time sequence as the core driving engine is constructed, realizing end-to-end deterministic scheduling and adjudication from global timestamp generation, strict partial order establishment, consistency verification to final execution.

[0067] The system can automatically establish a strict partial order relationship between transactions based on the global timestamp obtained for each transaction, and generate an unambiguous global execution sequence accordingly, providing a unique and reliable logical foundation for transaction ordering in a distributed environment. For different network conditions and system loads, the system achieves an intelligent balance between transaction verification processes and resource consumption through dynamic time windows and adaptive consistency level adjustment mechanisms.

[0068] Meanwhile, based on a pre-defined strict partial order theory and consistency constraint rules, the system defines a structured conflict detection and state adjudication mechanism in transaction sorting and verification. This serves as the core logic engine for distributed transaction processing, thereby achieving a coordinated guarantee of high throughput and strong consistency. Regarding state synchronization, the system standardizes and broadcasts the timestamps, sorting results, and verification logs generated during transaction execution to multiple nodes. This data is then used to continuously calibrate the local clock and optimize latency compensation strategies, ensuring the long-term reliability of the time base.

[0069] Based on the architectural paradigm of "global sorting and adjudication first, followed by deterministic execution," the system synchronizes and persists the transaction order, conflict relationships, and adjudication results across nodes, achieving global visibility and consistent recognition of the distributed transaction state. This method differs from traditional transaction processing approaches that rely on internal logical clocks or complex coordination protocols. Through external time-driven, strictly partial-order-driven, and adaptive verification-driven approaches, it constructs an efficient, reliable, and scalable distributed transaction processing pipeline, significantly improving transaction sorting accuracy, processing throughput, and system fault tolerance.

[0070] Furthermore, during transaction execution and state synchronization, the system establishes a closed-loop optimization mechanism based on distributed logs and feedback calibration. After a transaction is committed or rolled back, the system can automatically trigger fine-tuning of the time base and optimization of the synchronization strategy based on the status confirmation and clock error feedback of each node. This ensures continuous improvement of timing accuracy before the next round of transaction processing, guaranteeing absolute reliability of consistency in long-term operation. This improves processing efficiency while ensuring the absolute correctness of data in critical business scenarios such as financial transactions and telecommunications billing.

[0071] This system is suitable for distributed application scenarios with extremely stringent data consistency requirements, such as core financial transactions, distributed ledgers, and real-time billing systems, demanding high throughput, low latency, and strong reliability. By constructing a distributed transaction processing system based on external trusted time, mathematically provable ordering, and intelligent adaptive verification, it effectively reduces the complexity of distributed coordination, improves system resource utilization and fault recovery determinism, and provides a verifiable, optimizable, and scalable theoretical and engineering foundation for the large-scale and reliable deployment of strongly consistent distributed systems in complex network environments and under high concurrency loads, thus possessing significant industrial application value.

[0072] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for ensuring consistency in distributed transactions with precise time synchronization, characterized in that, include: Obtain transaction requests from a distributed system; Receive a standard time signal sent from an external precision time source, and generate a global timestamp for the transaction request based on the standard time signal; Based on the global timestamp, a strict partial order relationship is established for the transactions corresponding to the transaction request, and the transactions are globally sorted according to the strict partial order relationship to obtain the target transaction sequence; Consistency verification is performed based on the strict partial order relation and the target transaction sequence; Based on the target transaction sequence and the verification results, the commit or rollback operations corresponding to the transaction requests are executed sequentially.

2. The method for ensuring consistency of distributed transactions with precise time synchronization according to claim 1, characterized in that, The process of receiving a standard time signal from an external precise time source and generating a global timestamp for the transaction request based on the standard time signal includes: The time receiving module receives the standard time signal sent by the external precision time source. A standard time reference is generated based on the aforementioned standard time signal; The global timestamp is generated based on the standard time base, the node identifier and the transaction sequence number in the transaction request.

3. The method for ensuring distributed transaction consistency with precise time synchronization according to claim 2, characterized in that, Before generating the global timestamp, the following steps are included: Real-time acquisition of network status parameters, and determination of the current network transmission delay based on the network status parameters; Calculate the compensation value for the current network transmission delay by combining historical delay data; The standard time base is corrected using the compensation value to obtain the corrected time base.

4. The method for ensuring distributed transaction consistency with precise time synchronization according to claim 3, characterized in that, The calculation of the compensation value for the current network transmission delay by combining historical delay data includes: A baseline latency model is obtained based on the historical latency data; Monitor the real-time changes in the network status parameters; The compensation value is dynamically calculated based on the baseline delay model and the real-time changes in the network state parameters.

5. The method for ensuring consistency of distributed transactions with precise time synchronization according to claim 1, characterized in that, The step of establishing a strict partial order relation for the transactions corresponding to the transaction request based on the global timestamp, and then globally sorting the transactions according to the strict partial order relation to obtain the target transaction sequence includes: The transactions are sorted in total order based on the global timestamp to obtain an initial transaction sequence. Analyze the data dependencies between transactions in the initial transaction sequence and construct a causal dependency graph; Detect and resolve conflicts in the causal dependency graph; The causal dependency graph after conflict resolution is topologically sorted to generate the target transaction sequence.

6. The method for ensuring consistency of distributed transactions with precise time synchronization according to claim 5, characterized in that, The detection and resolution of conflicts in the causal dependency graph includes: Check whether there is an intersection between the set of write operations of the first transaction and the set of read operations or write operations of the subsequent transaction in the causal dependency graph; If there is an intersection, it is determined that there is a conflict.

7. The method for ensuring consistency of distributed transactions with precise time synchronization according to claim 1, characterized in that, The consistency verification based on the strict partial order relation and the target transaction sequence includes: The time window for consistency checks is dynamically divided based on the transaction request; Within the time window, verify whether the transaction operation corresponding to the transaction request meets the preset consistency constraints; Within adjacent time windows, verify the causal order consistency of the transactions across time windows; The transaction status is determined based on the verification results and preset business rules.

8. The method for ensuring consistency of distributed transactions with precise time synchronization according to claim 7, characterized in that, The step of dynamically dividing the consistency check time window according to the transaction request includes: The window size of the time window is evaluated based on the transaction type and data access mode of the transaction. The window size is dynamically adjusted based on real-time system performance metrics.

9. The method for ensuring consistency of distributed transactions with precise time synchronization according to claim 7, characterized in that, The process of determining the transaction status based on the verification results and preset business rules also includes: Predefined multi-level consistency guarantee strategies; Real-time assessment of system performance and resource utilization; Based on the evaluation results, the appropriate consistency level is dynamically selected from the multi-level consistency guarantee strategy to determine the transaction status.

10. A distributed transaction consistency guarantee terminal with precise time synchronization, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement each step of the distributed transaction consistency guarantee method with precise time synchronization as described in any one of claims 1 to 9.

Images