Nothing Special   »   [go: up one dir, main page]

CN110288255A - A kind of logistics method and device of distributed transaction - Google Patents

A kind of logistics method and device of distributed transaction Download PDF

Info

Publication number
CN110288255A
CN110288255A CN201910580564.XA CN201910580564A CN110288255A CN 110288255 A CN110288255 A CN 110288255A CN 201910580564 A CN201910580564 A CN 201910580564A CN 110288255 A CN110288255 A CN 110288255A
Authority
CN
China
Prior art keywords
sub
processing
processes
subsystem
overtime
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
CN201910580564.XA
Other languages
Chinese (zh)
Inventor
张兵
夏勇
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
WeBank Co Ltd
Original Assignee
WeBank Co Ltd
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 WeBank Co Ltd filed Critical WeBank Co Ltd
Priority to CN201910580564.XA priority Critical patent/CN110288255A/en
Publication of CN110288255A publication Critical patent/CN110288255A/en
Priority to PCT/CN2019/118181 priority patent/WO2020258665A1/en
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q10/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063Operations research, analysis or management
    • G06Q10/0633Workflow analysis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02Banking, e.g. interest calculation or account maintenance
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Human Resources & Organizations (AREA)
  • Accounting & Taxation (AREA)
  • Economics (AREA)
  • Finance (AREA)
  • Marketing (AREA)
  • General Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Technology Law (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Educational Administration (AREA)
  • Tourism & Hospitality (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Game Theory and Decision Science (AREA)
  • Retry When Errors Occur (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

The present embodiments relate to field of computer technology more particularly to a kind of logistics method and devices of distributed transaction, to solve the problems, such as that distributed transaction exception handling lacks flexibility.The embodiment of the present invention includes: it receives the processing that calling system is sent and requests;It is requested to determine main flow and N number of sub-process, N >=1 according to processing;For any sub-process in N number of sub-process, sub-process is sent to corresponding subsystem, so that subsystem handles sub-process;The treatment process of N number of sub-process is monitored, when the treatment process of any sub-process occurs abnormal, corresponding abnormality processing strategy is determined according to Exception Type, main flow type and sub-process type;Abnormality processing carried out to sub-process according to abnormality processing strategy, abnormality processing includes having executed asymmetric reverse operating to having handled successful sub-process, and asymmetric reverse operating is to execute reversed sub-process, and reversed sub-process and processed sub-process are asymmetric.

Description

Flow guarantee method and device for distributed transaction
Technical Field
The invention relates to the technical field of computers in financial technology (Fintech), in particular to a flow guarantee method and a flow guarantee device for distributed transactions.
Background
With the continuous development of financial technologies, especially internet technology and finance, more and more technologies (such as distributed, Blockchain, artificial intelligence, etc.) are applied to the financial field, but the financial industry also puts higher requirements on the technologies, such as a transaction guarantee process for distributed transactions.
Distributed transactions provide a mechanism to incorporate all operations involved in an activity into an indivisible execution unit, and all operations that make up a transaction can only commit if all operations can execute normally, resulting in a rollback of the entire transaction if any of the operations fails to execute.
The conventional distributed transaction processing scheme usually rolls back the whole preprocessing logic in a reverse order from a sub-transaction failure point, and cannot achieve the flexibility and difference of forward processing logic.
Disclosure of Invention
The application provides a flow guarantee method and device for distributed transactions, which are used for solving the problem that a distributed transaction exception handling mechanism is lack of flexibility.
The method for guaranteeing the flow of the distributed transaction provided by the embodiment of the invention comprises the following steps:
receiving a processing request sent by a calling system;
determining a main process and N sub-processes according to the processing request, wherein N is more than or equal to 1;
aiming at any sub-process in the N sub-processes, sending the sub-process to a corresponding subsystem so that the subsystem processes the sub-process;
monitoring the processing processes of the N sub-processes, and determining a corresponding exception handling strategy according to the exception type, the type of the main process and the type of the sub-process when the processing process of any sub-process is abnormal;
and carrying out exception processing on the sub-processes according to the exception processing strategy, wherein the exception processing comprises the step of executing asymmetric reverse operation on the successfully processed sub-processes, the asymmetric reverse operation is the step of executing reverse sub-processes, and the reverse sub-processes are asymmetric to the processed sub-processes.
In an optional embodiment, the N sub-processes include an asynchronous sub-process; the sending the sub-process to the corresponding subsystem for any sub-process of the N sub-processes, so that after the subsystem processes the sub-process, the method further includes:
and aiming at the asynchronous sub-process, sending a result query request to an asynchronous subsystem corresponding to the asynchronous sub-process at a set frequency until a processing result fed back by the asynchronous subsystem is received.
In an optional embodiment, the exception handling for the sub-process according to the exception handling policy includes:
and executing retry processing aiming at the asynchronous sub-process.
In an optional embodiment, the monitoring the processing procedures of the N sub-processes includes:
monitoring the processing time of the main flow and each sub-flow, and if the processing time of the main flow and/or any sub-flow exceeds a corresponding time threshold, determining that an overtime exception occurs;
the exception handling of the sub-process according to the exception handling policy comprises:
executing retry processing on the asynchronous sub-process when the timeout type exception occurs in the asynchronous sub-process;
feeding back overtime processing procedures to the calling system and determining the processing state of the overtime sub-procedures aiming at overtime type abnormity of the main procedures and/or the synchronous sub-procedures;
if the processing state of the overtime sub-process is definite, performing asymmetric reverse operation on the successfully processed sub-process;
and if the processing state of the overtime sub-process is not clear, the main process is transferred to batch asynchronous processing.
In an optional embodiment, the converting the main flow to batch asynchronous processing if the processing state of the timeout sub-flow is ambiguous includes:
after a preset time period, sending a result query request to a subsystem corresponding to the overtime sub-process;
if a processing success result sent by the subsystem is received, executing asymmetric reverse operation on the overtime sub-process and the sub-process before the overtime sub-process;
if a processing failure result sent by the subsystem is received, performing asymmetric reverse operation on the sub-process before the overtime sub-process;
and if the processing result sent by the subsystem is received to be ambiguous and fed back, executing the step of sending a result query request to the subsystem corresponding to the overtime sub-process after the interval preset time period.
In an optional embodiment, the receiving a processing request sent by a calling system includes:
counting the number of received processing requests;
and if the quantity of the processing requests is greater than the flow early warning value, sending an early warning message to the calling system, and controlling the time for feeding back a response message to the calling system.
In an optional embodiment, after the sending, for any sub-process in the N sub-processes, the sub-process to a corresponding subsystem, so that the subsystem processes the sub-process, the method further includes:
receiving a response message fed back by the subsystem;
formatting the response message to obtain a response message;
and sending the response message to the calling system.
A distributed transaction flow assurance device, comprising:
the receiving and sending unit is used for receiving a processing request sent by the calling system;
the configuration unit is used for determining a main process and N sub-processes according to the processing request, wherein N is more than or equal to 1;
the transceiver unit is further configured to send, to any sub-process in the N sub-processes, the sub-process to a corresponding subsystem, so that the subsystem processes the sub-process;
the monitoring unit is used for monitoring the processing processes of the N sub-processes, and when the processing process of any sub-process is abnormal, determining a corresponding abnormal processing strategy according to the abnormal type, the type of the main process and the type of the sub-process;
and the exception handling unit is used for carrying out exception handling on the sub-processes according to the exception handling strategy, wherein the exception handling comprises the step of executing asymmetric reverse operation on the successfully processed sub-processes, the asymmetric reverse operation is the step of executing reverse sub-processes, and the reverse sub-processes are asymmetric to the processed sub-processes.
In an optional embodiment, the N sub-processes include an asynchronous sub-process; the transceiver unit is further configured to:
and aiming at the asynchronous sub-process, sending a result query request to an asynchronous subsystem corresponding to the asynchronous sub-process at a set frequency until a processing result fed back by the asynchronous subsystem is received.
In an alternative embodiment, the exception handling unit is configured to:
and executing retry processing aiming at the asynchronous sub-process.
In an optional embodiment, the monitoring unit is configured to monitor processing time of the main flow and each sub-flow, and if the processing time of the main flow and/or any sub-flow exceeds a corresponding time threshold, determine that a timeout-type exception occurs;
the exception handling unit is used for executing retry processing on the asynchronous sub-process when the timeout type exception occurs in the asynchronous sub-process; feeding back overtime processing procedures to the calling system and determining the processing state of the overtime sub-procedures aiming at overtime type abnormity of the main procedures and/or the synchronous sub-procedures; if the processing state of the overtime sub-process is definite, performing asymmetric reverse operation on the successfully processed sub-process; and if the processing state of the overtime sub-process is not clear, the main process is transferred to batch asynchronous processing.
In an alternative embodiment, the exception handling unit is configured to:
after a preset time period, sending a result query request to a subsystem corresponding to the overtime sub-process;
if a processing success result sent by the subsystem is received, executing asymmetric reverse operation on the overtime sub-process and the sub-process before the overtime sub-process;
if a processing failure result sent by the subsystem is received, performing asymmetric reverse operation on the sub-process before the overtime sub-process;
and if the processing result sent by the subsystem is received to be ambiguous and fed back, executing the step of sending a result query request to the subsystem corresponding to the overtime sub-process after the interval preset time period.
In an optional embodiment, the transceiver unit is configured to:
counting the number of received processing requests;
and if the quantity of the processing requests is greater than the flow early warning value, sending an early warning message to the calling system, and controlling the time for feeding back a response message to the calling system.
In an optional embodiment, the transceiver unit is configured to:
receiving a response message fed back by the subsystem;
formatting the response message to obtain a response message;
and sending the response message to the calling system.
An embodiment of the present invention further provides an electronic device, including:
at least one processor; and the number of the first and second groups,
a memory communicatively coupled to the at least one processor; wherein,
the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method as described above.
Embodiments of the present invention also provide a non-transitory computer-readable storage medium storing computer instructions for causing the computer to perform the method as described above.
In the embodiment of the invention, the processing request sent by the calling system is received, the processing request is analyzed, and the corresponding main flow and the N sub-flows are matched. And for the N sub-processes, sequentially sending the sub-processes to the corresponding sub-systems so that the sub-systems process the sub-processes, simultaneously monitoring the processing processes of the N sub-processes, and when the processing process of any sub-process is abnormal, determining a corresponding abnormal processing strategy according to the abnormal type, the main process type and the sub-process type. And performing exception processing on the sub-processes according to the exception processing strategy, wherein the exception processing comprises executing asymmetric reverse operation on the successfully processed sub-processes, the asymmetric reverse operation is to execute reverse sub-processes, and the reverse sub-processes are asymmetric to the processed sub-processes. In the embodiment of the invention, the exception handling of the sub-process can be symmetrical reverse operation or asymmetrical reverse operation, and an exception handling strategy can be flexibly set according to actual conditions and scenes, so that the problem of distributed transaction exception is flexibly solved.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive exercise.
FIG. 1 is a schematic diagram of a possible system architecture according to an embodiment of the present invention;
fig. 2 is a schematic flowchart of a method for guaranteeing a distributed transaction flow according to an embodiment of the present invention;
FIG. 3 is a schematic diagram of a symmetrical punch according to an embodiment of the present invention;
FIG. 4 is a schematic diagram of asymmetric blanking provided by an embodiment of the present invention;
fig. 5 is a schematic structural diagram of a distributed transaction flow guaranteeing apparatus according to an embodiment of the present invention;
fig. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention clearer, the present invention will be described in further detail with reference to the accompanying drawings, and it is apparent that the described embodiments are only a part of the embodiments of the present invention, not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
As shown in fig. 1, a system architecture to which the embodiment of the present invention is applicable includes a calling system 101, a transaction processing server 102, and N subsystems 103. The calling system 101 may be a client installed on a terminal or an operating system installed on a server, where the terminal may be an electronic device with a wireless communication function, such as a mobile phone, a tablet computer, or a dedicated handheld device, or may be a device connected to the internet in a wired access manner, such as a Personal Computer (PC), a notebook computer, or a server. The terminal may be an independent device, or a terminal cluster formed by a plurality of terminals. Preferably, the terminal can perform information processing by using a cloud computing technology. The transaction processing server 102 may be a network device such as a computer, an independent device, or a server cluster formed by a plurality of servers. The N subsystems 103 may be installed on N servers, respectively, or may be installed on less than N servers, that is, there may be a case where two or more subsystems 103 are installed on the same server. Preferably, the transaction processing server 102 and the N subsystems 103 may perform information processing by using cloud computing technology.
The calling System 101 may communicate with the transaction processing server 102 through an INTERNET network, or may communicate with the server 101 through a Global System for Mobile Communications (GSM), a Long Term Evolution (LTE) System, or other Mobile communication systems. The transaction processing server 102 may remotely call the subsystem 103 in an RMB manner, may call in another manner such as RPC, and may communicate with the subsystem 103 through a Mobile communication System such as INTERNET network, Global System for Mobile Communications (GSM), and Long Term Evolution (LTE) System.
For convenience of understanding, terms that may be referred to in the embodiments of the present invention are defined and explained below.
Deposit combination transaction system: the system is mainly used for a transaction access system for linkage live period and deposit balance linkage consumption in a bank supporting consumption scene, and can also be used for a scene of linkage consumption of bank deposit combined with loan and linkage consumption of a cooperative bank deposit account and a bank deposit account.
Distributed sub-transactions: a portion of the transactional processing logic, which forms a distributed set of transactions, may be used to return the exception handling condition to a pre-processing state or equivalent state by flushing or compensating.
Main transaction: the distributed business processing logic may be formed by one or several synchronously or asynchronously processed sub-transactions and has the key attributes of main transaction type, processing state, correcting state, processing time, etc.
Sub-transaction: a service processing subunit split from a group of distributed service processing logics corresponds to a distributed sub-transaction, can be synchronously processed or asynchronously processed, and has a plurality of service attributes such as processing state, conflict state, processing type and the like.
The active punching is orthogonal: the invention relates to a compensation processing mechanism of a main transaction, which is automatically generated by a processing model of the invention when an abnormity occurs in a distributed transaction, and aims to enable the original main transaction to reach a final service consistency state.
A flow decision controller: the main function of the component of the invention is to determine the form of the distributed transaction corresponding to the request by a processing mode configured in advance by the service based on the input information item, such as the splitting and the definition of the sub-transaction and the determination of the remote system interface. The system can change the business processing form according to the preset configuration to adapt to the business change requirement.
Abnormality detection: the system performs abnormity identification when the distributed transaction is abnormal.
An exception handling decision maker: after distributed transaction abnormity occurs and is detected, the distributed transaction abnormity generation model generates a corresponding distributed transaction abnormity according to the type of the abnormity and the preset abnormity processing control parameters.
And (3) reverse operation: after an exception occurs in the data processing process, a compensation processing mechanism is executed to enable the data stored in the database to reach a final consistency state. In a specific service scenario of an embodiment of the present invention, the reverse operation includes a rollback operation and/or a forward flushing process. The reverse operation also includes one or more reverse sub-flows, either symmetrical or asymmetrical with respect to the sub-flows of the normal processing. The reverse sub-process is a forward sub-process in a specific service scenario of the embodiment of the present invention.
In the prior art, in order to implement distributed transactions, a group of distributed transactions, denoted as T, is generally fixed first1、T2、T3…TnWherein T isiAre equal sub-transactions. Corresponding compensation sub-affair C is set corresponding to each sub-affair1、C2、C3…CjWherein 0 is<j<n is the same as the formula (I). When executed, according to T1、T2、T3…TnAre performed in sequence. If a sub-transaction T is being executedjWhen an exception occurs, except for the child transaction TjA rollback operation is required and a sub-transaction T is also requiredjThe previous sub-transaction execution is flushed, i.e. the set compensation sub-transaction is executed, the order of execution is Cj-1、Cj-2、…C2、C1. In the prior art, the conflict of the sub-transaction can be executed only according to a fixed flow, and the flexibility is not provided.
In order to solve the above problem, based on the above architecture, an embodiment of the present invention provides a method for guaranteeing a flow of a distributed transaction, where as shown in fig. 2, the method for guaranteeing a flow of a distributed transaction provided by the embodiment of the present invention includes the following steps:
step 201, receiving a processing request sent by a calling system.
In a specific implementation process, the system provides a plurality of message service interfaces which can be called externally, each interface defines configuration information such as a structure and field meaning of a message, specifically, sets service meaning definitions of a corresponding interface request message field and a corresponding interface response message field, and further includes descriptions such as the type and length of the fields, whether the fields need to be filled, and use description. Therefore, the device in the embodiment of the invention can receive the processing request sent by the external calling system through the interface and feed back the response message to the external calling system through the interface.
Step 202, determining a main process and N sub-processes according to the processing request, wherein N is more than or equal to 1.
In the specific implementation process, after a new processing request enters, whether the processing request is a legal request is determined by analyzing information such as a request message field of the processing request and combining a configuration service field controlled by the system, wherein the configuration field can be an ID (identity) of a calling system, a service request channel number and the like.
After a legal processing request is received, the corresponding main flow and sub-flow examples are matched through analysis processing according to the service information items carried by the processing request. The embodiment of the invention is designed with the type definitions of the main process and the sub-process and the process matching factory class.
For the main flow, the main service information items include: the requested channel, the service scene ID, the partner ID, the abstract code, the account types of the lending party and the like can be longitudinally or transversely expanded according to actual needs, and finally the main process type is obtained through matching.
The sub-processes are sub-processes determined according to more service information items of some dimensions after the main process type is determined. For example, the customer pays for a three-way pass by scanning the code and buys a cup of coffee 30 yuan. After parsing, the main flow match results in a consumption flow, rather than a refund or otherwise. And then, the sub-process determines whether the bank financing account and the bank card need to be linked according to whether the bank financing account exists in Zhang III. Thus, sub-processes under the same main process may be different. If the bank financing account is not opened, the sub-process may be the consumption of a single bank card; if the bank financing account is opened, the sub-process is the linkage consumption of the bank financing account and the bank card. The matching of the sub-process types is also set through a matrix class, and can be expanded horizontally and vertically according to different business requirements.
Step 203, aiming at any sub-process in the N sub-processes, sending the sub-process to a corresponding subsystem, so that the subsystem processes the sub-process.
In the implementation process, a processing request determines a main process and a plurality of sub-processes which are hung down, and the model is a double-layer transaction model. The main process is mainly used for tracking and controlling the progress and the state, the positive state, the abnormal information and the like of the whole distributed transaction processing. The sub-process corresponds to a specific interaction with the remote system, and the sub-process state, the correction state of the sub-process, the exception information, the remote call type and other information are also set. In the embodiment of the invention, the messages of the sub-processes can be sent to the corresponding subsystems for remote transaction processing through the remote calling tool according to the sub-process processing steps and the information of the corresponding sub-processes.
The multiple sub-processes can be processed synchronously or asynchronously. For example, assuming that the balance of three bank cards is 10 yuan and the share of financial products is 100 yuan, the main process generated for the consumption request of buying coffee is a consumption process, and the sub-processes include:
1. the share of the financial products is frozen to the bank financial management system by 20 yuan;
2. grouping one-to-one transfer transactions to a deposit core system for 30 yuan, wherein 10 yuan is paid out from a bank card, and 20 yuan is paid out from the in-transit clearing funds;
3. and (4) carrying out share redemption processing on the financing product in the bank financing system, and finishing the clearing processing of clearing funds in transit.
Of the above three sub-processes, sub-processes 1 and 2 are synchronous processes, i.e. need to be executed immediately and wait for the result to be returned. The sub-process 3 is an asynchronous processing process, and can be processed by selecting an opportunity after the previous synchronous sub-processes 1 and 2 are successfully executed and returned, and different processing can be performed according to the type of the sub-process. Therefore, the timeliness of the synchronous processing operation can be higher, and the overall throughput of the system is improved.
And 204, monitoring the processing processes of the N sub-processes, and determining a corresponding exception handling strategy according to the exception type, the type of the main process and the type of the sub-process when the processing process of any sub-process is abnormal.
Specifically, the reverse operation flow in the embodiment of the present invention is also processed in the manner of a main sub-flow model. Meanwhile, the sub-processes of the reverse operation process and the sub-processes of the original process may be in one-to-one correspondence, which is called symmetric reverse operation, or the sub-processes of the reverse operation process and the sub-processes of the original process are not in one-to-one correspondence, but the effect of the reverse sub-processes after execution is equal to the effect of the non-execution of all the original sub-processes, which is called asymmetric reverse operation. The following examples illustrate symmetric reverse operation and asymmetric reverse operation in a forward flow.
Punching in a symmetrical mode:
if the balance of the bank is 30 yuan when three coffee drinks, which is enough to drink one cup of coffee, the actual main flow is a consumption flow, only one subprocess is needed, namely, the core one-to-one transfer is not needed, the bank financing account is not needed to be linked, and all consumption amount is paid out from the bank card. Supposing that the deposit core is abnormal in money discharge consumption from the bank card, but the amount of money transferred from the bank card of the third bank card is 30 yuan, a corresponding correction subprocess needs to be set, and the correction subprocess is also one, namely, the core one-to-one correction is realized, and only the original consumption transaction is corrected by the deposit core. In this case, the original flow and the rush flow are completely symmetrical, as shown in fig. 3.
Asymmetric punching:
if the balance of the bank card of Zhang III is 10 yuan, less than 30 yuan and the bank financing product has 100 yuan, the actual main flow is the consumption flow, and the sub-flows have three flows, namely 'freezing financing product', 'core one-to-one transfer' and 'financing unfreezing and redeeming'. However, after the original process is completed, a forward-moving transaction is initiated outside, if the process is symmetrical forward-moving, three forward-moving sub-processes are required to be set for the three sub-processes, namely 'financing product unfreezing', 'core one-to-one forward-moving' and 'financing product buying', namely 10 yuan is returned to the bank card, and 20 yuan of financing products are newly bought. And asymmetric correction, one correction sub-process can be set, for example, a core one-to-one transfer is adopted, 30 elements are directly returned to the bank card, so that the corresponding correction sub-process is only one, and the atomic processes are three, so that the system is asymmetric, as shown in fig. 4. At this time, for zhang san, the assets are not reduced, that is, the effect after correction is equal to the effect of the unexecuted atomic flow, and the operation process is greatly simplified compared with the symmetrical correction. It should be noted that the asymmetric correction is not only that the number of correction sub-processes is different from the number of atomic processes, but also that the number of correction sub-processes is consistent with the number of atomic processes, but not in one-to-one correspondence, for example, in the above example, three strokes may be divided, and each stroke returns 10 yuan to the bank card, which also belongs to the asymmetric correction.
And step 205, performing exception handling on the sub-process according to the exception handling strategy. The exception handling comprises the step of executing asymmetric reverse operation on the successfully processed sub-flow, wherein the asymmetric reverse operation is the step of executing a reverse operation sub-flow, and the reverse operation sub-flow is asymmetric to the processed sub-flow.
The reverse operation may be a rollback operation on the sub-process, a forward operation on the sub-process, or an account checking operation on the sub-process.
In the embodiment of the invention, the processing request sent by the calling system is received, the processing request is analyzed, and the corresponding main flow and the N sub-flows are matched. And for the N sub-processes, sequentially sending the sub-processes to the corresponding sub-systems so that the sub-systems process the sub-processes, simultaneously monitoring the processing processes of the N sub-processes, and when the processing process of any sub-process is abnormal, determining a corresponding abnormal processing strategy according to the abnormal type, the main process type and the sub-process type. And performing exception processing on the sub-processes according to the exception processing strategy, wherein the exception processing comprises executing asymmetric reverse operation on the successfully processed sub-processes, the asymmetric reverse operation is to execute reverse sub-processes, and the reverse sub-processes are asymmetric to the processed sub-processes. In the embodiment of the invention, the exception handling of the sub-process can be symmetrical reverse operation or asymmetrical reverse operation, and an exception handling strategy can be flexibly set according to actual conditions and scenes, so that the problem of distributed transaction exception is flexibly solved.
Further, in order to control message traffic and reduce system pressure, in the embodiment of the present invention, the receiving a processing request sent by a calling system includes:
counting the number of received processing requests;
and if the quantity of the processing requests is greater than the flow early warning value, sending an early warning message to the calling system, and controlling the time for feeding back a response message to the calling system.
In the specific implementation process, the number of received processing requests is monitored in all weather, when a new processing request is received, the variable of the counter is increased by 1, and meanwhile, different flow counters can be set according to different types of interfaces, so that high-flow early warning values and maximum values are configured for different request types or total system flow. When the number of certain types of requests or the number of total processing requests triggers an early warning value, message early warning can be provided; when the maximum value is reached, the limit response message is immediately returned to the calling system so as to achieve the purpose of system protection.
In the prior art, the subsystem provides a message service interface for asynchronous processing, but generally, distributed transactions require the subsystem to synchronously feed back message processing results. In order to solve the problem, in the embodiment of the present invention, the N sub-processes include an asynchronous sub-process; the sending the sub-process to the corresponding subsystem for any sub-process of the N sub-processes, so that after the subsystem processes the sub-process, the method further includes:
and aiming at the asynchronous sub-process, sending a result query request to an asynchronous subsystem corresponding to the asynchronous sub-process at a set frequency until a processing result fed back by the asynchronous subsystem is received.
The embodiment of the invention sets an asynchronous-to-synchronous realization mechanism, and better solves the problem that the asynchronous interface of the subsystem can not meet the requirement of synchronously returning a processing result. Specifically, after the asynchronous sub-process is sent to the corresponding asynchronous subsystem, a remote result query interface of the asynchronous subsystem is called according to the serial number of the main process, and a processing result of the asynchronous sub-process is obtained. If the timeout time of the asynchronous sub-process is not exceeded, the remote result query interface is retried to call after a certain time interval until a specific return result is obtained. In addition, if the result is not obtained until the timeout time of the set asynchronous sub-process, the asynchronous sub-process is directly considered to be abnormal due to timeout, and the asynchronous sub-process enters the exception processing logic.
Further, the exception handling of the sub-process according to the exception handling policy includes:
and executing retry processing aiming at the asynchronous sub-process.
Specifically, since the execution of the asynchronous sub-flow does not need to synchronously return the processing result, the retry processing may be performed on the asynchronous sub-flow in case of an abnormality of the asynchronous sub-flow.
In the execution process of the main flow or the sub-flow, if a business abnormality or a technical abnormality definitely occurs, for example, an account state abnormality, a database abnormality, or the like occurs during the transfer, in the embodiment of the present invention, the sub-flow may immediately perform a correction process, or may perform a process of switching to an asynchronous task, and specifically, the configuration may be performed as needed, and the configuration table itself may also be expanded horizontally or vertically to meet the needs of the business.
Another type of exception is a timeout type exception. The monitoring of the processing processes of the N sub-processes comprises:
monitoring the processing time of the main flow and each sub-flow, and if the processing time of the main flow and/or any sub-flow exceeds a corresponding time threshold, determining that an overtime exception occurs;
the exception handling of the sub-process according to the exception handling policy comprises:
executing retry processing on the asynchronous sub-process when the timeout type exception occurs in the asynchronous sub-process;
feeding back overtime processing procedures to the calling system and determining the processing state of the overtime sub-procedures aiming at overtime type abnormity of the main procedures and/or the synchronous sub-procedures;
if the processing state of the overtime sub-process is definite, performing asymmetric reverse operation on the successfully processed sub-process;
and if the processing state of the overtime sub-process is not clear, the main process is transferred to batch asynchronous processing.
In the specific implementation process, the timeout exception is divided into the following different cases. The embodiment of the invention introduces the main process timeout time and the sub-process timeout time. The main process timeout time, which is a system threshold set for the time period from the time when a processing request is received to the current processing time, is used to determine whether an abnormal condition of timeout occurs during the execution of a main process. If the main flow exceeds the set main flow overtime time, an abnormal state code of the main flow overtime is returned to the calling system, and the flow is identified to be in an intermediate state for processing overtime. The intermediate state of the processing timeout is considered as a processing failure for the calling system, and exception processing is required. Specifically, the processing state of the timeout sub-process needs to be acquired, and if the timeout sub-process has been successfully processed, a correction process is performed on the timeout sub-process and the sub-process that has been successfully processed before the timeout sub-process, where the correction process may be a symmetric correction or an asymmetric correction, and finally the data is returned to the equivalent state of the service start. If the overtime sub-process is not successfully processed, the overtime sub-process is not required to be processed, and only the sub-process which is successfully processed before the overtime sub-process needs to be processed. If the processing state of the overtime sub-process is ambiguous, the main process is converted into batch asynchronous processing, for example, the main process requiring batch asynchronous processing is collected, the processing state is inquired again in a fixed time period every day, and then the subsequent processing is performed according to the inquiry result. The main process with an undefined processing state is converted into a batch asynchronous processing mode for continuous subsequent processing operation, so that the final result of the abnormal transaction can be ensured to reach the consistency of the service requirement.
The batch asynchronous processing is realized by means of qrtz timing tasks, and different asynchronous processing strategies can be configured for main flows of different types of batch asynchronous processing, such as scheduling processing frequency of tasks, scheduling time range, thread resource investment of scheduling processing and the like.
Similar to the main flow timeout state, the sub-flows are also set with different system thresholds for the timeout state. The processing time of the sub-processes is the time interval from the moment when one sub-process is sent to the corresponding subsystem to the current processing time. And the sub-process is overtime, namely the time-consuming duration recorded by the timer of the sub-process exceeds the overtime system threshold set by the system for the sub-process of the current type. Whether the main flow is overtime or the sub-flows requiring synchronous processing are overtime, the processing result of the request is affected, the system intercepts the overtime exception and interrupts the execution of the flow, and the state of the flow is overtime externally returned.
In addition, for the asynchronous sub-flow, a timeout-like exception occurs, and since the timeout of the asynchronous sub-flow does not affect the processing result of the current request, the retry processing may be performed on the asynchronous sub-flow, where the retry processing may be to retry directly when the asynchronous sub-flow is found to have a timeout exception, or may be to perform batch asynchronous processing on the asynchronous sub-flow, for example, to perform retry processing on the asynchronous sub-flow in a fixed time period every day. Of course, the flushing process may also be performed on asynchronous sub-flows depending on the configuration.
Further, the embodiment of the invention provides the feedback result with consistent format to the calling system. The sending the sub-process to the corresponding subsystem for any sub-process of the N sub-processes, so that after the subsystem processes the sub-process, the method further includes:
receiving a response message fed back by the subsystem;
formatting the response message to obtain a response message;
and sending the response message to the calling system.
For example, a calling system sends a transaction processing request to a transaction processing server, and the transaction processing server processes the request overtime and returns a timeout status. The calling system may query the transaction result in the transaction processing server according to the specific overtime exception code, and then process the returned response message according to the specific transaction state information.
In addition, the package of the feedback response message can achieve the purpose that a consistent and stable output result is provided for the outside after the message formatting when the system changes, particularly when new system semantics appear. For example: the timeout exception code is fed back to the outside 000960 because the service requires access to the new downstream subsystem, but the timeout exception code of the newly accessed subsystem is a new value such as XXXTIMEOUT, and formatting the response message requires that XXXTIMEOUT be converted and packaged into a timeout exception code 000960 agreed with the calling system so that the calling system can also recognize the timeout exception code.
In order to more clearly understand the present invention, the above flow is described in detail with a specific embodiment, in the specific embodiment of the present invention, a specific scenario is that a user uses a mobile phone to perform quick payment, and a system architecture includes a client, a transaction processing system, a deposit core system and a financing system, where the deposit core system and the financing system are subsystems corresponding to sub-transactions respectively.
The steps of the specific embodiment are as follows:
step S501: the client sends a fast consumption payment request to the transaction processing system.
Step S502: and the transaction processing system analyzes the quick consumption payment request and sends a balance inquiry request to the deposit core system.
Step S503: and the transaction processing system determines that the balance in the bank card of the user is insufficient according to the result fed back by the deposit core system, and the client side is set to allow the financial product to be consumed in a linkage manner, and then sends a balance inquiry request to the financial system.
Step S504: the transaction processing system determines that the sub-processes are 'frozen financing products', 'core one-to-one transfer' and 'financing unfreezing and redeeming' respectively according to the result fed back by the financing system.
Step S505: the transaction processing system sends a frozen financing product request to the financing system. If the financing system is successfully executed, step 506 is executed. If the financial management system fails to execute, the result of the distributed transaction is not affected, so that the failure result is directly fed back to the client without processing. If the execution of the financial system is overtime, the processing result of the request for freezing the financial product needs to be verified, if the execution fails, the processing is not needed, and if the execution succeeds, correction processing needs to be executed, namely, the financial product is unfrozen.
Step S506: the transaction processing system sends a deduction and transfer request to the deposit core system. If the deposit core system is successfully executed, a deduction success result is fed back to the client, and step 507 is executed. If the execution of the deposit core system fails, correction processing needs to be executed on the 'frozen financial product', namely, the financial product is unfrozen. And if the execution of the deposit core system is overtime, the processing result of the deduction and transfer request needs to be verified, if the processing result fails, the financial product is unfrozen, and if the processing result succeeds, asynchronous redemption is executed, and the state is updated. The asymmetrical correction is realized between the correction sub-process of 'asynchronous redemption and updating state' and the sub-process of 'freezing financing products' and 'core one-to-one transfer'.
Step S507: the transaction processing system sends a financial unfreezing and financial redemption request to the financial system, wherein the financial unfreezing and financial redemption request is an asynchronous request. And if the financial management system is successfully executed, the transaction processing system feeds back a redemption success result to the client. And if the financial management system fails to execute, transferring to batch asynchronous processing and executing retry processing. If the financial system runs out of time, the processing state needs to be verified, and the processing can be manually intervened.
An embodiment of the present invention further provides a flow guaranteeing apparatus for distributed transactions, as shown in fig. 5, including:
a transceiver 601, configured to receive a processing request sent by a calling system;
a configuration unit 602, configured to determine a main process and N sub-processes according to the processing request, where N is greater than or equal to 1;
the transceiver 601 is further configured to send, for any sub-process in the N sub-processes, the sub-process to a corresponding subsystem, so that the subsystem processes the sub-process;
a monitoring unit 603, configured to monitor processing procedures of the N sub-processes, and when an exception occurs in a processing procedure of any sub-process, determine a corresponding exception handling policy according to an exception type, the type of the main process, and the type of the sub-process;
an exception handling unit 604, configured to perform exception handling on the sub-flows according to the exception handling policy, where the exception handling includes performing an asymmetric reverse operation on a successfully processed sub-flow, where the asymmetric reverse operation is to perform a reverse sub-flow, and the reverse sub-flow is asymmetric to the processed sub-flow.
Optionally, the N sub-processes include an asynchronous sub-process; the transceiver 601 is further configured to:
and aiming at the asynchronous sub-process, sending a result query request to an asynchronous subsystem corresponding to the asynchronous sub-process at a set frequency until a processing result fed back by the asynchronous subsystem is received.
Optionally, the exception handling unit 604 is configured to:
and executing retry processing aiming at the asynchronous sub-process.
Optionally, the monitoring unit 603 is configured to monitor the processing time of the main flow and each sub-flow, and if the processing time of the main flow and/or any sub-flow exceeds a corresponding time threshold, determine that a timeout-type exception occurs;
the exception handling unit 604 is configured to execute retry processing on an asynchronous sub-process if an timeout-type exception occurs in the asynchronous sub-process; feeding back overtime processing procedures to the calling system and determining the processing state of the overtime sub-procedures aiming at overtime type abnormity of the main procedures and/or the synchronous sub-procedures; if the processing state of the overtime sub-process is definite, performing asymmetric reverse operation on the successfully processed sub-process; and if the processing state of the overtime sub-process is not clear, the main process is transferred to batch asynchronous processing.
Optionally, the exception handling unit 604 is configured to:
after a preset time period, sending a result query request to a subsystem corresponding to the overtime sub-process;
if a processing success result sent by the subsystem is received, executing asymmetric reverse operation on the overtime sub-process and the sub-process before the overtime sub-process;
if a processing failure result sent by the subsystem is received, performing asymmetric reverse operation on the sub-process before the overtime sub-process;
and if the processing result sent by the subsystem is received to be ambiguous and fed back, executing the step of sending a result query request to the subsystem corresponding to the overtime sub-process after the interval preset time period.
Optionally, the transceiver 601 is configured to:
counting the number of received processing requests;
and if the quantity of the processing requests is greater than the flow early warning value, sending an early warning message to the calling system, and controlling the time for feeding back a response message to the calling system.
Optionally, the transceiver 601 is configured to:
receiving a response message fed back by the subsystem;
formatting the response message to obtain a response message;
and sending the response message to the calling system.
Based on the same principle, the present invention also provides an electronic device, as shown in fig. 6, including:
the system comprises a processor 701, a memory 702, a transceiver 703 and a bus interface 704, wherein the processor 701, the memory 702 and the transceiver 703 are connected through the bus interface 704;
the processor 701 is configured to read the program in the memory 702, and execute the following method:
receiving a processing request sent by a calling system;
determining a main process and N sub-processes according to the processing request, wherein N is more than or equal to 1;
aiming at any sub-process in the N sub-processes, sending the sub-process to a corresponding subsystem so that the subsystem processes the sub-process;
monitoring the processing processes of the N sub-processes, and determining a corresponding exception handling strategy according to the exception type, the main process type and the sub-process type when the processing process of any sub-process is abnormal;
and carrying out exception processing on the sub-processes according to the exception processing strategy, wherein the exception processing comprises the step of executing asymmetric reverse operation on the successfully processed sub-processes, the asymmetric reverse operation is the step of executing reverse sub-processes, and the reverse sub-processes are asymmetric to the processed sub-processes.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
While preferred embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all such alterations and modifications as fall within the scope of the invention.
It will be apparent to those skilled in the art that various changes and modifications may be made in the present invention without departing from the spirit and scope of the invention. Thus, if such modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include such modifications and variations.

Claims (16)

1. A flow guarantee method for distributed transactions is characterized by comprising the following steps:
receiving a processing request sent by a calling system;
determining a main process and N sub-processes according to the processing request, wherein N is more than or equal to 1;
aiming at any sub-process in the N sub-processes, sending the sub-process to a corresponding subsystem so that the subsystem processes the sub-process;
monitoring the processing processes of the N sub-processes, and determining a corresponding exception handling strategy according to the exception type, the type of the main process and the type of the sub-process when the processing process of any sub-process is abnormal;
and carrying out exception processing on the sub-processes according to the exception processing strategy, wherein the exception processing comprises the step of executing asymmetric reverse operation on the successfully processed sub-processes, the asymmetric reverse operation is the step of executing reverse sub-processes, and the reverse sub-processes are asymmetric to the processed sub-processes.
2. The method of claim 1, wherein the N sub-flows comprise asynchronous sub-flows; the sending the sub-process to the corresponding subsystem for any sub-process of the N sub-processes, so that after the subsystem processes the sub-process, the method further includes:
and if the sub-process is an asynchronous sub-process, sending a result query request to an asynchronous subsystem corresponding to the asynchronous sub-process at a set frequency until a processing result fed back by the asynchronous subsystem is received.
3. The method of claim 2, wherein said exception handling of sub-flows according to said exception handling policy comprises:
and executing retry processing aiming at the asynchronous sub-process.
4. The method of claim 1, wherein monitoring the processing of the N sub-processes comprises:
monitoring the processing time of the main flow and each sub-flow, and if the processing time of the main flow and/or any sub-flow exceeds a corresponding time threshold, determining that an overtime exception occurs;
the exception handling of the sub-process according to the exception handling policy comprises:
executing retry processing on the asynchronous sub-process when the timeout type exception occurs in the asynchronous sub-process;
feeding back overtime processing procedures to the calling system and determining the processing state of the overtime sub-procedures aiming at overtime type abnormity of the main procedures and/or the synchronous sub-procedures;
if the processing state of the overtime sub-process is definite, performing asymmetric reverse operation on the successfully processed sub-process;
and if the processing state of the overtime sub-process is not clear, the main process is transferred to batch asynchronous processing.
5. The method of claim 4, wherein said transferring said main flow to batch asynchronous processing if said processing state of said timed-out sub-flow is ambiguous comprises:
after a preset time period, sending a result query request to a subsystem corresponding to the overtime sub-process;
if a processing success result sent by the subsystem is received, executing asymmetric reverse operation on the overtime sub-process and the sub-process before the overtime sub-process;
if a processing failure result sent by the subsystem is received, performing asymmetric reverse operation on the sub-process before the overtime sub-process;
and if the processing result sent by the subsystem is received to be ambiguous and fed back, executing the step of sending a result query request to the subsystem corresponding to the overtime sub-process after the interval preset time period.
6. The method of claim 1, wherein receiving a processing request sent by a calling system comprises:
counting the number of received processing requests;
and if the quantity of the processing requests is greater than the flow early warning value, sending an early warning message to the calling system, and controlling the time for feeding back a response message to the calling system.
7. The method according to any one of claims 1 to 6, wherein, after sending the sub-flow to the corresponding subsystem for the subsystem to process the sub-flow, for any one of the N sub-flows, further comprising:
receiving a response message fed back by the subsystem;
formatting the response message to obtain a response message;
and sending the response message to the calling system.
8. A distributed transaction flow assurance device, comprising:
the receiving and sending unit is used for receiving a processing request sent by the calling system;
the configuration unit is used for determining a main process and N sub-processes according to the processing request, wherein N is more than or equal to 1;
the transceiver unit is further configured to send, to any sub-process in the N sub-processes, the sub-process to a corresponding subsystem, so that the subsystem processes the sub-process;
the monitoring unit is used for monitoring the processing processes of the N sub-processes, and when the processing process of any sub-process is abnormal, determining a corresponding abnormal processing strategy according to the abnormal type, the type of the main process and the type of the sub-process;
and the exception handling unit is used for carrying out exception handling on the sub-processes according to the exception handling strategy, wherein the exception handling comprises the step of executing asymmetric reverse operation on the successfully processed sub-processes, the asymmetric reverse operation is the step of executing reverse sub-processes, and the reverse sub-processes are asymmetric to the processed sub-processes.
9. The apparatus of claim 8, wherein the N sub-flows comprise asynchronous sub-flows; the transceiver unit is further configured to:
and aiming at the asynchronous sub-process, sending a result query request to an asynchronous subsystem corresponding to the asynchronous sub-process at a set frequency until a processing result fed back by the asynchronous subsystem is received.
10. The apparatus of claim 9, wherein the exception handling unit is to perform a retry process for the asynchronous sub-flow.
11. The apparatus according to claim 8, wherein the monitoring unit is configured to monitor the processing time of the main flow and each sub-flow, and determine that a timeout-type exception occurs if the processing time of the main flow and/or any sub-flow exceeds a corresponding time threshold;
the exception handling unit is used for executing retry processing on the asynchronous sub-process when the timeout type exception occurs in the asynchronous sub-process; feeding back overtime processing procedures to the calling system and determining the processing state of the overtime sub-procedures aiming at overtime type abnormity of the main procedures and/or the synchronous sub-procedures; if the processing state of the overtime sub-process is definite, performing asymmetric reverse operation on the successfully processed sub-process; and if the processing state of the overtime sub-process is not clear, the main process is transferred to batch asynchronous processing.
12. The apparatus of claim 11, wherein the exception handling unit is to:
after a preset time period, sending a result query request to a subsystem corresponding to the overtime sub-process;
if a processing success result sent by the subsystem is received, executing asymmetric reverse operation on the overtime sub-process and the sub-process before the overtime sub-process;
if a processing failure result sent by the subsystem is received, performing asymmetric reverse operation on the sub-process before the overtime sub-process;
and if the processing result sent by the subsystem is received to be ambiguous and fed back, executing the step of sending a result query request to the subsystem corresponding to the overtime sub-process after the interval preset time period.
13. The apparatus as claimed in claim 8, wherein said transceiver unit is configured to:
counting the number of received processing requests;
and if the quantity of the processing requests is greater than the flow early warning value, sending an early warning message to the calling system, and controlling the time for feeding back a response message to the calling system.
14. The apparatus according to any of claims 8 to 13, wherein the transceiver unit is configured to:
receiving a response message fed back by the subsystem;
formatting the response message to obtain a response message;
and sending the response message to the calling system.
15. An electronic device, comprising:
at least one processor; and the number of the first and second groups,
a memory communicatively coupled to the at least one processor; wherein,
the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.
16. A non-transitory computer readable storage medium storing computer instructions for causing a computer to perform the method of any one of claims 1-7.
CN201910580564.XA 2019-06-28 2019-06-28 A kind of logistics method and device of distributed transaction Pending CN110288255A (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201910580564.XA CN110288255A (en) 2019-06-28 2019-06-28 A kind of logistics method and device of distributed transaction
PCT/CN2019/118181 WO2020258665A1 (en) 2019-06-28 2019-11-13 Process guarantee method and device for distributed transactions

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910580564.XA CN110288255A (en) 2019-06-28 2019-06-28 A kind of logistics method and device of distributed transaction

Publications (1)

Publication Number Publication Date
CN110288255A true CN110288255A (en) 2019-09-27

Family

ID=68019847

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910580564.XA Pending CN110288255A (en) 2019-06-28 2019-06-28 A kind of logistics method and device of distributed transaction

Country Status (2)

Country Link
CN (1) CN110288255A (en)
WO (1) WO2020258665A1 (en)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110930110A (en) * 2019-10-31 2020-03-27 东软集团股份有限公司 Distributed flow monitoring method and device, storage medium and electronic equipment
CN111277639A (en) * 2020-01-16 2020-06-12 中国建设银行股份有限公司 Method and device for maintaining data consistency
CN111340340A (en) * 2020-02-17 2020-06-26 腾讯科技(深圳)有限公司 Event processing method and device
CN111367628A (en) * 2020-03-05 2020-07-03 中国银行股份有限公司 Distributed transaction processing method and device, message producer and consumer system
CN111414266A (en) * 2020-03-23 2020-07-14 山东浪潮通软信息科技有限公司 Synchronous and asynchronous communication method and device for distributed transactions
CN111866171A (en) * 2020-07-30 2020-10-30 中国工商银行股份有限公司 Message processing method and device, electronic equipment and medium
WO2020258665A1 (en) * 2019-06-28 2020-12-30 深圳前海微众银行股份有限公司 Process guarantee method and device for distributed transactions
CN112435004A (en) * 2020-11-20 2021-03-02 金蝶软件(中国)有限公司 Method and device for realizing service flow processing
CN112839110A (en) * 2021-03-05 2021-05-25 紫光云技术有限公司 Method for realizing network communication fault tolerance in distributed system
CN113051008A (en) * 2021-04-01 2021-06-29 金蝶软件(中国)有限公司 Interface request processing method and device, computer equipment and storage medium
CN113065967A (en) * 2021-05-18 2021-07-02 中国农业银行股份有限公司 Multi-mode service processing method, device and equipment
CN113111077A (en) * 2021-04-16 2021-07-13 中国工商银行股份有限公司 Consistency control method, consistency control device, electronic equipment, consistency control medium and program product
CN113297357A (en) * 2021-07-27 2021-08-24 北京健康之家科技有限公司 Asynchronous processing method and device for business process data
CN113724082A (en) * 2021-08-30 2021-11-30 上海浦东发展银行股份有限公司 Accounting processing method, device, equipment and storage medium
CN114219626A (en) * 2021-12-17 2022-03-22 中国建设银行股份有限公司 Task exception handling method, device, equipment, storage medium and program product

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102045682A (en) * 2009-10-19 2011-05-04 中兴通讯股份有限公司 Method and system for handling abnormal transactions of payment services
CN106445644A (en) * 2016-08-30 2017-02-22 中国民生银行股份有限公司 Distributed transaction processing method and device based on improved one-phase commit
CN107819861A (en) * 2017-11-16 2018-03-20 中国银行股份有限公司 Business data processing method, apparatus and system
CN108459919A (en) * 2018-03-29 2018-08-28 中信百信银行股份有限公司 A kind of distributed transaction processing method and device
CN108958894A (en) * 2018-06-14 2018-12-07 阿里巴巴集团控股有限公司 A kind of distributed transaction processing method, system, task manager and terminal device
CN109003069A (en) * 2018-07-27 2018-12-14 阿里巴巴集团控股有限公司 A kind of resource backing method and device
CN109254840A (en) * 2018-08-28 2019-01-22 中国邮政储蓄银行股份有限公司 Business compensation method and device, system
CN109785042A (en) * 2018-12-13 2019-05-21 深圳平安财富宝投资咨询有限公司 Abnormality eliminating method, server, storage medium and the device of distributed deployment

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104462370A (en) * 2014-12-09 2015-03-25 北京百度网讯科技有限公司 Distributed task scheduling system and method
CN106775959B (en) * 2016-12-06 2017-12-22 上海壹账通金融科技有限公司 distributed transaction processing method and system
CN108519920B (en) * 2018-03-14 2020-12-01 口碑(上海)信息技术有限公司 Scheduling retry method and device
CN110288255A (en) * 2019-06-28 2019-09-27 深圳前海微众银行股份有限公司 A kind of logistics method and device of distributed transaction

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102045682A (en) * 2009-10-19 2011-05-04 中兴通讯股份有限公司 Method and system for handling abnormal transactions of payment services
CN106445644A (en) * 2016-08-30 2017-02-22 中国民生银行股份有限公司 Distributed transaction processing method and device based on improved one-phase commit
CN107819861A (en) * 2017-11-16 2018-03-20 中国银行股份有限公司 Business data processing method, apparatus and system
CN108459919A (en) * 2018-03-29 2018-08-28 中信百信银行股份有限公司 A kind of distributed transaction processing method and device
CN108958894A (en) * 2018-06-14 2018-12-07 阿里巴巴集团控股有限公司 A kind of distributed transaction processing method, system, task manager and terminal device
CN109003069A (en) * 2018-07-27 2018-12-14 阿里巴巴集团控股有限公司 A kind of resource backing method and device
CN109254840A (en) * 2018-08-28 2019-01-22 中国邮政储蓄银行股份有限公司 Business compensation method and device, system
CN109785042A (en) * 2018-12-13 2019-05-21 深圳平安财富宝投资咨询有限公司 Abnormality eliminating method, server, storage medium and the device of distributed deployment

Cited By (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020258665A1 (en) * 2019-06-28 2020-12-30 深圳前海微众银行股份有限公司 Process guarantee method and device for distributed transactions
CN110930110A (en) * 2019-10-31 2020-03-27 东软集团股份有限公司 Distributed flow monitoring method and device, storage medium and electronic equipment
CN110930110B (en) * 2019-10-31 2022-06-07 东软集团股份有限公司 Distributed flow monitoring method and device, storage medium and electronic equipment
CN111277639A (en) * 2020-01-16 2020-06-12 中国建设银行股份有限公司 Method and device for maintaining data consistency
CN111340340A (en) * 2020-02-17 2020-06-26 腾讯科技(深圳)有限公司 Event processing method and device
CN111340340B (en) * 2020-02-17 2023-10-20 腾讯科技(深圳)有限公司 Event processing method and device
CN111367628A (en) * 2020-03-05 2020-07-03 中国银行股份有限公司 Distributed transaction processing method and device, message producer and consumer system
CN111367628B (en) * 2020-03-05 2023-05-23 中国银行股份有限公司 Distributed transaction processing method and device, message producer and consumer system
CN111414266B (en) * 2020-03-23 2024-04-05 浪潮通用软件有限公司 Synchronous and asynchronous communication method and device for distributed transaction
CN111414266A (en) * 2020-03-23 2020-07-14 山东浪潮通软信息科技有限公司 Synchronous and asynchronous communication method and device for distributed transactions
CN111866171B (en) * 2020-07-30 2023-08-22 中国工商银行股份有限公司 Message processing method, device, electronic equipment and medium
CN111866171A (en) * 2020-07-30 2020-10-30 中国工商银行股份有限公司 Message processing method and device, electronic equipment and medium
CN112435004A (en) * 2020-11-20 2021-03-02 金蝶软件(中国)有限公司 Method and device for realizing service flow processing
CN112839110A (en) * 2021-03-05 2021-05-25 紫光云技术有限公司 Method for realizing network communication fault tolerance in distributed system
CN112839110B (en) * 2021-03-05 2023-03-10 紫光云技术有限公司 Method for realizing problem processing based on network overtime in distributed system
CN113051008A (en) * 2021-04-01 2021-06-29 金蝶软件(中国)有限公司 Interface request processing method and device, computer equipment and storage medium
CN113111077A (en) * 2021-04-16 2021-07-13 中国工商银行股份有限公司 Consistency control method, consistency control device, electronic equipment, consistency control medium and program product
CN113065967A (en) * 2021-05-18 2021-07-02 中国农业银行股份有限公司 Multi-mode service processing method, device and equipment
CN113297357B (en) * 2021-07-27 2021-11-16 北京健康之家科技有限公司 Asynchronous processing method and device for business process data
CN113297357A (en) * 2021-07-27 2021-08-24 北京健康之家科技有限公司 Asynchronous processing method and device for business process data
CN113724082A (en) * 2021-08-30 2021-11-30 上海浦东发展银行股份有限公司 Accounting processing method, device, equipment and storage medium
CN113724082B (en) * 2021-08-30 2024-04-30 上海浦东发展银行股份有限公司 Accounting processing method, device, equipment and storage medium
CN114219626A (en) * 2021-12-17 2022-03-22 中国建设银行股份有限公司 Task exception handling method, device, equipment, storage medium and program product

Also Published As

Publication number Publication date
WO2020258665A1 (en) 2020-12-30

Similar Documents

Publication Publication Date Title
CN110288255A (en) A kind of logistics method and device of distributed transaction
CN107038645B (en) Service processing method, device and system and server
CN108242023A (en) A kind of intelligent trading system
US20140156785A1 (en) Method and Apparatus for Generating User Notifications
CN112650764A (en) Cross-chain data processing method, device, equipment and storage medium
WO2020258666A1 (en) Distributed system and data processing method
CN102999866A (en) Fund collection method and system
CN107194810A (en) Asset allocation system and method
CN101606172A (en) The system and method that is used for adaptive information dissemination
CN105096122A (en) Fragmented transaction matching method and fragmented transaction matching device
CN113626218A (en) Data processing method, data processing device, storage medium and computer equipment
CN114327804B (en) Block chain based distributed transaction processing method, device, equipment and medium
WO2020103728A1 (en) Transaction settlement method and apparatus
CN107038025B (en) SOA architecture-based system calling method and device
CN114004701A (en) Method and device for generating transaction result, electronic equipment and storage medium
CN111400283B (en) Data processing method, system, electronic equipment and storage medium
US20100169235A1 (en) Real-Time Trade Forecaster
CN111242762A (en) Financial product purchasing method, device and system
CN116662387A (en) Service data processing method, device, equipment and storage medium
CN105761069A (en) POS terminal communication method and system thereof
US11520802B2 (en) Systems and methods for data format conversion
CN110263063B (en) Asset query method and server
CN110706051B (en) Order data aggregation method and device and server
TWI665634B (en) Exchange transaction management system and a management method thereof
US9092258B2 (en) Task concurrency limiter

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination