Transaction processing method and device, equipment, medium and product

Abstract

The embodiment of the invention provides a transaction processing method and device, equipment, a medium and a product, and belongs to the technical field of data processing. The method comprises the following steps: under the condition that a target financial transaction is received, storing transaction information of the target financial transaction into a distributed log through a coordinator node, and sending a transaction execution request to a target participant node through the coordinator node; under the condition that the target participant node responds to the transaction execution request and executes the target financial transaction based on the transaction information, persistently recording the execution state of executing the target financial transaction in a distributed log; in the process that the target participant node executes the target financial transaction, if at least one of the coordinator node and the target participant node breaks down, the current transaction state in the coordinator node and the target participant node is recovered to the execution state recorded in the distributed log. According to the embodiment of the invention, the consistency of transaction processing can be improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a transaction processing method, apparatus, device, medium and product. Background Technology

[0002] In distributed systems in the financial sector, the consistency of transaction processing is a core requirement for ensuring business security. Especially in scenarios such as cross-institutional transfers and multi-account fund settlements, it is necessary to ensure that the fund data of both parties to the transaction are updated synchronously to avoid problems such as one-sided accounts and duplicate entries, otherwise it may lead to financial risks and a crisis of user trust.

[0003] Currently, most existing distributed transaction processing methods employ traditional coordination mechanisms (such as two-phase commit protocols) to manage cross-node transactions. These methods generally suffer from insufficient consistency guarantees when processing financial transactions: on the one hand, traditional coordination mechanisms rely on real-time communication between nodes to confirm transaction status. In high-concurrency scenarios, network latency or node response timeouts can easily lead to interruptions in transaction state synchronization, resulting in some nodes having already executed local commits while others remain in an incomplete state. This makes it difficult to maintain transaction consistency under complex network environments and high concurrency pressure. Summary of the Invention

[0004] The main objective of this application is to provide a transaction processing method, apparatus, device, medium, and product, which aims to improve the consistency of transaction processing.

[0005] To achieve the above objectives, a first aspect of this application proposes a transaction processing method applied to a distributed system. The distributed system includes a coordinator node, participant nodes, and a distributed log. The coordinator node coordinates the participant nodes to execute financial transactions, and the distributed log is associated with both the coordinator node and the participant nodes. The method includes:

[0006] Upon receiving a target financial transaction, the coordinator node stores the transaction information of the target financial transaction in a distributed log and sends a transaction execution request to the target participant node through the coordinator node; the target participant node is associated with the target financial transaction, and the transaction execution request includes transaction information;

[0007] When the target participant node responds to the transaction execution request and executes the target financial transaction based on the transaction information, the execution status of the target financial transaction is persistently recorded in the distributed log.

[0008] If at least one of the coordinator node and the target participant node fails during the execution of the target financial transaction by the target participant node, the current transaction state of the coordinator node and the target participant node will be restored to the execution state recorded in the distributed log.

[0009] To achieve the above objectives, a second aspect of this application provides a transaction processing apparatus applied to a distributed system, the distributed system including a coordinator node, participant nodes, and a distributed log, wherein the coordinator node is used to coordinate the participant nodes to execute financial transactions, and the distributed log is associated with both the coordinator node and the participant nodes; the apparatus includes:

[0010] A storage module is used to, upon receiving a target financial transaction, store the transaction information of the target financial transaction in the distributed log through the coordinator node, and send a transaction execution request to the target participant node through the coordinator node; the target participant node is associated with the target financial transaction, and the transaction execution request includes the transaction information;

[0011] An execution module is used to persistently record the execution status of the target financial transaction in the distributed log when the target participant node responds to the transaction execution request and executes the target financial transaction based on the transaction information;

[0012] The fault handling module is used to restore the current transaction state of the coordinator node and the target participant node to the execution state recorded in the distributed log if at least one of the coordinator node and the target participant node fails during the execution of the target financial transaction by the target participant node.

[0013] To achieve the above objectives, a third aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described in the first aspect.

[0014] To achieve the above objectives, a fourth aspect of the present application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect.

[0015] To achieve the above objectives, a fifth aspect of the present application provides a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform the method described in the first aspect above.

[0016] The transaction processing method, apparatus, device, medium, and product proposed in this application pre-store the transaction information of the target financial transaction in a distributed log through a coordinator node. Throughout the entire process of the target financial transaction execution by the target participant nodes, the execution status of the target financial transaction is persistently recorded in the distributed log in real time, achieving global traceability of the target financial transaction and its execution status. When either the coordinator node or the target participant node fails, the complete execution status recorded in the distributed log can accurately restore the current transaction state to a consistent state before the failure, avoiding the transaction state loss or synchronization interruption problems caused by node failure in traditional methods, thereby improving the consistency of transaction processing. Attached Figure Description

[0017] Figure 1 This is one of the flowcharts of the transaction processing method provided in the embodiments of this application;

[0018] Figure 2 This is the second flowchart of the transaction processing method provided in the embodiments of this application;

[0019] Figure 3 This is the third flowchart of the transaction processing method provided in the embodiments of this application;

[0020] Figure 4 This is the fourth flowchart of the transaction processing method provided in the embodiments of this application;

[0021] Figure 5 This is a schematic diagram of the structure of the transaction processing device provided in the embodiments of this application;

[0022] Figure 6 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0024] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0025] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0026] First, let's analyze some of the terms used in this application:

[0027] Artificial intelligence (AI) is a new branch of computer science that studies, develops, and applies theories, methods, technologies, and systems to simulate, extend, and expand human intelligence. It aims to understand the essence of intelligence and produce intelligent machines that can react in a way similar to human intelligence. Research in this field includes robotics, speech recognition, image recognition, natural language processing, and expert systems. AI can simulate the information processes of human consciousness and thought. Furthermore, AI utilizes digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceiving the environment, acquiring knowledge, and using that knowledge to achieve optimal results.

[0028] Currently, distributed transaction processing in the context of information technology innovation faces the following problems:

[0029] Performance bottleneck: Due to the performance issues of traditional distributed transaction processing mechanisms, it is difficult to complete a large number of concurrent transactions in a domestic IT innovation environment under high concurrency conditions.

