Method and system for building distributed steady-state transaction environment

Abstract

The invention relates to the technical field of distributed transactions, in particular to a distributed steady-state transaction environment building method and system, and the method comprises the following steps: building an independent fragment for a high-frequency target according to the real-time request frequency of a transaction target; combining the low-frequency standard to a shared fragment; based on the fragment type, chain type synchronization is adopted for the independent fragments, and global broadcast synchronization is adopted for the shared fragments; nodes in the backup node group pre-load an intermediate state, and the backup node group directly generates a complete state and takes over when the main node fails; the hash chain is verified in a layered mode according to the topological structure of the fragments, local verification is adopted for the independent fragments, and global arbitration is triggered by the shared fragments; and recovering the backup nodes of the low-frequency target, and redistributing the backup nodes to the backup group or the synchronization path of the high-frequency target. According to the invention, deep coupling of fragmentation, synchronization and fault-tolerant mechanisms can be realized, and the resource utilization rate and the fault recovery speed are improved.

Description

Technical Field

[0001] The present application relates to the technical field of distributed transactions, and in particular to a method and system for building a distributed steady-state transaction environment. Background Art

[0002] As an important part of the modern financial market, the core competitiveness of high-frequency trading depends on the low-latency response and continuous high availability of the trading system. With the exponential growth of trading frequency and data throughput, the traditional centralized architecture can no longer meet market demand due to the risk of single point failure and scalability limitations. Therefore, distributed systems have become the inevitable choice for high-frequency trading infrastructure. However, the existing distributed architecture still faces fundamental technical bottlenecks in high-concurrency scenarios, and its vulnerability is particularly significant during extreme market fluctuations or sudden traffic shocks.

[0003] In the design of distributed trading architecture, the sharding mechanism is the core strategy for dealing with massive transaction data. The currently widely used static sharding solution allocates transaction targets (such as stock codes and futures contracts) to specific nodes through preset rules. Each sharding node needs to maintain a complete order book status, position data and transaction flow records. This strategy can achieve a basic level of load balancing and fault tolerance in a stable market environment, but it causes two major structural defects due to the lack of dynamic adaptability.

[0004] First, the redundant backup mechanism under the solid-state sharding architecture cannot guarantee transaction continuity. To achieve redundancy for fault recovery, existing systems usually replicate data between the master node and the backup node through full data synchronization. When the master node fails, the backup node needs to load the full state snapshot of the current shard from the data cache or storage layer. This process involves reading a large amount of data such as order book depth, unfinished order queue, position change log, etc. from persistent storage. Studies have shown that the full synchronization time of mainstream systems usually reaches 2-5 seconds, resulting in a time window of several seconds to tens of seconds of interruption of trading services. Although this delay can be partially masked by the fault tolerance mechanism in conventional trading scenarios, it will directly lead to serious consequences such as failure of continuous order execution and failure of price discovery mechanism in high-frequency trading: for example, in a flash crash scenario with drastic price fluctuations, millisecond-level order processing interruptions may trigger an avalanche effect of a large number of unexecuted orders, destroying the market liquidity balance and fairness of participants.

[0005] Secondly, fixed sharding leads to a serious disconnect between resource allocation and business needs. Due to the significant dynamic differences in trading popularity among targets, unpopular targets (such as stocks with low liquidity) are idle for a long time, while popular targets (such as high-volatility futures contracts) need to process hundreds of thousands or even millions of TPS requests in a specific period of time. The static sharding architecture evenly distributes hot and cold targets on a fixed number of nodes, resulting in the coexistence of resource waste and computing power bottlenecks: on the one hand, the computing, storage and network resources of low-load shards are in a sub-healthy state for a long time; on the other hand, hot shards may experience chain reactions such as thread pool overflow and queue blocking under the impact of sudden traffic, ultimately leading to a sharp drop in local node performance. Industry surveys show that in the existing system, in the scenario where the single-day amplitude of the CSI 300 Index constituent stocks exceeds 10%, the average response delay of the key target shards may increase by 3-5 times, directly restricting the execution efficiency of high-frequency algorithm strategies.

[0006] To alleviate the above contradictions, the technical community has proposed several targeted improvement plans, but none of them have broken through the underlying limitations of the existing architecture. Some plans attempt to shorten data synchronization time by optimizing the synchronization protocol (such as introducing lightweight log compression and adding dedicated channels for network transmission). Actual measured data shows that even if the synchronization delay is optimized to the millisecond level, full synchronization still needs to complete a transmission volume that is linearly related to the size of the data set. When the shard contains millions of pending orders, the synchronization time will still exceed the acceptable threshold. Another type of solution focuses on expanding the node scale and redundancy level, such as using a multi-active architecture or server cluster to improve disaster recovery capabilities, but it falls into the dilemma of "resource dilution": although the addition of new nodes can share the computing pressure, the static allocation logic of fixed shards leads to a lack of targeted resource expansion, which in turn increases the overall burden of system management and redundant data traffic.

[0007] The deeper contradiction stems from the misalignment between the architecture design and business dynamics: the static sharding mechanism cannot perceive the real-time changes in trading popularity. When the popularity of the target changes suddenly in a short period of time (such as the sudden increase in ETF trading volume caused by the release of major policies), the corresponding fixed node may be overwhelmed by the traffic peak within a few minutes, thereby triggering a chain reaction of the data synchronization mechanism. The trade-off between the full synchronization solution and the incremental synchronization technology constitutes another core paradox - although the complete data copy can ensure business continuity, the strong positive correlation between the synchronization time and the data size makes it unable to meet the millisecond-level fault recovery requirements of high-frequency trading scenarios; and the solution that relies entirely on incremental synchronization will lead to data integrity risks due to network packet loss or inconsistent node status, which poses a fundamental challenge to the business characteristics of "precise matching" and "non-rollback" in high-frequency trading.

[0008] In summary, the inherent defects of the existing distributed transaction architecture have formed a technical closed loop: the static allocation of shards and the full synchronization mechanism not only cause resource waste, but also aggravate the performance bottleneck due to the inability to dynamically respond to business needs. To achieve a breakthrough, it is urgent to build a distributed architecture that can autonomously perceive load changes, dynamically adjust resource allocation and data synchronization strategies, and realize elastic expansion of computing resources while ensuring millisecond-level fault recovery capabilities. Summary of the invention

[0009] In order to solve the above problems, the present application provides a method and system for building a distributed steady-state trading environment.

[0010] In the first aspect, the present application provides a method for building a distributed stable trading environment, which adopts the following technical solutions: A method for building a distributed stable trading environment includes the following steps: According to the real-time request frequency of the transaction target, create independent shards for high-frequency targets, and bind synchronization paths and backup node groups to independent shards; merge low-frequency targets into shared shards, and bind backup node groups to each shard; Based on the shard type, chain synchronization is used for independent shards, and global broadcast synchronization is used for shared shards; The nodes in the backup node group preload the intermediate state. When the primary node fails, the backup node group directly generates the complete state and takes over. The hash chain is verified hierarchically according to the shard topology, where independent shards use local verification and shared shards trigger global arbitration; Recycle the backup nodes of low-frequency targets and reallocate them to the backup groups or synchronization paths of high-frequency targets.

[0011] In one embodiment, the step of creating independent shards for high-frequency targets according to the real-time request frequency of the transaction targets specifically includes: Track the number of requests per unit time for each transaction object; When the number of requests for a transaction target is greater than the preset frequency, several nodes are allocated from the global resource pool to form independent shards.

[0012] In one embodiment: the synchronization path of the local chain synchronization is a master node, a synchronization path node and a backup node group in sequence, and the incremental event is transmitted hop by hop along the preset path; The global broadcast synchronization method is to send incremental events to the global resource pool, and the events are dynamically processed by idle nodes in the pool.

