CN114066476A - Method, device and storage medium for solving issue-first issue of distributed application transaction - Google Patents
Method, device and storage medium for solving issue-first issue of distributed application transaction Download PDFInfo
- Publication number
- CN114066476A CN114066476A CN202111436757.1A CN202111436757A CN114066476A CN 114066476 A CN114066476 A CN 114066476A CN 202111436757 A CN202111436757 A CN 202111436757A CN 114066476 A CN114066476 A CN 114066476A
- Authority
- CN
- China
- Prior art keywords
- transaction
- main key
- unique main
- distributed
- application
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 18
- 238000003780 insertion Methods 0.000 claims abstract description 27
- 230000037431 insertion Effects 0.000 claims abstract description 27
- 238000012795 verification Methods 0.000 claims description 63
- 238000012545 processing Methods 0.000 claims description 26
- 230000008569 process Effects 0.000 claims description 6
- 230000000903 blocking effect Effects 0.000 claims description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 210000001503 joint Anatomy 0.000 description 1
Classifications
-
- 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/38—Payment protocols; Details thereof
- G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/242—Query formulation
- G06F16/2425—Iterative querying; Query formulation based on the results of a preceding query
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- General Engineering & Computer Science (AREA)
- Mathematical Physics (AREA)
- Accounting & Taxation (AREA)
- Computational Linguistics (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Computing Systems (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention relates to the technical field of information, and particularly provides a method, a device and a storage medium for solving the problem of first-come after-send of distributed application transaction. The invention aims to solve the problem of service errors caused by the fact that the distributed system is sent later and sent first. The technical problem is not solved, the main scheme includes that when a channel end initiates a transaction request containing a unique field, the transaction flow meter T1 and the check table T2 are inserted into the unique field through the same transaction, the distributed application system executes subsequent business logic according to the transaction flow table and then updates an execution result to the check table T2 for the channel end to check, when the channel end passes through the unique field check, data corresponding to the unique field cannot be found in the table T2, the unique field and the execution result fail are inserted into the table T2, when the channel end passes through the same transaction and is inserted into the tables T1 and T2, because the unique primary key in the T2 table already exists, the insertion into the table T1 and the table T2 fails, namely the transaction request fails.
Description
Technical Field
The invention relates to the technical field of information, and particularly provides a method, a device and a storage medium for solving the problem of first-come after-send of distributed application transaction.
Background
The technology is mainly applied to the field of internet distributed micro service architecture, basically, the technology is deployed by multiple machines as a service provider, due to the problem of network or machine resources, the situation that a request sent by a consumer afterwards is processed firstly by the service provider can occur, if a system is not processed properly, certain influence is certainly brought, the problem caused by the fact that the request sent by the consumer firstly occurs in distributed application can be solved through the technology, and the consumer can be ensured to obtain an accurate transaction result.
At present, banks cooperate with various large internet flow platforms and are in butt joint in an API mode, the banks are mainly responsible for outputting bottom-layer products, and channels are responsible for front-end display and sale. Most channels cache transaction data, and customers display local data when checking, so that frequent interaction with banks is reduced, and customer experience is improved.
For a purchase transaction, a bank needs to provide two interfaces, one for purchase and one for verification, and the current channel is to call the purchase interface at first, and if the interface is overtime, the verification interface is called by the original serial number at regular time to acquire the final state of the transaction, so that the purpose of being consistent with the transaction state of the bank is achieved. If the same transaction serial number checking interface receives and processes the transaction and receives the purchase request, the checking interface fails to check the original transaction return and the actual purchase transaction processing is successful, so that the transaction state recorded locally in the channel is inconsistent with the bank.
The problem of prior transaction, namely prior transaction, is verified, and the current channel solutions are mainly two types: firstly, the channel transaction request is verified after being sent for 10 minutes (configurable), on the premise that the transaction request cannot be received after 10 minutes, secondly, a special error code is returned in a verification interface for serial numbers which do not receive the transaction request, the channel still continues to verify the error code, and if the serial numbers are verified back or are the error code after more than 2 hours, failure processing is carried out. Neither of these two solutions solves the problem perfectly and, in extreme cases, there is a risk of inconsistency between the states of the two parties.
To facilitate understanding of the technical problem, the following examples are now made:
the channel party sends a transaction request S containing a unique transaction serial number N to the distributed application, in the distributed application, after one application node A receives the request, if the application node A is blocked, data of the transaction request sent by the channel party cannot be processed, and cannot be written into a transaction serial number of the distributed application, when the request sent by the channel party is overtime and the channel party is spaced for a fixed time, a checking request containing the transaction serial number N is initiated to the distributed application, the transaction processing state is confirmed, at the moment, after the distributed application node B receives the request, data is searched in the transaction serial number N, because the transaction serial number N cannot be checked in the transaction serial number of the distributed serial number, the distributed application returns 'failure' to the channel party, and when the application connection point A is blocked, if the transaction request S is continuously completed, the processing status of the transaction request S in the distributed application is actually "successful", and then the verification result returned to the channel is "failure", which may cause a subsequent arrival and a service error.
It should be noted that, when the channel initiates a verification including a unique primary key (serial number), if corresponding data cannot be found through the unique primary key in the distributed microservice application, there may be 2 situations, one is that a transaction corresponding to the unique primary key (serial number) may not exist, and at this time, a verification result "failure" may be returned, and another is that a transaction corresponding to the unique primary key (serial number) may not be written due to a jam, but the transaction actually exists, and at this time, if a verification result "failure" is returned, the transaction may run counter to the actual situation, because when the jam disappears, the transaction may be executed "successfully" and the verification returns "failure", which is contrary to the actual situation, and causes a business error.
Disclosure of Invention
The invention aims to solve the problem of service errors caused by the fact that the distributed system is sent later and sent first.
In order to solve the technical problems, the invention adopts the following technical means:
a method for solving the problem of the first-time issue of the distributed application transaction comprises a transaction flow meter T1, a check table T2,
when the distributed microservice application is not blocked:
when the distributed micro-service application receives a transaction request containing a unique main key initiated by a channel end, the micro-service application processes the submission of the unique main key insertion transaction, inserts data information containing the unique main key into the transaction flow meter T1 and the insertion verification table T2 for a later-stage application to call and execute, updates the execution result field of the verification table T2 according to the constraint of the unique field as the execution result of the transaction request, and returns the execution result of the transaction request, namely success and failure to the channel end, when the connection between the channel end and the distributed micro-service application is overtime, the channel end initiates a verification request containing the unique main key to the distributed micro-service application because the execution result of the transaction request returned by the distributed micro-service application is obtained, and the distributed micro-service application initiates a verification request containing the unique main key according to the value of the execution result field of the transaction request in the verification table T2 by the unique main key, and returning the value of the execution result field to the channel end;
when a distributed microservice application is blocked:
when the distributed microservice application receives a transaction request which is initiated by the channel end and contains a unique main key, because the blocked microservice application is always waiting for processing the submission of the unique main key insertion transaction, data information containing the unique main key cannot be inserted into the transaction flow meter T1 and the insertion verification table T2 for calling and executing the subsequent application until the connection between the channel end and the distributed microservice application is overtime, and the channel end obtains the transaction request execution result returned by the distributed microservice application, therefore, the channel end initiates a verification request containing the unique main key to the distributed microservice application, the distributed microservice application searches data in the verification table T2 according to the unique main key, at the moment, because the data containing the unique main key cannot exist in the blocked verification table T2, the unique main key cannot be searched, the distributed microservice application returns 'failure' to the channel end, and writing the unique main key and the result of executing 'failure' into the checking table T2, when the distributed microservice application is blocked and the unique main key inserting transaction is carried out, because the unique main key already exists in the checking table T2, the unique main key inserting into the checking table T2 will fail, so that the unique main key can not be inserted into the transaction flow meter T1, and the transaction request can not be called and executed by a later-stage application, namely the transaction request containing the unique main key fails to be executed.
In the above technical solution, the unique primary key insertion transaction means:
the unique main key is inserted into the transaction flow meter T1, and the unique main key and the transaction request processing state are inserted into the verification table T2, and the transaction is submitted in the same transaction, that is, if the unique main key is inserted into either one of the transaction flow meter T1 and the verification table T2, the unique main key is not inserted into either one of the transaction flow meter T1 and the verification table T2.
The invention also provides a device for solving the problem of first-time issue of the distributed application transaction, which comprises a database module, wherein the database module is provided with a transaction flow meter T1 and a checking table T2,
the system also comprises a business non-blocking processing module, when the distributed micro-service application is not blocked:
when the distributed micro-service application receives a transaction request containing a unique main key initiated by a channel end, the micro-service application processes the submission of the unique main key insertion transaction, inserts data information containing the unique main key into the transaction flow meter T1 and the insertion verification table T2 for a later-stage application to call and execute, updates the execution result field of the verification table T2 according to the constraint of the unique field as the execution result of the transaction request, and returns the execution result of the transaction request, namely success and failure to the channel end, when the connection between the channel end and the distributed micro-service application is overtime, the channel end initiates a verification request containing the unique main key to the distributed micro-service application because the execution result of the transaction request returned by the distributed micro-service application is obtained, and the distributed micro-service application initiates a verification request containing the unique main key according to the value of the execution result field of the transaction request in the verification table T2 by the unique main key, and returning the value of the execution result field to the channel end;
the system also comprises a business jam processing module, when the distributed micro-service application is jammed:
when the distributed microservice application receives a transaction request which is initiated by the channel end and contains a unique main key, because the blocked microservice application is always waiting for processing the submission of the unique main key insertion transaction, data information containing the unique main key cannot be inserted into the transaction flow meter T1 and the insertion verification table T2 for calling and executing the subsequent application until the connection between the channel end and the distributed microservice application is overtime, and the channel end obtains the transaction request execution result returned by the distributed microservice application, therefore, the channel end initiates a verification request containing the unique main key to the distributed microservice application, the distributed microservice application searches data in the verification table T2 according to the unique main key, at the moment, because the data containing the unique main key cannot exist in the blocked verification table T2, the unique main key cannot be searched, the distributed microservice application returns 'failure' to the channel end, and writing the unique main key and the result of executing 'failure' into the checking table T2, when the distributed microservice application is blocked and the unique main key inserting transaction is carried out, because the unique main key already exists in the checking table T2, the unique main key inserting into the checking table T2 will fail, so that the unique main key can not be inserted into the transaction flow meter T1, and the transaction request can not be called and executed by a later-stage application, namely the transaction request containing the unique main key fails to be executed.
In the above technical solution, the unique primary key insertion transaction means:
the unique main key is inserted into the transaction flow meter T1, and the unique main key and the transaction request processing state are inserted into the verification table T2, and the transaction is submitted in the same transaction, that is, if the unique main key is inserted into either one of the transaction flow meter T1 and the verification table T2, the unique main key is not inserted into either one of the transaction flow meter T1 and the verification table T2.
The invention also provides a storage medium, wherein the storage medium stores a program for solving the problem of the first-come-after-send of the distributed application transaction, and when the processor executes the program, the method for solving the problem of the first-come-after-send of the distributed application transaction is realized.
Because the invention adopts the technical means, the invention has the following beneficial effects:
1. the method effectively solves the problems that the request distribution type micro-service application initiated by the channel end cannot be processed in time when the distributed system is blocked, and the return result which is contrary to the actual situation can be obtained when the channel end initiates verification.
2. The method has the advantages of small modification amount, low cost, wide application range, no need of locking the table without adding new affairs, almost no influence on the original transaction performance, coverage of all scenes, improvement of the efficiency of the checking interface while solving the problem of the prior issue, inquiry of the original transaction flow meter according to the channel serial number by the logic of the original checking interface, assembly of messages and return, and various logic judgments of different transaction types. After the technical proposal is adopted, the checking interface only needs to inquire the checking table, is separated from the business logic and is suitable for checking all transactions.
Detailed Description
Hereinafter, a detailed description will be given of embodiments of the present invention. While the invention will be described and illustrated in connection with certain specific embodiments thereof, it should be understood that the invention is not limited to those embodiments. Rather, modifications and equivalents of the invention are intended to be included within the scope of the claims.
Furthermore, in the following detailed description, numerous specific details are set forth in order to provide a better understanding of the present invention. It will be understood by those skilled in the art that the present invention may be practiced without these specific details.
Aiming at the problem of the prior transaction after the transaction, the general solution is that only judgment is made according to the channel serial number, if the checking interface receives the serial number firstly and the original transaction return failure is not inquired, the transaction interface receives the channel serial number again and directly returns the channel serial number to fail, and the consumer needs to replace the serial number to initiate the transaction again.
The general service system has an original transaction flow meter T1 for receiving channel requests and recording transaction states, and the specific implementation of the scheme requires only an additional verification table T2, field: the channel number, the channel serial number, the transaction state, the return message, the latest update time (the current date and time is updated in each operation), the channel number and the channel serial number are set as joint main keys, and the purpose of adding the channel number is to prevent different channels from using the same serial number.
The server transaction interface processing logic: receiving a channel serial number A, inserting the channel serial number A into tables T1 and T2, setting the transaction state of the record A in T2 to be P-processing, and submitting the record in the same transaction with the T1 table. If the insertion is successful, the serial number A is received for the first time, the subsequent service logic is continuously executed, the transaction state and the return message recorded by the A in the T2 are updated to be in a final state after the service logic is processed, and the transaction state and the return message are submitted in the same transaction with the normal update of the T1 table; if the insertion fails, the exception of the catch primary key conflict is shown, the record of the flow A of the table T2 is inquired in the exception processing, if the transaction state is P, the flow A is directly returned to the processing, otherwise, the content of the field of the return message is returned.
The server side verifies the interface processing logic: receiving a request serial number A, firstly inquiring whether the serial number exists in the table T2, if so, directly taking the field content of the 'return message' for returning, if not, inserting the table T2, setting the transaction state as F-processing failure, and submitting the transaction. If the insertion fails, the serial number A is received, the transaction interface can be inserted, or the transaction interface can be inserted by the last checking interface, similarly, the exception of the catch primary key conflict exists, in the exception processing, the serial number A record of the table T1 is firstly inquired, if the 'transaction state' is P, the serial number A is directly returned to the processing, otherwise, the field content of the 'return message' is taken to return.
At this time, we simulate three transaction scenarios that are easy to be problematic:
the service provider receives the checking request A firstly, the record A is not checked by the checking table T2, the original transaction is not received or the original transaction is not sent at all, the return fails at the moment, and the direct return failure is realized through the record of the T2 table after the original transaction is received subsequently, so that the consistency of the checking and the transaction return states is ensured;
the service provider receives the transaction and the verification request A at the same time, if the transaction interface is inserted into the table T2 successfully, the insertion of the verification interface fails, and if the transaction is not processed, the verification is returned to the processing to wait for the next verification request; if the check interface is successfully inserted into the table T2, the check interface returns the original transaction failure, the transaction interface enters the exception processing of the insertion failure and directly returns the state of the check table, and the check and the transaction return states are consistent;
the service provider receives two requests with the same serial number at the same time, wherein only one request is successfully inserted into the table T2, the other request goes through the insertion failure logic, if the first transaction is not processed, the second transaction returns to the process, the channel continues to check the interface, and if the first transaction is completed, the second transaction returns the result of the first transaction in idempotent.
Claims (5)
1. A method for solving issue-first issue of distributed application transaction is characterized in that the method comprises a transaction flow meter T1, a check table T2,
when the distributed microservice application is not blocked:
when the distributed micro-service application receives a transaction request containing a unique main key initiated by a channel end, the micro-service application processes the submission of the unique main key insertion transaction, inserts data information containing the unique main key into the transaction flow meter T1 and the insertion verification table T2 for a later-stage application to call and execute, updates the execution result field of the verification table T2 according to the constraint of the unique field as the execution result of the transaction request, and returns the execution result of the transaction request, namely success and failure to the channel end, when the connection between the channel end and the distributed micro-service application is overtime, the channel end initiates a verification request containing the unique main key to the distributed micro-service application because the execution result of the transaction request returned by the distributed micro-service application is obtained, and the distributed micro-service application initiates a verification request containing the unique main key according to the value of the execution result field of the transaction request in the verification table T2 by the unique main key, and returning the value of the execution result field to the channel end;
when a distributed microservice application is blocked:
when the distributed microservice application receives a transaction request which is initiated by the channel end and contains a unique main key, because the blocked microservice application is always waiting for processing the submission of the unique main key insertion transaction, data information containing the unique main key cannot be inserted into the transaction flow meter T1 and the insertion verification table T2 for calling and executing the subsequent application until the connection between the channel end and the distributed microservice application is overtime, and the channel end obtains the transaction request execution result returned by the distributed microservice application, therefore, the channel end initiates a verification request containing the unique main key to the distributed microservice application, the distributed microservice application searches data in the verification table T2 according to the unique main key, at the moment, because the data containing the unique main key cannot exist in the blocked verification table T2, the unique main key cannot be searched, the distributed microservice application returns 'failure' to the channel end, and writing the unique main key and the result of executing 'failure' into the checking table T2, when the distributed microservice application is blocked and the unique main key inserting transaction is carried out, because the unique main key already exists in the checking table T2, the unique main key inserting into the checking table T2 will fail, so that the unique main key can not be inserted into the transaction flow meter T1, and the transaction request can not be called and executed by a later-stage application, namely the transaction request containing the unique main key fails to be executed.
2. The method of resolving a distributed application transaction-before-issue of claim 1,
the only primary key insertion transaction is:
the unique main key is inserted into the transaction flow meter T1, and the unique main key and the transaction request processing state are inserted into the verification table T2, and the transaction is submitted in the same transaction, that is, if the unique main key is inserted into either one of the transaction flow meter T1 and the verification table T2, the unique main key is not inserted into either one of the transaction flow meter T1 and the verification table T2.
3. The device for solving the problem of the distributed application transaction issue first issue is characterized by comprising a database module, wherein the database module is provided with a transaction flow meter T1 and a verification table T2,
the system also comprises a business non-blocking processing module, when the distributed micro-service application is not blocked:
when the distributed micro-service application receives a transaction request containing a unique main key initiated by a channel end, the micro-service application processes the submission of the unique main key insertion transaction, inserts data information containing the unique main key into the transaction flow meter T1 and the insertion verification table T2 for a later-stage application to call and execute, updates the execution result field of the verification table T2 according to the constraint of the unique field as the execution result of the transaction request, and returns the execution result of the transaction request, namely success and failure to the channel end, when the connection between the channel end and the distributed micro-service application is overtime, the channel end initiates a verification request containing the unique main key to the distributed micro-service application because the execution result of the transaction request returned by the distributed micro-service application is obtained, and the distributed micro-service application initiates a verification request containing the unique main key according to the value of the execution result field of the transaction request in the verification table T2 by the unique main key, and returning the value of the execution result field to the channel end;
the system also comprises a business jam processing module, when the distributed micro-service application is jammed:
when the distributed microservice application receives a transaction request which is initiated by the channel end and contains a unique main key, because the blocked microservice application is always waiting for processing the submission of the unique main key insertion transaction, data information containing the unique main key cannot be inserted into the transaction flow meter T1 and the insertion verification table T2 for calling and executing the subsequent application until the connection between the channel end and the distributed microservice application is overtime, and the channel end obtains the transaction request execution result returned by the distributed microservice application, therefore, the channel end initiates a verification request containing the unique main key to the distributed microservice application, the distributed microservice application searches data in the verification table T2 according to the unique main key, at the moment, because the data containing the unique main key cannot exist in the blocked verification table T2, the unique main key cannot be searched, the distributed microservice application returns 'failure' to the channel end, and writing the unique main key and the result of executing 'failure' into the checking table T2, when the distributed microservice application is blocked and the unique main key inserting transaction is carried out, because the unique main key already exists in the checking table T2, the unique main key inserting into the checking table T2 will fail, so that the unique main key can not be inserted into the transaction flow meter T1, and the transaction request can not be called and executed by a later-stage application, namely the transaction request containing the unique main key fails to be executed.
4. The apparatus for resolving a distributed application transaction issue prior issue of claim 1,
the only primary key insertion transaction is:
the unique main key is inserted into the transaction flow meter T1, and the unique main key and the transaction request processing state are inserted into the verification table T2, and the transaction is submitted in the same transaction, that is, if the unique main key is inserted into either one of the transaction flow meter T1 and the verification table T2, the unique main key is not inserted into either one of the transaction flow meter T1 and the verification table T2.
5. A storage medium storing a program for resolving a distributed application transaction issue first issue, the program when executed by a processor implementing a method for resolving a distributed application transaction issue first issue as claimed in claims 1-2.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111436757.1A CN114066476A (en) | 2021-11-30 | 2021-11-30 | Method, device and storage medium for solving issue-first issue of distributed application transaction |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111436757.1A CN114066476A (en) | 2021-11-30 | 2021-11-30 | Method, device and storage medium for solving issue-first issue of distributed application transaction |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114066476A true CN114066476A (en) | 2022-02-18 |
Family
ID=80277190
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111436757.1A Pending CN114066476A (en) | 2021-11-30 | 2021-11-30 | Method, device and storage medium for solving issue-first issue of distributed application transaction |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114066476A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115665175A (en) * | 2022-12-26 | 2023-01-31 | 江苏苏宁银行股份有限公司 | Distributed gateway system and transaction processing method thereof |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107194008A (en) * | 2017-06-19 | 2017-09-22 | 无锡井通网络科技有限公司 | A kind of distributed system quickly updates verification method |
| CN108459919A (en) * | 2018-03-29 | 2018-08-28 | 中信百信银行股份有限公司 | A kind of distributed transaction processing method and device |
| CN109359159A (en) * | 2018-09-30 | 2019-02-19 | 深圳前海微众银行股份有限公司 | Distributed storage method, system and equipment |
| CN111722946A (en) * | 2020-06-28 | 2020-09-29 | 深圳壹账通智能科技有限公司 | Distributed transaction processing method and device, computer equipment and readable storage medium |
| CN113486033A (en) * | 2021-07-02 | 2021-10-08 | 中国建设银行股份有限公司 | Method, apparatus, device and computer readable medium for controlling transaction consistency |
| CN115665175A (en) * | 2022-12-26 | 2023-01-31 | 江苏苏宁银行股份有限公司 | Distributed gateway system and transaction processing method thereof |
-
2021
- 2021-11-30 CN CN202111436757.1A patent/CN114066476A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107194008A (en) * | 2017-06-19 | 2017-09-22 | 无锡井通网络科技有限公司 | A kind of distributed system quickly updates verification method |
| CN108459919A (en) * | 2018-03-29 | 2018-08-28 | 中信百信银行股份有限公司 | A kind of distributed transaction processing method and device |
| CN109359159A (en) * | 2018-09-30 | 2019-02-19 | 深圳前海微众银行股份有限公司 | Distributed storage method, system and equipment |
| CN111722946A (en) * | 2020-06-28 | 2020-09-29 | 深圳壹账通智能科技有限公司 | Distributed transaction processing method and device, computer equipment and readable storage medium |
| CN113486033A (en) * | 2021-07-02 | 2021-10-08 | 中国建设银行股份有限公司 | Method, apparatus, device and computer readable medium for controlling transaction consistency |
| CN115665175A (en) * | 2022-12-26 | 2023-01-31 | 江苏苏宁银行股份有限公司 | Distributed gateway system and transaction processing method thereof |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115665175A (en) * | 2022-12-26 | 2023-01-31 | 江苏苏宁银行股份有限公司 | Distributed gateway system and transaction processing method thereof |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111752957B (en) | Sale locking method and system based on caching | |
| CN113396407A (en) | System and method for augmenting database applications using blockchain techniques | |
| US7917651B2 (en) | Apparatus, system, and method for asynchronous complex inbound transactions from SAP applications using service oriented architecture | |
| CN105989059B (en) | Data record checking method and device | |
| CN111259083A (en) | Distributed transaction processing method and device | |
| EP2550632A1 (en) | System with multiple conditional commit databases | |
| US20050193037A1 (en) | Peer-to-peer replication member initialization and deactivation | |
| CN111522631A (en) | Distributed transaction processing method, device, server and medium | |
| CN108762895B (en) | Method and device for processing distributed transaction | |
| WO2011120452A2 (en) | Method for updating data and control apparatus thereof | |
| US20190243820A1 (en) | Utilizing nonce table to resolve concurrent blockchain transaction failure | |
| CN113742043B (en) | Asynchronous splitting method for server back-end tasks | |
| CN113112344B (en) | Service processing method, device, storage medium and computer program product | |
| US20130318059A1 (en) | Transfer of data from transactional data sources to partitioned databases in restartable environment | |
| CN114066476A (en) | Method, device and storage medium for solving issue-first issue of distributed application transaction | |
| CN108009916B (en) | Transaction dynamic adjustment-based universal payment accounting method and system | |
| CN106845966B (en) | Method and device for processing goods payment information | |
| CN114595071A (en) | Security dealer core transaction data synchronization system and method | |
| CN115858489A (en) | Transaction processing method and device based on data migration, computer equipment and medium | |
| CN113191901B (en) | Transaction service processing method, device, equipment and storage medium | |
| CN114612204A (en) | Account checking method and device | |
| CN108564424B (en) | Method for reducing errors in transaction information query and payment transaction system | |
| US8732041B2 (en) | Replicating data in financial systems | |
| CN112463407A (en) | Message transmission and consumption method | |
| JP2001306380A (en) | Two-phase commitment evading system and its program recording medium |
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 |