[0030] Insufficient consistency guarantees: Current technical means are difficult to achieve the requirements of strong consistency, which can easily lead to data inconsistency in distributed transactions.

[0031] Poor resource isolation: In the context of domestic IT innovation, multi-tenant databases have poor resource isolation, which can easily lead to resource contention during transaction processing.

[0032] This application provides a transaction processing method, apparatus, device, medium, and product, aiming to improve the consistency of transaction processing.

[0033] The transaction processing methods, apparatuses, devices, media, and products provided in this application are specifically described through the following embodiments. First, the transaction processing methods in the embodiments of this application are described.

[0034] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence (AI) refers to the theories, methods, technologies, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0035] Foundational technologies for artificial intelligence generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies mainly encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0036] The transaction processing method provided in this application relates to the field of data processing technology. The transaction processing method provided in this application can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, etc.; the server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application implementing the transaction processing method, but is not limited to the above forms.

[0037] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0038] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirection to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data required for the proper functioning of these embodiments acquired.

[0039] Figure 1 This is an optional flowchart of the transaction processing method provided in the embodiments of this application. Figure 1 The method described above can be applied to a distributed system, which includes a coordinator node, participant nodes, and a distributed log. The coordinator node is used to coordinate the participant nodes to execute financial transactions, and the distributed log is associated with both the coordinator node and the participant nodes. Figure 1 The method may include, but is not limited to, steps S101 to S103.

[0040] S101, Upon receiving a target financial transaction, the coordinator node stores the transaction information of the target financial transaction in the distributed log, and sends a transaction execution request to the target participant node through the coordinator node; the target participant node is associated with the target financial transaction, and the transaction execution request includes the transaction information;

[0041] S102, if the target participant node responds to the transaction execution request and executes the target financial transaction based on the transaction information, the execution status of the target financial transaction is persistently recorded in the distributed log;

[0042] S103, during the execution of the target financial transaction by the target participant node, if at least one of the coordinator node and the target participant node fails, the current transaction state of the coordinator node and the target participant node is restored to the execution state recorded in the distributed log.

[0043] As illustrated in S101 to S103 of this application embodiment, the coordinator node pre-stores the transaction information of the target financial transaction in a distributed log, and persistently records the execution status of the target financial transaction in the distributed log in real time throughout the entire process of the target participant node executing the transaction, achieving global traceability of the target financial transaction and its execution status. When the coordinator node or the target participant node fails, the complete execution status recorded in the distributed log can be used to accurately restore the current transaction state to the consistent state before the failure, avoiding the problem of transaction state loss or synchronization interruption caused by node failure in traditional methods, thereby improving the consistency of transaction processing.

[0044] In step S101 of some embodiments, a distributed system refers to an integrated system composed of multiple independent nodes (such as servers, database nodes, etc.) connected through a network, where each node works collaboratively to complete complex financial transactions. In this application, the distributed system achieves cross-node financial transaction management through the division of labor and cooperation between coordinator nodes and participant nodes, and the support of distributed logs. For example, when processing cross-bank transfer transactions, multiple bank server nodes are involved, which together constitute the distributed system.

[0045] The coordinator node is the core node in a distributed system responsible for coordinating and managing the execution of financial transactions. Its main functions include receiving financial transaction requests, sending execution instructions to relevant participating nodes, synchronizing transaction status, and handling fault recovery. In cross-institutional transfer scenarios, the coordinator node receives transfer requests, identifies the bank nodes participating in the transaction, and coordinates these nodes to complete the synchronous execution of operations such as deduction and crediting.

[0046] Participant nodes are nodes in a distributed system that specifically execute local operations within a financial transaction. They complete their assigned transaction steps according to instructions sent by the coordinator node and then report the execution results back to the coordinator node. For example, in a multi-account fund settlement transaction, the bank servers or financial institution servers hosting each account are all participant nodes, each responsible for deducting or adding funds to their respective accounts.

[0047] A distributed log is a shared log system in a distributed system used to persistently store transaction-related information. It is associated with the coordinator node and all participant nodes, recording transaction initiation information, the execution status of each node, and on-site data at the time of failure. Its purpose is to provide a reliable basis for tracing and recovering transaction states, ensuring that the complete execution process of a transaction can be reconstructed through the logs in the event of a node failure.

[0048] The target financial transaction refers to the specific financial business that the distributed system needs to process, such as inter-institutional transfers, multi-account fund clearing, and confirmation of wealth management product purchases. These transactions typically require multiple nodes to collaborate and have extremely high requirements for data consistency and atomicity, ensuring that all related operations either succeed entirely or fail entirely.

[0049] Transaction information is a data set describing the core content of a target financial transaction, including but not limited to unique transaction identifiers (such as transaction numbers), involved account information (such as the transferring account and the transferring account), transaction amount, transaction type (such as transfer and settlement), and execution timestamp. This information is the basis for participating nodes to execute specific operations and is also the foundational data for distributed log recording.

[0050] A transaction execution request is an instruction sent by the coordinator node to the target participant node, notifying the participant node to initiate a partial operation of the target financial transaction. This request contains complete transaction information. Upon receiving it, the participant node can perform the corresponding operation (such as deducting funds from a specified account) based on its content and report the execution status.

[0051] A target participant node refers to a participant node that is directly related to the target financial transaction being processed; that is, a node that needs to perform partial operations of the transaction. For example, in a transfer transaction from account A to account B, the server nodes of bank A and bank B are the target participant nodes of the transaction, responsible for the deduction and receipt of funds, respectively.

[0052] Optionally, in one feasible implementation of this application, when the distributed system receives a target financial transaction (such as an inter-institutional transfer request), the coordinator node first initiates the processing flow. The coordinator node first parses the transaction, extracts key transaction information, including the transaction's unique identifier, involved account information, transaction amount, execution requirements, etc., and encapsulates this transaction information according to a preset format and immediately stores it in the distributed log to ensure that the transaction has a traceable record from the initiation stage.