[0013] In one embodiment: the number of synchronization path nodes of the independent shard is positively correlated with the real-time request frequency of the shard, and the nodes of the synchronization path are selected according to physical location adjacency, the difference in the length of the unprocessed event queue between path nodes, and node latency.

[0014] In one embodiment: the number of nodes in the backup node group is dynamically allocated according to the real-time request frequency of the shard.

[0015] In one embodiment: the steps of dynamically allocating the number of nodes in the backup node group according to the real-time request frequency of the shard specifically include: The number of nodes in the backup node group of the independent shard is determined based on the basic backup number and the real-time request frequency; The number of nodes in the backup node group of the shared shard is determined based on the remaining number of nodes in the global resource pool and the shard weight.

[0016] In one embodiment: the verification steps of the independent shard specifically include: After the master node processes a transaction, it generates an event and calculates a hash chain; The master node sends the generated event and hash chain to the synchronization path nodes; After each synchronization path node receives the event, it verifies the continuity of the hash chain. All synchronization path nodes form a local verification group, and when more than half of the synchronization path nodes confirm that the hash chain is valid, it means the verification passes; When the verification fails, the independent shard rolls back the data from the synchronization path nodes.

[0017] In one embodiment: the verification steps of the shared shard specifically include: Generate an event and a hash chain, and broadcast them to all nodes in the resource pool; Idle nodes preempt to process the event, calculate the local hash chain and return the result; Statistical sum of the voting weights of all nodes for the current hash chain. When the sum of the weights exceeds the preset weight threshold, it means the verification passes; among them, the voting weight of each node is determined based on historical behavior; When the verification fails, select the node with the highest historical voting weight as the arbiter, and its decision overrides other nodes.

[0018] In one embodiment: the backup nodes of the recycled low-frequency targets are allocated according to priorities, and the priorities are the high-frequency targets whose current load rate exceeds the load threshold, the independent shards whose average latency of the synchronization path nodes exceeds the latency threshold, and the shared shards whose available number of nodes in the global resource pool is lower than the preset threshold in turn.

[0019] In a second aspect, the present application provides a method and system for building a distributed steady-state transaction environment, adopting the following technical solutions: A system for building a distributed steady-state trading environment, characterized by comprising: The dynamic sharding module creates independent shards for high-frequency targets according to the real-time request frequency of the transaction targets, and binds synchronization paths and backup node groups to the independent shards; merges low-frequency targets into shared shards, and binds backup node groups to each shard; Data synchronization module, based on the shard type, uses chain synchronization for independent shards and global broadcast synchronization for shared shards; Pre-activate the backup module, pre-load the intermediate state of the nodes in the backup node group, and when the primary node fails, the backup node group directly generates a complete state and takes over; The consistency verification module verifies the hash chain hierarchically according to the shard topology structure. Independent shards use local verification, and shared shards trigger global arbitration. The resource recovery module recovers the backup nodes of low-frequency targets and redistributes them to the backup groups or synchronization paths of high-frequency targets.

[0020] In summary, this application has the following beneficial effects: The dynamic sharding method formed by classifying high- and low-frequency targets can autonomously sense load changes, dynamically adjust resource allocation and data synchronization strategies, achieve deep coupling of sharding, synchronization, and fault-tolerant mechanisms, and improve resource utilization and fault recovery speed. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 is a flow chart of a method for building a distributed steady-state trading environment in this embodiment; Figure 2 is a flow chart of the method for allocating backup node groups in this embodiment; Figure 3 is a flow chart of the verification method of independent shards in this embodiment; Figure 4 is a flow chart of the verification step method of the shared shard in this embodiment; Figure 5 It is a framework diagram of a distributed steady-state trading environment system in this embodiment. DETAILED DESCRIPTION

[0022] The present application is further described in detail below in conjunction with the accompanying drawings.

