Asynchronous transaction processing method and system for concurrent payment scenarios

Abstract

The embodiment of the application provides a kind of asynchronous transaction processing method and system for concurrent payment scene, it is related to payment processing technical field, first receive concurrent payment request set and generate transaction scene track mapping, then based on mapping start asynchronous execution engine drive transaction operation flow and record relevant data, then from the transaction flow of payment request Full volume record extraction scene feature association dataset generates scene feature association dataset, builds concurrent conflict dynamic modeling model and locates conflict and generates conflict association graph, again according to conflict association graph forms transaction dynamic linkage adaptation scheme to complete transaction execution and feedback result.The application improves the processing efficiency under concurrent payment scene, effectively solves the conflict problem, improves the stability and reliability of payment system.

Description

Technical Field

[0001] This application relates to the field of payment processing technology, and more specifically, to an asynchronous transaction processing method and system for concurrent payment scenarios. Background Technology

[0002] In today's era of booming digital payments, payment scenarios are becoming increasingly complex and diverse, and concurrent payments are occurring more frequently. For example, during large-scale e-commerce promotional events, a large number of users may initiate payment requests simultaneously within a short period of time, creating high-concurrency payment scenarios. Traditional synchronous transaction processing methods have many limitations in dealing with these concurrent payment scenarios.

[0003] Synchronous transaction processing typically requires all payment requests to be processed sequentially, with each request waiting for the previous one to complete before it can begin processing. In concurrent payment scenarios, this can lead to a large backlog of payment requests, increased payment system response time, and a deterioration in user experience. Furthermore, synchronous processing struggles to fully utilize the resource advantages of distributed systems and cannot achieve parallel processing to improve payment efficiency.

[0004] Meanwhile, during concurrent payments, conflicts may arise between different payment requests due to competition for limited system resources (such as database connections and computing resources). Existing technologies lack effective conflict detection and dynamic handling mechanisms, making it difficult to accurately identify the triggering nodes and scope of conflicts, and unable to take appropriate measures to resolve conflicts in a timely manner, which can easily lead to problems such as payment failures or data inconsistencies. Summary of the Invention

[0005] In view of this, the purpose of this application is to provide an asynchronous transaction processing method and system for concurrent payment scenarios.

[0006] According to a first aspect of this application, an asynchronous transaction processing method for concurrent payment scenarios is provided, the method comprising: Receive a set of concurrent payment requests and generate a transaction scenario trajectory mapping for each payment request, which includes transaction attribute information, execution scenario adaptation data, and linkage response specifications. Based on the transaction scenario trajectory mapping, the asynchronous execution engine is started, driving the transaction operation corresponding to each payment request to flow in the distributed nodes, and recording the operation coordination content, data synchronization status and resource consumption data between nodes to form a full record of the transaction flow. Extract execution scenario attributes, resource competition-related content, and coordination deviation data from the full transaction flow records of all payment requests to generate a scenario feature association dataset; A concurrent conflict dynamic modeling model is built based on the scene feature association dataset to locate the conflict triggering node, the scope of impact and the transmission path in the transaction flow, and generate a conflict association graph. Based on the conflict relationship diagram, a dynamic linkage and adaptation scheme for transactions is formed. Through the node scheduling operation, resource allocation process and operation coordination adjustment action of the asynchronous execution engine, the transaction execution of all payment requests is completed, the execution results are summarized and fed back to the corresponding payment initiator.

[0007] According to a second aspect of this application, an asynchronous transaction processing system for concurrent payment scenarios is provided. The asynchronous transaction processing system for concurrent payment scenarios includes a processor and a readable storage medium. The readable storage medium stores a program that, when executed by the processor, implements the aforementioned asynchronous transaction processing method for concurrent payment scenarios.

[0008] Based on any of the above aspects, by generating a transaction scenario trajectory mapping for each concurrent payment request, containing transaction attribute information, execution scenario adaptation data, and linkage response specifications, and starting an asynchronous execution engine based on the transaction scenario trajectory mapping, the transaction operations are driven to flow through distributed nodes and record relevant data to form a full record of the transaction flow. This fully utilizes the parallel processing capabilities of the distributed system, significantly improving processing efficiency in concurrent payment scenarios and effectively avoiding the request backlog and response delay problems caused by traditional synchronous processing methods. Key data is extracted from the full record of the transaction flow to generate a scenario feature association dataset, and a concurrent conflict dynamic modeling model is built. This model can accurately locate the conflict triggering nodes, impact range, and transmission path in the transaction flow, generating a conflict association graph, providing a scientific basis for dynamic conflict handling. Based on the transaction dynamic linkage adaptation scheme formed by the conflict association graph, through node scheduling, resource allocation, and operational coordination adjustments of the asynchronous execution engine, conflict problems in the concurrent payment process can be resolved flexibly and efficiently, ensuring that all payment requests can be executed smoothly. Finally, the execution results are summarized and fed back to the payment initiator, improving the stability, reliability, and user experience of the entire payment system. Attached Figure Description

[0009] Figure 1 A flowchart illustrating the asynchronous transaction processing method for concurrent payment scenarios provided in this application embodiment is shown. Figure 2 This paper illustrates a schematic diagram of the component structure of an asynchronous transaction processing system for concurrent payment scenarios provided in an embodiment of this application. Detailed Implementation

[0010] Figure 1 A flowchart illustrating the asynchronous transaction processing method for concurrent payment scenarios provided in this application embodiment is shown, and the detailed steps are described below.

[0011] Step S110: Receive the set of concurrent payment requests and generate a transaction scenario trajectory mapping for each payment request, which includes transaction attribute information, execution scenario adaptation data, and linkage response specifications.

[0012] In the daily operations of e-commerce platforms, when multiple users simultaneously purchase goods and initiate payment requests, the system receives these concurrent payment requests, forming a set of concurrent payment requests. For each payment request, a transaction scenario trajectory map needs to be generated. This transaction scenario trajectory map is a structured dataset. Transaction attribute information covers the basic elements of the payment request, such as the payment amount range, payment method type, and account identifiers of both parties. Execution scenario adaptation data involves processing strategies under different concurrency levels, such as the node allocation mode used when the concurrency level is in range Q1, and the resource allocation ratio when the concurrency level is in range Q2. The linkage response specification clarifies the processing rules when different payment requests are related or conflicting, such as the response priority setting when two payment requests involve fund operations on the same account. By integrating the above information, the transaction scenario trajectory map is formed.

[0013] Step S111: Parse the transaction attribute information carried in the payment request, and classify and integrate the payment account associated content, fund transfer path planning, compliance review basis, and transaction completion standard according to the operation steps to generate a transaction attribute classification set. The transaction attribute information includes the payment account associated content, fund transfer path planning, compliance review basis, and transaction completion standard.

[0014] Payment requests are transmitted to the system via a specific communication protocol. The system parses the received payment requests and extracts transaction attribute information. Payment account association information includes the payer's account's unique identifier, account type (e.g., personal account, corporate account), and account status (normal, restricted, etc.). Fund transfer path planning involves the sequence of identifiers of intermediaries or systems through which funds travel from the payer's account to the payee's account. Compliance review criteria include the legal and regulatory clause numbers that the transaction must comply with, and the platform's internal risk control rule codes. Transaction completion standards detail the specific conditions for successful transaction, such as the confirmation status of fund arrival and the completion status of transaction record writing. Based on operational stages, such as account verification, fund processing, compliance checks, and result confirmation, the above information is categorized and integrated, and the relevant attribute information corresponding to each stage is centrally stored to generate a transaction attribute classification set.

[0015] Step S112: Analyze the transaction type corresponding to the payment request, and in conjunction with the current concurrent running status of the system, extract the distributed node types, data interaction methods and resource call priorities that may be involved in the execution of the payment request, and generate basic data for the execution scenario.

[0016] First, determine the transaction type corresponding to the payment request. Different transaction types (such as physical goods transactions, virtual service transactions, etc.) will have different requirements during processing. Simultaneously, obtain the current concurrent operating status of the system, including the load of each node in the system (such as the number of tasks processed by each node, resource utilization, etc.), network transmission latency, database connection count, and other information. Based on the transaction type and the system's concurrent operating status, determine the types of distributed nodes that may be involved in the execution of the payment request, such as nodes responsible for account management, fund clearing, and compliance checks. The data interaction method is selected based on the real-time requirements and data volume of data transmission between nodes; for example, synchronous interaction is used for data with high real-time requirements, and asynchronous interaction is used for non-real-time data. The resource call priority is set according to factors such as the urgency of the transaction and the size of the transaction amount; for example, urgent or large transactions are given a higher priority for resource calls. Integrate the information extracted above to generate the basic data for the execution scenario.

[0017] Step S113: Retrieve the historical transaction records corresponding to the payment request, extract the scenario adaptation data, node selection preference and resource allocation data in the historical execution process, and generate historical scenario adaptation reference content.

[0018] The system's database query function retrieves historical transaction records related to the current payment request. These records can be similar transactions from the same user or transactions of the same type from other users. Scene adaptation data is extracted from these historical transaction records, including adaptation parameters used in different concurrency scenarios, such as node processing capacity adjustment parameters in high-concurrency scenarios; node selection preferences, referring to the selection preferences for different types of distributed nodes in historical transactions, such as a preference for nodes in specific regions for certain transaction types; and resource allocation data, including the allocation ratio and usage of various resources (such as computing resources, storage resources, and network resources) during the execution of historical transactions. The extracted data is then organized and statistically analyzed to generate historical scene adaptation reference content.

[0019] Step S114: Based on the transaction attribute classification set and execution scenario basic data, divide the transaction execution into the first operation stage and the second operation stage. The first operation stage is the necessary process to ensure the effective completion of the transaction, and the second operation stage is the auxiliary process to supplement and improve the transaction process.

[0020] Taking into account the importance of each operational step in the transaction attribute classification set and the operational requirements in the execution scenario's basic data, the operational steps of transaction execution are divided. The first operational step is the core process ensuring the effective completion of the transaction; if these steps encounter problems, the transaction will not be completed normally. Examples include the identity verification of the payment account, the actual transfer of funds, and the confirmation of the transaction result. The second operational step supplements and improves the transaction process. The absence or delay of these steps will not affect the core completion of the transaction, but it can improve the integrity of the transaction and the user experience. Examples include the notification sending after the transaction is completed and the statistical analysis of transaction data. By evaluating the function and importance of each step in the transaction attribute classification set, and combining the resource requirements and execution conditions of each step in the execution scenario's basic data, the first and second operational steps are clearly defined.