[0053] Subsequently, the coordinator node determines the target participant nodes related to the target financial transaction based on the transaction information (e.g., the nodes of the sending and receiving accounts in a transfer transaction) and generates a transaction execution request containing complete transaction information. Before sending the request, the coordinator node performs a preliminary verification of the availability of the target participant nodes to ensure that the request can be effectively received. Then, the coordinator node sends the transaction execution request to each target participant node through the system's internal communication mechanism (such as network transmission based on a preset protocol), while simultaneously recording the "execution request sent" status in the distributed log, including the sending time and the identifier of the receiving node. After receiving the request, each target participant node sends a receipt confirmation to the coordinator node, which also records this confirmation information in the distributed log, forming a complete request sending loop. This process, through the "log first, request later" order, ensures the integrity and traceability of transaction information, laying the foundation for the execution of subsequent steps and possible fault recovery.

[0054] In step S102 of some embodiments, the execution status of the target financial transaction refers to various specific status information generated by the target participant node during the transaction processing, which is used to reflect the real-time progress of the transaction, and may include the following:

[0055] Pending execution state: This refers to the state where the target participant node has received the transaction execution request sent by the coordinator node, but has not yet started to execute the specific operation. For example, in a cross-institutional transfer scenario, after the node of the receiving account receives the transfer request, it is in this state before it prepares to verify the account information and lock the amount of funds. This state will be recorded in the distributed log, indicating that the transaction has entered the node processing flow.

[0056] In-process state: This refers to the state in which the target participant node is performing a partial operation based on transaction information. Taking multi-account fund settlement as an example, when a participant node is deducting funds from a specified account (such as subtracting the transaction amount from the account balance and generating a deduction record), it will write this dynamic state to the distributed log in real time, including the completed operation steps, the current processing progress, etc., so that the coordinator node can grasp the overall progress.

[0057] Pre-commit status: This refers to the state where the target participant node has completed its own local operation, and the operation result meets the transaction requirements, but has not yet received the final commit instruction from the coordinator node. For example, in a transfer transaction, the sending account node has successfully deducted and locked the funds, and the receiving account node is ready to receive the funds. At this time, both will record the pre-commit status, indicating that the local operation is ready and waiting for global confirmation.

[0058] Partial commit state: This refers to the state in which the target participant node, after receiving the global commit instruction from the coordinator node, completes the final confirmation of its own partial transaction. For example, the receiving account node officially adds the locked funds to the account balance, generates the final transaction record, and writes this state to the distributed log, marking the completion of the node's transaction processing.

[0059] Partial rollback state: This refers to the state of a target participant node after it has executed a rollback operation due to its own operation failure or receiving a rollback instruction from the coordinator node. For example, if a node transferring funds finds insufficient funds when deducting funds, it will execute a rollback (abandon the deduction operation) and record the rollback reason, result, and other information in the distributed log to ensure the consistency of the transaction state.

[0060] These execution states are persistently recorded in real time through distributed logs, providing accurate information for global coordination of transactions and fault recovery, and ensuring that the status of each node is traceable and synchronized.

[0061] Optionally, in one feasible implementation of this application, after the target participant node receives the transaction execution request sent by the coordinator node, the target participant node first parses the transaction information in the request to clarify the specific operation it needs to perform (such as in inter-institutional transfers, the transferring node needs to perform fund deduction, and the receiving node needs to prepare for fund deposit), and then starts the local transaction processing flow.

[0062] During execution, the target participant nodes generate and record execution status in real time. These statuses encompass dynamic information across multiple stages, from "pending execution" to "in execution" and "pre-commit." For example, when deducting funds, details such as the account balance before deduction, the deduction amount, and the current operation progress are recorded. Simultaneously, participant nodes persist these execution statuses to a distributed log using a pre-defined log interface, following a unified format (including fields such as a unique transaction identifier, node identifier, status type, timestamp, and operation result). The writing process employs atomic operations to ensure integrity; that is, the status record is either completely written successfully or retried upon failure, preventing incomplete log information.

[0063] Furthermore, to ensure timeliness, the execution status is updated in real time as the transaction processing progresses. For example, once a node completes all local operations and verifies that everything is correct, it immediately writes the "pre-commit" status to the log and reports this status to the coordinator node. After receiving the status feedback from each participant node, the coordinator node also synchronizes the global status summary information to the distributed log, forming a complete state chain of multi-node collaboration. Through this real-time, complete, and reliable status recording mechanism, the distributed log accurately reflects the entire execution of the transaction across all nodes, providing a consistent benchmark for subsequent possible fault recovery.

[0064] In step S103 of some embodiments, if the coordinator node or the target participant node fails (such as a server crash or network interruption) during the execution of the target financial transaction by the target participant node, the system will trigger a fault detection mechanism to identify the faulty node through heartbeat detection or timeout failure. Once the fault is confirmed, the system first extracts the complete record of the target financial transaction from the distributed log, including transaction information, the historical execution status of each node (such as "pre-commit", "in execution", etc.), and the latest status timestamp, which serves as the recovery benchmark.

[0065] When a coordinator node fails, the system initiates a new coordinator election process. The new coordinator node obtains the global state of the current transaction by reading the distributed log, including the list of participating target participant nodes and the execution progress of each node. It then sends a state synchronization request to all target participant nodes to confirm the local state of each node at the time of the failure.

[0066] For a failed target participant node, upon restarting, it automatically connects to the distributed log system and queries the execution status of the target financial transaction it participated in using its unique transaction identifier. If the log shows the node is in an "in execution" state, any incomplete partial operations are rolled back; if it is in a "pre-commit" state, it maintains its current state and awaits instructions from the new coordinator node. During recovery, all node state updates are written to the distributed log in real time, ensuring the recovery operation itself is traceable. Ultimately, by uniformly calibrating the current transaction states of the coordinator node and the target participant nodes to the latest consistent state recorded in the distributed log, it ensures that transactions can continue to execute or be rolled back in an orderly manner after a failure, avoiding data inconsistency.

[0067] In one embodiment, such as Figure 2 As shown, the method further includes:

[0068] S201, During the execution of the target financial transaction by the target participant node, the target participant node generates a resource lock acquisition request based on the transaction information and sets a lock timeout threshold for the resource lock acquisition request; the resource lock acquisition request is used to acquire resource locks from the preset lock policies; the preset lock policies include row locks, table locks, and optimistic locks;

[0069] S202, if the target participant node fails to acquire the resource lock within the lock timeout threshold, the coordinator node controls the target participant node to stop executing the target financial transaction.

[0070] Optionally, in this embodiment, the resource lock acquisition request is a request instruction generated by the target participant node when executing a target financial transaction to prevent other transactions from operating on the same resource simultaneously. For example, when processing an account transfer, the participant node of the transferring account will generate this request to apply for exclusive access to the account resource, preventing other concurrent transactions from modifying the account balance at the same time and ensuring the accuracy of data during transaction execution.

[0071] The lock timeout threshold is the maximum waiting time set by a target participant node for a resource lock acquisition request. If a node fails to acquire the resource lock within this threshold time after initiating the request, the acquisition is considered a failure. For example, in a high-concurrency payment scenario, the threshold can be set to 500 milliseconds to prevent a transaction from being blocked due to a long wait for a resource lock, ensuring overall system processing efficiency.

[0072] Resource locks are mechanisms used to control access permissions to resources in distributed systems. By restricting the entities that can operate on specific resources (such as financial accounts or transaction records) at the same time, they prevent data conflicts caused by concurrent transactions. For example, when multiple users simultaneously transfer funds to the same account, resource locks ensure that only one transaction can modify the account balance, preventing errors in balance calculation.

[0073] A predefined lock strategy is a set of predefined resource lock management rules in a distributed system, used to select the appropriate lock type based on different business scenarios and resource characteristics. This strategy aims to balance concurrency efficiency and data consistency; for example, choosing a lock type with lower overhead in high-frequency, small-amount transfer scenarios, and choosing a lock type with higher security in large-amount settlement scenarios.

[0074] Row-level locking is a fine-grained locking strategy that locks only a single row of data in a database table. For example, when processing batch transfer transactions, the row data for each account involved is locked separately, allowing other transactions to operate on the unlocked rows in the table simultaneously, thereby improving the system's concurrency capabilities.

[0075] Table locks are a type of coarse-grained lock in the default locking strategy. They apply a lock to the entire database table, restricting any transaction from operating on any row in the table. For example, when upgrading the structure of a financial account table, table locks can prevent other transactions from reading or writing to the table, ensuring the integrity of the data structure during the upgrade process.

[0076] Optimistic locking is a non-blocking locking mechanism in predefined locking strategies. It assumes that no resource conflicts will occur during transaction execution and only verifies whether the data has been modified by checking the version number or timestamp when the transaction is committed. For example, in the scenario of purchasing financial products, when a user places an order, the version number of the current product's remaining quota is recorded. When committing, the version number is checked to see if they match. If they match, the purchase is allowed; otherwise, it is rejected. This is suitable for scenarios with a low probability of conflict to improve concurrency efficiency.

[0077] Optionally, in one specific implementation of this application, when the target participant node executes the target financial transaction (such as account transfer), the node first parses the transaction information, determines the specific resource to be operated on (such as the balance record of the transferring account), and selects the appropriate lock type from the preset locking strategy according to the resource characteristics (such as row lock when modifying single account data, table lock when updating table structure in batches, and optimistic lock in low conflict scenarios).

[0078] Subsequently, the target participant node generates a resource lock acquisition request. This request includes the target resource identifier, the required lock type, and a unique transaction identifier, and sets a lock timeout threshold based on transaction priority and system load. After the request is sent, the target participant node enters a waiting state and starts a timer to monitor the waiting time. If the resource lock is successfully acquired within the lock timeout threshold (e.g., a row lock locking the target account record), the transaction operation continues. If the lock is not acquired within the timeout period (e.g., the resource is occupied by other high-priority transactions), the target participant node immediately sends a lock acquisition failure notification to the coordinator node. Upon receiving the notification, the coordinator node sends a termination command to the target participant node. The target participant node stops the current transaction execution, releases the occupied local resources, and writes the "lock timeout termination" status to the distributed log. Simultaneously, the coordinator node decides whether to trigger a rollback or retry mechanism based on the global transaction state. This process, through explicit locking policies and timeout control, avoids deadlocks caused by prolonged resource contention while ensuring transaction execution efficiency and system stability.

[0079] In these alternative embodiments, resource contention conflicts are reduced and concurrency efficiency is improved by flexibly selecting locking strategies; lock timeout thresholds are set to avoid long-term transaction blocking and prevent deadlocks; execution is terminated when the lock is not acquired within the timeout period, ensuring reasonable allocation of system resources, reducing invalid waiting, and ensuring the efficiency and stability of financial transaction processing.

[0080] In one embodiment, the transaction information includes an organization identifier;

[0081] Upon receiving a target financial transaction, before storing the transaction information of the target financial transaction in the distributed log through the coordinator node, the method further includes:

[0082] Obtain institutional information for multiple financial institutions;

[0083] Based on the institutional information, multiple resource clusters are created, with one resource cluster corresponding to one financial institution; different resource clusters have different resource quotas, and one resource cluster is used to carry the processing load of financial transactions of one financial institution.

[0084] Sending the transaction execution request to the target participant node through the coordinator node includes:

[0085] From the plurality of resource clusters, obtain the target cluster that matches the organization identifier; the plurality of resource clusters include the target cluster;

[0086] Based on the target cluster, the transaction execution request is generated; the transaction execution request is used to instruct the target participant node to execute the target financial transaction under the resource quota of the target cluster;

[0087] Send the transaction execution request to the target participant node.

[0088] Optionally, in this embodiment, institutional information refers to the basic identifiers and attribute data of multiple financial institutions, including the financial institution's unique code, business type (such as banking, securities, and insurance), service scale, and transaction processing requirements. For example, a bank's institutional information may include its bank code, main transfer and settlement business type, and average daily transaction volume, used to distinguish different financial institutions and allocate appropriate resources to them.

[0089] A resource cluster is a dedicated collection of resources created for a single financial institution, consisting of hardware and software resources such as servers, database nodes, and network bandwidth. One financial institution corresponds to one resource cluster; for example, a dedicated server cluster and database node group might be built for a bank to handle all its financial transactions, achieving resource isolation between different institutions.

[0090] Resource quotas are the upper limits on resource usage set for each resource cluster, including metrics such as Central Processing Unit (CPU) utilization, memory allocation, input / output (I / O) throughput, and concurrent connections. Quotas for different resource clusters are set according to the business scale of the corresponding financial institution. For example, larger bank clusters are allocated higher CPU quotas and memory space to ensure that their high-concurrency transactions can be processed smoothly.