[0023] To more clearly understand the purpose, technical solutions and advantages of the present application, the present application is described and illustrated below in conjunction with the accompanying drawings and embodiments. However, it should be understood by those of ordinary skill in the art that the present application can be implemented without these details. In some cases, in order to avoid unnecessary descriptions that make various aspects of the present application obscure, well-known methods, processes, systems, components and / or circuits that have been described at a higher level will not be described in detail. For those of ordinary skill in the art, it is obvious that various changes can be made to the embodiments disclosed in the present application, and without departing from the principles and scope of the present application, the general principles defined in the present application can be applied to other embodiments and application scenarios. Therefore, the present application is not limited to the embodiments shown, but conforms to the broadest scope consistent with the scope claimed for protection of the present application.

[0024] It should be noted that the description of these embodiments is used to help understand the present invention, but does not constitute a limitation of the present invention. In addition, the technical features involved in each embodiment of the present invention described below can be combined with each other as long as there is no conflict between them.

[0025] In the description of this application, "several" means one or more, "more" means more than two, "greater than", "less than", "exceed", etc. are understood to exclude the number itself, and "above", "below", "within", etc. are understood to include the number itself. If there is a description of "first" or "second", it is only used to distinguish the technical features, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features or implicitly indicating the order of the indicated technical features.

[0026] In the description of the present application, the description with reference to the terms "one embodiment", "some embodiments", "illustrative embodiments", "examples", "specific examples", or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any one or more embodiments or examples.

[0027] The embodiment of the present application discloses a method for building a distributed steady-state trading environment.

[0028] like Figure 1 As shown, a method for building a distributed steady-state trading environment includes the following steps: S100. Create independent shards for high-frequency targets according to the real-time request frequency of the transaction targets, and bind synchronization paths and backup node groups to the independent shards; merge low-frequency targets into shared shards, and bind backup node groups to each shard.

[0029] Among them, according to the real-time request frequency of the transaction target, the steps of creating independent shards for high-frequency targets specifically include: Track the number of requests per unit time for each transaction target, such as the number of orders placed per second.

[0030] When the number of requests for a transaction target is greater than the preset frequency, several nodes are allocated from the global resource pool to form independent shards.

[0031] The core idea of ​​this sharding strategy is to dynamically allocate resources according to the real-time request frequency of the transaction target, and separate high-frequency transaction targets (such as hot stocks) from low-frequency targets (such as unpopular stocks). It has three core goals. The first is to improve system throughput. The transaction volume of high-frequency targets is concentrated, and dedicated shards are required to provide low latency and high concurrency processing capabilities. The second is to optimize resource utilization. Low-frequency targets do not need to monopolize resources, and resource waste can be avoided by sharing shards. The third is to enhance system elasticity and dynamically adjust the sharding strategy so that the system can flexibly respond to load changes.

[0032] Among them, the efficiency advantage of using independent shards for high-frequency targets is: first, there is a guarantee of dedicated resources. High-frequency transactions require fast responses. Independent shards allocate exclusive computing, network and storage resources for high-frequency targets to avoid competing for resources with other targets (especially low-frequency targets). Secondly, it can reduce cross-shard delays. The transaction links within independent shards are short, and the delay of synchronization paths (such as chain synchronization) is lower, thereby improving transaction throughput and response speed.

[0033] Cost-effectiveness of sharing shards for low-frequency targets: First, resource pools can be merged, and low-frequency targets share the same set of resources through shared shards, avoiding the allocation of independent resources for frequently idle targets and reducing the waste of servers, bandwidth and storage. Second, it has dynamic expansion flexibility. When a low-frequency target suddenly turns to a high frequency (such as a hot market event), the system can quickly transfer the transaction of the target from the shared shard to the newly created independent shard.

[0034] S200. Based on the shard type, chain synchronization is used for independent shards, and global broadcast synchronization is used for shared shards.

[0035] Chain synchronization transmits data through the interaction between nodes, rather than all nodes requesting data from a single master node. This distributed transmission method can significantly reduce the bandwidth pressure of the master node and improve data distribution efficiency. For example, independent shards of high-frequency targets require real-time synchronization of a large amount of transaction data. The parallel transmission capability of chain synchronization can avoid resource competition and delay accumulation between nodes.