[0021] For example, step S1141: Obtain the transaction attribute classification set and execution scenario basic data, extract the transaction value weight data, execution result impact data, and compliance requirement level data corresponding to each operation step from the transaction attribute classification set, and generate operation step importance indicators.

[0022] From the set of transaction attribute categories, relevant data reflecting the importance of each operational step is extracted. Transaction value weight data indicates the proportion of this operational step in the overall transaction value; execution result impact data measures the degree to which the execution result of this step affects the success or failure of the entire transaction; compliance requirement level data reflects the level of compliance requirements that this step needs to meet. This data is then quantified, for example, by converting the transaction value weight data into values ​​between 0 and 1, and the execution result impact data and compliance requirement level data into corresponding level values. Then, using a weighted calculation method, the quantified data is integrated into an operational step importance index. The higher the value of the operational step importance index, the more important the operational step is.

[0023] Step S1142: Extract the execution complexity data, resource consumption ratio data, and fault tolerance capability data of each operation step from the basic data of the execution scenario, and generate operation attribute indicators for the operation step.

[0024] The basic data for the execution scenario includes relevant operational attribute information for each operation step during execution. Execution complexity data reflects the complexity of the execution process for that step, such as the number of computational steps and logical judgments involved; resource consumption percentage data indicates the proportion of various system resources (such as CPU, memory, network bandwidth, etc.) consumed by that step during execution; and fault tolerance data reflects the self-recovery and error handling capabilities of that step in the event of anomalies. This data is analyzed and processed, for example, by classifying execution complexity data into different levels based on complexity, converting resource consumption percentage data into percentage form, and scoring fault tolerance data based on the strength of recovery capabilities. The processed data is then integrated to generate operational attribute indicators for each operation step, describing its operational characteristics.

[0025] Step S1143: Conduct a comprehensive analysis of the importance indicators and operational attribute indicators of the operational links, establish a weight allocation method for the analysis dimensions, determine the role of different indicators in the classification process, and generate the basis for link classification decisions.

[0026] A comprehensive analysis of the importance and operational attribute indicators of each operational step is conducted to determine how to classify these steps based on these indicators. First, different weights are assigned to each sub-indicator within the importance and operational attribute indicators based on the business requirements and system characteristics of transaction processing. For example, core indicators ensuring transaction completion, such as those affecting data from execution results, may be assigned higher weights; while indicators such as execution complexity may have relatively lower weights. By establishing this weight allocation method for the analytical dimensions, the importance of different indicators in the classification process is clarified. Then, based on the weights and specific values ​​of each indicator, a comprehensive score for each operational step is calculated, generating a decision-making criterion for step classification. This criterion will serve as the standard for distinguishing between the first and second operational steps.

[0027] Step S1144: Based on the decision criteria for classifying the links, set the criteria for dividing the first and second operation links, and generate detailed rules for the link division criteria. The division criteria include the range of importance indicators and the interval of operation attribute indicators.

[0028] Based on the decision-making criteria for process classification, specific division standards are formulated to distinguish between the first and second operational processes. These standards include the range of importance indicators and the intervals of operational attribute indicators. For example, an operational process where the comprehensive score of the importance indicator is within the interval [R1, R2], and the resource consumption ratio and fault tolerance data are within the interval [S1, S2] and [T1, T2], is defined as the first operational process; while an operational process where the comprehensive score of the importance indicator is within the interval [R3, R4], the resource consumption ratio is within the interval [S3, S4], and the fault tolerance data is within the interval [T3, T4], is defined as the second operational process. These interval ranges and judgment conditions are detailed to form a set of process classification standards, ensuring the objectivity and accuracy of the classification process.

[0029] Step S1145: Compare the detailed rules for segmentation, evaluate each operational segment in the transaction attribute classification set one by one, determine whether each operational segment meets the segmentation conditions of the first operational segment, and generate preliminary classification results.

[0030] According to the detailed rules for segmentation, each operational segment in the transaction attribute classification set is evaluated one by one. For each operational segment, its overall importance score and the values ​​of each operational attribute indicator are first calculated, and then these values ​​are checked to see if they meet the classification criteria for the first operational segment. If the overall importance score of an operational segment is within the specified range, and all operational attribute indicators are also within their corresponding ranges, then the segment is determined to meet the classification criteria for the first operational segment and is initially classified as the first operational segment; otherwise, it is initially classified as the second operational segment. The evaluation results are recorded to generate a preliminary classification result, which includes the code for each operational segment and its corresponding preliminary classification type.

[0031] Step S1146: For the first operation step in the preliminary classification results, verify the irreplaceability of each first operation step in the concurrent environment corresponding to the basic data of the execution scenario, confirm the necessity of each first operation step for the completion of the payment request, and generate the verification result of the first step.

[0032] For the first operational step in the preliminary classification results, further verification is needed to confirm its irreplaceability in the current concurrent environment and its necessity for completing the payment request. Combining the concurrent environment information in the execution scenario's basic data, analyze whether there are other steps that can replace the function of each first operational step in this environment. For example, check whether there are other operational steps that can complete the same core function without negatively impacting the integrity and accuracy of the transaction. Simultaneously, assess whether the absence or failure of this step would prevent the entire payment request from being completed. Through the above verification, confirm the necessity of each first operational step, generate the first step verification results, and record the first operational steps that have passed verification.

[0033] Step S1147: For the second operation step in the preliminary classification results, check the feasibility of delaying or downgrading the execution of each second operation step without affecting the execution effect of the first operation step, and generate the verification result of the second step.

[0034] For the second operational steps in the preliminary classification results, it is necessary to examine the feasibility of delayed or downgraded execution. Without affecting the normal execution of the first operational step and the completion of the core transaction functions, analyze whether the execution time of each second operational step can be postponed or the execution standard lowered. For example, the notification sending step after the transaction is completed can be delayed for a period of time without affecting the completion of the transaction; some statistical analysis steps can use simplified algorithms for downgraded execution to reduce resource consumption. Through the analysis of each second operational step, determine the feasibility of its delayed or downgraded execution, generate second-step verification results, and record the feasible second operational steps and their feasible execution methods.

[0035] Step S1148: Combining the verification results of the first and second stages, adjust the preliminary classification results, transfer the first operation stage that fails verification to the second operation stage, and transfer the second operation stage that meets the conditions of the first operation stage after verification to the first operation stage, generating the classification adjustment results.

[0036] Based on the verification results of the first and second stages, the preliminary classification results are adjusted. Operational steps that do not meet the criteria of irreplaceability and necessity in the first stage of verification are reclassified from first to second stage. Operational steps initially classified as second stage but actually crucial for transaction completion and whose execution cannot be delayed or downgraded are reclassified as first stage. Through these adjustments, the classification results are made more accurate and reasonable, generating a final classification adjustment result. This result ultimately determines the first and second operational steps for transaction execution.

[0037] Step S1149: For the first operation step in the classification adjustment results, summarize the operation attributes, execution requirements and relationships of each first operation step, and generate a summary list of the first operation steps.

[0038] After the classification and adjustment results are finalized, detailed information for each step in the first operation is summarized. Operation attributes include the step's name, unique identifier, and functional description; execution requirements include time constraints, data accuracy requirements, and resource needs; and relationships describe the execution order and data dependencies between this step and other first operation steps. This information is then organized into a structured format to generate a summary list of first operation steps.

[0039] Step S11410: For the second operation steps in the classification adjustment results, organize the operation functions, connection logic and flexible scheduling space of each second operation step, and generate a summary list of second operation steps.

[0040] For the second operational step in the classification and adjustment results, information is also organized. The operational function clearly defines the specific role and function of this step; the connection logic describes the connection method and execution order between this step and the first or other second operational steps; the flexible scheduling space specifies the time range for delayed execution, the degraded execution methods that can be used, and other scheduling flexibility information. After organizing the above information, a summary list of the second operational steps is generated.

[0041] Step S115: For the first operation stage, based on the historical scenario adaptation reference content, extract the execution node combination data, data synchronization frequency parameters and fault-tolerant alternative path information under different concurrency pressures, and generate the first stage scenario adaptation data.

[0042] Based on the summary list of the first operation stage and combined with historical scenario adaptation references, corresponding execution node combination data is extracted for different concurrency pressure conditions (such as low concurrency, medium concurrency, and high concurrency). Execution node combination data refers to the combination of types and quantities of distributed nodes allocated to the first operation stage under specific concurrency pressure. The data synchronization frequency parameter specifies the time interval or number of times data is synchronized between nodes under different concurrency pressures. Fault-tolerant alternative path information provides backup node paths available for switching when an execution node fails. Integrating the above data generates scenario adaptation data for the first stage, ensuring that the first operation stage can execute stably and efficiently under different concurrency pressures.

[0043] Step S116: For the second operation stage, extract the schedulable range data of the second operation stage, the connection logic information with the first operation stage, and the execution degradation method when resources are scarce, and generate the second stage scenario adaptation data.

[0044] For the second operation phase, schedulable range data is extracted. This data clarifies the earliest and latest times when the second operation phase can begin execution, as well as the range of nodes that can be allocated. The connection logic information with the first operation phase details at which node of the first operation phase completes execution, and how the second operation phase interacts with the first operation phase during execution. The execution degradation method under resource constraints specifies the specific degradation measures that the second operation phase can adopt when system resources are insufficient, such as simplifying the processing flow and reducing data precision. Integrating the above information generates scenario adaptation data for the second phase, enabling the second operation phase to be flexibly scheduled according to system resource conditions.

[0045] Step S117: Integrate the scenario adaptation data from the first stage and the scenario adaptation data from the second stage to form execution scenario adaptation data covering the entire process.

[0046] The scenario adaptation data from the first and second stages are integrated to ensure consistent data format and logical coherence. Following the order of transaction execution, the scenario adaptation data from the first and second operation stages are arranged in a sequential manner to form a complete execution scenario adaptation data set. This execution scenario adaptation data set covers the entire process from the start to the end of a transaction.

[0047] Step S118: Based on the execution scenario adaptation data and transaction attribute classification set, extract the operation coordination logic, data dependency relationship and conflict avoidance path between different payment requests, extract the linkage trigger conditions and response operation standards between transactions, and generate linkage response specifications.