[0091] Financial transaction processing load refers to the amount of system resources consumed by a single financial institution during the execution of financial transactions. It is usually related to the number of transactions, complexity, and data volume. For example, the CPU usage and memory consumption generated by an average of 100,000 transfer transactions per day for a bank constitute the bank's transaction processing load. The resource cluster must be able to handle this load to ensure smooth business operation.

[0092] The target cluster is a resource cluster selected from multiple resource clusters that matches the identifier of the institution to which the target financial transaction belongs. For example, when a cross-institutional transfer transaction initiated by a bank is received, the cluster corresponding to that bank is found from the resource clusters based on the bank identifier in the transaction information as the target cluster, and the transaction will be executed within the resource quota of that cluster.

[0093] Optionally, in one specific implementation of this application, the system first collects institutional information from multiple financial institutions as the basis for resource allocation. Then, based on this information, an independent resource cluster is created for each financial institution. Physical or logical isolation is achieved through resource grouping; for example, a cluster with more server nodes is configured for large banks, while a relatively streamlined cluster is configured for smaller institutions. Differentiated resource quotas are set for each cluster, such as CPU utilization limits, memory allocation, and I / O channel bandwidth, to ensure that resource allocation matches the institution's processing needs.

[0094] Upon receiving a target financial transaction, the coordinator node first parses the institution identifier from the transaction information to locate the corresponding target cluster from multiple resource clusters. Next, the coordinator node generates a transaction execution request containing resource quota parameters for the target cluster, explicitly instructing the target participant nodes to execute the transaction within the cluster's resource constraints. For example, the request limits the number of CPU cores used by the transaction to no more than 70% of the quota and ensures that I / O operations do not occupy channel resources of other clusters. Finally, the coordinator node sends this request to the target participant nodes, which then process the transaction within the resource constraints of the target cluster. Through this institution-isolated resource allocation mechanism, transaction processing by different financial institutions does not interfere with each other, avoiding resource contention and ensuring the stability of transaction processing and the achievement of Service Level Agreements (SLAs).

[0095] In these alternative embodiments, by creating a dedicated resource cluster for each financial institution and setting differentiated quotas, resource isolation between institutions is achieved, avoiding resource contention; transactions are ensured to be executed within the matching target cluster, guaranteeing the stability and efficiency of transaction processing for each institution, and improving the achievement rate of service level agreements.

[0096] In one embodiment, sending a transaction execution request to the target participant node through the coordinator node includes:

[0097] Upon receiving a preset number of target financial transactions, the coordinator node compresses the preset number of target financial transactions based on a serialization protocol to obtain a batch message; the transaction execution request is the batch message.

[0098] Send the batch processing information to the target participant node;

[0099] The target participant node responds to the transaction execution request and executes the target financial transaction based on the transaction information, including:

[0100] The target participant node responds to the batch message, decompresses the batch message sequentially according to the message arrangement order, and executes each target financial transaction in the batch message;

[0101] During the execution of each target financial transaction, the commit log of each target financial transaction is cached in the local transaction buffer of the target participant node;

[0102] Specifically, when the number of commit logs accumulated in the local transaction buffer reaches a preset threshold, the accumulated commit logs in the local transaction buffer are sequentially written to the write-ahead log area of ​​the target participant node through a group commit mechanism.

[0103] Optionally, in this embodiment, a serialization protocol is a set of rules and methods for converting objects or data structures into a transmittable or storeable binary format. In financial transaction processing, it is used to encode information from multiple target financial transactions (such as institution identifiers, transaction amounts, etc.) in a unified format, facilitating efficient compression and transmission, and ensuring accurate data transfer between coordinator nodes and participant nodes.

[0104] Batch messages are single message packets formed by the coordinator node compressing a preset number of target financial transactions using a serialization protocol. For example, information from 100 transfer transactions can be merged into a single message, reducing network transmissions, improving communication efficiency, and making it suitable for batch processing of transactions in high-concurrency scenarios.

[0105] The local transaction buffer is a memory area in the target participant node used to temporarily store the commit logs of each target financial transaction. When executing transactions in a batch message, the node first temporarily stores the commit log of each transaction here to avoid frequent writes to disk, reduce I / O operation overhead, and improve transaction processing speed.

[0106] Group commit is a strategy to optimize log writing efficiency. When the number of commit logs accumulated in the local transaction buffer reaches a preset threshold (e.g., 50), these logs are written to disk in batches at once, instead of being processed one by one. This can significantly reduce disk I / O operations and improve the efficiency of log persistence.

[0107] The Write-Ahead Logging (WAL) area is the disk storage area of ​​the target participant nodes, used to persistently record the transaction commit log. Before a transaction is executed, its log is written to this area to ensure that even if a node fails, the transaction state can be recovered through the log in this area, thus guaranteeing data consistency.

[0108] Optionally, in one specific implementation of this application, when the coordinator node receives a preset number of target financial transactions (such as 200 transfer requests), it uses an efficient serialization protocol (such as Protobuf) to uniformly encode the transaction information, compresses and packages multiple transactions into a single batch message, and sends it to the target participant node as a transaction execution request, thereby reducing network overhead by reducing the number of network transmissions.

[0109] After receiving the batch processing message, the target participant node decompresses it sequentially according to the transaction order within the message and executes each financial transaction one by one (such as sequentially completing account deductions, balance updates, etc.). During execution, the commit log of each transaction (including operation details, status identifiers, etc.) is temporarily stored in the local transaction buffer (memory-level cache area) to avoid frequent disk writes. When the accumulated commit logs in the buffer reach a preset threshold (e.g., 100 logs), the group commit mechanism is triggered, writing all cached logs sequentially to the write-ahead log area in batches, leveraging sequential disk write characteristics to reduce disk I / O latency. This process compresses network communication through batch processing and optimizes disk write efficiency through group commit, adapting to the characteristics of domestic databases (such as XeSQL) and storage devices in the domestic IT innovation environment, effectively alleviating I / O bottlenecks and improving transaction processing performance in high-concurrency scenarios.