[0036] The nodes in the chain-synchronized shards form a direct transmission path, avoiding the redundant transmission and waiting time of global broadcasts. The real-time requirements of high-frequency transactions (such as high-frequency quantitative transactions) can be quickly completed through short paths and local synchronization, ensuring that the transaction confirmation delay is controlled at the millisecond level, achieving the effect of low latency and high throughput.

[0037] Low-frequency targets in shared shards (such as unpopular assets or low-liquidity transactions) have low transaction frequencies, but their consistency requirements are extremely high (for example, cross-asset settlements must be globally confirmed). Global broadcast ensures that all replica nodes obtain the latest data, avoiding the risk of "forks" or "double spending" caused by some nodes not being synchronized.

[0038] This design takes into account the low latency and high throughput requirements of high-frequency scenarios and the global consistency of low-frequency scenarios, while combining the randomness and dynamics of sharding technology to achieve resource optimization, security enhancement and scalability breakthroughs.

[0039] Specifically, the synchronization path of local chain synchronization is the master node, synchronization path node and backup node group in turn, and transmits incremental events hop by hop along the preset path. Among them, the number of synchronization path nodes of independent shards is positively correlated with the real-time request frequency of the shards, and the nodes of the synchronization path are selected based on the physical location proximity, the difference in the length of the unprocessed event queue between the path nodes, and the node delay.

[0040] Among them, physical location proximity means giving priority to nodes in the same computer room or low-latency network area. When the difference in the length of the unprocessed event queue between path nodes exceeds the preset threshold, it means that the load is large, so it is not given priority. And when the delay of a node exceeds the preset threshold, the link is automatically bypassed to rebuild the node and realize dynamic path switching. The nodes of the synchronous path are selected by the above three conditions to ensure low latency while avoiding path node overload.

[0041] In high-frequency trading scenarios, independent shards may face tens of thousands of order requests per second, far exceeding the processing capacity of ordinary shards. Increasing the number of nodes in the shard synchronization path can increase the number of relay nodes, which can ensure the efficiency and stability of data transmission under high load.

[0042] For example, the original path is primary node → node 1 → node 2 → backup node, and the single-hop delay is 2ms (total delay is 6ms).

[0043] After adding the relay node, the path becomes: Primary node → Node A (1ms) → Node B (1ms) → Backup node (total delay 3ms); Primary node → Node C (1ms) → Node D (1ms) → Backup node (total delay 3ms).

[0044] Data is transmitted in two parallel paths, the actual effective delay is reduced to 3ms, and the single-hop delay is reduced to 1ms due to load reduction.

[0045] The global broadcast synchronization method is to send incremental events to the global resource pool, and the idle nodes in the pool dynamically process the events. Its core goal is to allow idle nodes to dynamically process events through a decentralized broadcast mechanism and maximize resource utilization by dynamically grabbing orders.

[0046] S300, the nodes in the backup node group preload the intermediate state, and when the primary node fails, the backup node group directly generates a complete state and takes over.

[0047] This step implements zero-perception fault switching. In the traditional mode, the master-slave mode is required. The backup node needs to wait for the master node to fail before starting to synchronize data. There is a switching delay of several seconds to several minutes, during which the system may suspend service.

[0048] In this embodiment, the backup node group preloads the intermediate state of the master node (such as position holdings, order books, etc.), but does not submit it to the database for the time being, ensuring that when the master node fails, there is no need to resynchronize the data, and the business can be taken over immediately, achieving sub-second switching. In addition, the intermediate state is only stored in memory, and the computing overhead is reduced by regularly generating snapshots.

[0049] For example, when the master node processes the event "buy 100 shares", the backup node will mark the position +100 shares in the memory after preloading, but no actual deduction will be made.