[0048] This analysis examines the interrelationships between different payment requests during execution, drawing upon data adapted to specific execution scenarios and a set of transaction attribute classifications. Operational coordination logic refers to the operational rules governing multiple payment requests when sharing resources or coordinating processing, such as the processing order when multiple requests access the same node simultaneously. Data dependency relationships indicate that the execution of a payment request depends on the processing results of other payment requests. Conflict avoidance paths are pre-defined solutions to prevent resource contention or data conflicts between different payment requests. Furthermore, the analysis extracts the triggering conditions for inter-transaction linkages, such as the specific processing mechanisms that trigger other related requests when an anomaly occurs in a payment request, as well as response operation standards, clarifying the specific response measures to be taken when the triggering conditions are met. This information is then integrated to generate a linkage response specification.

[0049] Step S119: Structure and integrate the transaction attribute classification set, execution scenario adaptation data, and linkage response specifications. Arrange the elements of the transaction attribute classification set, the elements of the execution scenario adaptation data, and the elements of the linkage response specifications according to the preset mapping format to generate a transaction scenario trajectory mapping.

[0050] Following a pre-defined mapping format, the elements in the transaction attribute classification set (such as account information and amount information), the elements in the execution scenario adaptation data (such as node combinations and synchronization frequencies), and the elements in the linkage response specifications (such as triggering conditions and response standards) are arranged in an orderly manner. The mapping format can adopt a hierarchical structure to organize related elements together, ensuring that the correspondence between elements is clear. Through the above structured integration, a preliminary version of the transaction scenario trajectory mapping is generated.

[0051] Step S1110: Verify the element association logic in the transaction scenario trajectory mapping. By supplementing the missing association data between elements, correcting the inconsistent content in the element expressions, and organizing the logical order of the element arrangements, maintain the coherence among the transaction attribute information, the execution scenario adaptation data, and the linkage response specifications. Based on the verified results, adjust the structure and content expression of the transaction scenario trajectory mapping to improve the transaction scenario trajectory mapping.

[0052] Verify the element association logic of the preliminarily generated transaction scenario trajectory mapping. Check whether the associations between elements are reasonable and whether there is any missing association data. For example, whether a certain field in the transaction attribute information is correctly associated with the corresponding parameter in the execution scenario adaptation data. At the same time, correct the possible inconsistent content in the element expressions, such as inconsistent terminology usage. Organize the logical order of the element arrangements to ensure the seamless connection among the transaction attribute information, the execution scenario adaptation data, and the linkage response specifications. According to the verification results, adjust the structure and content expression of the transaction scenario trajectory mapping, and finally improve the transaction scenario trajectory mapping.

[0053] Step S120: Based on the transaction scenario trajectory mapping, start the asynchronous execution engine to drive the transaction operations corresponding to each payment request to flow among the distributed nodes, and record the operation coordination content, data synchronization status, and resource consumption data among the nodes to form a full record of transaction flow.

[0054] Use the generated transaction scenario trajectory mapping to start the asynchronous execution engine. The asynchronous execution engine distributes the transaction operations of each payment request to the corresponding distributed nodes according to the execution scenario adaptation data in the mapping. During the flow of transaction operations, the engine is responsible for coordinating the work of each node and driving the transaction operations to be processed among the nodes according to the predetermined process. At the same time, the system will record in detail the operation coordination content among the nodes, such as the instruction transmission, task assignment, and result feedback between nodes; the data synchronization status, including the synchronized data content, synchronization time point, whether the synchronization is successful, and the synchronization delay time; and the resource consumption data, such as the CPU usage rate, memory occupancy, and network bandwidth consumption of each node during the processing of transaction operations. Integrate the above records to form a full record of transaction flow, which comprehensively reflects the execution process of transaction operations.

[0055] Step S121: Obtain the transaction scenario trajectory mapping of each payment request, extract the execution scenario adaptation data and the linkage response specifications therein, and respectively convert the execution scenario adaptation data and the linkage response specifications into startup parameters recognizable by the asynchronous execution engine to generate an engine startup configuration set.

[0056] From the transaction scenario trajectory mapping of each payment request, execution scenario adaptation data and linkage response specifications are extracted. Execution scenario adaptation data includes information such as node combinations and resource allocation ratios, while linkage response specifications include conflict handling rules and collaborative triggering conditions. This data is then transformed into startup parameters that the asynchronous execution engine can recognize; for example, node combination information is converted into a list of node identifiers, and resource allocation ratios are converted into specific resource allocation values. This transformation process is performed on each payment request, generating an engine startup configuration set containing startup parameters for all payment requests.

[0057] Step S122: Input the engine startup configuration set into the asynchronous execution engine to trigger the engine initialization process, and sequentially complete the connection adaptation operation of the distributed nodes, the startup operation of the resource scheduling module, and the establishment operation of the data synchronization channel, and generate the engine initialization completion signal.

[0058] The engine startup configuration set is input into the asynchronous execution engine. Upon receiving the configuration set, the engine triggers the initialization process. First, it performs distributed node connection adaptation, establishing network connections with each distributed node based on the node information in the configuration set and verifying node availability and compatibility. Next, it starts the resource scheduling module, which is responsible for the initial allocation and management of system resources according to the resource allocation parameters in the configuration set. Then, it establishes a data synchronization channel to ensure data transmission and synchronization between nodes. Once these initialization operations are complete, the engine generates an initialization completion signal, indicating that it can begin processing payment request transactions.

[0059] Step S123: Based on the engine initialization completion signal, according to the execution scenario adaptation data in the transaction scenario trajectory mapping, assign execution node combinations to the first operation stage of each payment request, determine the operation division of labor and data transmission path between nodes, and generate the first operation node allocation scheme.

[0060] Upon receiving the engine initialization completion signal, execution node combinations are assigned to the first operation stage of each payment request based on the execution scenario adaptation data in the transaction scenario trajectory mapping. The selection of execution node combinations is based on the functional requirements of the first operation stage, the current node load, and historical scenario adaptation references. Simultaneously, the operational division of each node in the first operation stage is determined, such as one node handling account verification and another handling fund freezing. The data transmission paths between nodes are clearly defined, specifying the exact route and method for data transmission from one node to another. This allocation information is then compiled to generate the first operation node allocation scheme.

[0061] Step S124: Based on the first operation node allocation scheme, drive the first operation step to start execution in the corresponding distributed node, collect the operation execution progress data, data processing result information and resource usage data of the node in real time, and generate the first operation execution record.

[0062] According to the first operation node allocation scheme, start commands are sent to the corresponding distributed nodes to drive the first operation step to begin execution on these nodes. During execution, real-time data on the node's operation progress is collected, such as the number of completed operation steps and the number of remaining operation steps; data processing result information, including the processing result, intermediate data, and final data for each operation step; and resource usage data, such as the node's CPU utilization, memory usage, and network bandwidth usage. The collected data is then organized according to time sequence and operation steps to generate the first operation execution record.

[0063] For example, step S1241: Obtain the first operation node allocation scheme, extract the first operation link identifier, the corresponding execution node list, the operation division content and the data transmission path, and generate the first operation execution start parameters.

[0064] From the first operation node allocation scheme, key information related to the first operation stage is extracted. The first operation stage identifier uniquely identifies each first operation stage; the execution node list lists the distributed nodes responsible for executing that stage; the operation division of labor clarifies the specific task of each node in that stage; and the data transmission path specifies the route for data transmission between nodes. Integrating the above information generates the first operation execution startup parameters, which serve as the specific instruction to initiate the execution of the first operation stage.

[0065] Step S1242: Send the first operation execution start parameters to the corresponding distributed node, trigger the node's first operation execution preparation process, and sequentially complete the data loading operation, environment configuration operation and resource reservation operation required for operation execution, and generate a node execution preparation completion signal.

[0066] The startup parameters for the first operation are sent to the corresponding distributed node via the network. Upon receiving the startup parameters, the node triggers the preparation process for the first operation. First, a data loading operation is performed, loading the data required for this operation from the database or other storage location. Then, an environment configuration operation is performed, setting the node's runtime environment parameters, such as operating system parameters and application configurations. Next, a resource reservation operation is performed, reserving the necessary CPU, memory, network, and other resources for this operation. Once these preparation operations are complete, the node generates an execution preparation completion signal, indicating that the first operation can begin execution.

[0067] Step S1243: Based on the node execution preparation completion signal, start the execution process of each first operation step in sequence according to the operation division of the first operation execution start parameters, record the operation start time, start node and initial execution status, and generate operation start record.

[0068] Upon receiving the node execution preparation completion signal, the execution process of each first operation step is initiated sequentially according to the operation division of labor in the first operation execution startup parameters. The startup time, the node identifier responsible for execution, and the initial execution status (e.g., "Started," "Executing," etc.) of each operation step are recorded. This information is compiled into an operation startup record, serving as the initial basis for tracking the operation execution process.

[0069] Step S1244: During the execution of the first operation stage, real-time data on the CPU running status, memory usage, and network transmission rate of the node are collected. Changes in the CPU running status, memory usage, and network transmission rate are recorded at fixed time intervals to generate a real-time record of resource consumption.

[0070] During the execution of the first operation phase, resource consumption data of the nodes is collected in real time through system monitoring tools. CPU operating status data includes CPU utilization and number of cores; memory usage data includes used memory and available memory; network transmission rate data includes sending rate and receiving rate. The changes in these data are recorded at fixed time intervals (e.g., every certain period of time) to form a real-time resource consumption record, reflecting the dynamic resource usage of the nodes during execution.

[0071] Step S1245: Track the data processing process of the first operation stage, record the data input content, processing method application, intermediate processing results and final output data, and generate a data processing process record.

[0072] The entire data processing process in the first operation stage is tracked. Record the data input content, i.e., the specific values ​​and formats of the data entering this stage; the processing methods applied, such as the algorithms and processing logic used; intermediate processing results, i.e., the intermediate data generated during processing; and the final output data, i.e., the data output after the completion of this stage. Record all of the above information in detail to generate a data processing record.

[0073] Step S1246: Monitor the data transmission between the first operation stages, record the initiating node, receiving node, transmission time, data integrity status, and transmission delay duration, and generate a data transmission monitoring record.

[0074] Monitor the data transfer process between the first operational stages. Record the initiating and receiving node identifiers, the specific time the transfer occurred, the integrity status of the data before and after the transfer (e.g., whether there was data loss or corruption), and the transmission delay from the initiating node to the receiving node. Organize the above monitoring information to generate a data transfer monitoring log, ensuring accurate and timely data transmission between stages.

[0075] Step S1247: Collect the execution progress information of the first operation step and generate an execution progress tracking record. The execution progress information includes completed operation steps, remaining operation steps, and current execution stage.

