WO2021109719A1 - 事务处理方法、装置、设备及计算机存储介质 - Google Patents

事务处理方法、装置、设备及计算机存储介质 Download PDF

Info

Publication number
WO2021109719A1
WO2021109719A1 PCT/CN2020/121033 CN2020121033W WO2021109719A1 WO 2021109719 A1 WO2021109719 A1 WO 2021109719A1 CN 2020121033 W CN2020121033 W CN 2020121033W WO 2021109719 A1 WO2021109719 A1 WO 2021109719A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
sub
processing
transactions
parts
Prior art date
Application number
PCT/CN2020/121033
Other languages
English (en)
French (fr)
Inventor
杨佳
费强
陈宁国
刘德志
Original Assignee
腾讯科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 腾讯科技（深圳）有限公司 filed Critical 腾讯科技（深圳）有限公司
Priority to JP2021509740A priority Critical patent/JP7142152B2/ja
Priority to EP20851368.9A priority patent/EP4071610A4/en
Priority to SG11202102157UA priority patent/SG11202102157UA/en
Priority to KR1020217002929A priority patent/KR102510195B1/ko
Priority to US17/170,207 priority patent/US11544245B2/en
Publication of WO2021109719A1 publication Critical patent/WO2021109719A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/466—Transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793—Remedial or corrective actions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1474—Saving, restoring, recovering or retrying in transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy

Definitions

  • This application relates to the field of databases, in particular to transaction processing methods, devices, equipment, and computer storage media.
  • the embodiments of the present application provide a transaction processing method, device, equipment, and computer storage medium, which can automatically process abnormal sub-transactions using matching processing strategies, thereby improving fault tolerance and transaction processing capabilities.
  • an embodiment of the present application provides a transaction processing method.
  • the method is applied to a transaction processing device and includes: dividing a pending transaction obtained from a database into at least two sub-transactions; The functions implemented by the network interface and the sub-transactions divide each sub-transaction into N parts with an association relationship, where N is an integer greater than 1, and the N of each sub-transaction is determined according to the association relationship.
  • N is an integer greater than 1
  • the processing strategy is used to process the abnormal sub-transaction to obtain the final processing result of the pending transaction.
  • an embodiment of the present application provides a transaction processing device, including: a first division module configured to divide a transaction to be processed obtained from a database into at least two sub-transactions; and a second division module configured to divide each transaction into at least two sub-transactions; Each of the sub-transactions belongs to the network interface and the functions implemented by the sub-transactions.
  • Each sub-transaction is divided into N parts with an association relationship, where N is an integer greater than 1; the first processing module is configured to follow the The association relationship processes the N parts of each of the sub-transactions to obtain the processing result of the last executed part of the N parts; the first determining module is configured to determine if an abnormal sub-transaction is determined according to the processing result Transaction, determining a processing strategy that matches the abnormal cause of the abnormal sub-transaction; a second processing module configured to use the processing strategy to process the abnormal sub-transaction to obtain the final processing result of the pending transaction .
  • an embodiment of the present application provides a transaction processing device, including: a memory configured to store executable instructions; a processor configured to implement the foregoing transaction processing method when executing the executable instructions stored in the memory.
  • an embodiment of the present application provides a storage medium (non-transitory storage medium) that stores executable instructions and is configured to cause execution by a processor to implement the transaction processing method provided in the embodiment of the present application.
  • the embodiments of the present application have the following beneficial effects: For the transaction to be processed, the sub-transaction is divided into multiple parts through the network interface based on the sub-transaction, and each part is processed to solve the problem that the performance of the overall service is limited by the processing capacity of the stand-alone database. For abnormal sub-transactions with abnormal processing results, a matching processing strategy is selected based on the abnormal cause to process the abnormal sub-transactions to obtain the final processing results; in this way, the abnormal sub-transactions are automatically processed with matching processing strategies to improve Improved fault tolerance and the ability to handle transactions.
  • FIG. 1 is a schematic diagram of an optional architecture of a transaction processing system provided by an embodiment of the present application
  • FIG. 2A is a schematic diagram of another optional architecture of the transaction processing system provided by an embodiment of the present application.
  • 2B is a schematic structural diagram of a transaction processing system provided by an embodiment of the present application.
  • FIG. 3 is a schematic diagram of an implementation flow of a transaction processing method provided by an embodiment of the present application.
  • FIG. 4 is a schematic diagram of another implementation flow of the transaction processing method provided by an embodiment of the present application.
  • FIG. 5 is a framework diagram of a transaction processing system provided by an embodiment of the present application.
  • Figure 6 is another framework diagram of long transaction processing provided by an embodiment of the present application.
  • FIG. 7 is a schematic diagram of an implementation process of a transaction processing method provided by an embodiment of the present application.
  • FIG. 8 is an execution path diagram of a long transaction flow state provided by an embodiment of the present application.
  • FIG. 9 is a schematic diagram of another implementation flow of a transaction processing method provided by an embodiment of the present application.
  • FIG. 10 is a schematic diagram of the implementation process of storing the transaction status of the message middleware according to an embodiment of the present application.
  • FIG. 11 is a schematic diagram of an implementation process of implementing a transfer request according to an embodiment of the present application.
  • FIG. 12 is a schematic diagram of the implementation process of a transaction processing method provided by an embodiment of the present application.
  • first ⁇ second ⁇ third involved only distinguishes similar objects, and does not represent a specific order for the objects. Understandably, “first ⁇ second ⁇ third” Where permitted, the specific order or sequence can be interchanged, so that the embodiments of the present application described in some embodiments can be implemented in a sequence other than those illustrated or described in some embodiments.
  • ACID characteristics Transaction has four characteristics, namely Atomicity, Consistency, Isolation and Durability, referred to as the ACID characteristics of the transaction.
  • Long transaction a transaction takes a long time and cannot be completed, it is a long transaction, referred to as a long transaction (Long Transaction).
  • Long Transaction In the database, a transaction that runs for more than 6 seconds is considered a long transaction.
  • Informix calls transactions that occupy more than a certain percentage of the entire logical log space (the percentage of transactions occupying the entire logical log space exceeds the value defined by the "long transaction depth waterline ratio" parameter) as "long transactions".
  • Publish-subscribe mechanism (Publish-Subscribe, PubSub):
  • the introduction of the message delivery mode is a classic message delivery mode with a long history; the subscription release mode defines a one-to-many dependency relationship, allowing multiple subscriber objects to be at the same time Monitor a certain subject object.
  • This topic object will notify all subscriber objects when its state changes, so that they can automatically update their state.
  • Dividing a system into a series of cooperating classes has a very bad side effect, that is, the consistency between the corresponding objects needs to be maintained, which will bring inconvenience to maintenance, expansion, and reuse.
  • Cluster server A collective term for one or more servers in a cluster. Broker does not have a copy mechanism. Once the broker goes down, the broker’s messages will be unavailable. The Broker does not save the status of the subscribers, it is saved by the subscribers themselves.
  • BookKeeper is a service framework that provides log entry stream storage and persistence. Especially suitable for log stream storage, a more classic application is as a persistent framework for message queues.
  • Transaction logging can help improve the efficiency of transactions. Using the transaction log, the storage engine only needs to modify its memory copy when modifying the target data, and then record the modification behavior in the transaction log persisted on the hard disk, instead of persisting the modified data itself to the disk every time.
  • the transaction log uses an append method, so the operation of writing the log is sequential I/O in a small area on the disk, unlike random I/O that requires moving the head in multiple places on the disk, so the transaction log is used. The way is relatively faster. After the transaction log is durable, the modified data in the memory can be slowly flushed back to the disk in the background.
  • Blockchain An encrypted, chain-type transaction storage structure formed by blocks.
  • Blockchain Network A series of nodes that incorporate new blocks into the blockchain through consensus.
  • Cloud technology is a general term for network technology, information technology, integration technology, management platform technology, application technology, etc., based on the application of cloud computing business models, which can form a resource pool, which can be used as needed, which is flexible and convenient. Cloud computing technology will become an important support.
  • the background service of the technical network system requires a large amount of computing and storage resources, such as video websites, image websites and more portal websites.
  • each item may have its own identification mark, which needs to be transmitted to the back-end system for logical processing. Data of different levels will be processed separately, and all types of industry data need to be powerful The backing of the system can only be achieved through cloud computing.
  • Database in short, can be regarded as an electronic file cabinet-a place where electronic files are stored, and users can perform operations such as adding, querying, updating, and deleting data in the file.
  • the so-called “database” is a collection of data that is stored together in a certain way, can be shared with multiple users, has as little redundancy as possible, and is independent of the application.
  • Database Management System is a computer software system designed for database management. It generally has basic functions such as storage, interception, security, and backup.
  • the database management system can be classified according to the database model it supports, such as relational, XML (Extensible Markup Language); or according to the type of computer supported, such as server clusters, mobile phones; Or classify based on the query language used, such as SQL (Structured Query Language), XQuery; or classify based on performance impulse focus, such as maximum scale, maximum operating speed; or other classification methods. No matter what you use Which classification method, some DBMS can cross categories, for example, support multiple query languages at the same time.
  • the embodiments of the present application provide a transaction processing method, device, equipment, and computer storage medium (non-transitory storage medium).
  • the acquired pending transactions are divided into Is at least two sub-transactions; then, according to the network interface of each sub-transaction, each sub-transaction is divided into multiple parts with an association relationship; and, according to the association relationship, the transaction of each sub-transaction Multiple parts are processed to obtain the processing result of the last executed part of the multiple parts; finally, if an abnormal sub-transaction is determined according to the processing result, it is determined that the abnormal cause matches the abnormal sub-transaction Processing strategy; using the processing strategy to process the abnormal sub-transaction to obtain the final processing result of the pending transaction; in this way, for the pending transaction, the sub-transaction is divided into multiple sub-transactions based on the network interface of the sub-transaction In order to solve the problem that the performance of the overall service is limited by the processing capacity of the single-machine database; then
  • the equipment provided in the embodiments of the application can be implemented as a notebook computer, a tablet computer, a desktop computer, a set-top box, and a mobile device (for example, a mobile phone, a portable music player).
  • a mobile device for example, a mobile phone, a portable music player.
  • personal digital assistants, dedicated messaging devices, portable game devices can also be implemented as servers.
  • the server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers.
  • the terminal can also provide cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, and intermediate Cloud servers for basic cloud computing services such as software services, domain name services, security services, CDN, and big data and artificial intelligence platforms.
  • the terminal can be a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, etc., but it is not limited to this.
  • the terminal and the server can be directly or indirectly connected through wired or wireless communication, which is not limited in this application.
  • FIG. 1 is a schematic diagram of an optional architecture of a transaction processing system provided by an embodiment of the present application.
  • the transaction is processed Request the specified pending transaction 11 to be divided into multiple sub-transactions 12; then, according to the network interface of each sub-transaction, the sub-transaction is divided again to obtain multiple parts 13 related to each other; The association relationship between the parts 13 processes these parts in turn, and obtains the processing result 101 of the last executed part of the parts 13; if the processing result 101 is abnormal, determine the matching result based on the reason for the abnormality Processing strategy 102; Finally, the processing strategy is used to process the abnormal sub-transaction 103 to obtain the final processing result 104 of the pending transaction 11; in this way, the sub-transaction is divided into multiple parts based on the network interface of the sub-transaction , To deal with each part, to solve the problem that the performance of the overall service is limited by the processing capacity of the stand
  • FIG. 2A is a schematic diagram of another optional architecture of the transaction processing system provided by an embodiment of the present application, including a blockchain network 20 (exemplarily showing a server 200 as a native node) and a monitoring system 30 (example The characteristic shows the equipment 300 belonging to the monitoring system 30 and its graphical interface 301), which will be described separately below.
  • a blockchain network 20 exemplarily showing a server 200 as a native node
  • a monitoring system 30 example The characteristic shows the equipment 300 belonging to the monitoring system 30 and its graphical interface 301, which will be described separately below.
  • the type of the blockchain network 20 is flexible and diverse, for example, it can be any one of a public chain, a private chain, or a consortium chain.
  • the electronic equipment of any business entity such as user equipment and servers, can access the blockchain network 20 without authorization; taking the alliance chain as an example, the business entity has its jurisdiction after being authorized
  • the electronic device (for example, device/server) can access the blockchain network 20. At this time, it becomes a special type of node in the blockchain network 20, that is, the client node.
  • the client node can only provide the function of supporting business entities to initiate transactions (for example, for storing data on the chain or querying data on the chain).
  • the client node can be implemented by default or selectively (for example, depending on the specific business requirements of the business entity). Therefore, the data and business processing logic of the business entity can be migrated to the blockchain network 20 to the greatest extent, and the credibility and traceability of the data and business processing process can be realized through the blockchain network 20.
  • the blockchain network 20 receives the transaction submitted by the client node (for example, the device 300 belonging to the monitoring system 30 shown in FIG. 2A) of the business entity (for example, the monitoring system 30 shown in FIG. 2A), and executes the transaction to Update the ledger or query the ledger, and display various intermediate or final results of the execution of the transaction on the user interface of the device (for example, the graphical interface 301 of the device 300).
  • the client node for example, the device 300 belonging to the monitoring system 30 shown in FIG. 2A
  • the business entity for example, the monitoring system 30 shown in FIG. 2A
  • the equipment 300 of the monitoring system 30 is connected to the blockchain network 20 and becomes a client node of the blockchain network 20.
  • the device 300 obtains the transaction to be processed through the sensor, and divides the transaction to be processed into at least two sub-transactions; then, according to the network interface to which each sub-transaction belongs, divides the sub-transactions into multiple parts with an association relationship; and, according to The association relationship processes multiple parts of the sub-transaction to obtain the processing result of the last executed part; finally, if the processing result shows that there is an abnormal sub-transaction, determine the processing strategy that matches the cause of the abnormality; adopt this processing strategy to the abnormal sub-transaction
  • the transaction is processed to obtain the final processing result of the transaction to be processed; and the final processing result is transferred to the server 200 in the blockchain network 20 or stored in the device 300; the upload logic is deployed to the device 300 or the user performs operations
  • the device 300 generates a transaction corresponding to the update operation/query operation according to the pending transaction/synchronization time query request, and
  • the native node in the blockchain network 20 for example, when the server 200 receives the transaction, it verifies the digital signature carried by the transaction. After the digital signature verification succeeds, it confirms whether the monitoring system 30 is carried in the transaction according to the identity of the monitoring system 30 It has transaction authority, and any one of the digital signature and authority verification will cause the transaction to fail. After the verification is successful, the native node's own digital signature is signed (for example, the digest of the transaction is encrypted using the private key of the native node), and the broadcast continues in the blockchain network 20.
  • the native node's own digital signature is signed (for example, the digest of the transaction is encrypted using the private key of the native node), and the broadcast continues in the blockchain network 20.
  • the node with the sorting function in the blockchain network 20 After the node with the sorting function in the blockchain network 20 receives the successfully verified transaction, it fills the transaction into a new block and broadcasts it to the node in the blockchain network 20 that provides consensus services.
  • the nodes that provide consensus services in the blockchain network 20 conduct a consensus process on the new block to reach agreement.
  • the node that provides the ledger function appends the new block to the end of the blockchain and executes the transaction in the new block: For submission to be processed For transactions with transaction processing results, update the key-value pairs corresponding to the transaction to be processed in the state database; for transactions querying the synchronization time, query the key-value pairs corresponding to the synchronization time from the state database, and return the query result.
  • the obtained synchronization time can be displayed in the graphical interface 301 of the device 300.
  • the native node in the blockchain network 20 can read the pending transaction from the blockchain and present the pending transaction on the monitoring page of the native node.
  • the native node can also use the pending transaction stored in the blockchain to
  • the pending transaction is processed, for example, the sub-transaction is divided into multiple parts through the network interface based on the sub-transaction belonging, which solves the problem that the performance of the overall service is limited by the processing capacity of the stand-alone database; for abnormal sub-transactions with abnormal processing results
  • a matching processing strategy is selected based on the cause of the abnormality to process the abnormal sub-transaction to obtain the final processing result; in this way, the abnormal sub-transaction is automatically processed with a matching processing strategy, which improves the fault tolerance and the ability to handle the transaction.
  • the server 200 can be set to have transaction processing functions and accounting functions.
  • sub-transactions can be divided into multiple sub-transactions through a network interface based on sub-transactions. Each part is processed for each part, and the abnormal sub-transaction with abnormal processing result is determined; then, the abnormal sub-transaction is selected based on the abnormal reason and the matching processing strategy is selected to process the abnormal sub-transaction to obtain the final processing result.
  • the server 200 receives the transaction processing request sent by the device 300, and the server 200 is used to divide the transaction to be processed based on the transaction processing request to obtain multiple sub-transactions; then, based on the network interface of the sub-transaction The sub-transaction is divided into multiple parts; finally, each part is processed.
  • the abnormal sub-transaction is selected based on the abnormal reason and the matching processing strategy is selected to process the abnormal sub-transaction to obtain the final processing result; in this way, both It solves the problem that the performance of the overall service is limited by the processing capacity of the stand-alone database, and automatically adopts matching processing strategies for abnormal sub-transactions to improve fault tolerance and transaction processing capabilities.
  • FIG. 2B is a schematic structural diagram of a transaction processing system provided by an embodiment of the present application.
  • the device 400 shown in FIG. 2B includes: at least one processor 410, a memory 450, at least one network interface 420, and a user interface 430.
  • the various components in the device 400 are coupled together through the bus system 440.
  • the bus system 440 is used to implement connection and communication between these components.
  • the bus system 440 also includes a power bus, a control bus, and a status signal bus.
  • various buses are marked as the bus system 440 in FIG. 2B.
  • the processor 410 may be an integrated circuit chip with signal processing capabilities, such as general-purpose processors, digital signal processors, or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc., among which, general-purpose processing
  • the processor can be a microprocessor or any conventional processor or the like.
  • the user interface 430 includes one or more output devices 431 that enable the presentation of media content, including one or more speakers and/or one or more visual display screens.
  • the user interface 430 also includes one or more input devices 432, including user interface components that facilitate user input, in some examples keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.
  • the memory 450 may be removable, non-removable, or a combination thereof.
  • Exemplary hardware devices include solid-state memory, hard disk drives, optical disk drives, and so on.
  • the memory 450 optionally includes one or more storage devices that are physically remote from the processor 410.
  • the memory 450 includes volatile memory or non-volatile memory, and may also include both volatile and non-volatile memory.
  • the non-volatile memory may be a read only memory (Read Only Memory, ROM), and the volatile memory may be a random access memory (Random Access Memory, RAM).
  • ROM Read Only Memory
  • RAM Random Access Memory
  • the memory 450 described in the embodiment of the present application is intended to include any suitable type of memory.
  • the memory 450 can store data to support various operations. Examples of these data include programs, modules, and data structures, or a subset or superset thereof, where the "module” can use hardware (such as processing circuits and/ Or memory), software (for example, software developed using a programming language), or a combination thereof.
  • hardware such as processing circuits and/ Or memory
  • software for example, software developed using a programming language
  • Operating system 451 including system programs configured to process various basic system services and perform hardware-related tasks, such as framework layer, core library layer, driver layer, etc., configured to implement various basic services and process hardware-based tasks;
  • the network communication module 452 is configured to reach other computing devices via one or more (wired or wireless) network interfaces 420.
  • Exemplary network interfaces 420 include: Bluetooth, wireless compatibility authentication, and Universal Serial Bus (Universal Serial Bus). , USB) etc.;
  • the presentation module 453 is configured to enable the presentation of information via one or more output devices 431 (for example, a display screen, a speaker, etc.) associated with the user interface 430 (for example, a user interface for operating peripheral devices and displaying content and information) );
  • output devices 431 for example, a display screen, a speaker, etc.
  • the user interface 430 for example, a user interface for operating peripheral devices and displaying content and information
  • the input processing module 454 is configured to detect one or more user inputs or interactions from one of the one or more input devices 432 and translate the detected inputs or interactions.
  • FIG. 2B shows a transaction processing server 455 stored in a memory 450, which can be software in the form of programs and plug-ins, including the following software Modules: the first division module 4551, the second division module 4552, the first processing module 4553, the first determination module 4554, and the second processing module 4555; these modules are logical, so any combination can be made according to the implemented functions Or split further. The function of each module will be explained below.
  • the device provided in the embodiment of the application may be implemented in hardware.
  • the device provided in the embodiment of the application may be a processor in the form of a hardware decoding processor, which is programmed to execute the application.
  • the transaction processing method provided in the embodiment for example, a processor in the form of a hardware decoding processor may adopt one or more application specific integrated circuits (ASIC), DSP, and programmable logic device (PLD). ), Complex Programmable Logic Device (CPLD), Field-Programmable Gate Array (FPGA) or other electronic components.
  • ASIC application specific integrated circuits
  • DSP digital signal processor
  • PLD programmable logic device
  • CPLD Complex Programmable Logic Device
  • FPGA Field-Programmable Gate Array
  • FIG. 3 is a schematic diagram of the implementation process of the transaction processing method provided by an embodiment of the present application. The device applied to transaction processing will be described with reference to the steps shown in FIG. 3.
  • Step S301 Divide the to-be-processed transaction obtained from the database into at least two sub-transactions.
  • the transaction to be processed may be a long transaction, that is, a transaction that needs to be implemented across networks, such as a Tencent billing transaction.
  • the transaction to be processed may be divided according to the type of resource interface that needs to be called for the transaction to be processed. For example, if the type of resource interface is 3 types, then the transaction to be processed is divided into at least 3 sub-transactions. That is, a category of resource interface corresponds to a sub-transaction.
  • the transaction to be processed may be a transaction sent by a client received by a transaction processing device, or a transaction read by the transaction processing device from a client or a server.
  • the client sends a game billing transaction or checkout transaction to the transaction processing device.
  • each sub-transaction is divided into N parts having an association relationship according to the network interface to which each sub-transaction belongs and the functions implemented by the sub-transactions.
  • N is an integer greater than one.
  • the network interface that each sub-transaction belongs to can be understood as the network interface that needs to be called to realize the sub-transaction.
  • three network interfaces need to be called to divide the sub-transaction into three parts with an association relationship.
  • the association relationship may be the sequential relationship of these three parts in the execution process.
  • the sub-transaction is A and B to achieve a call. Because three network interfaces need to be called during the call, it is divided into three parts. These three parts can be.
  • the first part is that the calling terminal A queries the called terminal B's phone number to prepare for the call; the second part is based on the number found, dialing the number, based on the network
  • the communication establishes a network connection between A and B, and a call is made based on the network connection; the third part is to process the result of the call.
  • Step S303 Process the N parts of each of the sub-transactions according to the association relationship, and obtain the processing result of the last executed part of the N parts.
  • each part is processed according to the association relationship, and finally the processing result of the last executed part is obtained.
  • the processing result of the last executed part is obtained.
  • the result of the call is finally obtained.
  • the result of the call is regarded as the processing result of the sub-transaction.
  • step S304 if it is determined that there is an abnormal sub-transaction according to the processing result, a processing strategy that matches the abnormal cause of the abnormal sub-transaction is determined.
  • the abnormal sub-transaction can be understood as a sub-transaction whose processing result does not match the expected result. For example, taking the communication between A and B as an example, if the final call result indicates that the call failed, then the sub-transaction is an abnormal sub-transaction.
  • the processing strategy that matches the abnormal cause of the abnormal sub-transaction can be understood as determining whether to roll back data or continue processing the abnormal sub-transaction based on the abnormal cause, so that the abnormality can be obtained more accurately. The processing result of the sub-transaction.
  • the processing result of the previous sub-transaction of the abnormal sub-transaction is used as the processing result of the abnormal sub-transaction.
  • the abnormality that occurs when the user side processes the abnormal sub-transaction may be that it cannot be executed again after the abnormality occurs this time, or that the abnormality will still occur even if the execution is executed again, for example, the user has insufficient balance of the selected bank card If the payment fails, even if the transaction on this page is executed again, the payment will still fail. The transaction needs to be rolled back to the page for reselecting the payment method so that the user can reselect another bank card.
  • the N parts of the abnormal sub-transaction are processed again according to the association relationship.
  • the exception that occurs on the server side when processing the abnormal sub-transaction can be that after the exception occurs this time, the sub-transaction needs to be executed again to complete the sub-transaction.
  • the data cannot be processed.
  • Rollback requires re-delivery to the user until the delivery is successful; in this way, the abnormal sub-transaction can be processed automatically based on the matching processing strategy based on the abnormal reason, and the abnormal sub-transaction can be automatically processed in time, which improves the processing capacity of the transaction .
  • Step S305 Use a processing strategy to process the abnormal sub-transaction to obtain the final processing result of the transaction to be processed.
  • the correct processing result is obtained for each sub-transaction, so as to obtain the final processing result of the transaction to be processed.
  • the abnormal sub-transaction is automatically processed with a matching processing strategy, which can ensure that multiple sub-transactions are processed
  • the consistency of the system also improves fault tolerance and the ability to handle transactions.
  • the long transaction that needs to be processed is first divided into multiple word transactions, and then the sub-transactions are divided into multiple parts, processed for each part, and the processing result of each sub-transaction is obtained.
  • the solution The performance of the overall service is limited by the processing capacity of the single-machine database; based on the abnormal cause of the abnormal processing result, a matching processing strategy is selected to process the abnormal sub-transaction to obtain the final processing result; in this way, the abnormal sub-transaction is automatically processed Transactions are processed using matching processing strategies, which improves fault tolerance and the ability to process transactions.
  • step S302 may be implemented through the following steps:
  • Step S321 Determine the type set of the network interface to which each sub-firm belongs.
  • Step S322 Divide the corresponding sub-transactions into N parts according to the set of types of the network interfaces and the functions implemented by the corresponding sub-transactions.
  • each sub-transaction is divided into at least the same number of categories in the category set, and combined with the functions implemented by the corresponding sub-transactions, it is determined to divide the sub-transaction into parts For example, taking the above B to A transfer as an example, there are three categories and the functions implemented are order submission, transfer operation and transfer success notification, then the sub-transaction is divided into at least three parts. If A and B correspond to the same bank, then the sub-transaction can be divided into three parts. If A and B correspond to not the same bank, then the sub-transaction can be divided into four parts.
  • Step S323 Determine the association relationship between the N parts according to the functions implemented by each sub-transaction to form N parts with the association relationship.
  • the step S303 includes the following two situations:
  • Case 1 If the at least two sub-transactions are independent, the N parts of each sub-transaction are processed according to the association relationship to obtain the processing result of the last executed part of the N parts .
  • the at least two sub-transactions are independent, that is, there is no intersection between these sub-transactions.
  • one sub-transaction is to implement communication
  • one sub-transaction is to implement bank interface calls.
  • the intersecting sub-transactions may not consider the processing order between the sub-transactions.
  • the multiple parts are processed according to the relationship between these parts to obtain the final executed part. process result.
  • Case 2 First, if there is an intersection between the at least two sub-transactions, the processing path between the at least two sub-transactions is determined according to the intersection and the preset white list.
  • one sub-transaction is product pricing
  • one sub-transaction is order payment
  • one sub-transaction is delivery. Then there is an intersection between these three sub-transactions. , That is, it is necessary to perform product pricing first, realize order payment based on the result of product pricing, and finally, realize delivery success or failure based on the result of order payment.
  • the preset whitelist can be considered to be a reasonable processing path between the set transactions. For example, it is necessary to pay for the order first and then ship the goods. If it is to ship the goods first, and then pay for the order, then confirm This processing path does not satisfy the preset whitelist.
  • the N parts of each sub-transaction are processed in turn according to the association relationship, so as to obtain the processing result of each sub-transaction.
  • the processing path first determine the first sub-transaction that needs to be executed, and process multiple parts of the first sub-transaction according to the association relationship to obtain the processing result of the first sub-transaction; then, Based on the processing result of the first sub-transaction, multiple parts of the second sub-transaction are processed according to the association relationship to obtain the processing result of the second sub-transaction; and so on, all sub-transactions are processed according to the processing path. , Get the final processing result of the pending transaction. In this way, by dividing multiple sub-transactions into multiple parts for processing, the real-time consistency of the sub-transactions is guaranteed. By introducing a whitelist mechanism, the rationality of state transfer among multiple sub-transactions is ensured.
  • the step S303 can be performed as follows: Steps to achieve:
  • the first step is to determine the serial execution order among the at least M parts according to the association relationship.
  • the second step according to the serial execution order, based on the processing result of the M-1th part of the at least M parts in the serial execution order, execute the at least M parts in the serial execution order.
  • the M-th part in the execution sequence to obtain the processing result of the last executed part.
  • the processing flow of a single sub-transaction is realized through the above first to fourth steps, and the multiple parts are executed one by one according to the execution order among the multiple parts to obtain the processing of the sub-transaction The result; thereby improving the processing speed of the transaction.
  • the method further includes the following steps, as shown in FIG. 4.
  • FIG. 4 is a schematic diagram of another implementation process of the transaction processing method provided by the embodiment of the present application. Description:
  • step S401 the result of processing the abnormal sub-transaction by the processing strategy is adopted, and a new processing result is determined.
  • the matching processing strategy is to continue to deliver the goods for the users who have successfully paid, and obtain a new delivery result.
  • Step S402 If the new sub-transaction with abnormal processing result is still in an abnormal state, determine the processing result set of the currently processed sub-transaction.
  • step S403 the message middleware is used to store the processing result set.
  • the current network may be faulty.
  • the processing result set of the currently processed sub-transaction namely The current transaction status information of the transaction to be processed, and then the current transaction status information is stored in the message middleware, which improves the high reliability of the data layer.
  • step S404 when the input read instruction is received, the processing result set is read from the message middleware, and the N parts of the abnormal sub-transaction are processed continuously to obtain the final processing result of the transaction to be processed.
  • the received input read instruction can be understood to mean that when the transaction to be processed needs to be processed, for example, the network changes from an abnormal state to a normal state, then from the message middleware, use the message
  • the subscription mechanism realizes the recovery of the transaction, and continues to process multiple parts of the abnormal sub-transaction to obtain the normal processing result.
  • the first step is to determine the set of resource interfaces that need to be called to implement the pending transaction.
  • the set of resource interfaces that need to be called to implement the transaction include at least: a resource interface that implements product pricing, a user-side resource interface that implements order payment, and a resource interface that implements delivery. Resource interface, etc.
  • the second step is to divide the transaction to be processed into multiple sub-transactions matching the set of resource interfaces.
  • Tencent billing is divided into three sub-transactions that match the resource interface for product pricing, the user-side resource interface for order payment, and the resource interface for delivery.
  • the third step is to activate each resource interface in response to the received processing execution instruction.
  • the first stage of the distributed transaction (external XA) capability transaction is entered, that is, each resource interface is started to prompt each resource interface to do a good job. Preparatory work for handling sub-business.
  • the fourth step when the preparation completion information of the feedback of the resource interface is received, the N parts of the matching sub-transactions are processed in the resource interface according to the association relationship, so as to obtain the processing of the last executed part of the N parts result.
  • the preparation completion information is fed back to the processor, the matching sub-transactions are processed in the resource interface, and the processing results are obtained, and then enter the first part of the distributed transaction (external XA) capability.
  • the second stage is to submit the processing result and feedback the notification information of the processing completion to the user; in this way, by using multiple resource interfaces to process multiple sub-transactions, the consistency of different sub-transactions is ensured.
  • general transactions can be guaranteed by local transactions of the database. For example, in MySQL's default repeatable read (RR) isolation level, when transaction A is operating data and committing or rolling back, other transactions cannot see the modification of data by transaction A. For short transactions, the database lock time is relatively short, and for long transactions, if the transaction is not committed, it will cause the request to operate on the same resource to block or process timeout. Therefore, long transactions are generally not suitable for direct use of database transactions.
  • a long transaction is decomposed into a sequence of sub-transactions and executed in sequence. If one of the sub-transactions fails to execute, a corresponding compensation transaction is executed for the previously successfully executed sub-transaction.
  • FIG. 5 is a framework diagram of the transaction processing system provided by an embodiment of the present application. The following description will be given in conjunction with FIG. 5:
  • Condition 1 The transaction feature support of the DBMS is required.
  • Condition 2 A long transaction can be decomposed into multiple sub-transactions.
  • the execution process is as follows:
  • each sub-transaction is independent of each other. During the execution of a long transaction, there is no transaction isolation, and the intermediate state of the transaction can be externally read.
  • the application opens a long transaction by opening the transaction (begin-saga) command word and generates a unique transaction identifier (ID), and defines each child by the start-transaction (begin-transaction) and end-transaction command words. At the boundary of the transaction, the end-saga command word is used to complete the commit of the entire transaction.
  • FIG. 6 is another framework diagram of long transaction processing provided by an embodiment of the present application. The following description will be given in conjunction with FIG. 6:
  • the pending transaction output by the application (Application, APP) 61 is divided into multiple sub-transactions T 1 62, T 2 63 to T N 64.
  • the APP 61 outputs pending transactions to the system service 69.
  • the pending transaction is a long transaction.
  • the multiple sub-transactions T 1 62, T 2 63 to T N 64 may be independent or have a series relationship.
  • the second step is to record each business operation at the same time to ensure the consistency of the two operations.
  • the APP table 65 represents the logic of the business
  • the processing event table 66 is configured
  • the overall idea is that when the business operation needs to be completed, the operation of the entire transaction will be recorded at the same time, so as to ensure that the two tables are either all executed or all failed, which means that two The operation takes effect at the same time.
  • the third step based on the table 66, determine the next sub-transaction to be executed after the sub-transaction T 1 62 is executed, and use a message relay 67 (message delay) to drive the execution of the sub-transaction to be executed.
  • a message relay 67 messages delay
  • the information relay 67 is used to drive the execution of the next sub-transaction after the execution of one sub-transaction.
  • the fourth step is to publish the sub-transaction to be executed to the system so that the sub-transaction continues to be executed.
  • database 68 represents database storage.
  • Tencent billing is an Internet billing platform that supports Tencent’s internal business revenue of 100 billion yuan. Under such a huge business volume , Tencent billing must support the rapid growth of its business, while also ensuring that every transaction is well accounted for. However, a transaction process of Tencent billing usually involves dozens of network calls. In a distributed scenario, ACID must be satisfied to ensure that all operations are executed successfully before the results are submitted. As the scale of the distributed system expands, it will take time to reach a consensus The longer the cycle. For example, the scalability of the Bitcoin network requires 10 minutes for the average confirmation time of a transaction to meet consistency.
  • the embodiment of the present application provides a transaction processing method, which delegates complex distributed consistency issues to the engine platform for processing, mainly realizes the atomicity of distributed transactions, and ensures real-time high consistency of transactions; automatic exception handling improves fault tolerance ; And the process management based on the state machine, strengthen the constrainability of the process.
  • long-term transaction billing at Tencent refers to a complete transaction process, which usually includes user login status verification, risk control check, original item pricing, marketing activity pricing, user payment, item delivery, event gifting, etc. Process, it is necessary to ensure the consistency of the overall process, to achieve all success or all failures.
  • FSM Finite State Machine
  • reliable message middleware long transactions based on the application layer are realized.
  • FIG. 7 is a schematic diagram of the implementation process of the transaction processing method provided by the embodiment of the present application, and the following description will be made with reference to FIG. 7:
  • the initiator receives the pending transaction submitted by the APP 700, and divides the pending transaction into multiple sub-transactions T 1 701, T 2 702 and T N 703.
  • the initiator determines to execute the sub-transaction T 1 701 based on the operator condition 1, and then executes T 2 702; based on the operator condition 3, determines to execute the sub-transaction T 1 701 and then executes T N 703; that is, the operator Condition 2 determines that after subtransaction T 2 702 is executed, T N 703 is executed.
  • the resource party can be understood as a call to a database or a network interface. Arrows 71 and 72 respectively indicate that if the execution of the sub-transaction fails, a reverse operation is performed.
  • a sub-transaction is divided into three independent parts (that is, prepare-Remote Procedure Call Protocol (pre-rpc) 704, rpc 705 and submit rpc (post-rpc) 706), If an abnormality occurs in one of the sub-transactions during processing, the transaction can be recovered by the business according to the result information of the rpc response, through a combination of multiple operator conditions (Conditions) to specify whether to adopt forward recovery or backward recovery.
  • pre-rpc prepare-Remote Procedure Call Protocol
  • post-rpc submit rpc
  • each part is executed, and the processing result of the last executed part is fed back to the resource party 74.
  • Fig. 8 is an execution path diagram of a long transaction process state provided by an embodiment of the present application.
  • the number in the node indicates a certain execution state, where, for example, 01 indicates initialization, 50 indicates successful pricing, and 100 indicates If the order is successfully placed, the order will be placed after the price is approved. 100 means a payment is submitted, which means that the call to WeChat Pay is successful. For example, a pop-up window will pop up to WeChat for the user to enter the password and use You can enter it or not.
  • the payment is successful and enters 101.
  • the payment is successful.
  • 901 indicates that the delivery fails; 205 indicates that the payment is not successful; 601 indicates that the user initiates a refund, and 602 indicates to The user refunded successfully; the arrows from 602 to 910 indicate that after the refund is successful, the status of the payment order will be updated at the same time, and then the payment order will be marked as having initiated a refund.
  • the solid line path indicates the path that can be executed normally, while the dashed path 801 indicates the restricted execution path (ie, node 50 cannot directly flow to node 901, that is, it is an unreasonable state flow from the price to the failure of the shipment, and payment is required in the middle. Complete status node 101). In this way, the internal execution of a long transaction will be divided into multi-step operations, and some steps are sequential, so the state process needs to be constrained, and the reasonable circulation of the transaction process can be controlled through the finite state machine whitelist.
  • FIG. 9 is a schematic diagram of another implementation flow of the transaction processing method provided by an embodiment of the present application, and the following description will be made with reference to FIG. 9:
  • the APP 91 submits the pending transaction to the system service 92.
  • the system service 92 processes the sub-transaction T 1 93 in the transaction to be processed. Based on the condition operator 1, it determines that after T 1 93 is executed, the sub-transaction T 2 94 is executed, and so on, each sub-transaction is executed in sequence. Until the last sub-transaction TN 95 is executed, the processing of the pending transaction is completed, and the final processing result is obtained.
  • the transaction status of processing the sub-transaction T 1 93 can be stored in the transaction status storage area 96, and the transaction status storage area 96 can also feed back T 1 to the system service. 93 transaction status.
  • the transaction status of processing sub-transaction T 2 94 is stored in the transaction status storage area 97, and the transaction status of T 2 94 can also be fed back to the system service from the transaction status storage area 97; the transaction status of the sub-transaction T N 95 will be processed
  • the transaction status is stored in the transaction status storage area 98, and from the event storage area 98, the transaction status of TN 95 can also be fed back to the system service.
  • FIG. 10 is a schematic diagram of the implementation process of the message middleware storing transaction status according to the embodiment of the present application.
  • APP11, APP12, and APPN13 are respectively used to submit pending transactions.
  • the transaction status of the pending transaction submitted by APP12 can be stored in the message middleware 1004.
  • the message middleware 1004 includes production The end 1005 and the consumer end 1006, wherein the production end 1005 is used to enqueue the stored transaction state, and the consumer end 1006 is used to dequeue the stored transaction state.
  • the control distributor 1007 determines where to store the transaction state according to the request.
  • the underlying storage of the control distributor 1007 includes a computing engine 1008 (broker), a storage engine 1009 (bookkeeper, BK), and a distributed coordinator. 1010 (zookeeper).
  • the calculation engine 1008 uses load balance 1011 (load balance), management classification 1012 (managed ledger), storage 1013 (cache), and BK client 1014 to determine how to store the transaction state requested for storage.
  • the control distributor 1007 realizes the separation of calculation and storage, that is, calculates how and where the transaction status is stored.
  • Storage refers to the highly reliable storage of the transaction status guaranteed by the storage engine 1009.
  • a highly reliable message middleware In order to ensure that transaction messages are not lost, the message middleware is based on multiple copies in the data layer to ensure the high reliability of the data layer; in addition, the WAL sequential log writing method on the production side improves the processing capacity of the system, which can reach milliseconds Level delay; the architecture can be flexibly expanded horizontally through the separation of computing and storage; finally, in order to facilitate management, we have implemented a set of easy-to-operate management consoles that can view transactions executed at any time.
  • FIG. 11 is a schematic diagram of the implementation process of implementing a transfer request according to an embodiment of the present application, and the following description will be made with reference to FIG. 11:
  • the transfer request submitted by the APP terminal 1101 is included in the order service 1102 to create a transfer order.
  • two groups 1104 and 1105 need to be implemented.
  • M and S respectively represent: the master and backup in a set of database settings.
  • user A transfers money to user B, but the account opening banks of the two users are different, one is China Construction Bank and the other is Industrial and Commercial Bank. The data storage of these two banks is not on the same server. In this case, by using Two groups 1104 and 1105 realize transfers between different banks.
  • the dashed line 1107 and the dashed line 1108 respectively indicate that the data rollback is performed when the current step fails.
  • the read and write performance of the message middleware is higher than the processing performance of the database, and the combination of local storage and remote high consistency message middleware ensures that transaction messages are not lost.
  • the status information of the long transaction is stored persistently through the message middleware, and does not need to be coupled with the storage of the business.
  • the execution of the entire transaction is driven by the pub-sub method, which ensures the non-invasiveness of the database.
  • the transaction since the database transaction is based on connection, the transaction will be rolled back when the connection is disconnected. Therefore, suppose the following scenarios:
  • Scenario 1 If the DB transaction is successfully submitted first, other transactions fail.
  • Scenario 2 If other transactions are successfully submitted first, the DB connection is broken at this time.
  • Scenario 3 If other transactions are successfully submitted first, then the DB partially succeeds and partially fails.
  • Scenario 4 If there is an asynchronous service, the DB operation is submitted or not submitted at this time.
  • the embodiment of the present application combines the external XA capability of MySQL to implement native distributed transactions. Since MySQL provides the capability of external XA transactions, it allows the preparation of successful transactions across connections. A two-phase commit method is used to realize distributed transactions across databases. Since there are no restrictions on business SQL, the usage scenarios are wider.
  • FIG. 12 is a schematic diagram of the implementation process of the transaction processing method provided by the embodiment of the present application. 12 Make the following instructions:
  • Step S1201 start the transaction.
  • the APP sends an instruction to start a transaction to the middleware service engine (TDXA); the APP initiates a transfer request to TDXA, and TDXA is used to implement a consistent middleware service engine.
  • TDXA middleware service engine
  • step S1202 a transfer order is created.
  • Try means to create an order, and after creating an order service, initiate an sql transfer operation and enter the first stage of the transfer operation.
  • step S1203 the sql command "xa start xd1" is sent to the database 1.
  • Step S1204 Send the sql command "xa start xd2" to the database 2.
  • the sql commands "xa start xd1" and “xa start xd2" are sent to database 1 and database 2 respectively (where these two sql commands are used as coordinators to ensure that the two databases reach agreement, so that Both database 1 and database 2 are ready) to maintain the consistency of transaction processing between database 1 and database 2.
  • Step S1205 Send the sql command "xa prepare xd1" to the database 1.
  • Step S1206 Send the sql command "xa prepare xd2" to the database 2.
  • the sql commands "xa prepare xd1" and “xa prepare xd2" are sent to the database 1 and the database 2 respectively, so that both DBs are ready to process transactions, that is, to process transfer orders.
  • Step S1207 Determine the transfer result, and send a notification message to the user.
  • “do” can be used to obtain the transfer result. If the order service fails during the process of creating the transfer order, reset the status of the created order, for example, when the creation of the order is completed, the set status is 1 , If it fails, modify the status of the order; do means to notify the user that the transfer has failed or succeeded. In this embodiment, if the order is created successfully but the transfer result fails, the status of the created order must be changed to the order invalid. After completing step S1207, enter the second phase of the state between multiple transactions.
  • local files can also be used as storage. For example, the status information of each sub-transaction is stored in rows, and then the transaction status information in the file is checked through an asynchronous shipment to determine subsequent operations.
  • Step S1208 confirm the foregoing steps.
  • step S1201 in the second phase of the state between multiple transactions, the agreement that has been negotiated in the previous step S1201 to step S1207 is confirmed.
  • Step S1209 Send "xa commit xid1" to database 1, and send "xa commit xid2" to database 2.
  • step S1210 a transaction end message is returned to the APP.
  • a long transaction process may involve multiple resource operations such as RPC database and KV.
  • the consistency of mixed resource operations needs to be achieved to achieve universality. Sex.
  • the software module stored in the transaction processing server 455 of the memory 450 may include: a first division module 4551, configured to divide the transaction to be processed obtained from the database into at least two sub-transactions; a second division module 4552, configured to implement according to the network interface of each sub-transaction and the sub-transactions Each of the sub-transactions is divided into N parts with an association relationship, where N is an integer greater than 1.
  • the first processing module 4553 is configured to perform N of each sub-transaction according to the association relationship.
  • the first determining module 4554 is configured to determine if an abnormal sub-transaction is determined according to the processing result, determine the transaction related to the abnormal sub-transaction A processing strategy that matches the cause of the abnormality; the second processing module 4555 is configured to use the processing strategy to process the abnormal sub-transaction to obtain the final processing result of the pending transaction.
  • the first division module 4551 is further configured to: determine the type set of the network interface to which each sub-transaction belongs; according to the type set of the network interface and the functions implemented by the corresponding sub-transaction, The corresponding sub-transaction is divided into N parts; according to the functions implemented by each sub-transaction, the association relationship between the N parts is determined to form N parts with the association relationship.
  • the first processing module 4553 is further configured to: if the at least two sub-transactions are independent, process the N parts of each of the sub-transactions according to the association relationship, Obtain the processing result of the last executed part among the N parts.
  • the first processing module 4553 is further configured to: if there is an intersection between the at least two sub-transactions, determine the difference between the at least two sub-transactions according to the intersection and a preset whitelist Processing path; According to the processing path, the N parts of each sub-transaction are processed in turn according to the association relationship to obtain the processing result of each sub-transaction.
  • the sub-transaction is divided into at least M parts, where M is an integer greater than 1, and the first processing module 4553 , And also configured to: determine the serial execution order between the at least M parts according to the association relationship; according to the serial execution order, based on the sequence of the at least M parts in the serial execution order For the processing result of the M-1th part, the Mth part of the at least M parts in the serial execution sequence is executed to obtain the processing result of the last executed part.
  • the first processing module 4553 is further configured to: use the processing strategy to process the abnormal sub-transaction to determine a new processing result; if the new processing result is abnormal If the sub-transaction is still in an abnormal state, determine the processing result set of the currently processed sub-transaction; use a message middleware to store the processing result set; when an input read instruction is received, read from the message middleware The processing results are collected, and the N parts of the abnormal sub-transaction are processed continuously.
  • the second processing module 4555 is further configured to: if the cause of the abnormality is that an abnormality occurred on the user side during the processing of the abnormal sub-transaction, the processing of the previous sub-transaction of the abnormal sub-transaction The result is taken as the processing result of the abnormal sub-transaction; if the cause of the abnormality is that the server side is abnormal in processing the abnormal sub-transaction, the N parts of the abnormal sub-transaction are processed again according to the association relationship.
  • the first division module 4551 is further configured to: determine a set of resource interfaces that need to be invoked to implement the transaction to be processed; divide the transaction to be processed into multiple sub-transactions that match the resource interface set ; Correspondingly, in response to the received processing execution instruction, each resource interface is started; when the preparation completion information of the feedback of the resource interface is received, the N parts of the matching sub-transactions in the resource interface are in accordance with all The association relationship is processed to obtain the processing result of the last executed part of the N parts.
  • the embodiment of the present application provides a storage medium storing executable instructions, and the executable instructions are stored therein.
  • the processor will cause the processor to execute the method provided in the embodiments of the present application.
  • the storage medium may be a flash memory, a magnetic surface memory, an optical disk, or an optical disk memory; it may also be various devices including one or any combination of the foregoing memories.
  • the executable instructions may be in the form of programs, software, software modules, scripts or codes, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and their It can be deployed in any form, including being deployed as an independent program or as a module, component, subroutine or other unit suitable for use in a computing environment.
  • executable instructions may but do not necessarily correspond to files in the file system, and may be stored as part of a file that saves other programs or data, for example, in a HyperText Markup Language (HTML) document
  • HTML HyperText Markup Language
  • One or more scripts in are stored in a single file dedicated to the program in question, or in multiple coordinated files (for example, a file storing one or more modules, subroutines, or code parts).
  • executable instructions can be deployed to be executed on a vehicle-mounted computing device, or on multiple computing devices located in one location, or on multiple computing devices that are distributed in multiple locations and interconnected by a communication network. Equipment execution.
  • the sub-transaction is divided into multiple parts through the network interface based on the sub-transaction belonging, and the processing is performed for each part, and the processing result is
  • the abnormal abnormal sub-transaction solves the problem that the performance of the overall service is limited by the processing capacity of the stand-alone database; the abnormal sub-transaction is selected based on the abnormal reason and the matching processing strategy is selected to obtain the final processing result; in this way, the abnormality is automatically processed
  • Sub-transactions are processed using matching processing strategies, which improves fault tolerance and transaction processing capabilities.
  • the transaction to be processed obtained from the database is divided into at least two sub-transactions; each sub-transaction is divided into at least two sub-transactions according to the network interface to which each sub-transaction belongs and the functions implemented by the sub-transactions N parts with an association relationship; N parts of each sub-transaction are processed according to the association relationship, and the processing result of the last executed part of the N parts is obtained; if it is determined according to the processing result If there is an abnormal sub-transaction, determine the processing strategy that matches the abnormal cause of the abnormal sub-transaction; use the processing strategy to process the abnormal sub-transaction to obtain the final processing result of the pending transaction; in this way, Through automated deployment, matching processing strategies are used to handle abnormal sub-transactions, which improves fault tolerance and transaction processing capabilities.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Quality & Reliability (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Technology Law (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请实施例提供了一种事务处理方法、装置、设备及计算机存储介质；所述方法包括：将从数据库获取的待处理事务，划分为至少两个子事务；按照每一子事务所属的网络接口和所述子事务实现的各功能，将每一所述子事务划分为具有关联关系的N个部分；按照所述关联关系对每一所述子事务的N个部分进行处理，得到所述N个部分中最后被执行的部分的处理结果；如果根据所述处理结果确定出有异常子事务，确定与所述异常子事务的异常原因相匹配的处理策略；采用所述处理策略对所述异常子事务进行处理，以得到所述待处理事务的最终处理结果。

Description

事务处理方法、装置、设备及计算机存储介质
相关申请的交叉引用
本申请基于申请号为201911223449.3、申请日为2019年12月3日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此引入本申请作为参考。
技术领域
本申请涉及数据库领域，尤其涉及事务处理方法、装置、设备及计算机存储介质。
背景技术
在相关技术的数据库中，在事务A在操作数据且提交(commit)或回滚(rollback)之前，其他事务不能看到事务A对数据的修改。对于长事务而言，如果事务不提交将会导致操作相同资源的请求阻塞或处理超时。如此，子事务的提交依赖于数据库本地事务，使得整体服务的性能受限于单机数据库的处理能力，处理效率较低。
发明内容
本申请实施例提供一种事务处理方法、装置、设备及计算机存储介质，能够通过自动的对异常子事务采用匹配的处理策略进行处理，提高了容错性以及处理事务的能力。
本申请实施例的技术方案是这样实现的：
第一方面，本申请实施例提供一种事务处理方法，所述方法应用于事务处理的设备，包括：将从数据库获取的待处理事务，划分为至少两个子事务；按照每一子事务所属的网络接口和所述子事务实现的各功能，将每一所述子事务划分为具有关联关系的N个部分，N为大于1的整数；按照所述关联关系对每一所述子事务的N个部分进行处理，得到所述N个部分中最后被执行的部分的处理结果；如果根据所述处理结果确定出有异常子事务，确定与所述异常子事务的异常原因相匹配的处理策略；采用所述处理策略对所述异常子事务进行处理，以得到所述待处理事务的最终处理结果。
第二方面，本申请实施例提供一种事务处理装置，包括：第一划分模块，配置为将从数据库获取的待处理事务，划分为至少两个子事务；第二划分模块，配置为按照每一子事务所属的网络接口和所述子事务实现的各功能，将每一所述子事务划分为具有关联关系的N个部分，N为大于1的整数；第一处理模块，配置为按照所述关联关系对每一所述子事务的N个部分进行处理，得到所述N个部分中最后被执行的部分的处理结果；第一确定模块，配置为如果根据所述处理结果确定出有异常子事务，确定与所述异常子事务的异常原因相匹配的处理策略；第二处理模块，配置为采用所述处理策略对所述异常子 事务进行处理，以得到所述待处理事务的最终处理结果。
第三方面，本申请实施例提供一种事务处理的设备，包括：存储器，配置为存储可执行指令；处理器，配置为执行所述存储器中存储的可执行指令时，实现上述事务处理方法。
第四方面，本申请实施例提供一种存储介质(非暂时性存储介质)，存储有可执行指令，配置为引起处理器执行时，实现本申请实施例提供的事务处理方法。
本申请实施例具有以下有益效果：对于待处理事务，通过基于子事务所属的网络接口将子事务划分成多个部分，针对每一部分进行处理以解决整体服务的性能受限于单机数据库的处理能力的问题；对于处理结果异常的异常子事务，基于异常原因选择匹配的处理策略对异常子事务进行处理，以得到最终的处理结果；如此，自动对异常子事务采用匹配的处理策略进行处理，提高了容错性以及处理事务的能力。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，这些附图示出了符合本申请的实施例，并与说明书一起用于说明本申请的技术方案。
图1是本申请实施例提供的事务处理系统的一个可选的架构示意图；
图2A是本申请实施例提供的事务处理系统的另一个可选的架构示意图；
图2B是本申请实施例提供的事务处理系统的结构示意图；
图3是本申请实施例提供的事务处理方法的实现流程示意图；
图4是本申请实施例提供的事务处理方法的另一实现流程示意图；
图5是本申请实施例提供的事务处理系统的框架图；
图6是本申请实施例提供的长事务处理的另一框架图；
图7是本申请实施例提供的事务处理方法的实现流程示意图；
图8是本申请实施例提供的长事务流程状态的执行路径图；
图9是本申请实施例提供的事务处理方法的另一实现流程示意图；
图10是本申请实施例消息中间件存储事务状态的实现流程示意图；
图11是本申请实施例实现转账请求的实施流程示意图；
图12是本申请实施例提供的事务处理方法的实现流程示意图。
具体实施方式
为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一 步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。
在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使在一些实施例中描述的本申请实施例能够以除了在在一些实施例中图示或描述的以外的顺序实施。
除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。
对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。
1)ACID特性：事务具有四个特性，分别是原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持久性(Durability)，简称为事务的ACID特性。
2)长事务：一个事务花费很长时间不能够结束，就是一个长的事务，简称长事务(Long Transaction)。在数据库中，运行时间超过6秒的事务就被视为长事务。Informix把占用整个逻辑日志空间在一定比例以上的事务(事务占用整个逻辑日志空间的百分比超过“长事务深水线比例”这个参数限定的值)，叫做“长事务”。
3)发布-订阅机制(Publish-Subscribe，PubSub)：消息传递模式介绍是一种历史悠久的经典消息传递模式；订阅发布模式定义了一种一对多的依赖关系，让多个订阅者对象同时监听某一个主题对象。这个主题对象在自身状态变化时，会通知所有订阅者对象，使它们能够自动更新自己的状态。将一个系统分割成一系列相互协作的类有一个很不好的副作用，那就是需要维护相应对象间的一致性，这样会给维护、扩展和重用都带来不便。当一个对象的改变需要同时改变其他对象，而且当不知道具体有多少对象需要改变时，就可以使用订阅发布模式。
4)集群服务器(Broker)：集群中的一台或多台服务器的统称，Broker没有副本机制，一旦broker宕机，该broker的消息将都不可用。Broker不保存订阅者的状态，由订阅者自己保存。
5)记账者(BookKeeper)，是一个提供日志条目流存储持久化的服务框架。特别适合日志流存储，一个比较经典的应用是作为消息队列的持久框架。
6)预写式日志(Write-Ahead Logging)：事物日志可以帮助提高事物的效率。使用事物日志，存储引擎在修改标的数据时只需要修改其内存拷贝，再把修改行为记录到持久在硬盘上的事务日志中，而不用每次都将修改的数据本身持久到磁盘中。事物日志采用的是追加的方式，因此写日志的操作是磁盘上一小块区域内的顺序I/O，而不像随机I/O需要在磁盘的多个地方移动磁头，所以采用事物日志的方式相对来说要快得多。事务日志持久以后，内存中被修改的数据在后台可以慢慢地刷回磁盘。
7)区块链(Blockchain)：由区块(Block)形成的加密的、链式的交易的存储结构。
8)区块链网络(Blockchain Network)：通过共识的方式将新区块纳入区块链的一系列的节点的集合。
9)云技术(Cloud technology)基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。
10)数据库(Database，DB)，简而言之可视为电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据进行新增、查询、更新、删除等操作。所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。
11)数据库管理系统(Database Management System，DBMS)是为管理数据库而设计的电脑软件系统，一般具有存储、截取、安全保障、备份等基础功能。数据库管理系统可以依据它所支持的数据库模型来作分类，例如关系式、XML(Extensible Markup Language，即可扩展标记语言)；或依据所支持的计算机类型来作分类，例如服务器群集、移动电话；或依据所用查询语言来作分类，例如SQL(结构化查询语言(Structured Query Language)、XQuery；或依据性能冲量重点来作分类，例如最大规模、最高运行速度；亦或其他的分类方式。不论使用哪种分类方式，一些DBMS能够跨类别，例如，同时支持多种查询语言。
在相关技术中，由于子事务的提交依赖数据库本地事务，因此整体服务的性能受限于单机数据库的处理能力；长事务的状态需要和业务的数据库操作作为一个本地数据库事务提交，因此对业务数据库存在侵入性；而且，对于一些无法提供补偿事务的操作，存在一定的使用限制。
基于此，本申请实施例提供一种事务处理方法、装置、设备及计算机存储介质(非暂时性存储介质)，在需要对长事务进行处理的场景下，首选，将获取的待处理事务，划分为至少两个子事务；然后，按照每一子事务所属的网络接口，将每一所述子事务划分为具有关联关系的多个部分；并且，按照所述关联关系对每一所述子事务的多个部分进行处理，得到所述多个部分中最后被执行的部分的处理结果；最后，如果根据所述处理结果确定出有异常子事务，确定与所述异常子事务的异常原因相匹配的处理策略；采用所述处理策略对所述异常子事务进行处理，以得到所述待处理事务的最终处理结果；如此，对于待处理事务，通过基于子事务所属的网络接口将子事务划分成多个部分，以解决整体服务的性能受限于单机数据库的处理能力的问题；然后，针对每一部分进行处理，对于处理结果异常的异常子事务，基于异常原因选择匹配的处理策略对异常子事务进行处理，以得到最终的处理结果；如此，自动对异常子事务采用匹配的处理策略进行处理，能够提高容错性以及处理事务的能力。
下面说明本申请实施例提供的事务处理的设备的示例性应用，本申请实施例提供的设备可以实施为笔记本电脑，平板电脑，台式计算机，机顶盒，移动设备(例如，移动电话，便携式音乐播放器，个人数字助理，专用消息设备，便携式游戏设备)等各种类型的用户设备，也可以实施为服务器。下面，将说明设备实施为设备或服务器时示例性应用。服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。
参见图1，图1是本申请实施例提供的事务处理系统的一个可选的架构示意图，为实现支撑一个示例性应用，首先，当接收到终端10发送的事务处理请求时，将该事务处理请求指定的待处理事务11，划分为多个子事务12；然后，按照每一个子事务所属的网络接口，对该子事务再次进行划分，得到相互关联的多个部分13；接下来，按照该多个部 分13之间的关联关系对这多个部分依次进行处理，得到所述多个部分13中最后被执行的部分的处理结果101；如果该处理结果101存在异常，基于异常原因确定相匹配的处理策略102；最后，采用该处理策略对异常子事务103进行处理，以得到所述待处理事务11的最终处理结果104；如此，通过基于子事务所属的网络接口将子事务划分成多个部分，针对每一部分进行处理，解决了整体服务的性能受限于单机数据库的处理能力的问题；对于处理结果异常的异常子事务，基于异常原因选择匹配的处理策略对异常子事务进行处理，以得到最终的处理结果；这样，自动的对异常子事务采用匹配的处理策略进行处理，提高了容错性以及处理事务的能力。
参见图2A，图2A是本申请实施例提供的事务处理系统的另一个可选的架构示意图，包括区块链网络20(示例性示出了作为原生节点的服务器200)、监测系统30(示例性示出归属于监测系统30的设备300及其图形界面301)，下面分别进行说明。
区块链网络20的类型是灵活多样的，例如可以为公有链、私有链或联盟链中的任意一种。以公有链为例，任何业务主体的电子设备例如用户设备和服务器，都可以在不需要授权的情况下接入区块链网络20；以联盟链为例，业务主体在获得授权后其下辖的电子设备(例如设备/服务器)可以接入区块链网络20，此时，成为区块链网络20中的一类特殊的节点即客户端节点。
需要指出地，客户端节点可以只提供支持业务主体发起交易(例如，用于上链存储数据或查询链上数据)功能，对于区块链网络20的原生节点的功能，例如下文所述的排序功能、共识服务和账本功能等，客户端节点可以缺省或者有选择性(例如，取决于业务主体的具体业务需求)地实现。从而，可以将业务主体的数据和业务处理逻辑最大程度迁移到区块链网络20中，通过区块链网络20实现数据和业务处理过程的可信和可追溯。
区块链网络20接收来自业务主体(例如图2A中示出的监测系统30)的客户端节点(例如，图2A中示出的归属于监测系统30的设备300)提交的交易，执行交易以更新账本或者查询账本，并在设备的用户界面(例如，设备300的图形界面301)显示执行交易的各种中间结果或最终结果。
下面以监测系统接入区块链网络以实现事务处理的上链为例说明区块链网络的示例性应用。
监测系统30的设备300接入区块链网络20，成为区块链网络20的客户端节点。设备300通过传感器获取待处理事务，将该待处理事务，划分为至少两个子事务；然后，按照每一子事务所属的网络接口，将子事务划分为具有关联关系的多个部分；以及，按照关联 关系对子事务的多个部分进行处理，得到最后被执行的部分的处理结果；最后，如果处理结果表明存在异常子事务，确定与异常原因相匹配的处理策略；采用该处理策略对异常子事务进行处理，从而得到待处理事务的最终处理结果；并且，将最终处理结果传递给区块链网络20中的服务器200或者保存在设备300中；在已对设备300部署上传逻辑或用户进行操作的情况下，设备300根据待处理事务/同步时间查询请求，生成对应更新操作/查询操作的交易，在交易中指定了实现更新操作/查询操作需要调用的智能合约、以及向智能合约传递的参数，交易还携带了监测系统30签署的数字签名(例如，使用监测系统30的数字证书中的私钥，对交易的摘要进行加密得到)，并将交易广播到区块链网络20。其中，数字证书可由监测系统30向认证中心31进行登记注册得到。
区块链网络20中的原生节点，例如服务器200在接收到交易时，对交易携带的数字签名进行验证，数字签名验证成功后，根据交易中携带的监测系统30的身份，确认监测系统30是否是具有交易权限，数字签名和权限验证中的任何一个验证判断都将导致交易失败。验证成功后签署原生节点自己的数字签名(例如，使用原生节点的私钥对交易的摘要进行加密得到)，并继续在区块链网络20中广播。
区块链网络20中具有排序功能的节点接收到验证成功的交易后，将交易填充到新的区块中，并广播到区块链网络中20提供共识服务的节点。
区块链网络20中的提供共识服务的节点对新区块进行共识过程以达成一致，提供账本功能的节点将新区块追加到区块链的尾部，并执行新区块中的交易：对于提交待处理事务的处理结果的交易，更新状态数据库中待处理事务对应的键值对；对于查询同步时间的交易，从状态数据库中查询同步时间对应的键值对，并返回查询结果。对于得到的同步时间，可显示于设备300的图形界面301中。
区块链网络20中的原生节点可从区块链中读取待处理事务，并将待处理事务呈现于原生节点的监测页面，原生节点也可以利用在区块链存储的待处理事务，对该待处理事务进行处理，比如，通过基于子事务所属的网络接口将子事务划分成多个部分，解决了整体服务的性能受限于单机数据库的处理能力的问题；对于处理结果异常的异常子事务，基于异常原因选择匹配的处理策略对异常子事务进行处理，以得到最终的处理结果；这样，自动的对异常子事务采用匹配的处理策略进行处理，提高了容错性以及处理事务的能力。
在实际应用中，可为区块链网络20的不同原生节点设置不同的功能，例如设置服务器200具有事务处理功能和记账功能，比如，通过基于子事务所属的网络接口将子事务划 分成多个部分，针对每一部分进行处理，确定出处理结果异常的异常子事务；然后，基于异常原因选择匹配的处理策略对异常子事务进行处理，以得到最终的处理结果。对于该情况，可在交易过程中，服务器200接收设备300发送的事务处理请求，采用服务器200基于事务处理请求，对待处理事务进行划分，得到多个子事务；然后，基于子事务所属的网络接口将子事务划分成多个部分；最后，针对每一部分进行处理，对于处理结果异常的异常子事务，基于异常原因选择匹配的处理策略对异常子事务进行处理，以得到最终的处理结果；这样，既解决了整体服务的性能受限于单机数据库的处理能力的问题，而且通过自动的对异常子事务采用匹配的处理策略进行处理，提高了容错性以及处理事务的能力。
参见图2B，图2B是本申请实施例提供的事务处理系统的结构示意图，图2B所示的设备400包括：至少一个处理器410、存储器450、至少一个网络接口420和用户接口430。设备400中的各个组件通过总线系统440耦合在一起。可理解，总线系统440用于实现这些组件之间的连接通信。总线系统440除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图2B中将各种总线都标为总线系统440。
处理器410可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。
用户接口430包括使得能够呈现媒体内容的一个或多个输出装置431，包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口430还包括一个或多个输入装置432，包括有助于用户输入的用户接口部件，在一些示例中键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。
存储器450可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器450可选地包括在物理位置上远离处理器410的一个或多个存储设备。
存储器450包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(Read Only Memory，ROM)，易失性存储器可以是随机存取存储器(Random Access Memory，RAM)。本申请实施例描述的存储器450旨在包括任意适合类型的存储器。
在一些实施例中，存储器450能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，其中，“模块”可以使用硬件(例如处理电路和 /或存储器)，软件(例如使用编程语言开发的软件)或其组合来实现。下面示例性说明。
操作系统451，包括配置为处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，配置为实现各种基础业务以及处理基于硬件的任务；
网络通信模块452，配置为经由一个或多个(有线或无线)网络接口420到达其他计算设备，示例性的网络接口420包括：蓝牙、无线相容性认证、和通用串行总线(Universal Serial Bus，USB)等；
呈现模块453，配置为经由一个或多个与用户接口430相关联的输出装置431(例如，显示屏、扬声器等)使得能够呈现信息(例如，用于操作外围设备和显示内容和信息的用户接口)；
输入处理模块454，配置为对一个或多个来自一个或多个输入装置432之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。
在一些实施例中，本申请实施例提供的装置可以采用软件方式实现，图2B示出了存储在存储器450中的事务处理的服务器455，其可以是程序和插件等形式的软件，包括以下软件模块：第一划分模块4551、第二划分模块4552、第一处理模块4553、第一确定模块4554和第二处理模块4555；这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。
在另一些实施例中，本申请实施例提供的装置可以采用硬件方式实现，作为示例，本申请实施例提供的装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本申请实施例提供的事务处理方法，例如，硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(Application Specific Integrated Circuit，ASIC)、DSP、可编程逻辑器件(Programmable Logic Device，PLD)、复杂可编程逻辑器件(Complex Programmable Logic Device，CPLD)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或其他电子元件。
将结合本申请实施例提供的设备的示例性应用和实施，说明本申请实施例提供的事务处理方法。
参见图3，图3是本申请实施例提供的事务处理方法的实现流程示意图，应用于事务处理的设备，结合图3示出的步骤进行说明。
步骤S301，将从数据库获取的待处理事务，划分为至少两个子事务。
在一些实施例中，所述待处理事务可以是长事务，即需要跨网络实现的事务，比如，腾讯计费事务。在一些实施例中，可以是按照待处理事务需要调用的资源接口的类别， 对该待处理事务进行划分，比如，资源接口的类别为3类，那么将待处理事务至少划分为3个子事务，即一个资源接口的类别对应一个子事务。
在本申请实施例中，待处理事务可以是事务处理的设备接收客户端发送的事务，还可以是事务处理设备从客户端或者服务器中读取的事务。比如，客户端向事务处理设备发送游戏计费事务或结账事务等。
步骤S302，按照每一子事务所属的网络接口和子事务实现的各功能，将每一子事务划分为具有关联关系的N个部分。
在一些实施例中，N为大于1的整数。每一子事务所属的网络接口可以理解为实现该子事务需要调用的网络接口，比如，需要调用三个网络接口，将该子事务划分为具有关联关系的三个部分。所述关联关系可以是这三个部分在执行的过程中的先后关系，比如，该子事务是A和B实现通话，因为在通话过程中需要调用三个网络接口，所以划分为三个部分，这三个部分可以是，第一部分是，主叫端A查询被叫端B的电话号码，为实现通话做准备工作；第二个部分是，基于查询到的号码，拨通该号码，基于网络通信建立A与B的之间的网络连接，基于该网络连接进行通话；第三部分是，对于通话的结果进行处理。
步骤S303，按照关联关系对每一所述子事务的N个部分进行处理，得到N个部分中最后被执行的部分的处理结果。
在一些实施例中，按照该关联关系对每一部分进行处理，最终得到最后被执行的部分的处理结果。比如，以上述A与B实现通话为例，最终得到通话的结果。将该通话的结果作为该子事务的处理结果。
步骤S304，如果根据处理结果确定出有异常子事务，确定与异常子事务的异常原因相匹配的处理策略。
在一些实施例中，所述异常子事务可以理解为是处理结果与预期结果不符的子事务。比如，以A与B之间实现通信为例，最后得到的通话结果如果表明通话失败，那么说明该子事务是异常子事务。所述与所述异常子事务的异常原因相匹配的处理策略，可以理解为是基于该异常原因，确定是对该异常子事务进行数据回滚还是继续进行处理，从而能够更加准确的得到该异常子事务的处理结果。在一些实施例中，如果所述异常原因为用户端在处理所述异常子事务时发生异常，将所述异常子事务的上一个子事务的处理结果作为所述异常子事务的处理结果。在一个具体例子中，用户端在处理所述异常子事务时发生异常可以是本次发生异常之后，不能再次执行或者是即使再次执行仍然会发生异常，比如，用户由于选择的银行卡的余额不足导致的付款失败，那么即使再次执行该页面的 事务，仍然会付款失败，需要对事务进行回滚，以回滚到重新选择付款方式的页面，以使用户可以重新选择其他银行卡。如果所述异常原因为服务器端在处理所述异常子事务时发生异常，按照所述关联关系再次对所述异常子事务的N个部分进行处理。一个具体例子中，服务器端在处理所述异常子事务时发生异常可以是本次发生异常之后，需要再次执行即可完成该子事务，比如，用户付款成功之后，发货失败，那么不能进行数据回滚，需要给用户重新发货，直至发货成功；如此，基于异常原因选择相匹配的处理策略对异常子事务进行处理，能够及时的对异常子事务进行自动处理，提高了事务的处理能力。
步骤S305，采用处理策略对异常子事务进行处理，以得到待处理事务的最终处理结果。
在一些实施例中，对于每一个子事务得到正确的处理结果，从而得到待处理事务的最终处理结果，这样，自动对异常子事务采用匹配的处理策略进行处理，既可以保证多个子事务进行处理的一致性，还提高了容错性以及处理事务的能力。
在本实施例中，对于需要处理的长事务，先划分为多个字事务，然后，将子事务划分成多个部分，针对每一部分进行处理，得到每一个子事务的处理结果，这样，解决了整体服务的性能受限于单机数据库的处理能力的问题；基于发生异常的处理结果的异常原因选择匹配的处理策略对异常子事务进行处理，以得到最终的处理结果；如此，自动对异常子事务采用匹配的处理策略进行处理，提高了容错性以及处理事务的能力。
在一些实施例中，为了保证对于每一个部分进行处理的高效性，所述步骤S302可以通过以下步骤实现：
步骤S321，确定每一子事务所属的网络接口的类别集合。
比如，以B向A转账为例，需要调用A发起转账请求的网络接口、A和B分别对应的银行的网络接口以及B接收转账请求并实现转账的网络接口等。
步骤S322，根据网络接口的类别集合和对应子事务实现的各功能，将对应子事务划分为N个部分。
在一些实施例中，根据网络接口的类别集合，将每一子事务至少划分为和类别集合中类别数量相同的多个部分，并且结合对应子事务实现的各功能，确定将子事务划分为部分的划分点，比如，以上述的B向A转账为例，有三个类别且实现的各功能是提交订单、实施转账操作和转账成功通知，那么将该子事务至少划分为三个部分。如果A和B对应的是同一个银行，那么可以将该子事务划分为三个部分，如果A和B对应的不是同一个银行，那么可以将该子事务划分为四个部分。
步骤S323，根据每一子事务实现的各功能，确定N个部分之间的关联关系，以形成具有关联关系的N个部分。
比如，以上述的B向A转账为例，基于这三个功能(即提交订单、实施转账操作和转账成功通知)，将子事务划分为三个部分，并确定这三个部分之间的关联关系。
在一些实施例中，为了保证对于多个子事务处理的一致性，所述步骤S303包括以下两种情况：
情况一：如果所述至少两个子事务之间是独立的，按照所述关联关系对每一所述子事务的N个部分进行处理，得到所述N个部分中最后被执行的部分的处理结果。
在一些实施例中，所述至少两个子事务之间是独立的，即这些子事务之间没有交集，比如，一个子事务是实现通信，一个子事务是实现银行接口的调用，那么对于这样没有交集的子事务，可以不考虑子事务之间的处理顺序，对于每一子事务的多个部分，按照这些部分之间的关联关系，对这多个部分进行处理，以得到最后被执行部分的处理结果。
情况二：首先，如果所述至少两个子事务之间存在交集，按照所述交集和预设白名单，确定所述至少两个子事务之间的处理路径。
在一些实施例中，以待处理事务为腾讯计费为例，一个子事务是产品批价，一个子事务是订单支付，一个子事务是发货，那么这三个子事务之间是存在交集的，即，需要先进行产品批价，基于产品批价的结果实现订单支付，最后，基于订单支付的结果实现发货成功或者失败。所述预设的白名单可以认为是实现设定的事务之间的合理的处理路径，比如，需要是先进行订单支付再进行发货，如果是先进行发货，后进行订单支付，则确定这一处理路径不满足预设白名单。
然后，按照所述处理路径，依次对每一子事务的N个部分按照所述关联关系进行处理，以得到每一所述子事务的处理结果。
比如，按照该处理路径，首先确定需要执行的第一个子事务，对于该第一个子事务的多个部分按照所述关联关系进行处理，以得到第一个子事务的处理结果；然后，基于第一个子事务的处理结果，对第二个子事务的多个部分按照所述关联关系进行处理，以得到第二个子事务的处理结果；依次类推，对所有子事务按照该处理路径处理完毕，得到待处理事务的最终处理结果。如此，通过对多个子事务划分为多个部分进行处理，保证了子事务的实时一致性。通过引入白名单机制，保证多个子事务之间状态流转的合理性。
在一个具体例子中，如果所述子事务所属的网络接口的类别集合中包含M个类别， 将所述子事务划分为至少M个部分，M为大于1的整数，所述步骤S303可以通过以下步骤实现：
第一步，根据所述关联关系，确定所述至少M个部分之间的串行执行顺序。
比如，以B向A转账为例，若划分为三个部分：创建转账订单，执行转账操作和转账结果，确定这三个部分之间的执行顺序。
第二步，按照所述串行执行顺序，基于所述至少M个部分在所述串行执行顺序中的第M-1个部分的处理结果，执行所述至少M个部分在所述串行执行顺序中的第M个部分，以得到最后被执行的部分的处理结果。
比如，先执行创建转账订单，得到创建成功的转账订单；然后，基于该转账订单，执行B向A转账；最后，判断该结果是成功还是失败，以通知用户。
在本申请实施例中，通过上述第一步至第四步实现了单个子事务的处理流程，按照多个部分之间的执行顺序对这多个部分进行逐一执行，以得到该子事务的处理结果；从而提高了事务的处理速度。
在一些实施例中，在对于多个子事务进行处理的过程中，对于发生异常的异常子事务，将待处理事务的当前事务状态存储在消息中间件中，提高了数据层的可靠性，而且保证存储的数据不会丢失，在步骤S305之前，所述方法还包括以下步骤，如图4所示，图4是本申请实施例提供的事务处理方法的另一实现流程示意图，结合图3进行以下说明：
步骤S401，采用处理策略对异常子事务进行处理的结果，确定新的处理结果。
比如，该异常子事务为发货失败，那么相匹配的处理策略为继续为已付款成功的用户进行发货，得到新的发货结果。
步骤S402，如果新的处理结果异常子事务仍处于异常状态，确定当前已处理的子事务的处理结果集合。
步骤S403，采用消息中间件，存储处理结果集合。
比如，如果新的发货结果表明仍然是发货失败，那么说明可能是当前网络出现故障，这样的情况下，为了保证事务消息不丢，先确定当前已处理的子事务的处理结果集合，即待处理事务的当前事务状态信息，然后，将该当前事务状态信息存储在消息中间件中，提高了数据层的高可靠性。
步骤S404，当接收到输入的读取指令时，从消息中间件中读取处理结果集合，并继续对异常子事务的N个部分进行处理，以得到待处理事务的最终处理结果。
在一些实施例中，所述接收到输入的读取指令可以理解为，当需要继续对待处理事 务进行处理时，比如，网络从异常状态变为正常状态，那么从该消息中间件中，利用消息订阅机制实现事务的恢复，继续对异常子事务的多个部分进行处理，以得到正常的处理结果。
在一些实施例中，对于不同资源相混合的待处理事务，为了保证这样的待处理事务中不同资源的子事务的一致性，所述方法以下步骤实现。
第一步，确定实现所述待处理事务需要调用的资源接口集合。
在一些实施例中，以待处理事务为腾讯计费为例，实现该事务需要调用的资源接口集合至少包括：实现产品批价的资源接口，实现订单支付的用户端资源接口，实现发货的资源接口等。
第二步，将待处理事务划分为与资源接口集合相匹配的多个子事务。
比如，将腾讯计费划分为与实现产品批价的资源接口，实现订单支付的用户端资源接口，实现发货的资源接口相匹配的三个子事务。
第三步，响应于接收到的处理执行指令，启动每一资源接口。
在一些实施例中，当接收到需要对待处理事务进行处理的处理执行指令时，进入分布式事务(外部XA)能力事务第一阶段，即启动每一个资源接口，以促使每一个资源接口做好处理子事务的准备工作。
第四步，当接收到资源接口的反馈的准备完成信息时，在资源接口中对相匹配的子事务的N个部分按照关联关系进行处理，以得到N个部分中最后被执行的部分的处理结果。
在一些实施例中，当资源接口准备完成之后，向处理器反馈准备完成信息，在资源接口中对相匹配的子事务进行处理，得到处理结果，然后进入分布式事务(外部XA)能力的第二阶段，即对于处理结果进行提交，并向用户反馈处理完成的通知信息；这样，通过采用多个资源接口对多个子事务进行处理，保证了不同子事务的一致性。
下面，将说明本申请实施例在一个实际的应用场景中的示例性应用，以对计费场景下的长事务进行处理为例，进行说明。
在一些实施例中，一般事务可以通过数据库的本地事务来保证。比如，在MySQL默认可重复读(Repeatable read，RR)的隔离级别下，当事务A在操作数据且提交或回滚前，其他事务不能看到事务A对数据的修改。对于短事务而言，数据库锁的时间比较短，而对于长事务，如果事务不提交将会导致操作相同资源的请求阻塞或处理超时。因此，长事务一般不适合直接使用数据库事务实现。在一些实施例中，将一个长事务分解成一串子 事务序列并依次执行，若其中某子事务执行失败，则对之前执行成功的子事务执行相应的补偿事务。其中，每个子事务都是作为本地数据库事务提交，并通过另一个后台服务(Daemon)保证整个长事务的原子性。如此，在保证长事务一致性的基础上，解决了传统基于数据库的长事务性能低的问题，从而能够改善整体服务的性能。处理过程如图5所示，图5是本申请实施例提供的事务处理系统的框架图，结合图5进行以下说明：
首先，启动处理流程51，将长事务分为多个子事务501、502、50j和50n，对应于T 1至T n，其中，C 151和C 252为子事务501至50n对应的补偿事务。通过对多个子事务501至50n进行处理，若均执行成功，则结束流程52；对于执行失败的子事务，采用补偿事务进行补偿，当执行成功时，结束流程53。
由此可见，实现图5所示的方案需要具备以下两个条件：
条件1：需要DBMS的事务特性支持。
条件2：能够将一个长事务可以分解为多个子事务。
执行过程如下：
(1)假设将一个长事务T分解为多个子事务{T 1，T 2，···，T N}，每个子事务都是相对独立的，且可以保证原子性。
(2)为了保证整个长事务T的原子性，若出现部分执行成功的情况，每个子事务需要提供对应的补偿事务{C 1，C 2，···，C N}。因此，长事务执行的序列如下：(其中，0≤j≤N)
正常执行序列：T 1，T 2，···，T j，···，T N；
异常执行序列：T 1，T 2，···，T j，···，C j，···，C 2，C 1；
(3)每个子事务的执行是相互独立的，在长事务执行过程中，不具备事务隔离性，事务的中间状态可以被外部读取。
(4)应用程序通过开启事务(begin-saga)命令字开启一个长事务并生成一个唯一事务标识(ID)，通过开始处理(begin-transaction)和结束处理(end-transaction)命令字定义每个子事务的边界，最后通过结束事务(end-saga)命令字完成整个事务的提交。
(5)在执行每个子事务时，会同时将当前子事务的状态信息作为一个数据库本地事务提交保存。与数据库事务异常(比如，宕机(Crash))处理机制不同，数据库事务在出现异常时通过回滚日志(undo log)可以对事务进行自动回滚。而处理异常的机制是，需要应用程序通过信息中继(Message Relay)服务saga后台服务(saga daemon)继续完 成后续子事务(forward recovery)，或者执行补偿事务(backward recovery)，以保证长事务的原子性。如图6所示，图6是本申请实施例提供的长事务处理的另一框架图，结合图6进行以下说明：
第一步，将应用程序(Application，APP)61输出的待处理事务，划分为多个子事务T 162、T 263至T N64。
在一些实施例中，APP 61向系统服务69输出待处理事务。该待处理事务为长事务。该多个子事务T 162、T 263至T N64之间可以是独立的，也可以是存在串联关系的。
第二步，对于每个业务操作同时记录下来，以保证两个操作的一致性。
在一些实施例中，在执行每一个事务时，因为是基于数据库进行的，所以要保证每一个操作和基于的事务是一致性的；其中，APP表65表示业务的逻辑，处理事件表66配置为表明事务的状态信息，整体思路为，需要完成业务操作的时候，同时会把整个事务的操作同时都记录下来，这样，以保证两个表是要么全部执行要么全部失败，即是表明两个操作是同时生效的。
第三步，基于表66，确定执行完子事务T 162之后下一个待执行的子事务，采用信息中继67(message delay)驱动执行该待执行的子事务。
在一些实施例中，信息中继67用于一个子事务执行完之后，驱动去执行下一个子事务。
第四步，将该待执行的子事务进行发布到系统中，以使继续执行该子事务。在一些实施例中，数据库68表示数据库存储。
由此可见，由于子事务的提交依赖数据库本地事务，整体服务的性能受限于单机数据库的处理能力；而且长事务的状态需要和业务的数据库操作作为一个本地数据库事务提交，对业务数据库存在侵入性；对于一些无法提供补偿事务的操作，存在一定的使用限制。
在本申请实施例中，基于腾讯计费的应用场景，进行以下说明，首先，腾讯计费是孵化于支撑腾讯内部业务千亿级营收的互联网计费平台，在如此庞大的业务体量下，腾讯计费要支撑业务的快速增长，同时还要保证每笔交易不错账。然而腾讯计费的一笔交易流程通常涉及几十次的网络调用，在分布式场景下要满足ACID，保证所有操作均执行成功才提交结果，随着分布式规模的扩大要达成一致性的时间周期也就越长。比如，比特币网络的可扩展性(Scalability)问题，为了满足一致性一笔交易的平均确认时间需要10分钟。因此，为了适应复杂的业务场景出现了Base理论，使用最终一致性来代替强一 致性。然而，对于腾讯计费日均过亿的交易量，采用最终一致性或离线补偿性的方案往往会带来较多的处理风险及投诉，需要做到实时的一致性。因此，本申请实施例提供一种事务处理方法，将复杂的分布式一致性问题交给引擎平台处理，主要实现分布式事务的原子性，保证交易实时高一致；自动的异常处理，提高容错性；以及基于状态机的流程管理，加强流程的可约束性。其中，长事务在腾讯计费是指，一次完整的交易流程，通常包括，用户登录态校验，风控检查，原始物品批价，营销活动批价，用户支付，物品发货，活动赠送等流程，需要保证整体流程的一致性，做到全部成功或者全部失败。通过引入有限状态机(Finite State Machine，FSM)和可靠的消息中间件实现基于应用层的长事务。
图7是本申请实施例提供的事务处理方法的实现流程示意图，结合图7进行以下说明：
首先，发起方接收APP端700提交的待处理事务，并将该待处理事务划分为多个子事务T 1 701，T 2 702和T N703。
在一些实施例中，发起方基于算子条件1确定执行子事务T 1 701之后，执行T 2 702；基于算子条件3，确定执行子事务T 1 701之后，执行T N 703；即算子条件2确定执行子事务T 2 702之后，执行T N 703。资源方可以理解为数据库或者网络接口的调用。箭头71和72分别表示子事务执行失败的话，进行一个逆向操作。
然后，向资源方73发送启动信息，以使资源方对一个子事务T 1 701开始处理。
在一些实施例中，把一个子事务分为三个独立部分(即准备远程过程调用协议(prepare-Remote Procedure Call Protocol，pre-rpc)704，rpc 705和提交rpc(post-rpc)706)，若其中某个子事务在处理过程中发生异常，事务恢复可以由业务根据rpc应答的结果信息，通过多种算子条件(Conditions)组合指定采取forward recovery还是backward recovery。
再次，按照每一个部分之间的关联关系，执行每一个部分，并将最后被执行的部分的处理结果反馈给资源方74。
最后，向资源方75反馈子事务T 1 701执行完成，并最终反馈给APP端700。
在本申请实施例中，通过引入FSM白名单机制，保证交易状态流转的合理性。例如，不会出现已经支付的订单，被再次提交支付。图8是本申请实施例提供的长事务流程状态的执行路径图，如图8所述，节点中的数字表示某种执行状态，其中，比如，01表示初始化，50表示批价成功，100表示下单成功，那么批价成功之后，就要进行下单，100就表示提交了一笔支付，表示调用微信支付这个窗口调用成功了，比如，给微信弹出一个弹窗，让用户输入密码，用于可以输入也可以不输入，如果输入就支付成功进入101支付成 功，然后就到610表示发货成功，901表示发货失败；205表示没有支付未成功；601表示用户发起退款，602表示给用户退款成功；602到910的箭头表示，退款成功之后，会同时更新支付单的状态，然后标记该支付单已经发起退款。实线路径表示可以正常执行的路径，而虚线路径801表示受限的执行路径(即，节点50不能直接流转到节点901，即批价到发货失败是不合理的状态流转，中间需要经过支付完成状态节点101)。如此，长事务内部执行会分为多步操作，并且有些步骤是有先后顺序的，因此需要做到对状态流程可约束，通过有限状态机白名单的方式可以控制事务流程合理的流转执行。
在本申请实施例中，通过采用高可靠消息中间件(pub-sub)，将事务的状态存储在消息中间件中，并通过消息订阅机制实现事务的恢复。如此，解决了业务侵入性的问题，可以应用在更多的场景，同时提供了灵活的订阅能力，使得并发处理能力更高，延迟也在毫秒级，比较适合在线长事务的处理场景。如图9所示，图9是本申请实施例提供的事务处理方法的另一实现流程示意图，结合图9进行以下说明：
首先，APP端91向系统服务92提交待处理事务。
然后，系统服务92对待处理事务中的子事务T 193进行处理，基于条件算子1，确定执行完T 193之后，执行子事务T 294，以此类推，顺序执行每一个子事务，直至执行最后一个子事务T N95，以对该待处理事务处理完成，得到最终的处理结果。
在一些实施例中，在处理这些子事务的过程中，可以将处理子事务T 193的事务状态保存在事务状态存储区96中，并且从事务状态存储区96还可以向系统服务反馈T 193的事务状态。同理，将处理子事务T 294的事务状态保存在事务状态存储区97中，并且从事务状态存储区97还可以向系统服务反馈T 294的事务状态；将处理子事务T N95的事务状态保存在事务状态存储区98中，并且从事件存储区98还可以向系统服务反馈T N95的事务状态。
图10是本申请实施例消息中间件存储事务状态的实现流程示意图，如图10所示，APP11、APP 12和APPN 13分别用于提交待处理事务。在一个具体例子中，如果APP12提交的待处理事务在处理过程中出现异常，那么可以将APP12提交的待处理事务的事务状态存储在消息中间件1004中，在该消息中间件1004中，包括生产端1005和消费端1006，其中，生产端1005用于将存储的事务状态进行入队，消费端1006用于将存储的事务状态进行出队。接下来，对于消息中间件中的要存储的事务状态，因为强调的是高可靠的消息件，要保证消息存储下来不会丢失，所以基于作为底层存储的控制分发器1007(dispatcher)，在接收请求之后，控制分发器1007根据请求，确定将事务状态存储在哪里，在该控制分发器1007底层存储中包括计算引擎1008(broker)，和存储引擎1009 (bookkeeper，BK)，以及分布式协调件1010(zookeeper)。在计算引擎1008中通过负载均衡1011(load balance)、管理分类1012(managed ledger)、存储器1013(cache)和BK客户端1014，来确定请求存储的事务状态如何存储。总体来说，控制分发器1007实现的是计算和存储的分离，即计算这个事务状态怎么存储，存储在哪里，存储是指存储引擎1009保证事务状态的高可靠的存储。
在本实施例中，高可靠的消息中间件。为了保证事务消息不丢，消息中间件在数据层是基于多副本的方式，保证数据层的高可靠；另外，在生产端通过WAL顺序写日志的方式，提高了系统的处理能力，可以达到毫秒级的延迟；在架构上通过计算和存储分离的方式，可以灵活的水平扩展；最后，为了便于管理我们实现了一套易于操作的管理台，可以实现对任意时刻执行的事务进行查看。
在一些实施例中，在腾讯计费的实际业务场景中，一次交易处理过程处理调用RPC接口还可能会直接操作数据库或其他资源接口。以用户转账为例：一次转账操作流程，涉及了图11中的三个步骤。图11是本申请实施例实现转账请求的实施流程示意图，结合图11进行以下说明：
第一步，对于APP端1101提交的转账请求，计入订单服务1102，以创建转账订单。
第二步，订单创建完成之后，进入DB服务1103，以执行转账DB操作，同时对用户的DB数据进行修改。
在一些实施例中，执行转账操作的过程中对于需要调用两个不同网络接口的情况，需要通过两个组1104和1105来实现。在组1104和1105中M和S分别表示：数据库一套设置中的主和备。在一个具体例子中，用户A给用户B转账，但是两个用户的开户行不同，一个建设银行一个工商银行，这两个银行的数据存储是不在一个服务器上的，这种情况下，通过采用两个组1104和1105，实现不同银行之间的转账。
第三步，转账完成后，进入通知服务1106，以生成转账成功信息，进行转账成功通知，并将转账成功信息返回给APP端1101。
在一些实施例中，虚线1107和虚线1108分别表示当前步骤失败时，进行数据回滚。
在本实施例中，消息中间件的读写性能高于数据库的处理性能，并通过本地存储和远程高一致消息中间件相结合的方式保证事务消息不丢失。长事务的状态信息通过消息中间件进行持久化存储，不需要与业务的存储耦合，通过pub-sub的方式驱动整个事务的执行，保证了数据库的无侵入性。
在一些实施例中，由于数据库的事务是基于连接的，连接断开事务就会回滚，所以 假设这样几个场景：
场景1：若DB事务先提交成功，其他事务失败了。
场景2：若其他事务先提交成功，此时DB连接断了。
场景3：若其他事务先提交成功，此时DB部分成功，部分失败。
场景4：若存在某个异步服务，此时DB操作提交还是不提交。
由此可见，当长事务中涉及DB操作时，很难实现或提供补偿事务操作，例如，一些复杂的SQL操作无法实现对应的反操作。从而无法实现长事务的一致性处理。当上面四种场景出现时，都会发生子事务部分提交部分失败的情况。因此，为了解决上面的问题，本申请实施例结合MySQL外部XA能力，实现了原生的分布式事务。由于MySQL提供了外部XA事务的能力，允许准备成功的事务跨连接。通过两个阶段提交的方式来实现跨数据库的分布式事务。由于对业务SQL不存在限制，使用场景更广。下面以转账为例来说明长事务中涉及混合资源操作时是保证不同子事务一致性的过程，如图12所示，图12是本申请实施例提供的事务处理方法的实现流程示意图，结合图12进行以下说明：
步骤S1201，开启事务。
在一些实施例中，APP端向中间件服务引擎(TDXA)发送开启事务的指令；APP端发起转账请求给TDXA，TDXA用于实现一致性的中间件服务引擎。
步骤S1202，创建转账订单。
在一些实施例中，Try表示创建订单，创建订单服务(order service)之后，发起sql转账操作，进入转账操作的第一阶段。
步骤S1203，向数据库1发送sql指令“xa start xd1”。
在一些实施例中，sql1，对子事务T1进行更新，可以通过sql语句“@sql1＝update T1 set balance＝balance+10 where user＝'g1'”实现。sql2，对子事务T1再次进行更新，可以通过sql语句“@sql2＝update T1 set balance＝balance-10 where user＝'g2'and balance>＝10”实现。
步骤S1204，向数据库2发送sql指令“xa start xd2”。
在一些实施例中，通过分别向数据库1和数据库2发送sql指令“xa start xd1”和“xa start xd2”(其中，这两个sql指令作为协调者，用于保证双方数据库达成一致，以使数据库1和数据库2都准备就绪)，保持数据库1和数据库2处理事务的一致性。
步骤S1205，向数据库1发送sql指令“xa prepare xd1”。
步骤S1206，向数据库2发送sql指令“xa prepare xd2”。
在一些实施例中，通过分别向数据库1和数据库2发送sql指令“xa prepare xd1”和“xa prepare xd2”，使得两个DB均准备就绪，以对事务的处理，即对转账订单进行处理。
步骤S1207，确定转账结果，并向用户发送通知消息。
在一些实施例中，可以采用“do”获取转账结果，如果order service在创建转账订单的过程中失败了，对该创建的订单重新设置状态，比如，创建订单完成时，设定的状态为1，如果失败了就修改该订单的状态；do的意思是通知用户转账失败或者成功。在本实施例中，如果订单创建成功，但是转账结果失败，就要把创建的订单的状态改成订单失效。完成步骤S1207之后，进入多个事务之间状态的第二阶段。
在其他实施例中，数据库事务处理过程中，在需要回滚的场景下，通过记录sql的undo log方式进行逆向操作(例如，a＝a+1的逆向操作是a＝a-1)。除了使用数据库作为存储介质，也可以采用本地文件作为存储，比如，按行存储每一个子事务的状态信息，然后通过一个异步发货检查文件中的事务状态信息以决定后续的操作。
步骤S1208，对前述步骤进行确认。
在一些实施例中，多个事务之间状态的第二阶段，把前面步骤S1201至步骤S1207中已经协商好的协议进行确认。
步骤S1209，向数据库1发送“xa commit xid1”，和向数据库2发送“xa commit xid2”。
在一些实施例中，通过分别向数据库1和数据库2发送“xa commit xid1”和“xa commit xid2”，确认数据库1和数据库2对最后的处理结果(比如，转账成功)进行提交，已反馈给APP端。
步骤S1210，向APP端返回事务结束消息。
在本申请实施例中，支持多种不同资源的事务类型，应用场景更广，一个长事务流程可能涉及RPC数据库，KV等多种资源操作，需要做到混合资源操作的一致性，实现了通用性。
下面继续说明本申请实施例提供的事务处理的服务器455的实施为软件模块的示例性结构，在一些实施例中，如图2B所示，存储在存储器450的事务处理的服务器455中的软件模块可以包括：第一划分模块4551，配置为将从数据库获取的待处理事务，划分为至少两个子事务；第二划分模块4552，配置为按照每一子事务所属的网络接口和所述子事务实现的各功能，将每一所述子事务划分为具有关联关系的N个部分，N为大于1的整数；第一处理模块4553，配置为按照所述关联关系对每一所述子事务的N个部分进行处理，得到所述N个部分中最后被执行的部分的处理结果；第一确定模块4554，配置为如果根据 所述处理结果确定出有异常子事务，确定与所述异常子事务的异常原因相匹配的处理策略；第二处理模块4555，配置为采用所述处理策略对所述异常子事务进行处理，以得到所述待处理事务的最终处理结果。在一些实施例中，所述第一划分模块4551，还配置为：确定每一所述子事务所属的网络接口的类别集合；根据所述网络接口的类别集合和对应子事务实现的各功能，将所述对应子事务划分为N个部分；根据每一所述子事务实现的各功能，确定所述N个部分之间的关联关系，以形成具有关联关系的N个部分。在一些实施例中，所述第一处理模块4553，还配置为：如果所述至少两个子事务之间是独立的，按照所述关联关系对每一所述子事务的N个部分进行处理，得到所述N个部分中最后被执行的部分的处理结果。在一些实施例中，所述第一处理模块4553，还配置为：如果所述至少两个子事务之间存在交集，按照所述交集和预设白名单，确定所述至少两个子事务之间的处理路径；按照所述处理路径，依次对每一子事务的N个部分按照所述关联关系进行处理，以得到每一所述子事务的处理结果。在一些实施例中，如果所述子事务所属的网络接口的类别集合中包含M个类别，将所述子事务划分为至少M个部分，M为大于1的整数，所述第一处理模块4553，还配置为：根据所述关联关系，确定所述至少M个部分之间的串行执行顺序；按照所述串行执行顺序，基于所述至少M个部分在所述串行执行顺序中的第M-1个部分的处理结果，执行所述至少M个部分在所述串行执行顺序中的第M个部分，以得到最后被执行的部分的处理结果。在一些实施例中，所述第一处理模块4553，还配置为：采用所述处理策略对所述异常子事务进行处理的结果，确定新的处理结果；如果所述新的处理结果所述异常子事务仍处于异常状态，确定当前已处理的子事务的处理结果集合；采用消息中间件，存储所述处理结果集合；当接收到输入的读取指令时，从所述消息中间件中读取所述处理结果集合，并继续对异常子事务的N个部分进行处理。在一些实施例中，所述第二处理模块4555，还配置为：如果所述异常原因为用户端在处理所述异常子事务时发生异常，将所述异常子事务的上一个子事务的处理结果作为所述异常子事务的处理结果；如果所述异常原因为服务器端在处理所述异常子事务时发生异常，按照所述关联关系再次对所述异常子事务的N个部分进行处理。在一些实施例中，所述第一划分模块4551，还配置为：确定实现所述待处理事务需要调用的资源接口集合；将所述待处理事务划分为与资源接口集合相匹配的多个子事务；对应地，响应于接收到的处理执行指令，启动每一资源接口；当接收到资源接口的反馈的准备完成信息时，在所述资源接口中对相匹配的子事务的N个部分按照所述关联关系进行处理，以得到所述N个部分中最后被执行的部分的处理结果。
本申请实施例提供一种存储有可执行指令的存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法。在一些实施例中，存储介质可以是闪存、磁表面存储器、光盘、或光盘存储器等存储器；也可以是包括上述存储器之一或任意组合的各种设备。在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(Hyper Text Markup Language，HTML)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。作为示例，可执行指令可被部署为在一个车载计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备执行。综上所述，本申请实施例在对长事务进行处理的过程中，对于待处理事务，通过基于子事务所属的网络接口将子事务划分成多个部分，针对每一部分进行处理，对于处理结果异常的异常子事务，解决了整体服务的性能受限于单机数据库的处理能力的问题；基于异常原因选择匹配的处理策略对异常子事务进行处理，以得到最终的处理结果；如此，自动对异常子事务采用匹配的处理策略进行处理，提高了容错性以及处理事务的能力。以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。
工业实用性
本申请实施例中，将从数据库获取的待处理事务，划分为至少两个子事务；按照每一子事务所属的网络接口和所述子事务实现的各功能，将每一所述子事务划分为具有关联关系的N个部分；按照所述关联关系对每一所述子事务的N个部分进行处理，得到所述N个部分中最后被执行的部分的处理结果；如果根据所述处理结果确定出有异常子事务，确定与所述异常子事务的异常原因相匹配的处理策略；采用所述处理策略对所述异常子事务进行处理，以得到所述待处理事务的最终处理结果；这样，通过自动化部署的方式，采用匹配的处理策略处理异常子事务，提高了容错性以及处理事务的能力。

Claims (11)

  1. 一种事务处理方法，所述方法应用于事务处理的设备，所述方法包括：
    将从数据库获取的待处理事务，划分为至少两个子事务；
    按照每一子事务所属的网络接口和所述子事务实现的各功能，将每一所述子事务划分为具有关联关系的N个部分，N为大于1的整数；
    按照所述关联关系对每一所述子事务的N个部分进行处理，得到所述N个部分中最后被执行的部分的处理结果；
    如果根据所述处理结果确定出有异常子事务，确定与所述异常子事务的异常原因相匹配的处理策略；
    采用所述处理策略对所述异常子事务进行处理，以得到所述待处理事务的最终处理结果。
  2. 根据权利要求1所述的方法，其中，所述按照每一子事务所属的网络接口和所述子事务实现的各功能，将每一所述子事务划分为具有关联关系的N个部分，包括：
    确定每一所述子事务所属的网络接口的类别集合；
    根据所述网络接口的类别集合和对应子事务实现的各功能，将所述对应子事务划分为N个部分；
    根据每一所述子事务实现的各功能，确定所述N个部分之间的关联关系，以形成具有关联关系的N个部分。
  3. 根据权利要求1所述的方法，其中，所述按照所述关联关系对每一所述子事务的N个部分进行处理，得到所述N个部分中最后被执行的部分的处理结果，包括：
    如果所述至少两个子事务之间是独立的，按照所述关联关系对每一所述子事务的N个部分进行处理，得到所述N个部分中最后被执行的部分的处理结果。
  4. 根据权利要求3所述的方法，其中，所述按照所述关联关系对每一所述子事务的N个部分进行处理，得到所述N个部分中最后被执行的部分的处理结果，包括：
    如果所述至少两个子事务之间存在交集，按照所述交集和预设白名单，确定所述至少两个子事务之间的处理路径；按照所述处理路径，依次对每一子事务的N个部分按照所述关联关系进行处理，以得到每一所述子事务的处理结果。
  5. 根据权利要求2所述的方法，其中，如果所述子事务所属的网络接口的类别集合 中包含M个类别，将所述子事务划分为至少M个部分，M为大于1的整数，所述按照所述关联关系对每一所述子事务的N个部分进行处理，得到所述N个部分中最后被执行的部分的处理结果，包括：
    根据所述关联关系，确定所述至少M个部分之间的串行执行顺序；
    按照所述串行执行顺序，基于所述至少M个部分在所述串行执行顺序中的第M-1个部分的处理结果，执行所述至少M个部分在所述串行执行顺序中的第M个部分，以得到最后被执行的部分的处理结果。
  6. 根据权利要求1至5任一项所述的方法，其中，在所述采用所述处理策略对所述异常子事务进行处理，以得到所述待处理事务的最终处理结果之前，所述方法还包括：
    采用所述处理策略对所述异常子事务进行处理的结果，确定新的处理结果；
    如果所述新的处理结果所述异常子事务仍处于异常状态，确定当前已处理的子事务的处理结果集合；
    采用消息中间件，存储所述处理结果集合；
    当接收到输入的读取指令时，从所述消息中间件中读取所述处理结果集合，并继续对异常子事务的N个部分进行处理，以得到所述待处理事务的最终处理结果。
  7. 根据权利要求1所述的方法，其中，所述如果根据所述处理结果确定出有异常子事务，确定与所述异常子事务的异常原因相匹配的处理策略，包括：
    如果所述异常原因为用户端在处理所述异常子事务时发生异常，将所述异常子事务的上一个子事务的处理结果作为所述异常子事务的处理结果；
    如果所述异常原因为服务器端在处理所述异常子事务时发生异常，按照所述关联关系再次对所述异常子事务的N个部分进行处理。
  8. 根据权利要求1所述的方法，其中，所述将从数据库获取的待处理事务，划分为至少两个子事务，包括：
    确定实现所述待处理事务需要调用的资源接口集合；
    将所述待处理事务划分为与资源接口集合相匹配的多个子事务；
    对应地，响应于接收到的处理执行指令，启动每一资源接口；
    当接收到资源接口的反馈的准备完成信息时，在所述资源接口中对相匹配的子事务的N个部分按照所述关联关系进行处理，以得到所述N个部分中最后被执行的部分的处理结果。
  9. 一种事务处理装置，其中，所述装置包括：
    第一划分模块，配置为将从数据库获取的待处理事务，划分为至少两个子事务；
    第二划分模块，配置为按照每一子事务所属的网络接口和所述子事务实现的各功能，将每一所述子事务划分为具有关联关系的N个部分，N为大于1的整数；
    第一处理模块，配置为按照所述关联关系对每一所述子事务的N个部分进行处理，得到所述N个部分中最后被执行的部分的处理结果；
    第一确定模块，配置为如果根据所述处理结果确定出有异常子事务，确定与所述异常子事务的异常原因相匹配的处理策略；
    第二处理模块，配置为采用所述处理策略对所述异常子事务进行处理，以得到所述待处理事务的最终处理结果。
  10. 一种事务处理的设备，其中，包括：
    存储器，配置为存储可执行指令；
    处理器，配置为执行所述存储器中存储的可执行指令时，实现权利要求1至8任一项所述的方法。
  11. 一种存储介质，其中，存储有可执行指令，配置为引起处理器执行时，实现权利要求1至8任一项所述的方法。
PCT/CN2020/121033 2019-12-03 2020-10-15 事务处理方法、装置、设备及计算机存储介质 WO2021109719A1 (zh)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2021509740A JP7142152B2 (ja) 2019-12-03 2020-10-15 トランザクション処理方法、装置、機器並びにコンピュータプログラム
EP20851368.9A EP4071610A4 (en) 2019-12-03 2020-10-15 TRANSACTION PROCESSING METHOD, EQUIPMENT AND DEVICE AND COMPUTER STORAGE MEDIUM
SG11202102157UA SG11202102157UA (en) 2019-12-03 2020-10-15 Transaction processing method, apparatus, and device and computer storage medium
KR1020217002929A KR102510195B1 (ko) 2019-12-03 2020-10-15 트랜잭션 처리 방법, 장치 및 기기, 그리고 컴퓨터 저장 매체
US17/170,207 US11544245B2 (en) 2019-12-03 2021-02-08 Transaction processing method, apparatus, and device and computer storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201911223449.3 2019-12-03
CN201911223449.3A CN110990182B (zh) 2019-12-03 2019-12-03 事务处理方法、装置、设备及存储介质

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/170,207 Continuation US11544245B2 (en) 2019-12-03 2021-02-08 Transaction processing method, apparatus, and device and computer storage medium

Publications (1)

Publication Number Publication Date
WO2021109719A1 true WO2021109719A1 (zh) 2021-06-10

Family

ID=70089740

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/121033 WO2021109719A1 (zh) 2019-12-03 2020-10-15 事务处理方法、装置、设备及计算机存储介质

Country Status (6)

Country Link
EP (1) EP4071610A4 (zh)
JP (1) JP7142152B2 (zh)
KR (1) KR102510195B1 (zh)
CN (1) CN110990182B (zh)
SG (1) SG11202102157UA (zh)
WO (1) WO2021109719A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113724082A (zh) * 2021-08-30 2021-11-30 上海浦东发展银行股份有限公司 账务处理方法、装置、设备及存储介质
CN114741254A (zh) * 2022-02-21 2022-07-12 驼驼数字科技(北京)有限公司 监控跨境电商平台支付成功率的方法、系统、计算设备和存储介质
CN117667319A (zh) * 2024-02-02 2024-03-08 建信金融科技有限责任公司 一种事务处理方法和装置

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110990182B (zh) * 2019-12-03 2021-06-11 腾讯科技（深圳）有限公司 事务处理方法、装置、设备及存储介质
US11544245B2 (en) 2019-12-03 2023-01-03 Tencent Technology (Shenzhen) Company Limited Transaction processing method, apparatus, and device and computer storage medium
CN111880908A (zh) * 2020-06-28 2020-11-03 北京沃东天骏信息技术有限公司 分布式事务的处理方法、装置及存储介质
CN112068810A (zh) * 2020-08-27 2020-12-11 北京五八信息技术有限公司 一种活动事件的处理方法、装置、电子设备及存储介质
CN112148528A (zh) * 2020-09-14 2020-12-29 北京同邦卓益科技有限公司 一种实现自动容错的方法和装置
CN113760924B (zh) * 2020-10-28 2024-06-14 北京沃东天骏信息技术有限公司 一种分布式事务的处理方法和装置
CN112559140B (zh) * 2020-12-17 2022-07-26 江苏满运物流信息有限公司 数据一致性的事务控制方法、系统、设备及存储介质
CN112732415B (zh) * 2021-01-06 2024-03-29 深圳华锐分布式技术股份有限公司 基于资源交换代理系统的事务处理方法、装置和设备
CN112835687B (zh) * 2021-01-22 2023-05-26 恒生电子股份有限公司 一种计算机事务处理方法及系统
CN113778631A (zh) * 2021-01-29 2021-12-10 北京沃东天骏信息技术有限公司 分布式事务补偿方法、装置、电子设备及可读存储介质
CN112882802B (zh) * 2021-02-01 2024-10-22 杭州云象网络技术有限公司 一种用于跨链的多链消息表事务处理方法及跨链系统
CN112766829A (zh) * 2021-03-16 2021-05-07 中国工商银行股份有限公司 一种业务处理方法、装置及设备
CN113127427B (zh) * 2021-04-21 2022-08-02 山东英信计算机技术有限公司 一种解析数据库日志中事务分布的方法、系统及装置
CN113989030A (zh) * 2021-11-05 2022-01-28 中国工商银行股份有限公司 跨行汇款方法、装置、电子设备、存储介质及程序产品
CN114090376A (zh) * 2021-11-09 2022-02-25 中国银联股份有限公司 一种基于联盟链系统的业务处理方法及装置
CN113986941A (zh) * 2021-11-26 2022-01-28 中国银行股份有限公司 事务批量处理方法及装置
CN115145697B (zh) * 2022-07-05 2023-07-25 中电金信软件有限公司 数据库事务的处理方法、装置及电子设备
CN115220877B (zh) * 2022-07-15 2023-06-13 中电金信软件有限公司 一种业务处理方法及装置
CN115981828B (zh) * 2023-02-09 2023-09-22 中国证券登记结算有限责任公司 一种业务消息处理方法和装置
CN116028245B (zh) * 2023-02-09 2023-10-13 中国证券登记结算有限责任公司 一种基于消息中间件的业务消息处理方法和装置
CN116578395B (zh) * 2023-07-13 2024-04-05 腾讯科技（深圳）有限公司 事务处理方法、系统、装置、电子设备及存储介质
CN116861200B (zh) * 2023-09-05 2023-12-29 中国民航信息网络股份有限公司 一种基于区块链的行李数据的处理方法、装置及设备
CN118349319B (zh) * 2024-06-18 2024-09-03 华能信息技术有限公司 一种分布式事务的管理方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102073540A (zh) * 2010-12-15 2011-05-25 北京新媒传信科技有限公司 分布式事务提交方法和装置
CN108415757A (zh) * 2018-02-02 2018-08-17 阿里巴巴集团控股有限公司 分布式事务处理方法及装置
US20190227723A1 (en) * 2016-12-13 2019-07-25 EMC IP Holding Company LLC Dual-splitter for high performance replication
CN110231980A (zh) * 2019-06-10 2019-09-13 世纪龙信息网络有限责任公司 分布式事务的处理方法、装置及事务处理器
CN110990182A (zh) * 2019-12-03 2020-04-10 腾讯科技（深圳）有限公司 事务处理方法、装置、设备及存储介质

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06223007A (ja) * 1993-01-22 1994-08-12 Hitachi Ltd ２フェーズコミット制御方法
JPH06243072A (ja) * 1993-02-17 1994-09-02 Hitachi Ltd 分散処理システムの分散トランザクションコミット制御方式
JPH10232809A (ja) * 1996-12-16 1998-09-02 N T T Data Tsushin Kk トランザクション処理システム
US8347292B2 (en) * 2007-08-30 2013-01-01 International Business Machines Corporation Transaction aggregation to increase transaction processing throughout
US20130166523A1 (en) * 2011-12-21 2013-06-27 Sybase, Inc. Parallel Execution In A Transaction Using Independent Queries
KR101424568B1 (ko) * 2012-10-12 2014-08-01 (주)티베로 트랜잭션 재시작 가능한 클라이언트 장치와 데이터베이스 서버 및 방법
CN103647834B (zh) * 2013-12-16 2017-03-22 上海证券交易所 一种用于处理多阶段分布式任务调度的系统及方法
JP2016009423A (ja) 2014-06-26 2016-01-18 キヤノンマーケティングジャパン株式会社 情報処理装置、情報処理装置の制御方法、およびプログラム
CN104317850B (zh) * 2014-10-14 2017-11-14 北京国双科技有限公司 数据处理方法和装置
CN105988865B (zh) * 2015-03-04 2019-10-08 阿里巴巴集团控股有限公司 回滚处理方法及装置
KR102110027B1 (ko) * 2018-01-19 2020-05-12 전북대학교산학협력단 트랜잭셔널 메모리 분할 장치 및 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102073540A (zh) * 2010-12-15 2011-05-25 北京新媒传信科技有限公司 分布式事务提交方法和装置
US20190227723A1 (en) * 2016-12-13 2019-07-25 EMC IP Holding Company LLC Dual-splitter for high performance replication
CN108415757A (zh) * 2018-02-02 2018-08-17 阿里巴巴集团控股有限公司 分布式事务处理方法及装置
CN110231980A (zh) * 2019-06-10 2019-09-13 世纪龙信息网络有限责任公司 分布式事务的处理方法、装置及事务处理器
CN110990182A (zh) * 2019-12-03 2020-04-10 腾讯科技（深圳）有限公司 事务处理方法、装置、设备及存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4071610A4 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113724082A (zh) * 2021-08-30 2021-11-30 上海浦东发展银行股份有限公司 账务处理方法、装置、设备及存储介质
CN113724082B (zh) * 2021-08-30 2024-04-30 上海浦东发展银行股份有限公司 账务处理方法、装置、设备及存储介质
CN114741254A (zh) * 2022-02-21 2022-07-12 驼驼数字科技(北京)有限公司 监控跨境电商平台支付成功率的方法、系统、计算设备和存储介质
CN117667319A (zh) * 2024-02-02 2024-03-08 建信金融科技有限责任公司 一种事务处理方法和装置
CN117667319B (zh) * 2024-02-02 2024-05-03 建信金融科技有限责任公司 一种事务处理方法和装置

Also Published As

Publication number Publication date
KR102510195B1 (ko) 2023-03-14
SG11202102157UA (en) 2021-07-29
EP4071610A1 (en) 2022-10-12
CN110990182B (zh) 2021-06-11
KR20210071942A (ko) 2021-06-16
JP2022515949A (ja) 2022-02-24
CN110990182A (zh) 2020-04-10
JP7142152B2 (ja) 2022-09-26
EP4071610A4 (en) 2023-01-25

Similar Documents

Publication Publication Date Title
WO2021109719A1 (zh) 事务处理方法、装置、设备及计算机存储介质
US11243945B2 (en) Distributed database having blockchain attributes
US11070360B2 (en) Parallel transaction validation and block generation in a blockchain
US8185499B2 (en) System and method for transactional session management
US20190318338A1 (en) Network node management on a blockchain
US11544245B2 (en) Transaction processing method, apparatus, and device and computer storage medium
US20200319982A1 (en) Notification mechanism for disaster recovery events
US8898109B2 (en) Automatic transaction retry after session failure
CN103782574B (zh) 用于数据库事务的幂等性
US20200082025A1 (en) Atomically executed application program interfaces
US11720545B2 (en) Optimization of chaincode statements
US8352421B2 (en) Recording distributed transactions using probabalistic data structures
US7480816B1 (en) Failure chain detection and recovery in a group of cooperating systems
US11048598B2 (en) Enhanced disaster recovery procedure of applications in a cloud environment
CN103782573A (zh) 对客户端和应用掩盖服务器停运
US20230052935A1 (en) Asynchronous accounting method and apparatus for blockchain, medium and electronic device
CN110413687B (zh) 基于节点互证校验的分布式事务故障处理方法及相关设备
CN111414266B (zh) 一种分布式事务的同步异步通信方法和装置
AU2019371362B2 (en) Methods, devices and systems for non-disruptive upgrades to a distributed coordination engine in a distributed computing environment
JP7305898B2 (ja) 操作応答方法、操作応答装置、電子機器及び記憶媒体
WO2022206429A1 (zh) 一种分布式事务实现方法及分布式系统
CN112099879B (zh) 配置信息管理方法、装置、计算机设备及存储介质
CN105874435A (zh) 分布式事务中的非阻塞注册
US11348101B2 (en) Post-settlement processes
US20240184914A1 (en) Multiple synonymous identifiers in data privacy integration protocols

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2021509740

Country of ref document: JP

Kind code of ref document: A

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20851368

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020851368

Country of ref document: EP

Effective date: 20220704