[0050] When the primary node fails, the backup node can directly generate the final state based on the preloaded intermediate state and the latest events, and then submit the final state to the database to complete the transaction takeover.

[0051] S400. The hash chain is verified hierarchically according to the shard topology structure, wherein independent shards use local verification and shared shards trigger global arbitration.

[0052] Different verification methods are used for different shards to achieve a balance between latency and throughput, optimize resource utilization, improve security, and enhance scalability.

[0053] Local verification of independent shards has the advantages of fast transaction confirmation, high throughput support, and consistency guarantee within the shard.

[0054] Fast transaction confirmation: Only nodes within the group need to verify the hash chain (such as 3 to 5 nodes), avoiding coordination of nodes across the entire network and significantly reducing latency. For example, in high-frequency trading scenarios, local verification can compress the confirmation time to less than 10ms, which is suitable for scenarios such as stock trading.

[0055] High throughput support: Local verification reduces network bandwidth usage, enabling independent shards to handle millions of TPS.

[0056] Intra-shard consistency guarantee: Through local hash chain verification, it ensures that the data in the shard cannot be tampered with, while eliminating the waiting time for cross-shard synchronization.

[0057] Global arbitration of shared shards has the advantages of strong consistency of cross-shard transactions and eventual consistency guarantee of data.

[0058] Strong consistency of cross-shard transactions: When a transaction involves multiple shards, consensus must be reached through global arbitration.

[0059] Data eventual consistency guarantee: Through the majority voting of the whole network or the hash chain segment verification, global data inconsistency caused by local failures in the shared shards can be prevented.

[0060] S500: Recover the backup nodes of the low-frequency targets and reallocate them to the backup groups or synchronization paths of the high-frequency targets.

[0061] Recycling the backup nodes of low-frequency targets and reallocating them to the backup groups or synchronization paths of high-frequency targets is an effective dynamic resource management strategy. It provides an efficient resource management solution for distributed trading systems by improving resource utilization, enhancing system elasticity, reducing resource waste, improving system stability, and optimizing system performance. This design can significantly improve the efficiency and stability of the system in practical applications, especially in high-concurrency and high-throughput trading scenarios, providing a strong guarantee for the high performance and reliability of the system.

[0062] In this embodiment, in order to dynamically optimize resource utilization, ensure service quality and improve overall reliability, the backup nodes of the recovered low-frequency targets are allocated according to priority.

[0063] The priorities are divided into three levels, with the needs of the first priority being met first, followed by the second priority, and finally the third priority. Among them, the first priority is the high-frequency target whose current load rate exceeds the load threshold, the second priority is the independent shard whose average delay of the synchronization path node exceeds the delay threshold, and the third priority is the shared shard whose number of available nodes in the global resource pool is lower than the preset threshold.

[0064] In one of the embodiments, the number of nodes in the backup node group is dynamically allocated based on the real-time request frequency of the shard.

[0065] Specifically, Figure 2 As shown, the steps of dynamically allocating the number of nodes in the backup node group according to the real-time request frequency of the shards specifically include: S201. The number of nodes in the backup node group of the independent shard is determined based on the number of basic backups and the real-time request frequency.

[0066] In this step, the value of the real-time request frequency can be directly used for calculation, but in order to reduce the load, in this embodiment, the real-time request frequency needs to be converted into a heat level before calculation.

[0067] The real-time request frequency can be pre-designed into multiple heat levels, and then a corresponding basic value is assigned to each heat level. For example, a real-time request frequency less than 1000 is low heat, greater than 1000 and less than 5000 is medium heat, and greater than 5000 is high heat. The basic value corresponding to low heat is 0, the basic value corresponding to medium heat is 1, and the basic value corresponding to high heat is 2.

[0068] The calculation formula for the number of nodes in the backup node group of an independent shard is: The number of nodes in the backup node group = the number of basic backups + the shard heat level × elasticity coefficient Elasticity coefficient = basic value × 1 + current total system load - average load in the past 24 hours Average load in the past 24 hours Among them, the elastic coefficient ranges from 0.5 to 1.5, and the basic value can be preset to 1.