[0076] Regularly collect execution progress information for the first operational stage. "Completed steps" refers to the number of steps successfully executed in this stage; "Remaining steps" refers to the number of steps yet to be executed; "Current execution stage" describes the current execution stage of this stage (e.g., "Data verification stage," "Funds processing stage," etc.). Summarize the above information to generate an execution progress tracking record, enabling real-time monitoring of the first operational stage's progress.

[0077] Step S1248: When a discrepancy occurs between the data in the transaction scenario trajectory mapping and the execution of the first operation step, record the time of the exception, the content of the exception, the nodes involved and the operation content affected, and generate an execution exception record.

[0078] During the execution of the first operation phase, the system continuously compares the actual execution status with the adaptation data in the transaction scenario trajectory mapping. When a discrepancy is found between the actual execution status and the adaptation data, such as node resource utilization exceeding the threshold in the adaptation data or data synchronization frequency not meeting the requirements, the system immediately records the time of the anomaly, the specific manifestation of the anomaly (e.g., "node CPU utilization is too high"), the identifier of the node involved, and the affected operations. This information is then compiled to generate an execution anomaly record.

[0079] Step S1249: Integrate the operation start record, real-time resource consumption record, data processing record, data transmission monitoring record, execution progress tracking record, and execution exception record. Combine the operation start record, real-time resource consumption record, data processing record, data transmission monitoring record, execution progress tracking record, and execution exception record according to the operation steps and time sequence to generate the first operation execution record.

[0080] The operation initiation record, real-time resource consumption record, data processing record, data transmission monitoring record, execution progress tracking record, and execution exception record are integrated. Following the chronological order of the operation steps, relevant information from these records is combined and correlated to form a complete first operation execution record. This first operation execution record comprehensively reflects the entire process of the first operation step from initiation to completion (or abnormal termination).

[0081] Step S125: In accordance with the linkage response specification in the transaction scenario trajectory mapping, trigger the scheduling process of the second operation step during the execution of the first operation step, allocate execution nodes for the second operation step, determine the execution sequence connection relationship between the second operation step and the first operation step, and generate the second operation scheduling scheme.

[0082] Based on the linkage response specifications in the transaction scenario trajectory mapping, the scheduling process of the second operation step is triggered when the first operation step reaches a specific stage or meets specific conditions. Execution nodes are allocated to the second operation step; these nodes can be idle or have low load. The execution sequence relationship between the second and first operation steps is determined, such as the second operation step starting execution after a certain step in the first operation step is completed, or executing in parallel with a certain step in the first operation step. The node allocation information and timing relationship are organized to generate a second operation scheduling scheme.

[0083] Step S126: Based on the second operation scheduling scheme, drive the second operation step to be executed in the distributed nodes, record the execution process data of the second operation, the data interaction content and the supporting data for the first operation step, and generate the second operation execution record.

[0084] According to the second operation scheduling scheme, the second operation is driven to execute on the allocated distributed nodes. During execution, the execution process data of the second operation is recorded, such as execution steps and execution time; data interaction content, including data exchange with other nodes; and supporting data for the first operation, such as auxiliary information and result verification data provided for the first operation. The above records are integrated to generate the second operation execution record.

[0085] Step S127: Monitor the operational coordination status between distributed nodes in real time, record the coordination trigger time, data synchronization content, synchronization delay data and coordination anomaly data between nodes, and generate node coordination monitoring records.

[0086] The system's monitoring module monitors the operational collaboration status between distributed nodes in real time. It records the trigger time of collaborative operations between nodes (the start time of collaboration); data synchronization content (the specific information of the data transmitted during collaboration); synchronization delay data (the delay time during data synchronization); and collaboration anomaly data, such as collaboration failures and data synchronization errors. This monitoring data is then compiled to generate a node collaboration monitoring record.

[0087] Step S128: Track the data synchronization process of each transaction operation, record the data transmission path from the initiating node to the receiving node, the encryption method, the verification result and the synchronization completion status, and generate a data synchronization tracking record.

[0088] The data synchronization process for each transaction is tracked. This includes recording the data transmission path from the initiating node to the receiving node, the encryption method used (e.g., symmetric encryption, asymmetric encryption), the verification result after data transmission (e.g., checksum consistency), and the synchronization completion status (e.g., "success," "failure," "in progress"). Recording this information generates a data synchronization tracking log, ensuring the security and accuracy of data synchronization.

[0089] Step S129: Calculate the types, scale, duration and release time of resource consumption for each distributed node during transaction execution, and generate a node resource consumption statistics record.

[0090] The resource consumption of each distributed node during transaction execution is statistically analyzed. Resource consumption types include CPU, memory, storage, and network bandwidth; consumption scale refers to the specific amount of each resource consumed; occupation duration refers to the time interval from when a resource is occupied to when it is released; release time refers to the specific time when the resource is released. The above statistical data is compiled to generate node resource consumption statistics records.

[0091] Step S1210: Integrate the first operation execution record, the second operation execution record, the node collaboration monitoring record, the data synchronization tracking record, and the node resource consumption statistics record. Sort and combine the first operation execution record, the second operation execution record, the node collaboration monitoring record, the data synchronization tracking record, and the node resource consumption statistics record according to the time sequence and operation association logic to generate a full transaction flow record.

[0092] The first operation execution record, the second operation execution record, the node collaboration monitoring record, the data synchronization tracking record, and the node resource consumption statistics record are integrated. Events in all records are sorted chronologically and combined according to the logical relationships between operations (e.g., a data synchronization record is associated with an operation execution record). Through this integration, a full transaction flow record is generated, which completely records the entire flow process of the transaction operation in the distributed nodes.

[0093] Step S130: Extract execution scenario attributes, resource competition related content, and collaborative deviation data from the full transaction flow records of all payment requests to generate a scenario feature association dataset.

[0094] The entire transaction flow record of all payment requests is analyzed and processed to extract key information. Execution scenario attributes include concurrency and node load during transaction execution; resource content refers to the competitive relationships and mutual influences between different payment requests during resource usage; and coordination deviation data represents the deviation between actual coordinated operations and the coordinated response specifications. The extracted information is then correlated and integrated to generate a scenario feature association dataset, which reflects the scenario characteristics and interrelationships of different payment requests during concurrent execution.

[0095] Step S131: Obtain the full transaction flow record of all payment requests and the corresponding transaction scenario trajectory mapping, and compare and correlate the full transaction flow record with the execution scenario adaptation data in the transaction scenario trajectory mapping to generate a related dataset.

[0096] Collect the full transaction flow records of all payment requests and their corresponding transaction scenario trajectory mappings. Compare and correlate the actual execution data in the full transaction flow records with the execution scenario adaptation data in the transaction scenario trajectory mappings. For example, compare the actual node allocation with the node combinations in the adaptation data, and compare the actual resource consumption with the resource allocation parameters in the adaptation data. Through these comparisons, generate a correlated dataset containing the correspondence and differences between the actual execution data and the adaptation data.

[0097] Step S132: Extract the transaction operation execution environment parameters, node configuration information, resource call mode and data interaction characteristics of each payment request from the associated dataset. The transaction operation execution environment parameters, node configuration information, resource call mode and data interaction characteristics together reflect the scenario adaptation status of transaction execution and generate an initial execution scenario attribute set.

[0098] From the associated dataset, for each payment request, extract the transaction operation execution environment parameters, such as system load and network conditions during execution; node configuration information, including the number, type, and performance parameters of the nodes participating in the execution; resource call mode, such as the resource application method and release method; and data interaction characteristics, such as the frequency and size of data transmission. The above parameters and characteristics together reflect the scenario adaptation status of transaction execution. Integrate them to generate an initial execution scenario attribute set.

[0099] Step S133: Classify and filter the data in the initial execution scenario attribute set, retain the data directly related to the concurrent execution state, remove duplicate data and irrelevant data, and generate a refined execution scenario attribute set.

[0100] The data in the initial execution scenario attribute set is processed. First, the data is categorized according to its relevance to the concurrent execution state. Then, data directly related to the concurrent execution state is filtered out, such as concurrency, node load rate, and resource contention. Duplicate data, such as identical parameter values ​​appearing in multiple records, is removed. Irrelevant data, such as node physical location information with extremely low correlation to the concurrent execution state, is also removed. After processing, a refined execution scenario attribute set is generated, containing more concise and relevant data.

[0101] Step S134: Filter out execution record fragments of multiple payment requests involving the same type of resource calls from the full transaction flow record, analyze the resource application time, occupation duration, release order and resource conflict occurrence data in the execution record fragments, and generate raw resource competition data.

[0102] From the full transaction flow record, execution record fragments involving multiple payment requests that call the same type of resource are filtered out based on resource type (e.g., CPU resources, memory resources, specific database resources, etc.). These record fragments are analyzed to extract resource request time (the time each payment request requests the resource), occupation duration (the length of time the resource is occupied), release order (the order in which multiple payment requests release the resource), and data on resource conflict occurrences (e.g., waiting time due to resource contention, operation failures, etc.). The above analysis results are integrated to generate raw resource contention data.

[0103] Step S135: Based on the original data of resource competition, extract the mutual influence relationship between different payment requests caused by resource calls, determine the triggering conditions, presentation content and scope of the influence, and generate resource competition related content.

[0104] For example, step S1351: Obtain the original resource competition data, extract the payment request identifier, resource type, resource application time, resource occupation duration, resource release time, and conflict occurrence identifier, and generate a set of resource competition data fields.

[0105] Key data fields are extracted from the raw resource competition data. The payment request identifier uniquely identifies each payment request; the resource type indicates the type of resource being competed for; the resource application time, occupation duration, and release time describe the resource's usage time information; and the conflict occurrence identifier indicates whether a resource conflict has occurred. These fields are then integrated to generate a set of resource competition data fields.

[0106] Step S1352: Group the resource competition data field set according to resource type, and group the relevant data such as payment request identifier, resource type, resource application time, resource occupation duration, resource release time, and conflict occurrence identifier of all payment requests involving the same resource type into one group to generate resource type grouping data.

[0107] The resource contention data field set is grouped according to resource type. All data records involving the same resource type are grouped together; for example, data records competing for CPU resources are placed in one group, and data records competing for memory resources are placed in another. This allows for separate analysis for different resource types, generating resource type-grouped data.

[0108] Step S1353: Group the data for each resource type, sort them according to the order of resource application time, organize the call sequence of each payment request for the corresponding resource, and generate a resource call sequence table.

[0109] For each group of resource types, the data records are sorted according to the order of resource request time. The call sequence of each payment request for that resource is compiled, including information such as request time, usage duration, and release time, forming a resource call sequence table. This table shows the call order and time distribution of multiple payment requests for the same resource.

