Method and device for retrying online transaction failureTechnical Field
The invention relates to the technical field of online transaction failure retry, in particular to a method and a device for online transaction failure retry.
Background
An online transaction processing system may fail to process a transaction for various reasons (including business layer reasons and system layer reasons) when processing a request, such as a common transfer transaction, a transaction failure due to network jitter between an application server and a database server, a transaction failure due to a lock conflict in an account table in a database, and a transaction failure due to insufficient account balance.
From the perspective of transaction idempotent, for a transaction to be processed (whether the state is processing success or processing failure), the results of multiple retry processes must be consistent with the first process results; theoretically, this is indeed a superior solution; in practical application scenarios, however, it is required to analyze the error cause of failed transactions, and for some specific error causes, online transaction processing systems are required to support failed transaction retries.
Transaction idempotent is an excellent theoretical model and solution, and transaction retries are the supplement and enrichment of the transaction idempotent in the actual application scene; the two are not opposite, but together form a complete system; in the flow of transaction retries, the principle of transaction idempotent is still adhered to; for example, for a failed transaction meeting the retry condition, the retry request and the original request must also satisfy the transaction idempotent principle (transaction serial number idempotent, request report Wen Mideng, scene customization idempotent).
Precondition for transaction retry: first, only for failed normal transactions (non-impact orthogonal easy, non-proof transactions), this mainly accounts for the transaction type of transaction retries; secondly, the error cause must meet retry requirements, which mainly account for the scenario of transaction retries; again, the retry transaction request and the original transaction request must conform to the principle of transaction idempotent, which mainly achieves precise control of the implementation of the transaction.
In the prior art, the client can exchange a transaction serial number to support the function of failed transaction retry. After the online transaction processing fails, the client identifies a retry scene according to the error code in the returned message, and the new transaction serial number is reused to initiate retry.
Because the prior art mainly uses the client to control the main logic of the failed retry transaction, the recognition and judgment logic of the failed retry transaction is relatively scattered (peripheral systems using the functions are all needed to be realized respectively), and the centralized and unified control of the server is lost; or the client uses the new transaction flow to resend the transaction, the server can process the new transaction, and the management and control of the server on the transaction can be bypassed, so that the association relationship between the original transaction and the retried transaction can not be managed.
Disclosure of Invention
The present invention is directed to a method and apparatus for online transaction failure retry, which solve the above-mentioned problems in the prior art.
In order to achieve the above purpose, the present invention provides the following technical solutions:
An online transaction failed retry device comprises a failed retry transaction identification module, a transaction layer configuration retry error code and a peripheral system layer configuration retry error code, wherein the failed retry transaction identification module comprises a transaction configuration table, a transaction registry, a transaction retry check table and a transaction idempotent check table, the transaction configuration table comprises a default retry error code list, a default maximum retry number and a default minimum retry interval, the transaction registry comprises a retry error code list, a maximum retry number and a minimum retry interval, and the transaction layer is a system layer and the peripheral system layer is a channel layer.
As still further aspects of the invention: the default retriable error code list is used for precisely controlling which error codes of the transaction can be retried, the default retriable error code list is the default control of the transaction layer, and when the control of the peripheral system layer is empty, the default retriable error code list is effective; the default maximum retry number is used for controlling the maximum number of failed retries, and avoiding infinite failed retries; the default minimum retry interval is used to control the period and frequency of failed retries, and avoid retries from being too frequent.
As still further aspects of the invention: the transaction registry is used for realizing failed retry control of a peripheral system layer, and the priority of the control logic of the peripheral system layer (channel layer) is higher than that of the transaction layer (system layer); the relationship between the peripheral system layer control logic and the transaction layer control logic is a relationship of two alternatives, and cannot be effective at the same time, namely, for a determined control point of failed retry transaction, the peripheral system layer is effective, or the transaction layer is effective, but cannot be effective at the same time.
As still further aspects of the invention: the transaction retry checklist is used for recording related data of failed retry transactions.
A method for failed retry of an online transaction, comprising failed retry determination logic and failed retry execution logic, the failed retry determination logic comprising operations on a transaction configuration table, a transaction registry, and a transaction retry checklist, the operational flow comprising the steps of:
s11, when online transaction starts, executing transaction idempotent logic, and then checking preconditions of failed retry: the original transaction is a common transaction, the state of the original transaction is "processing failure", the original transaction request is idempotent with the current request, wherein the common transaction is a non-positive transaction and a non-verification transaction, and if the common transaction is not satisfied, the normal transaction returns to "retry impossible";
S12, inquiring a transaction registry according to the transaction code and the peripheral system ID, and acquiring related control parameters of a peripheral system layer, wherein the method comprises the following steps: a retried error code list, a maximum number of retries, and a minimum retry interval;
s13, inquiring a transaction configuration table according to the transaction code to acquire related control parameters of a transaction layer, wherein the method comprises the following steps: defaulting the retry error code list, default maximum retry times, default minimum retry intervals;
S14, judging the error code: firstly checking whether a 'retry error code list' of a peripheral system layer is empty, and if so, using a 'default retry error code list' of a transaction layer to detect whether a current transaction error code is in the retry error code list; if not, then use the "retry error code list" of the peripheral system layer to detect;
The judgment and detection results are as follows: if the current transaction error code is not contained in the list, the transaction is not retried, and the 'unable to retry' is returned, otherwise, further judgment is needed;
S15, inquiring a transaction retry detection table according to the transaction serial number, acquiring the retry times and the last retry time, and defaulting to be empty if the retry times and the last retry time are not found;
S16, judging the retry times: judging whether the maximum retry number of the peripheral system layer is empty or not; if yes, comparing and judging the default maximum retry times of the transaction layer with the retry times; if not, comparing and judging the maximum retry times of the peripheral system layer with the retry times; if the retry number > =retry number threshold, returning to the state that the retry cannot be performed, otherwise, further judgment is needed;
S17, judging for the retry interval: judging whether the minimum retry interval of the peripheral system layer is empty or not; if yes, comparing and judging the default minimum retry interval of the transaction layer with the last retry time and the current time; if not, comparing and judging the minimum retry interval of the peripheral system layer with the last retry time and the current time; if the last retry time+retry interval threshold > = current time, return "unable to retry"; otherwise, return "retry possible".
As still further aspects of the invention: the execution logic of the failed retry comprises operations of an idempotent check list and a transaction retry check list, and the operation flow comprises the following steps:
s21, updating the transaction state of a transaction idempotent checklist according to the transaction serial number by using independent transactions, and modifying from transaction processing failure to transaction processing;
s22, if the operation fails, a retry request for concurrent processing exists, and the original transaction retry is returned; if the operation is successful, entering a normal business logic processing flow;
S23, after the normal business logic processing flow is finished, registering a transaction retry check list;
S24, if the first registration is performed, assigning values to all the fields, and executing an inserting operation;
And S25, if the first registration is not performed, assigning values for the two fields of the retried times and the last retried time, and executing the updating operation.
Compared with the prior art, the invention has the beneficial effects that:
The invention sets the failed retry transaction identification module, the transaction layer configured retry error code and the peripheral system layer configured retry error code, can realize unified control, centralized management and flexible configuration of the service end of the failed retry identification logic, and can accurately correlate the original transaction with the retry transaction based on transaction idempotent so as to realize management and control of the retry transaction.
Drawings
FIG. 1 is a diagram of a transaction configuration table for a transaction failed retry in a method for online transaction failed retries;
FIG. 2 is a diagram of a transaction registry of a transaction failure retry in a method of online transaction failure retry;
FIG. 3 is a diagram of a transaction retry checklist for a failed transaction retry in a method for an online transaction failed retry;
FIG. 4 is a schematic diagram of an idempotent checklist of transactions in a method of online transaction failure retries;
FIG. 5 is a logic flow diagram illustrating a transaction failure retry determination in an online transaction failure retry method;
FIG. 6 is a logic flow diagram illustrating a method of performing a failed transaction retry in an online transaction failed retry method.
Detailed Description
In the embodiment of the invention, the device for the failed retry of the online transaction comprises a failed retry transaction identification module, a transaction layer configuration retry error code and a peripheral system layer configuration retry error code, wherein the failed retry transaction identification module comprises a transaction configuration table, a transaction registry, a transaction retry check table and a transaction idempotent check table, the transaction configuration table comprises a default retry error code list, a default maximum retry number and a default minimum retry interval, and the transaction registry comprises a retry error code list, a maximum retry number and a minimum retry interval, wherein the transaction layer is a system layer, and the peripheral system layer is a channel layer.
Preferably, the default retriable error code list is used for precisely controlling which error codes of the transaction can be retried, the default retriable error code list is the default control of the transaction layer, and when the control of the peripheral system layer is empty, the default retriable error code list is effective; the default maximum retry number is used for controlling the maximum number of failed retries, and avoiding infinite failed retries; the default minimum retry interval is used to control the period and frequency of failed retries, and avoid retries from being too frequent.
Preferably, the transaction registry is configured to implement failed retry control at a peripheral system layer, and the peripheral system layer (channel layer) control logic has a higher priority than the transaction layer (system layer); the relationship between the peripheral system layer control logic and the transaction layer control logic is a relationship of two alternatives, and cannot be effective at the same time, namely, for a determined control point of failed retry transaction, the peripheral system layer is effective, or the transaction layer is effective, but cannot be effective at the same time.
Preferably, the transaction retry check table is used to record data related to failed retry transactions.
A method for failed retry of an online transaction, comprising failed retry determination logic and failed retry execution logic, the failed retry determination logic comprising operations on a transaction configuration table, a transaction registry, and a transaction retry checklist, the operational flow comprising the steps of:
S11, when an online transaction starts, executing transaction idempotent logic, and then checking preconditions of failed retry: the original transaction is a common transaction, the state of the original transaction is "processing failure", the original transaction request is idempotent with the current request, wherein the common transaction is a non-positive transaction and a non-verification transaction, and if the common transaction is not satisfied, the normal transaction returns to "retry impossible";
s12, in 102, inquiring a transaction registry according to the transaction code and the peripheral system ID, and acquiring related control parameters of the peripheral system layer, wherein the method comprises the following steps: a retried error code list, a maximum number of retries, and a minimum retry interval;
S13, in 103, inquiring a transaction configuration table according to the transaction code to acquire related control parameters of a transaction layer, wherein the method comprises the following steps: defaulting the retry error code list, default maximum retry times, default minimum retry intervals;
S14—in 104—determine for error code: firstly checking whether a 'retry error code list' of a peripheral system layer is empty, and if so, using a 'default retry error code list' of a transaction layer to detect whether a current transaction error code is in the retry error code list; if not, then use the "retry error code list" of the peripheral system layer to detect;
The judgment and detection results are as follows: if the current transaction error code is not contained in the list, the transaction is not retried, and the 'unable to retry' is returned, otherwise, further judgment is needed;
s15, inquiring a transaction retry detection table according to the transaction serial number, acquiring the retry times and the last retry time, and defaulting to be empty if the retry times and the last retry time cannot be found;
s16—determine in 106—for the number of retries: judging whether the maximum retry number of the peripheral system layer is empty or not; if yes, comparing and judging the default maximum retry times of the transaction layer with the retry times; if not, comparing and judging the maximum retry times of the peripheral system layer with the retry times; if the retry number > =retry number threshold, returning to the state that the retry cannot be performed, otherwise, further judgment is needed;
S17—in 107—determine for retry interval: judging whether the minimum retry interval of the peripheral system layer is empty or not; if yes, comparing and judging the default minimum retry interval of the transaction layer with the last retry time and the current time; if not, comparing and judging the minimum retry interval of the peripheral system layer with the last retry time and the current time; if the last retry time+retry interval threshold > = current time, return "unable to retry"; otherwise, return "retry possible".
As still further aspects of the invention: the execution logic of the failed retry comprises operations of an idempotent check list and a retry check list of the transaction, and in fig. 6, the operation flow comprises the following steps:
S21, in 201, updating the transaction state of a transaction idempotent checklist according to a transaction serial number by using independent transactions, and modifying from transaction processing failure to transaction processing;
S22, if the operation fails, a retry request for concurrent processing exists, and the original transaction retry is returned; if the operation is successful, entering a normal business logic processing flow;
S23, after the normal business logic processing flow is finished, registering a transaction retry checklist is required;
S24, if the first registration is performed, assigning values to all the fields, and executing an inserting operation in the step 204;
S25, in 205, if the registration is not the first time, assigning values to the two fields of the retried times and the last retried time, and executing the updating operation. .
The foregoing description is only a preferred embodiment of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art, who is within the scope of the present invention, should make equivalent substitutions or modifications according to the technical solution of the present invention and the inventive concept thereof, and should be covered by the scope of the present invention.