[0069] S202. The number of nodes in the backup node group of the shared shard is determined based on the number of remaining nodes in the global resource pool and the shard weight.

[0070] In this step, the number of remaining nodes in the global resource pool is obtained by real-time monitoring and broadcasting of the number of available nodes by the centralized resource management module. The shard weight is set by the business priority, such as 0.3 for core stocks, 0.1 for ordinary stocks, and 0.05 for unpopular derivatives. Important business shards need higher priority to ensure that their backup resources are sufficient.

[0071] In another embodiment, Figure 3 As shown in the figure, the verification steps of independent shards specifically include: S411. The master node generates an event after processing the transaction and calculates the hash chain.

[0072] S412. The master node sends the generated event and hash chain to the synchronization path node.

[0073] S413. After receiving the event, each synchronization path node verifies the continuity of the hash chain. All synchronization path nodes form a local verification group. When more than half of the synchronization path nodes confirm that the hash chain is valid, it means that the verification is successful.

[0074] It should be noted here that the setting for verification to pass does not necessarily require that more than half of the synchronization path nodes confirm that the hash chain is valid. It can also be set to a higher requirement, such as more than two-thirds of the synchronization path nodes confirm that the hash chain is valid.

[0075] S414: When verification fails, the independent shard rolls back data from the synchronization path node.

[0076] In another embodiment, Figure 4 As shown in the figure, the verification steps of shared shards specifically include: S421. Generate events and hash chains, and broadcast them to all nodes in the resource pool.

[0077] S422, the idle node preempts the processing event, calculates the local hash chain and returns the result.

[0078] S423. Count the total voting weights of all nodes for the current hash chain. When the total weight exceeds the preset weight threshold, it means that the verification is passed; wherein the voting weight of each node is determined based on historical behavior.

[0079] Among them, voting weight = (number of correct responses − number of incorrect responses) / total number of participations.

[0080] S424: When verification fails, the node with the highest historical voting weight is selected as the arbitrator, and its decision overrides other nodes.

[0081] It should be noted that the node with the highest historical voting weight is not limited to selecting only the highest node, but can also be the sum of the voting weights of all nodes above the threshold.

[0082] In one embodiment, if Figure 5 As shown, a system for building a distributed steady-state trading environment includes: The dynamic sharding module creates independent shards for high-frequency targets based on the real-time request frequency of the transaction targets, and binds synchronization paths and backup node groups to the independent shards; merges low-frequency targets into shared shards, and binds backup node groups to each shard.

[0083] The data synchronization module uses chain synchronization for independent shards and global broadcast synchronization for shared shards based on the shard type.

[0084] Pre-activate the backup module, pre-load the intermediate state of the nodes in the backup node group, and when the primary node fails, the backup node group directly generates a complete state and takes over.

[0085] The consistency verification module verifies the hash chain hierarchically according to the shard topology structure. Independent shards use local verification, and shared shards trigger global arbitration.

[0086] The resource recovery module recovers the backup nodes of low-frequency targets and redistributes them to the backup groups or synchronization paths of high-frequency targets.

[0087] The embodiments of this specific implementation method are all preferred embodiments of the present application, and are not intended to limit the protection scope of the present application. Therefore, all equivalent changes made based on the structure, shape, and principle of the present application should be included in the protection scope of the present application.

Claims

1. A method for building a distributed steady-state trading environment, characterized in that: The following steps are involved: According to the real-time request frequency of the transaction target, create independent shards for high-frequency targets, and bind synchronization paths and backup node groups to independent shards; merge low-frequency targets into shared shards, and bind backup node groups to each shard; Based on the shard type, chain synchronization is used for independent shards, and global broadcast synchronization is used for shared shards; The nodes in the backup node group preload the intermediate state. When the primary node fails, the backup node group directly generates the complete state and takes over. The hash chain is verified hierarchically according to the shard topology, where independent shards use local verification and shared shards trigger global arbitration; Recycle the backup nodes of low-frequency targets and reallocate them to the backup groups or synchronization paths of high-frequency targets.