[0110] Step S1354: Analyze the resource call time sequence table, identify the overlapping resource occupation time periods of different payment requests under the same resource type, record the overlapping time periods, the payment request identifiers involved and the resource occupation scale, and generate resource occupation overlap records.

[0111] Analyze the resource call sequence table to identify instances where resource usage periods overlap for different payment requests of the same resource type. Record the specific overlapping time periods (start and end times), the identifiers of the involved payment requests, and the resource usage scale (e.g., the amount of resources used) for each payment request within the overlapping period. Organize the above information to generate a resource usage overlap record.

[0112] Step S1355: For each overlapping period in the resource occupation overlap record, query the corresponding transaction flow full record fragment, extract the execution delay data, data synchronization failure data, or operation interruption data caused by resource occupation overlap, and generate overlap impact data.

[0113] For each overlapping period in the resource usage overlap records, query the corresponding segment in the full transaction flow record based on the time information. Extract the impact data caused by resource usage overlap from these record segments, such as execution delay data (operation execution time is longer than expected), data synchronization failure data (data synchronization fails due to resource contention), and operation interruption data (operation is forced to be interrupted during execution). Integrate the above data to generate overlap impact data.

[0114] Step S1356: Based on the overlapping impact data, extract the correspondence between the affected payment requests and the payment requests that caused the impact, determine the initiator identifier, recipient identifier and impact presentation content, and generate basic impact relationship data.

[0115] From the overlapping impact data, analyze the correspondence between affected payment requests and the payment requests that caused the impact. Determine the initiator of the impact (i.e., the payment request that caused the impact), the recipient (i.e., the affected payment request), and the content of the impact (such as specific impact manifestations like execution delays and synchronization failures). Organize the above correspondences and impact content to generate basic impact relationship data.

[0116] Step S1357: Extract the total resource demand data, resource call frequency data, and resource priority data for each payment request from the resource competition data field set, analyze the correlation between the total resource demand data, resource call frequency data, resource priority data, and the degree of influence of resource competition, and generate influence degree correlation data.

[0117] From the resource contention data field set, extract the total resource demand data (the total amount of resources required by the payment request), resource call frequency data (the number of times resources are called per unit time), and resource priority data (the resource call priority of the payment request) for each payment request. Analyze the correlation between these data and the degree of impact of resource contention (such as the severity and duration of the impact), for example, whether payment requests with large total resource demand are more likely to have a significant impact on other requests. Based on the analysis results, generate impact degree correlation data.

[0118] Step S1358: Combining the basic data on impact relationships and the data on the degree of impact, determine the intensity and scope of the impact caused by resource calls between different payment requests, and generate the results of the impact intensity division.

[0119] By combining basic data on impact relationships and data on the degree of impact correlation, a comprehensive assessment is conducted on the impact of resource allocation on different payment requests. Impact intensity can be quantified based on the correlations in the impact intensity correlation data, such as categorizing it as high-intensity, medium-intensity, or low-intensity impact; the scope of impact refers to the number and range of affected payment requests. Based on the assessment results, an impact intensity classification is generated.

[0120] Step S1359: Based on the impact intensity division results, construct a resource competition association network between different payment requests. The network nodes are payment request identifiers, and the connections between nodes indicate the existence of resource competition impact relationships. The connection attributes include impact intensity data and impact presentation content, thereby generating a resource competition association network.

[0121] Using payment request identifiers as network nodes, connections are established between nodes with resource competition relationships based on the intensity of their impact. The attributes of these connections include impact intensity data (e.g., high intensity, medium intensity) and impact presentation content (e.g., execution delay, synchronization failure). This method constructs a resource competition relationship network, visually demonstrating the resource competition relationships between different payment requests.

[0122] Step S13510: Extract and organize the relationship, influence intensity data, and influence presentation content information in the resource competition relationship network in a structured manner to generate resource competition relationship content.

[0123] The information in the resource competition network is structured to extract relationships (connections between nodes), influence strength data, and influence presentation. This information is then organized into a structured data format, such as tables or specific object structures, to generate resource competition relationship content.

[0124] Step S136: By comparing the linkage response specifications in the transaction scenario trajectory mapping, extract the deviation data between the node collaborative operation and data synchronization process in the full transaction flow record and the specification requirements, identify the deviation manifestations in the collaborative process, and generate the original record of collaborative deviation.

[0125] Compare the node collaboration operations and data synchronization processes in the full transaction flow record with the linkage response specifications in the transaction scenario trajectory mapping. Check whether the actual collaboration operations meet the requirements of the specifications, and whether the data synchronization process is performed according to the frequency and method specified in the specifications. Extract data with deviations, such as collaboration trigger time being later than the specification requirement, data synchronization frequency being lower than the specified value, etc., and identify the deviation manifestations in the collaboration process (such as "collaboration delay," "missing synchronization data," etc.). Record the above deviation data and manifestations to generate the original collaboration deviation record.

[0126] Step S137: Analyze the location, time, type and cause of deviation in the original record of collaborative deviation, and combine it with the resource consumption data and operation execution status data in the full record of transaction flow to generate collaborative deviation analysis data.

[0127] A thorough analysis of the original records of coordination deviations is conducted. This includes determining the specific location of the deviation (e.g., which nodes were involved in the coordination, which data synchronization process occurred), the time of occurrence, the type of deviation (e.g., time deviation, data deviation, operational deviation), and the possible causes (e.g., insufficient resources, network failure, node failure). By combining resource consumption data (e.g., node resource occupancy rate at the time of the deviation) and operation execution status data (e.g., whether the operation is in progress, whether any anomalies have occurred), the causes of the deviations are further verified and analyzed. The analysis results are then integrated to generate coordination deviation analysis data.

[0128] Step S138: Align and unify the fields and formats of the refined execution scenario attribute set, resource competition related content, and collaborative deviation analysis data to generate initial scenario feature related data.

[0129] Data preprocessing is performed on the refined execution scenario attribute set, resource competition correlation content, and collaborative deviation analysis data. Field alignment is performed to ensure consistency in field names and meanings across different datasets; format unification is achieved by converting all data to the same format (e.g., JSON). Through these processes, the three datasets are integrated to generate initial scenario feature correlation data.

[0130] Step S139: Clean and integrate the initial scene feature association data, supplement the missing association information in the data, correct the inconsistencies in the data description, and generate corrected scene feature association data.

[0131] The initial scene feature association data undergoes data cleaning to remove missing values, outliers, and duplicate data. Missing association information is supplemented by querying other relevant records or using appropriate interpolation methods. Inconsistencies in data representation (such as inconsistent terminology or data units) are corrected. After cleaning and integration, revised scene feature association data is generated, improving data quality and consistency.

[0132] Step S1310: Classify and organize the data in the modified scene feature association data according to the preset classification criteria, establish index associations between data, and generate scene feature association dataset.

[0133] Based on preset classification criteria (such as concurrency range, resource type, deviation type, etc.), the data in the scene feature association data is categorized and organized. Indexes are created to link different categories of data for easier subsequent querying and analysis. Through the above classification and indexing, a scene feature association dataset is generated. This well-organized dataset facilitates further model building and analysis.

[0134] Step S140: Build a concurrent conflict dynamic modeling model based on the scene feature association dataset, locate the conflict triggering node, the scope of impact and the transmission path in the transaction flow, and generate a conflict association graph.

[0135] A concurrent conflict dynamic model is built using a scenario feature-related dataset as input. This model analyzes execution scenario attributes, resource competition correlation content, and coordination deviation analysis data in the dataset to identify conflict triggering nodes (i.e., nodes that cause conflict), the scope of conflict (nodes and operational steps affected by the conflict), and the conflict propagation path (the route the conflict takes from the triggering node to other nodes). Based on the model's analysis results, a conflict correlation graph is generated, which graphically displays relevant conflict information.

[0136] Step S141: Obtain the scene feature association dataset, extract the resource competition association content and the collaboration deviation analysis data from it, and use the resource competition association content and the collaboration deviation analysis data together as the basic data for conflict analysis to generate the conflict analysis data source.

[0137] Resource content competition and collaborative deviation analysis data are extracted from the scenario feature association dataset. Resource content competition reflects the conflict relationships between different payment requests due to resource allocation, while collaborative deviation analysis data reflects deviations in collaborative operations. These are both important factors leading to concurrent conflicts. These two datasets are merged as the foundation for conflict analysis, generating a conflict analysis data source.

[0138] Step S142: Extract the first data item that may cause transaction execution anomalies from the conflict analysis data source. The first data item directly reflects the intensity of resource competition and the prominence of coordination deviation, and generate a set of conflict first data items.

[0139] Analyzing the conflict analysis data source identifies the primary data items that may trigger transaction execution anomalies. These data items directly reflect the intensity of resource contention (e.g., the number of resource conflicts per unit time, the duration of resource overlap, etc.) and the prominence of coordination deviations (e.g., the frequency and severity of coordination deviations, etc.). These data items are then extracted to generate a set of primary conflict data items.

[0140] Step S143: Based on the first set of conflicting data items, analyze the relationship between different data items, extract the combination of data items that cause the conflict, and generate the combination of conflict triggering conditions.

[0141] Perform correlation analysis on the data items in the first set of conflict data items to identify the relationships between different data items. For example, is there a positive correlation between the number of resource conflicts and the frequency of coordination deviations? Based on these correlations, extract combinations of data items that may lead to conflicts, such as the combination condition "the number of resource conflicts exceeds a certain threshold and the frequency of coordination deviations exceeds a certain threshold". Organize the above combination conditions to generate conflict triggering condition combinations.

[0142] Step S144: For each combination of conflict triggering conditions, trace the corresponding full record of transaction flow in the scenario feature association dataset, locate the node operation, resource call request or data synchronization process in which the conflict first occurs, and generate the conflict triggering node location result.

[0143] For each combination of conflict triggering conditions, the full record fragments of transaction flows that satisfy the combination of conditions are searched in the scenario feature association dataset. By analyzing these record fragments, the specific location where the conflict first occurred is traced, which could be the execution process of an operation on a certain node, the initiation process of a resource call request, or a data synchronization process. The specific node and operation that triggered the conflict are determined, and the conflict triggering node location result is generated.

[0144] Step S145: Starting from the location result of the conflict triggering node, track the impact of the corresponding conflict on subsequent transaction operations, other distributed nodes and related payment requests, record the affected operation links, node range and payment request identifier, and generate conflict impact range data.