[0110] In these alternative embodiments, batch compression reduces the number of network transmissions and the amount of data, thereby reducing network overhead; local buffers and group commit mechanisms reduce disk I / O operations and improve write efficiency; adapting to the characteristics of the domestic IT innovation environment alleviates I / O bottlenecks and significantly improves the processing performance of financial transactions and the overall system efficiency in high-concurrency scenarios.

[0111] In one embodiment, the target participant node, in response to the transaction execution request, executes the target financial transaction based on the transaction information, including:

[0112] The target participant node obtains an execution policy from a preset policy library that matches the hardware architecture identifier and the operating system identifier of the target participant node. The preset policy library includes multiple correspondences, and each correspondence includes an execution policy corresponding to a hardware architecture identifier and an operating system identifier. The execution policy includes CPU scheduling parameters corresponding to the hardware architecture identifier and kernel tuning parameters corresponding to the operating system identifier.

[0113] The target financial transaction is executed according to the execution strategy described above.

[0114] Optionally, in this embodiment, the preset strategy library is a collection storing various execution strategies, containing multiple correspondences. Each correspondence is associated with a specific hardware architecture identifier, operating system identifier, and corresponding execution strategy. For example, for different chip architectures and operating systems, adapted resource scheduling and performance optimization rules are pre-stored for target participant nodes to query and call.

[0115] Hardware architecture identifiers are unique identifiers used to distinguish the underlying hardware structure of target participant nodes, such as the encoding of information like chip type, processor model, and number of cores. They help the system identify hardware characteristics and ensure the acquisition of appropriate execution strategies.

[0116] The operating system identifier is used to distinguish the operating system installed on the target participant node, including information such as operating system type, version number, and kernel version.

[0117] Central processing unit (CPU) scheduling parameters are CPU resource scheduling rules that match the hardware architecture within the execution strategy. These include process priorities, core binding policies, and scheduling algorithms. For example, setting higher process priorities for high-concurrency financial transactions, or binding specific CPU cores, can reduce switching overhead and improve processing efficiency.

[0118] Kernel tuning parameters are kernel-level configuration items in the execution strategy that match the operating system, including memory management (such as page cache size), I / O scheduling, network protocol stack parameters, etc.

[0119] Optionally, in one specific implementation of this application, after receiving a transaction execution request, the target participant node first reads its own hardware architecture identifier and operating system identifier, and then accesses a preset strategy library. The target participant node obtains the corresponding execution strategy from the library by matching its own identifier, which includes CPU scheduling parameters matching the hardware architecture and kernel tuning parameters matching the operating system. Subsequently, the target participant node adjusts its CPU resource allocation method according to the execution strategy (e.g., binding transaction threads to specific cores to reduce switching overhead) and applies kernel parameter optimization (e.g., increasing the file handle limit to support more concurrent connections), finally executing the target financial transaction in the optimized environment. Through this dynamic adaptation of hardware and system characteristics, transaction processing is ensured to fully utilize hardware performance in heterogeneous environments, while adapting to the underlying mechanisms of different operating systems, improving execution efficiency and stability.

[0120] In these alternative embodiments, a preset strategy library is used to achieve precise adaptation between hardware and system, optimize CPU scheduling for different hardware architectures, and adjust kernel parameters to adapt to the operating system, so that financial transactions can run efficiently in heterogeneous environments, reduce resource waste, improve execution efficiency and stability, and enhance system compatibility and adaptability.

[0121] In one embodiment, such as Figure 3 As shown, the method further includes:

[0122] S301, Obtain the time-series feature vector during the execution of the target financial transaction. The time-series feature vector includes at least one of the following: transaction duration, CPU utilization, and abnormal signal.

[0123] S302, Input the time-series feature vector into the fault prediction model to obtain the fault prediction result;

[0124] S303, if the fault prediction result indicates that the target financial transaction has a risk of failure, trigger a preset solution strategy that matches the fault prediction result.

[0125] Optionally, in this embodiment, the time-series feature vector is a combination of multi-dimensional feature data collected in chronological order during the execution of the target financial transaction. It resembles a dynamic "health report," containing indicators such as transaction duration, CPU utilization, and abnormal signals that change over time. This data characterizes the transaction's operational status at different stages, providing a data foundation for fault prediction.

[0126] Transaction time is the total time consumed from the start of a target financial transaction to its current stage, including the cumulative time of each sub-step (such as data verification, resource locking, and log writing). For example, a sudden increase in the time taken for a transfer transaction from initiation to completion of account deduction may indicate a decrease in system processing efficiency or a potential malfunction.

[0127] CPU utilization is the percentage of CPU resources used by a transaction and its associated processes during execution. It reflects the hardware load. For example, if the CPU utilization consistently exceeds 90% during the execution of a financial transaction, it may cause subsequent steps to be blocked due to resource overload, becoming a potential malfunction.

[0128] Anomaly signals are unexpected status indicators that occur during transaction execution, including error codes (such as resource lock acquisition failure), timeout alerts (such as network response delays), and data verification failures. These signals are early warnings of failures; for example, a series of "log write failure" signals may indicate that disk I / O is about to malfunction.

[0129] Failure prediction models are algorithmic models trained on historical data (such as Long Short-Term Memory (LSTM) networks and random forests in machine learning). They can analyze the operational trend of transactions and predict the risk of failure by using the input time-series feature vectors. Like an "intelligent diagnostic tool," it combines historical failure cases with real-time data to determine whether the current transaction is likely to fail and the probability of failure.

[0130] Failure prediction results are the judgment conclusions output by the failure prediction model, which typically include categories such as "no risk," "low risk," and "high risk," or specific failure probability values. For example, if the model determines a transaction to be "high risk (probability 85%)," it means that the transaction has a very high probability of failing.

[0131] Pre-defined solutions are pre-defined responses to different failure prediction results. If the prediction result is "high risk", the strategy may include immediately triggering transaction retries, switching to a backup resource cluster, and automatically releasing some non-critical resources, aiming to avoid failures in advance and reduce losses caused by transaction failures.

[0132] Optionally, in one specific implementation of this application, during the execution of the target financial transaction, the system initiates a full-link monitoring mechanism to collect time-series feature vectors at time intervals (e.g., every 100 milliseconds), including the time consumption of each stage of the transaction, the real-time CPU utilization rate, and abnormal signals.