2. The method for building a distributed stable trading environment according to claim 1, characterized in that: The step of creating independent shards for high-frequency targets according to the real-time request frequency of the transaction targets specifically includes: Track the number of requests per unit time for each transaction object; When the number of requests for a transaction target is greater than the preset frequency, several nodes are allocated from the global resource pool to form independent shards.

3. The method for building a distributed stable trading environment according to claim 1, characterized in that: The synchronization path of the local chain synchronization is a master node, a synchronization path node and a backup node group in sequence, and the incremental events are transmitted hop by hop along the preset path; The global broadcast synchronization method is to send incremental events to the global resource pool, and the events are dynamically processed by idle nodes in the pool.

4. The method for building a distributed stable trading environment according to claim 1, characterized in that: The number of synchronization path nodes of the independent shard is positively correlated with the real-time request frequency of the shard, and the nodes of the synchronization path are selected based on physical location proximity, the difference in unprocessed event queue lengths between path nodes, and node delays.

5. The method for building a distributed stable trading environment according to claim 1, characterized in that: The number of nodes in the backup node group is dynamically allocated according to the real-time request frequency of the shards.

6. A method for building a distributed stable trading environment according to claim 5, characterized in that: The step of dynamically allocating the number of nodes in the backup node group according to the real-time request frequency of the shards specifically includes: The number of nodes in the backup node group of an independent shard is determined based on the number of basic backups and the real-time request frequency; The number of nodes in the backup node group that shares the shard is determined based on the number of remaining nodes in the global resource pool and the shard weight.

7. The method for building a distributed stable trading environment according to claim 1, characterized in that: The verification steps of the independent shards specifically include: The master node generates events after processing transactions and calculates the hash chain; The master node sends the generation event and hash chain to the synchronization path node; After receiving the event, each synchronization path node verifies the continuity of the hash chain. All synchronization path nodes form a local verification group. When more than half of the synchronization path nodes confirm that the hash chain is valid, it means that the verification is successful. When verification fails, the independent shards roll back the data from the synchronization path nodes.

8. The method for building a distributed stable trading environment according to claim 1, characterized in that: The verification steps of the shared shards specifically include: Generate events and hash chains, and broadcast them to all nodes in the resource pool; Idle nodes preempt processing events, calculate local hash chains and return results; The total voting weight of all nodes on the current hash chain is counted. When the total weight exceeds the preset weight threshold, it means that the verification is passed. The voting weight of each node is determined based on historical behavior. When verification fails, the node with the highest historical voting weight is selected as the arbitrator, and its decision overrides other nodes.

9. The method for building a distributed stable trading environment according to claim 1, characterized in that: The recovered backup nodes of the low-frequency targets are allocated according to priorities, which are high-frequency targets whose current load rate exceeds the load threshold, independent shards whose average delay of synchronization path nodes exceeds the delay threshold, and shared shards whose number of available nodes in the global resource pool is lower than the preset threshold.

10. A system for building a distributed stable trading environment, characterized in that: include: The dynamic sharding module creates independent shards for high-frequency targets based on the real-time request frequency of the transaction targets, and binds synchronization paths and backup node groups to the independent shards; Merge low-frequency tags into shared shards and bind a backup node group to each shard; Data synchronization module, based on the shard type, uses chain synchronization for independent shards and global broadcast synchronization for shared shards; Pre-activate the backup module, pre-load the intermediate state of the nodes in the backup node group, and when the primary node fails, the backup node group directly generates a complete state and takes over; The consistency verification module verifies the hash chain hierarchically according to the shard topology structure. Independent shards use local verification, and shared shards trigger global arbitration. The resource recovery module recovers the backup nodes of low-frequency targets and redistributes them to the backup groups or synchronization paths of high-frequency targets.

Images