[0145] Starting with the location of the conflict-triggered node, track the spread of the conflict. Observe the impact of the conflict on the execution of subsequent transaction operations, such as whether it causes operation delays or failures; record other affected distributed nodes and the payment request identifiers being executed on these nodes; determine the affected operation steps, such as the fund transfer step in the first operation step and the notification sending step in the second operation step. Record the above affected information to generate conflict ripple range data.

[0146] Step S146: Analyze the relationship logic between affected objects in the conflict impact range data, extract the path, transmission method and change data of the conflict from the triggering node to other objects, and generate a conflict transmission path description.

[0147] Analyze the logical relationships between affected objects (such as nodes, operational steps, payment requests, etc.) in the conflict impact data. Determine the specific path of conflict propagation from the triggering node to other objects, such as propagation through data dependencies or resource sharing relationships; the propagation method, such as direct propagation or indirect propagation; and the changes in conflict data during propagation, such as whether the intensity of the conflict increases or decreases, or whether the type of conflict changes. Organize the above analysis results to generate a conflict propagation path description.

[0148] Step S147: Combining the conflict triggering node location results, conflict impact range data, and conflict propagation path description, construct an initial conflict association model with the conflict triggering node as the core, the impact range as the branch, and the propagation path as the connection.

[0149] Using the conflict triggering node from the conflict triggering node location results as the core of the model, and the affected objects from the conflict impact range data as branch nodes, the core node and branch nodes are connected through the transmission path in the conflict transmission path description. This constructs an initial conflict association model that can intuitively demonstrate the triggering, impact, and transmission relationships of conflicts.

[0150] Step S148: Integrate the relevant data from the refined execution scenario attribute set into the initial conflict association model to generate an enhanced conflict association model.

[0151] Data related to conflict correlation, such as concurrency and node load rate, is extracted from the refined set of execution scenario attributes. This data is then integrated into the initial conflict correlation model. For example, concurrency is used as a parameter to adjust the probability and impact of conflict occurrence; node load rate is used as a node attribute to influence the likelihood of conflict propagation. By incorporating this data, the model's ability to describe dynamic changes in conflict is enhanced, generating an enhanced conflict correlation model.

[0152] Step S149: Optimize the structure of the enhanced conflict association model, simplify redundant association paths, strengthen the connection relationship between core conflict elements, and generate a concurrent conflict dynamic modeling model.

[0153] The enhanced conflict correlation model undergoes structural optimization. Redundant correlation paths in the model are identified and simplified; these paths contribute little to conflict analysis and only increase model complexity. The connections between core conflict elements (such as major conflict triggering nodes and key transmission paths) are strengthened, highlighting their importance in the conflict process. Through these optimization measures, a more concise and analytically powerful concurrent conflict dynamic model is generated.

[0154] Step S1410: Based on the concurrent conflict dynamic modeling model, extract the conflict trigger node identifier, the affected area boundary, and the first information of the transmission path node. Present the conflict trigger node identifier, the affected area boundary, and the first information of the transmission path node in a graph format to generate a conflict association graph.

[0155] From the concurrent conflict dynamic modeling model, extract the identification information of the conflict triggering node, the boundary of the conflict's impact range (such as the maximum affected area), and the node information on the transmission path. Present this information in a graph format (e.g., using a directed graph, nodes are represented by circles, and paths are represented by arrowed lines) to generate a conflict association graph. This graph displays the conflict's triggering point, impact range, and transmission route.

[0156] Step S150: Based on the conflict association diagram, a dynamic linkage adaptation scheme for transactions is formed. Through the node scheduling operation, resource allocation process and operation coordination adjustment action of the asynchronous execution engine, the transaction execution of all payment requests is completed, the execution results are summarized and fed back to the corresponding payment initiator.

[0157] Based on the conflict information shown in the conflict correlation diagram, a dynamic transaction linkage adaptation scheme is formulated. This scheme includes handling measures for conflict-triggered nodes, methods for controlling the scope of impact, and strategies for blocking transmission paths. The scheme resolves conflicts and completes the transaction execution of all payment requests by using an asynchronous execution engine to perform node scheduling operations (such as migrating tasks from conflicting nodes to other nodes), resource allocation processes (such as increasing resource allocation to conflicting nodes), and operational coordination adjustments (such as adjusting the coordination methods between nodes). Finally, the execution results of all payment requests are summarized and fed back to the corresponding payment initiator.

[0158] For example, step S151: Obtain the conflict association graph, extract the conflict trigger node identifier, the boundary of the affected area, the transmission path node and the conflict type information, and generate a set of core conflict information.

[0159] From the conflict correlation diagram, extract key conflict information. Conflict trigger node identifiers determine the starting point of the conflict; the affected area boundary clarifies the maximum scope of the conflict's impact; the propagation path nodes list the nodes the conflict passes through during its propagation; and the conflict type information describes the nature of the conflict (e.g., resource conflict, data conflict, etc.). Integrate the above information to generate a core conflict information set.

[0160] Step S152: Analyze the impact of each conflict from the core conflict information set, combine the scope and depth of the conflict's impact on transaction execution, divide the conflict handling priorities, and generate a conflict handling priority list.

[0161] Each conflict in the core conflict information set undergoes an impact degree analysis. Impact degree considers the scope of the conflict (number of affected nodes and operations) and the depth of impact (degree of obstruction to transaction execution, magnitude of losses, etc.). Based on the different impact degrees, conflicts are divided into different processing priorities, such as high priority (requiring immediate processing), medium priority (to be processed within a specified time), and low priority (processing can be postponed). The conflicts are then sorted according to processing priority to generate a conflict processing priority list.

[0162] Step S153: For each conflict in the conflict handling priority list, query the corresponding execution scenario attributes and collaborative deviation analysis data in the scenario feature association dataset, determine the corresponding conflict handling direction in the current concurrent scenario, and generate conflict handling direction guidance.

[0163] For each conflict in the conflict handling priority list, based on information such as the conflict triggering node identifier, the corresponding execution scenario attributes (such as current concurrency and node load) and coordination deviation analysis data (such as the reasons for the deviation caused by the conflict) are queried from the scenario feature association dataset. Combining this data, the direction for handling the conflict in the current concurrency scenario is determined, such as adding resources, adjusting nodes, or modifying coordination rules, thus generating conflict handling direction guidance.

[0164] Step S154: Based on the conflict handling direction guidance and combined with the attributes of the conflict triggering node, extract the resource adjustment parameters for the corresponding conflict, including the resource reallocation ratio, resource scheduling path optimization method, and resource occupation duration adjustment data, and generate a detailed resource adjustment plan.