[0133] Subsequently, these dynamically updated time-series feature vectors are input into the fault prediction model in real time. The fault prediction model analyzes the changing trends of the feature vectors (such as sudden increases in latency, continuous increases in CPU utilization, and increased frequency of abnormal signals) and outputs fault prediction results (such as "no risk," "low risk requiring attention," and "high risk of failure"). If the result indicates a risk of failure, the system immediately triggers a matching preset solution strategy: in the case of low risk, resource priority is increased (such as allocating more CPU cores to the transaction); in the case of high risk, transaction routing is switched (transferring the transaction to a standby node) or automatic retry with a backoff algorithm is performed, while a warning log is recorded to the distributed system. Through the linkage of real-time monitoring, intelligent prediction, and proactive intervention, potential faults are avoided in advance, fault recovery time is shortened, and the reliability of financial transaction processing is improved.

[0134] In these alternative embodiments, by collecting transaction operation indicators in real time and using fault prediction models to identify failure risks in advance and trigger corresponding solutions in advance, faults can be proactively avoided, transaction failure rates can be reduced, fault recovery time can be shortened, system reliability, availability and resilience can be improved, and the stable execution of financial transactions can be guaranteed.

[0135] It should be noted that the various optional implementation methods described in the embodiments of this application can be combined with each other or implemented individually without conflict, and the embodiments of this application do not limit this.

[0136] To facilitate understanding of the transaction processing method provided in the above embodiments, the following describes the transaction processing method using a specific scenario embodiment.

[0137] Optionally, such as Figure 4 As shown, a transaction processing method may include the following steps:

[0138] 1. Log-based transaction management: ensuring strong consistency

[0139] The core of this approach lies in employing an enhanced Two-Phase Commit (2PC) protocol and deeply integrating it with a distributed logging system (such as a log service based on Raft or Paxos). Traditional 2PC is susceptible to single-point failures of the coordinator, leading to transaction blocking. This application achieves this by persistently recording transaction states in a distributed log: in the event of a coordinator failure, a new coordinator can quickly recover the state from the log and continue processing; and after a participant fails and restarts, the state can be recovered or rolled back based on the log. This fundamentally solves the "blocking" problem, guaranteeing atomicity (A) and durability (D) of the ACID properties (Atomicity, Consistency, Isolation, Durability), providing strong consistency guarantees for cross-node transactions.

[0140] 2. Resource Isolation Optimization: Overcoming Competition Bottlenecks

[0141] To address the sharp performance drop caused by intense resource contention under high concurrency, this application implements a dual strategy:

[0142] Fine-grained resource lock management: Introduce multi-granularity locks (row locks, table locks) and lock timeout mechanisms, combined with optimistic locking (such as Multi-Version Concurrency Control (MVCC)) to reduce blocking and balance concurrency and consistency.

[0143] Multi-tenant resource isolation: On shared infrastructure, technologies such as resource groups, quota limits, and priority scheduling are used to isolate transaction processing resources (CPU, memory, I / O channels) of different services or tenants, avoiding mutual interference and ensuring the SLA of critical transactions. This significantly reduces latency and failure rate caused by resource contention.

[0144] 3. Performance Optimization: Deepening the Performance of the Information Technology Innovation Environment

[0145] The solution is specifically optimized for the information technology innovation environment:

[0146] Network overhead compression: Employ efficient serialization protocols (such as Protobuf), batch commit, transaction pipelines, and other technologies to reduce the number of communication sessions and the amount of data between nodes.

[0147] Disk I / O latency reduction: Optimize log write strategies (such as Group Commit) and utilize WAL technology for sequential disk writing; adapt I / O scheduling algorithms to the characteristics of Solid State Drives (SSDs); and configure caching strategies (Buffer Pool) appropriately to improve access speed for hot data. These measures effectively alleviate potential I / O bottlenecks in the domestic IT innovation environment.

[0148] 4. Heterogeneous environment adaptation: Improve compatibility and performance

[0149] This application demonstrates high adaptability to the diverse hardware platforms and operating systems within the domestic IT innovation ecosystem:

[0150] Hardware-aware optimization: Identifies the characteristics of different CPU architectures and automatically adjusts transaction processing thread scheduling strategies, memory barrier usage, cache affinity settings, etc., to maximize the utilization of hardware performance.

[0151] Operating System Adaptation Layer: Abstracts underlying OS differences (system calls, file system characteristics, network stack) and provides a unified interface. It optimizes kernel parameters for specific OSes (such as socket buffer size and file handle limits) to ensure the transaction processing engine runs efficiently and stably on all platforms.

[0152] 5. Intelligent fault-tolerance mechanism: ensuring system resilience

[0153] This application constructs an active fault-tolerance system:

[0154] Real-time transaction monitoring: Track transaction status across the entire chain and collect key indicators (time consumption, resource usage, and abnormal signals) in real time.

[0155] Fault Prediction and Rapid Recovery: Based on historical data and real-time metrics, machine learning models (such as time-series prediction and anomaly detection) are used to predict potential failure points. Once a problem is detected or a failure risk is predicted, preset strategies are immediately triggered: automatic retry (with backoff algorithm), transaction routing switch (to a healthy node), partial rollback, or compensation operations. This mechanism significantly shortens the Recovery Time Objective (RTO) and improves system reliability and availability.

[0156] Please see Figure 5This application also provides a transaction processing apparatus that can implement the above-described transaction processing method. The apparatus is applied to a distributed system, which includes a coordinator node, participant nodes, and a distributed log. The coordinator node coordinates the participant nodes to execute financial transactions, and the distributed log is associated with both the coordinator node and the participant nodes. The apparatus includes:

[0157] A storage module is used to, upon receiving a target financial transaction, store the transaction information of the target financial transaction in the distributed log through the coordinator node, and send a transaction execution request to the target participant node through the coordinator node; the target participant node is associated with the target financial transaction, and the transaction execution request includes the transaction information;

[0158] An execution module is used to persistently record the execution status of the target financial transaction in the distributed log when the target participant node responds to the transaction execution request and executes the target financial transaction based on the transaction information;