[0165] Based on the conflict resolution guidelines and the attributes of the conflict-triggered node (such as the node's resource type and current resource occupancy), determine the resource adjustment parameters. The resource reallocation ratio refers to the proportion of resources from other nodes allocated to the conflict-triggered node; the resource scheduling path optimization method refers to optimizing the resource scheduling route between nodes to reduce resource transmission latency; and the resource occupancy duration adjustment data refers to adjusting the resource occupancy time of the conflict-triggered node. Integrate these parameters to generate a detailed resource adjustment plan.

[0166] Step S155: Analyze the relationships between nodes in the conflict propagation path, extract the node operation adjustment parameters that block conflict propagation, including node execution order adjustment methods, node function switching schemes, and node data caching optimization measures, and generate a set of node adjustment strategies.

[0167] Analyze the relationships between nodes in the conflict propagation path to identify node operation adjustment parameters that can block conflict propagation. Node execution order adjustment refers to changing the execution order of operations on a node to avoid conflict propagation; node function switching refers to switching some functions of a node to other nodes for execution, reducing the load on the conflicting node; node data caching optimization measures refer to optimizing node data caching strategies to improve data access efficiency and reduce conflicts caused by data interaction. Organize these adjustment parameters to generate a set of node adjustment strategies.

[0168] Step S156: Combining the details of the resource adjustment plan and the set of node adjustment strategies, extract the impact data of the adjustment measures on the execution of related payment request transactions, determine the implementation time, execution steps and connection methods of the adjustment measures, and generate adjustment implementation details.

[0169] A comprehensive analysis is conducted on the adjustment measures within the resource adjustment plan details and node adjustment strategy set to assess their impact on the execution of related payment request transactions, such as whether they will cause delays in other operations or affect data consistency. Based on the assessment results, the implementation time of the adjustment measures (e.g., during a specific off-peak period), the implementation steps (specific operations to be performed sequentially), and the connection method between different measures (e.g., node adjustment after resource adjustment is completed) are determined. The above information is then compiled to generate detailed adjustment implementation rules.

[0170] Step S157: For each adjustment measure in the implementation details, extract the corresponding exception handling parameters so that when new problems arise during the adjustment process, the corresponding handling operations can be performed, and an adjustment contingency plan set can be generated.

[0171] For each adjustment measure in the implementation details, predict potential anomalies (such as resource adjustment failure, node switching anomalies, etc.) and extract corresponding anomaly response parameters. These parameters include anomaly detection conditions (such as node load still exceeding a threshold after resource adjustment) and response measures (such as rolling back the adjustment operation, starting a backup node, etc.). Compile these anomaly response parameters to generate an adjustment contingency plan set, ensuring timely handling of any issues that arise during the adjustment process.

[0172] Step S158: Integrate the details of all conflict-related resource adjustment plans, node adjustment strategies, adjustment implementation rules, and adjustment contingency plans, analyze the synergy and compatibility between different conflict adjustment measures, and generate an initial dynamic linkage adaptation plan.

[0173] All conflicting resource adjustment plans, node adjustment strategies, implementation rules, and contingency plans are integrated. The synergistic effects (e.g., a resource adjustment measure alleviates multiple conflicts) and compatibility (e.g., conflicts exist between different node adjustment strategies) of the adjustment measures are analyzed. Based on the analysis results, the adjustment measures are coordinated and optimized to generate an initial dynamic linkage adaptation plan.

[0174] Step S159: Conduct a feasibility analysis on the initial transaction dynamic linkage adaptation scheme, simulate the execution process under the current concurrent payment scenario, extract analysis data that effectively resolves conflicts without causing new problems, and generate the scheme feasibility analysis results.

[0175] Using simulation tools or environments, the execution process of the initial transaction dynamic linkage adaptation scheme is simulated under the current concurrent payment scenario. The execution effect of the scheme is observed to check whether it can effectively resolve conflicts and whether it will cause new problems (such as resource strain on other nodes, new conflicts, etc.). Key data from the simulation process, such as conflict resolution rate, transaction execution success rate, and resource utilization, are extracted to generate a feasibility analysis result for the scheme.

[0176] Step S1510: Based on the feasibility analysis results, optimize and improve the adjustment measures in the initial transaction dynamic linkage adaptation scheme to generate a transaction dynamic linkage adaptation scheme.

[0177] Based on the feasibility analysis results, the adjustment measures in the initial dynamic transaction linkage adaptation scheme were optimized. Measures that effectively resolve conflicts without causing new problems were retained; measures that were ineffective or might cause new problems were modified or replaced; and necessary adjustment measures were added to improve the overall effectiveness of the scheme. After optimization and improvement, the final dynamic transaction linkage adaptation scheme was generated.

[0178] For example, step S1511: Extract the details of resource adjustment schemes, node adjustment strategy sets and adjustment implementation rules from the transaction dynamic linkage adaptation scheme, and generate engine scheduling configuration parameters.

[0179] From the dynamic linkage adaptation scheme for transactions, extract the details of resource adjustment schemes (such as resource allocation ratios, scheduling paths, etc.), the set of node adjustment strategies (such as node execution order, function switching schemes, etc.), and the adjustment implementation details (such as implementation time, execution steps, etc.). Convert the above information into scheduling configuration parameters that the asynchronous execution engine can recognize and execute, and generate engine scheduling configuration parameters.

[0180] Step S1512: Input the engine scheduling configuration parameters into the scheduling module of the asynchronous execution engine to trigger the resource adjustment process. According to the requirements in the resource adjustment plan details, reallocate the computing resources, storage resources and network resources of the distributed nodes, record the objects of resource adjustment, the adjustment amount, the adjustment time and the resource status after adjustment, and generate a resource adjustment execution record.

[0181] The engine scheduling configuration parameters are input into the scheduling module of the asynchronous execution engine. The scheduling module triggers the resource reallocation process based on the parameters. According to the requirements of the resource adjustment plan details, the computing resources (such as the number of CPU cores), storage resources (such as disk space), and network resources (such as bandwidth) of the distributed nodes are reallocated. The system records the objects of resource reallocation (the nodes involved), the reallocation amount (the amount of resources adjusted), the reallocation time (start and end times), and the resource status after reallocation (the resource occupancy of each node), generating a resource reallocation execution record.

[0182] Step S1513: Based on the node adjustment strategy set, adjust the execution status of distributed nodes through the node management module of the asynchronous execution engine, including node start operation, pause operation, restart operation, and function switching operation. Record the node adjustment identifier, adjustment operation content, adjustment time, and node running status after adjustment, and generate a node adjustment execution record.

[0183] Based on the node adjustment strategy set, the execution status of distributed nodes is adjusted through the node management module of the asynchronous execution engine. This includes node startup operations (starting a new node or restarting a stopped node), pause operations (pausing some or all operations on a node), restart operations (restarting a node to resolve exceptions), and function switching operations (switching the node's functional mode). Each node adjustment is recorded, including its identifier (node ​​ID), the specific content of the adjustment operation, the time of the adjustment, and the node's running status after the adjustment (e.g., "running normally," "paused," etc.), generating a node adjustment execution record.

[0184] Step S1514: In accordance with the requirements of the adjustment implementation details, adjust the execution order of transaction operations, data synchronization frequency and collaboration mode between nodes through the collaborative control module of the asynchronous execution engine, record the operation steps, adjustment content, adjustment time and collaborative effect data after adjustment, and generate collaborative adjustment execution records.

[0185] Based on the implementation details, transaction operations are adjusted through the collaborative control module of the asynchronous execution engine. This includes adjusting the execution order of transaction operations (e.g., changing the order of certain operations), adjusting the data synchronization frequency (e.g., increasing or decreasing the number of data synchronizations), and changing the collaboration method between nodes (e.g., changing from synchronous to asynchronous collaboration). The system records the operational steps involved in the collaborative adjustment, the specific adjustment content, the adjustment time, and the resulting collaborative effect data (e.g., reduced collaboration latency, improved synchronization success rate), generating a collaborative adjustment execution record.

[0186] Step S1515: During the resource allocation process, node adjustment operation and collaborative adjustment action execution, monitor the transaction execution status of each payment request in real time, including operation completion progress data, data synchronization status data, resource usage status data and whether new conflict data have occurred, and generate a real-time monitoring record of the execution status.

[0187] During resource allocation, node adjustment, and collaborative adjustment, the transaction execution status of each payment request is monitored in real time using system monitoring tools. This includes collecting data on operation completion progress (e.g., the proportion of completed operation steps to total steps), data synchronization status (e.g., number of successful and failed synchronizations), resource usage status (e.g., the current node's resource occupancy rate), and whether new conflicts have occurred (e.g., whether new resource contention or collaborative deviations have arisen). This monitoring data is then compiled to generate a real-time execution status monitoring record.

[0188] Step S1516: When an abnormal situation that matches the set of adjustment plans is detected in the real-time monitoring record of the execution status, the corresponding abnormal response plan is triggered, the preset processing operation is executed, the time, measures, results and impact data of the abnormal handling are recorded, and an abnormal handling execution record is generated.

[0189] Continuous monitoring of the execution status records in real time is performed. When a situation is detected that meets the preset abnormal conditions in the adjustment plan set, the corresponding abnormal response plan is immediately triggered. The preset processing operations in the plan are executed, such as rolling back resource reallocation operations, switching to a standby node, and restarting the collaborative process. The time of abnormal handling, the specific measures taken, the handling results (such as whether the abnormality was resolved), and the impact data on transaction execution (such as whether transaction execution has returned to normal, whether there is any delay, etc.) are recorded, and an abnormal handling execution record is generated.

[0190] Step S1517: Track the completion status of each payment request transaction operation. When all the first operation steps are completed and the transaction completion criteria are met, record the first operation completion time, completion status and result data, and generate the first operation completion record.

[0191] Continuously track the completion status of each payment request transaction. When all steps in the first operation are completed and the transaction completion criteria specified in the transaction attribute classification set are met (such as successful fund transfer, correct writing of transaction records, etc.), record the completion time, completion status (such as "successfully completed", "partially completed", etc.) and related result data (such as transfer amount, transaction serial number, etc.) of the first operation, and generate the first operation completion record.

[0192] Step S1518: After the second operation is completed in accordance with the linkage response specification, record the completion time, completion status and auxiliary effect data of the second operation, and generate the second operation completion record.

[0193] After the first operation is completed, continue to track the execution of the second operation. When the second operation is completed in accordance with the requirements of the linkage response specification, record the completion time, completion status (such as "successfully completed", "downgraded and completed", etc.), and auxiliary effect data (such as the number of notifications successfully sent, the increase in points, etc.), and generate a second operation completion record.

[0194] Step S1519: Integrate the resource allocation execution record, node adjustment execution record, collaborative adjustment execution record, real-time execution status monitoring record, exception handling execution record, first operation completion record, and second operation completion record to generate the final transaction execution record for each payment request.

[0195] The resource allocation execution record, node adjustment execution record, collaborative adjustment execution record, real-time execution status monitoring record, exception handling execution record, first operation completion record, and second operation completion record are integrated. These records are then associated according to the payment request identifier to form a complete final execution record for each payment request. This final execution record contains all key information from the transaction execution process.

[0196] Step S1520: Based on the final execution record of all payment requests, confirm the execution effect of each payment request, summarize them to form a payment result, and feed back the payment result to the corresponding payment initiator according to the corresponding payment request identifier.

[0197] Analyze the final execution records of all payment requests to confirm the effectiveness of each request, such as whether the transaction was successfully completed and whether any anomalies occurred. Summarize the execution results to form a payment outcome, which includes the payment request identifier, transaction status (success / failure), and relevant result information (such as transaction amount and completion time). Send the payment outcome to the corresponding payment initiator through the original payment request's feedback channel, according to the corresponding payment request identifier.

[0198] Furthermore, Figure 2A schematic diagram of the hardware structure of an asynchronous transaction processing system 100 for concurrent payment scenarios, used to implement the methods provided in the embodiments of this application, is shown. Figure 2 As shown, the asynchronous transaction processing system 100 for concurrent payment scenarios may include at least one processor 102 (the processor 102 may be, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, a transmission device 106 for communication functions, and a controller 108. Those skilled in the art will understand that... Figure 2 The structure shown is for illustrative purposes only and does not limit the structure of the asynchronous transaction processing system 100 for concurrent payment scenarios. For example, the asynchronous transaction processing system 100 for concurrent payment scenarios may also include... Figure 2 The more or fewer components shown, or having the same Figure 2 The different configurations shown.

[0199] The memory 104 can be used to store software programs and modules of the application software, such as the program instructions corresponding to the method embodiments described above in this application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the above-described asynchronous transaction processing method for concurrent payment scenarios. The transmission device 106 is used to acquire or send data via a network.

[0200] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

Claims

1. An asynchronous transaction processing method for concurrent payment scenarios, characterized in that, The method includes: Receive a set of concurrent payment requests and generate a transaction scenario trajectory mapping for each payment request, which includes transaction attribute information, execution scenario adaptation data, and linkage response specifications. Based on the transaction scenario trajectory mapping, the asynchronous execution engine is started, driving the transaction operation corresponding to each payment request to flow in the distributed nodes, and recording the operation coordination content, data synchronization status and resource consumption data between nodes to form a full record of the transaction flow. Extract execution scenario attributes, resource competition-related content, and coordination deviation data from the full transaction flow records of all payment requests to generate a scenario feature association dataset; A concurrent conflict dynamic modeling model is built based on the scene feature association dataset to locate the conflict triggering node, the scope of impact and the transmission path in the transaction flow, and generate a conflict association graph. Based on the conflict relationship diagram, a dynamic linkage and adaptation scheme for transactions is formed. Through the node scheduling operation, resource allocation process and operation coordination adjustment action of the asynchronous execution engine, the transaction execution of all payment requests is completed, the execution results are summarized and fed back to the corresponding payment initiator.

2. The asynchronous transaction processing method for concurrent payment scenarios according to claim 1, characterized in that, The process of generating a transaction scenario trajectory mapping for each payment request, including transaction attribute information, execution scenario adaptation data, and linkage response specifications, includes: The transaction attribute information carried in the payment request is analyzed, and the payment account associated content, fund transfer path planning, compliance review basis, and transaction completion standard are classified and integrated according to the operation steps to generate a transaction attribute classification set. The transaction attribute information includes payment account associated content, fund transfer path planning, compliance review basis, and transaction completion standard. Analyze the transaction type corresponding to the payment request, and in conjunction with the current concurrent running status of the system, extract the types of distributed nodes, data interaction methods, and resource call priorities that may be involved in the execution of the payment request, and generate basic data for the execution scenario; Retrieve the historical transaction records corresponding to the payment request, extract scenario adaptation data, node selection preferences and resource allocation data during the historical execution process, and generate historical scenario adaptation reference content; Based on the transaction attribute classification set and the basic data of the execution scenario, the transaction execution is divided into the first operation step and the second operation step. The first operation step is the necessary process to ensure the effective completion of the transaction, and the second operation step is the auxiliary process to supplement and improve the transaction process. For the first operation stage, based on historical scenario adaptation reference content, we extract execution node combination data, data synchronization frequency parameters and fault-tolerant alternative path information under different concurrency pressures to generate scenario adaptation data for the first stage. Based on the scenario adaptation data from the first stage, the second stage involves generating adaptation data, integrating adaptation data across the entire process, formulating linkage response specifications, and constructing and verifying transaction scenario trajectory mapping.

3. The asynchronous transaction processing method for concurrent payment scenarios according to claim 2, characterized in that, The process of generating second-stage adaptation data based on the first-stage scenario adaptation data, integrating full-process adaptation data, formulating linkage response specifications, and constructing and verifying transaction scenario trajectory mappings includes: For the second operation stage, extract the schedulable range data of the second operation stage, the connection logic information with the first operation stage, and the execution degradation method when resources are scarce, and generate the second stage scenario adaptation data; Integrate the scenario adaptation data from the first stage and the scenario adaptation data from the second stage to form execution scenario adaptation data covering the entire process; Based on execution scenario adaptation data and transaction attribute classification set, the operation coordination logic, data dependency relationship and conflict avoidance path between different payment requests are extracted, the linkage triggering conditions and response operation standards between transactions are extracted, and linkage response specifications are generated. The transaction attribute classification set, execution scenario adaptation data, and linkage response specifications are structurally integrated. The elements of the transaction attribute classification set, the elements of the execution scenario adaptation data, and the elements of the linkage response specifications are arranged according to the preset mapping format to generate a transaction scenario trajectory mapping. The logic of element association in the transaction scenario trajectory mapping is verified. By supplementing missing association data between elements, correcting inconsistencies in element descriptions, and organizing the logical order of element arrangement, the consistency between transaction attribute information, execution scenario adaptation data, and linkage response specifications is maintained. Based on the verification results, the structure and content description of the transaction scenario trajectory mapping are adjusted to improve the transaction scenario trajectory mapping.

4. The asynchronous transaction processing method for concurrent payment scenarios according to claim 1, characterized in that, The asynchronous execution engine, based on transaction scenario trajectory mapping, drives the transaction operations corresponding to each payment request to flow through distributed nodes, recording the full transaction flow, including: Obtain the transaction scenario trajectory mapping for each payment request, extract the execution scenario adaptation data and linkage response specifications, and convert the execution scenario adaptation data and linkage response specifications into startup parameters that the asynchronous execution engine can recognize, thereby generating an engine startup configuration set. Input the engine startup configuration set into the asynchronous execution engine to trigger the engine initialization process, which sequentially completes the connection adaptation operation of distributed nodes, the startup operation of the resource scheduling module, and the establishment operation of the data synchronization channel, generating an engine initialization completion signal; Based on the engine initialization completion signal, according to the execution scenario adaptation data in the transaction scenario trajectory mapping, the first operation stage of each payment request is assigned a combination of execution nodes, the operation division of labor and data transmission path between nodes are determined, and the first operation node allocation scheme is generated. Based on the first operation node allocation scheme, the first operation step is driven to start and execute in the corresponding distributed nodes, and the operation execution progress data, data processing result information and resource usage data of the nodes are collected in real time to generate the first operation execution record; According to the linkage response specification in the transaction scenario trajectory mapping, the scheduling process of the second operation is triggered during the execution of the first operation, an execution node is allocated to the second operation, the execution sequence connection relationship between the second operation and the first operation is determined, and a second operation scheduling scheme is generated. Based on the second operation scheduling scheme, the second stage execution record generation, node collaboration and data synchronization monitoring, resource consumption statistics, and full transaction flow record integration are performed.

5. The asynchronous transaction processing method for concurrent payment scenarios according to claim 4, characterized in that, The process of generating execution records for the second stage based on the second operation scheduling scheme, monitoring node collaboration and data synchronization, integrating resource consumption statistics and full transaction flow records includes: According to the second operation scheduling scheme, the second operation is driven to be executed in the distributed nodes, and the execution process data, data interaction content and support data of the first operation are recorded to generate the second operation execution record; Real-time monitoring of the operational collaboration status between distributed nodes, recording the collaboration trigger time, data synchronization content, synchronization delay data, and collaboration anomaly data between nodes, and generating node collaboration monitoring records; Track the data synchronization process of each transaction operation, record the data transmission path from the initiating node to the receiving node, the encryption method, the verification result, and the synchronization completion status, and generate a data synchronization tracking record; The system collects statistics on the types, scale, duration, and release time of resource consumption for each distributed node during transaction execution, generating a record of node resource consumption statistics. Integrate the first operation execution record, the second operation execution record, the node collaboration monitoring record, the data synchronization tracking record, and the node resource consumption statistics record. Sort and combine the first operation execution record, the second operation execution record, the node collaboration monitoring record, the data synchronization tracking record, and the node resource consumption statistics record according to the time sequence and operation association logic to generate a full record of the transaction flow.

6. The asynchronous transaction processing method for concurrent payment scenarios according to claim 1, characterized in that, The process of extracting execution scenario attributes, resource content competition correlation, and coordination deviation data from the full transaction flow record of all payment requests to generate a scenario feature correlation dataset includes: Obtain the full transaction flow record of all payment requests and the corresponding transaction scenario trajectory mapping. Then, compare and correlate the full transaction flow record with the execution scenario adaptation data in the transaction scenario trajectory mapping to generate a related dataset. Extract the transaction operation execution environment parameters, node configuration information, resource call mode and data interaction characteristics of each payment request from the associated dataset. The transaction operation execution environment parameters, node configuration information, resource call mode and data interaction characteristics together reflect the scenario adaptation status of transaction execution and generate an initial execution scenario attribute set. The data in the initial execution scenario attribute set is classified and filtered, retaining data directly related to the concurrent execution state, and removing duplicate and irrelevant data to generate a refined execution scenario attribute set; Execution record fragments involving multiple payment requests for the same type of resource calls are selected from the full transaction flow record. The resource request time, occupation duration, release order, and resource conflict occurrence data in the execution record fragments are analyzed to generate raw resource competition data. Based on the raw data of resource competition, the mutual influence relationship between different payment requests caused by resource calls is extracted, the triggering conditions, presentation content and scope of the influence are determined, and resource competition related content is generated. Based on resource competition-related content, collaborative deviation analysis, feature data format standardization, cleaning and correction, and generation of scene feature-related datasets are performed.

7. The asynchronous transaction processing method for concurrent payment scenarios according to claim 6, characterized in that, The process of performing collaborative deviation analysis, standardizing feature data formats, cleaning and correcting data, and generating scene feature association datasets based on resource competition-related content includes: By comparing the linkage response specifications in the transaction scenario trajectory mapping, the deviation data of node collaborative operation and data synchronization process in the full transaction flow record with the specification requirements are extracted, the deviation manifestation content in the collaborative process is identified, and the original record of collaborative deviation is generated. Analyze the location, time, type, and cause of deviations in the original records of collaborative deviations, and combine them with the resource consumption data and operation execution status data in the full transaction flow records to generate collaborative deviation analysis data; The refined execution scenario attribute set, resource competition related content, and collaborative deviation analysis data are aligned and formatted to generate initial scenario feature related data. The initial scene feature association data is cleaned and integrated to supplement the missing association information in the data, correct inconsistencies in the data description, and generate corrected scene feature association data. The data in the scene feature association data are classified and organized according to the preset classification criteria, and the index association between the data is established to generate the scene feature association dataset.

8. The asynchronous transaction processing method for concurrent payment scenarios according to claim 1, characterized in that, The concurrent conflict dynamic modeling model built based on the scene feature association dataset, which locates the conflict triggering node, the affected area and the transmission path, and generates a conflict association graph, includes: Obtain the scene feature association dataset, extract the resource competition association content and the collaboration deviation analysis data from it, and use the resource competition association content and the collaboration deviation analysis data together as the basic data for conflict analysis to generate the conflict analysis data source; Extract the first data item that may cause transaction execution anomalies from the conflict analysis data source. The first data item directly reflects the intensity of resource competition and the prominence of coordination deviation, and generate a set of conflict first data items. Based on the first set of conflicting data items, analyze the relationships between different data items, extract the combination of data items that cause the conflict, and generate a combination of conflict triggering conditions. For each combination of conflict triggering conditions, trace the corresponding full record of transaction flow in the scenario feature association dataset, locate the node operation, resource call request or data synchronization process where the conflict first occurs, and generate conflict triggering node location results; Starting from the location of the conflict-triggered node, track the impact of the corresponding conflict on subsequent transaction operations, other distributed nodes and related payment requests, record the affected operation links, node ranges and payment request identifiers, and generate conflict impact range data. Based on the conflict impact range data, we perform conflict propagation path analysis, conflict correlation model construction and optimization, and conflict correlation graph generation.

9. The asynchronous transaction processing method for concurrent payment scenarios according to claim 8, characterized in that, The process of performing conflict propagation path analysis, conflict correlation model construction and optimization, and conflict correlation graph generation based on conflict impact range data includes: Analyze the relationship logic between affected objects in the conflict impact range data, extract the path, transmission method and change data of the conflict from the triggering node to other objects, and generate a conflict transmission path description; Based on the location results of the conflict triggering node, the data on the scope of the conflict, and the description of the conflict propagation path, an initial conflict association model is built with the conflict triggering node as the core, the scope of the conflict as the branch, and the propagation path as the connection. The relevant data from the refined execution scenario attribute set is integrated into the initial conflict association model to generate an enhanced conflict association model; The enhanced conflict association model is structurally optimized to simplify redundant association paths, strengthen the connection between core conflict elements, and generate a concurrent conflict dynamic modeling model. Based on the concurrent conflict dynamic modeling model, the conflict trigger node identifier, the affected area boundary, and the first information of the transmission path node are extracted. The conflict trigger node identifier, the affected area boundary, and the first information of the transmission path node are presented in a graph format to generate a conflict association graph.

10. An asynchronous transaction processing system for concurrent payment scenarios, characterized in that, It includes a processor and a readable storage medium storing a program that, when executed by the processor, implements the asynchronous transaction processing method for concurrent payment scenarios as described in any one of claims 1-9.

Images