[0159] The fault handling module is used to restore the current transaction state of the coordinator node and the target participant node to the execution state recorded in the distributed log if at least one of the coordinator node and the target participant node fails during the execution of the target financial transaction by the target participant node.

[0160] The specific implementation of this transaction processing device is basically the same as the specific implementation of the transaction processing method described above, and will not be repeated here.

[0161] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described transaction processing method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0162] Please see Figure 6 , Figure 6 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes:

[0163] The processor 601 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0164] The memory 602 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 602 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 602 and is called and executed by the processor 601 using the transaction processing method of the embodiments of this application.

[0165] The input / output interface 603 is used to implement information input and output;

[0166] The communication interface 604 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0167] Bus 605 transmits information between various components of the device (e.g., processor 601, memory 602, input / output interface 603, and communication interface 604);

[0168] The processor 601, memory 602, input / output interface 603, and communication interface 604 are connected to each other within the device via bus 605.

[0169] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described transaction processing method.

[0170] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0171] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0172] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0173] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0174] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0175] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0176] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0177] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0178] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0179] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0180] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0181] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A transaction processing method, characterized in that, The method is applied to a distributed system, which includes a coordinator node, participant nodes, and a distributed log. The coordinator node coordinates the participant nodes to execute financial transactions, and the distributed log is associated with both the coordinator node and the participant nodes. Upon receiving a target financial transaction, the coordinator node stores the transaction information of the target financial transaction in the distributed log, and sends a transaction execution request to the target participant node through the coordinator node; the target participant node is associated with the target financial transaction, and the transaction execution request includes the transaction information; When the target participant node responds to the transaction execution request and executes the target financial transaction based on the transaction information, the execution status of the target financial transaction is persistently recorded in the distributed log. If at least one of the coordinator node and the target participant node fails during the execution of the target financial transaction by the target participant node, the current transaction state of the coordinator node and the target participant node will be restored to the execution state recorded in the distributed log.

2. The method according to claim 1, characterized in that, The method further includes: During the execution of the target financial transaction by the target participant node, the target participant node generates a resource lock acquisition request based on the transaction information and sets a lock timeout threshold for the resource lock acquisition request; the resource lock acquisition request is used to acquire a resource lock from a preset locking strategy; the preset locking strategy includes row locks, table locks, and optimistic locks; If the target participant node fails to acquire the resource lock within the lock timeout threshold, the coordinator node controls the target participant node to stop executing the target financial transaction.

3. The method according to claim 1, characterized in that, The transaction information includes the organization identifier; Upon receiving a target financial transaction, before storing the transaction information of the target financial transaction in the distributed log through the coordinator node, the method further includes: Obtain institutional information for multiple financial institutions; Based on the institutional information, multiple resource clusters are created, with one resource cluster corresponding to one financial institution; different resource clusters have different resource quotas, and one resource cluster is used to carry the processing load of financial transactions of one financial institution. Sending the transaction execution request to the target participant node through the coordinator node includes: From the plurality of resource clusters, obtain the target cluster that matches the organization identifier; the plurality of resource clusters include the target cluster; Based on the target cluster, the transaction execution request is generated; the transaction execution request is used to instruct the target participant node to execute the target financial transaction under the resource quota of the target cluster; Send the transaction execution request to the target participant node.

4. The method according to claim 1, characterized in that, Sending the transaction execution request to the target participant node through the coordinator node includes: Upon receiving a preset number of target financial transactions, the coordinator node compresses the preset number of target financial transactions based on a serialization protocol to obtain a batch message; the transaction execution request is the batch message. Send the batch processing information to the target participant node; The target participant node responds to the transaction execution request and executes the target financial transaction based on the transaction information, including: The target participant node responds to the batch message, decompresses the batch message sequentially according to the message arrangement order, and executes each target financial transaction in the batch message; During the execution of each target financial transaction, the commit log of each target financial transaction is cached in the local transaction buffer of the target participant node; Specifically, when the number of commit logs accumulated in the local transaction buffer reaches a preset threshold, the accumulated commit logs in the local transaction buffer are sequentially written to the write-ahead log area of ​​the target participant node through a group commit mechanism.

5. The method according to claim 1, characterized in that, The target participant node responds to the transaction execution request and executes the target financial transaction based on the transaction information, including: The target participant node obtains an execution policy from a preset policy library that matches the hardware architecture identifier and the operating system identifier of the target participant node. The preset policy library includes multiple correspondences, and each correspondence includes an execution policy corresponding to a hardware architecture identifier and an operating system identifier. The execution policy includes CPU scheduling parameters corresponding to the hardware architecture identifier and kernel tuning parameters corresponding to the operating system identifier. The target financial transaction is executed according to the execution strategy described above.

6. The method according to claim 1, characterized in that, The method further includes: Obtain the time-series feature vector during the execution of the target financial transaction, wherein the time-series feature vector includes at least one of the following: transaction duration, CPU utilization, and abnormal signal. The time-series feature vector is input into the fault prediction model to obtain the fault prediction result; If the failure prediction result indicates that the target financial transaction has a risk of failure, a preset solution strategy that matches the failure prediction result is triggered.

7. A transaction processing apparatus, characterized in that, This invention is applied to a distributed system, which includes a coordinator node, participant nodes, and a distributed log. The coordinator node is used to coordinate the participant nodes to execute financial transactions, and the distributed log is associated with both the coordinator node and the participant nodes. The device includes: A storage module is used to, upon receiving a target financial transaction, store the transaction information of the target financial transaction in the distributed log through the coordinator node, and send a transaction execution request to the target participant node through the coordinator node; the target participant node is associated with the target financial transaction, and the transaction execution request includes the transaction information; An execution module is used to persistently record the execution status of the target financial transaction in the distributed log when the target participant node responds to the transaction execution request and executes the target financial transaction based on the transaction information; The fault handling module is used to restore the current transaction state of the coordinator node and the target participant node to the execution state recorded in the distributed log if at least one of the coordinator node and the target participant node fails during the execution of the target financial transaction by the target participant node.

8. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the transaction processing method according to any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the transaction processing method according to any one of claims 1 to 6.

10. A computer program product, characterized in that, When the instructions in the computer program product are executed by an electronic device, the electronic device causes the electronic device to perform the transaction processing method as described in any one of claims 1-6.

Images