CN117082149A - Transaction processing method, device, electronic equipment and computer readable medium - Google Patents
Transaction processing method, device, electronic equipment and computer readable medium Download PDFInfo
- Publication number
- CN117082149A CN117082149A CN202311070883.9A CN202311070883A CN117082149A CN 117082149 A CN117082149 A CN 117082149A CN 202311070883 A CN202311070883 A CN 202311070883A CN 117082149 A CN117082149 A CN 117082149A
- Authority
- CN
- China
- Prior art keywords
- function module
- transaction
- identifier
- message
- transaction processing
- 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
- 238000003672 processing method Methods 0.000 title claims abstract description 27
- 238000012545 processing Methods 0.000 claims abstract description 122
- 238000000034 method Methods 0.000 claims abstract description 56
- 230000008569 process Effects 0.000 claims abstract description 33
- 230000004044 response Effects 0.000 claims abstract description 25
- 238000004590 computer program Methods 0.000 claims description 16
- 238000012544 monitoring process Methods 0.000 claims 2
- 230000006870 function Effects 0.000 description 213
- 238000010586 diagram Methods 0.000 description 13
- 238000004891 communication Methods 0.000 description 7
- 230000007246 mechanism Effects 0.000 description 7
- 230000003287 optical effect Effects 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 230000000644 propagated effect Effects 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000011144 upstream manufacturing Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/62—Establishing a time schedule for servicing the requests
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/55—Push-based network services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/566—Grouping or aggregating service requests, e.g. for unified processing
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Debugging And Monitoring (AREA)
Abstract
The application discloses a transaction processing method, a device, electronic equipment and a computer readable medium, which relate to the technical field of task scheduling, and one specific embodiment comprises the steps of responding to a transaction failure processing request and acquiring a corresponding transaction identifier and a function module identifier; calling a message queue to determine corresponding transaction messages according to the transaction identifications and the function module identifications; executing retry logic based on the transaction message, and generating a functional module transaction success message in response to the retry success; determining a target function module identifier, and sending a function module transaction success message to a target function module corresponding to the target function module identifier so as to execute the next transaction processing; and responding to the target function module identification corresponding to the terminal function module, acquiring a transaction processing result after the next transaction processing is successfully executed, and ending the transaction processing process. Thereby improving the success rate and efficiency of processing the failed transaction.
Description
Technical Field
The present application relates to the field of task scheduling technologies, and in particular, to a transaction processing method, a transaction processing device, an electronic device, and a computer readable medium.
Background
In some transaction scenes needing to ensure success, the retry of the scanning task is a more traditional retry mechanism, the database is scanned regularly, if abnormal records exist, the retry processing is performed, and the transaction with low requirements on processing efficiency and real-time performance can be met. This approach typically handles exception records at fixed cycles. In order to ensure that multiple retries are not performed on the same transaction within the same time period, it is necessary to ensure that the time interval for the retries is sufficiently large, resulting in low business processing efficiency.
Disclosure of Invention
In view of this, embodiments of the present application provide a transaction processing method, apparatus, electronic device, and computer readable medium, which can solve the problem that in the prior art, in order to ensure that multiple retries are not performed on the same transaction within the same time period, it is required to ensure that the time interval for retries is sufficiently large, so that the service processing efficiency is low.
To achieve the above object, according to one aspect of the embodiments of the present application, there is provided a transaction processing method including:
responding to the transaction failure processing request, and acquiring a corresponding transaction identifier and a function module identifier;
calling a message queue to determine corresponding transaction messages according to the transaction identifications and the function module identifications;
executing retry logic based on the transaction message, and generating a functional module transaction success message in response to the retry success;
determining a target function module identifier, and sending a function module transaction success message to a target function module corresponding to the target function module identifier so as to execute the next transaction processing;
and responding to the target function module identification corresponding to the terminal function module, acquiring a transaction processing result after the next transaction processing is successfully executed, and ending the transaction processing process.
Optionally, after acquiring the corresponding transaction identifier and the function module identifier, the method further includes:
and executing a function module expansion process in response to the fact that the function module identifier does not exist in the preset identifier list, further determining the position corresponding to the function module identifier, and logically inserting the function module corresponding to the function module identifier into the position.
Optionally, executing the function module extension process includes:
determining a publisher identifier and a subscriber identifier corresponding to the function module identifier;
and adding a subscription theme, and executing function module expansion based on the subscription theme, the publisher identifier and the subscriber identifier.
Optionally, executing the function module extension process includes:
responding to the expansion failure of the functional module, generating an asynchronous expansion task, and sending the asynchronous expansion task to an asynchronous task pool;
the task execution thread is invoked to execute each asynchronous task in the asynchronous task pool.
Optionally, after executing the retry logic based on the transaction message, the method further comprises:
in response to the retry failure, the transaction message is not consumed, and the retry is performed after waiting for the next time the transaction message is monitored.
Optionally, determining the target function module identifier includes:
acquiring a corresponding function module identification pool based on the transaction identification;
and determining the next function module identifier which is connected with the function module identifier in series and is adjacent to the function module identifier in the function module identifier pool as a target function module identifier.
Optionally, the transaction processing method further comprises:
and when the target function module identifier is the last function module identifier in the function module identifier pool, determining that the target function module identifier corresponds to the tail end function module.
In addition, the application also provides a transaction processing device, which comprises:
the identification acquisition unit is configured to respond to the transaction failure processing request and acquire a corresponding transaction identification and a function module identification;
a transaction message determining unit configured to invoke the message queue to determine a corresponding transaction message according to the transaction identifier and the function module identifier;
a message generation unit configured to execute retry logic based on the transaction message, and generate a functional module transaction success message in response to the retry success;
the message sending unit is configured to determine a target function module identifier, send a function module transaction success message to a target function module corresponding to the target function module identifier, and execute the next transaction processing;
and the transaction processing result acquisition unit is configured to respond to the target function module identification corresponding to the tail end function module, acquire a transaction processing result after the next transaction processing is successfully executed, and end the transaction processing process.
Optionally, the transaction processing device further comprises a functional module extension unit configured to:
and executing a function module expansion process in response to the fact that the function module identifier does not exist in the preset identifier list, further determining the position corresponding to the function module identifier, and logically inserting the function module corresponding to the function module identifier into the position.
Optionally, the function module extension unit is further configured to:
determining a publisher identifier and a subscriber identifier corresponding to the function module identifier;
and adding a subscription theme, and executing function module expansion based on the subscription theme, the publisher identifier and the subscriber identifier.
Optionally, the function module extension unit is further configured to:
responding to the expansion failure of the functional module, generating an asynchronous expansion task, and sending the asynchronous expansion task to an asynchronous task pool;
the task execution thread is invoked to execute each asynchronous task in the asynchronous task pool.
Optionally, the message generating unit is further configured to:
in response to the retry failure, the transaction message is not consumed, and the retry is performed after waiting for the next time the transaction message is monitored.
Optionally, the messaging unit is further configured to:
acquiring a corresponding function module identification pool based on the transaction identification;
and determining the next function module identifier which is connected with the function module identifier in series and is adjacent to the function module identifier in the function module identifier pool as a target function module identifier.
Optionally, the transaction processing result acquisition unit is further configured to:
and when the target function module identifier is the last function module identifier in the function module identifier pool, determining that the target function module identifier corresponds to the tail end function module.
In addition, the application also provides a transaction processing electronic device, which comprises: one or more processors; and a storage means for storing one or more programs which, when executed by the one or more processors, cause the one or more processors to implement the transaction processing method as described above.
In addition, the application also provides a computer readable medium, on which a computer program is stored, which when executed by a processor implements the transaction processing method as described above.
To achieve the above object, according to still another aspect of an embodiment of the present application, there is provided a computer program product.
A computer program product of an embodiment of the present application includes a computer program, which when executed by a processor implements a transaction processing method provided by the embodiment of the present application.
One embodiment of the above application has the following advantages or benefits: the method comprises the steps of responding to a transaction failure processing request to obtain a corresponding transaction identifier and a corresponding function module identifier; calling a message queue to determine corresponding transaction messages according to the transaction identifications and the function module identifications; executing retry logic based on the transaction message, and generating a functional module transaction success message in response to the retry success; determining a target function module identifier, and sending a function module transaction success message to a target function module corresponding to the target function module identifier so as to execute the next transaction processing; and responding to the target function module identification corresponding to the terminal function module, acquiring a transaction processing result after the next transaction processing is successfully executed, and ending the transaction processing process. Thereby improving the success rate and efficiency of processing the failed transaction.
Further effects of the above-described non-conventional alternatives are described below in connection with the embodiments.
Drawings
The drawings are included to provide a better understanding of the application and are not to be construed as unduly limiting the application. Wherein:
FIG. 1 is a schematic diagram of the main flow of a transaction processing method according to one embodiment of the application;
FIG. 2 is a schematic diagram of the main flow of a transaction processing method according to one embodiment of the application;
FIG. 3 is a schematic diagram of the main flow of a transaction processing method according to one embodiment of the application;
FIG. 4 is a schematic diagram of the main units of a transaction processing device according to an embodiment of the application;
FIG. 5 is an exemplary system architecture diagram in which embodiments of the present application may be applied;
fig. 6 is a schematic diagram of a computer system suitable for use in implementing an embodiment of the application.
Detailed Description
Exemplary embodiments of the present application will now be described with reference to the accompanying drawings, in which various details of the embodiments of the present application are included to facilitate understanding, and are to be considered merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the application. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness. In the technical scheme of the application, the aspects of acquisition, analysis, use, transmission, storage and the like of the related user personal information all meet the requirements of related laws and regulations, are used for legal and reasonable purposes, are not shared, leaked or sold outside the aspects of legal use and the like, and are subjected to supervision and management of a supervision department. Necessary measures should be taken for the personal information of the user to prevent illegal access to such personal information data, ensure that personnel having access to the personal information data comply with the regulations of the relevant laws and regulations, and ensure the personal information of the user. Once these user personal information data are no longer needed, the risk should be minimized by limiting or even prohibiting the data collection and/or deletion.
User privacy is protected by de-identifying data when used, including in some related applications, such as by removing a particular identifier, controlling the amount or specificity of stored data, controlling how data is stored, and/or other methods.
Fig. 1 is a schematic diagram of the main flow of a transaction processing method according to an embodiment of the present application, and as shown in fig. 1, the transaction processing method includes:
step S101, responding to a transaction failure processing request, and acquiring a corresponding transaction identifier and a corresponding function module identifier.
In this embodiment, the execution body (for example, may be a server) of the transaction processing method may detect whether a transaction failure processing request is received by means of a wired connection or a wireless connection. When a transaction failure processing request is received, the execution body can acquire a transaction identifier and a function module identifier carried in the request. With the increasing complexity of the transaction, the functional modules of the transaction are increased, the transaction is split into a plurality of functional modules through a message queue retry mechanism, the plurality of functional modules of the transaction can be respectively retried, the condition of retried from the beginning is avoided, and the system has a plurality of characteristics of stability, expandability and the like. The transaction identifier may be, for example, a transaction serial number or a transaction type number, which is not specifically limited in the embodiment of the present application. The function module identifier may be a function module number or a function module name corresponding to the transaction failure corresponding to the transaction identifier. Each transaction function module may access the message queue to consume messages in the message queue.
Step S102, a message queue is called to determine corresponding transaction messages according to the transaction identifications and the function module identifications.
The message queue may contain any transaction message that fails. The transaction information corresponding to the transaction failure processing request in the information queue can be determined through the transaction identifier and the function module identifier carried in the transaction failure processing request. The method specifically can be that a corresponding function module identification list in a message queue is determined according to the transaction identification, and when the function module identification exists in the function module identification list, transaction messages corresponding to the function module identification in the message queue are acquired.
Step S103, executing retry logic based on the transaction message, and generating a function module transaction success message in response to the retry success.
Specifically, after executing the retry logic based on the transaction message, the method further comprises: in response to the retry failure, the transaction message is not consumed, and the retry is performed after waiting for the next time the transaction message is monitored.
After invoking the retry procedure to perform a transaction retry based on the transaction message, the executing body may acquire retry result data, and when the acquired retry result data corresponds to a retry failure, the executing body does not consume the transaction message, and performs a retry after listening to the transaction message next time. And when the obtained retry result data corresponds to the success of the retry, the transaction result data of the functional module is sent to the next functional module to further carry out transaction processing.
Step S104, the target function module identification is determined, and a function module transaction success message is sent to the target function module corresponding to the target function module identification so as to execute the next transaction processing.
Specifically, determining the target function module identifier includes: acquiring a corresponding function module identification pool based on the transaction identification; and determining the next function module identifier which is connected with the function module identifier in series and is adjacent to the function module identifier in the function module identifier pool as a target function module identifier.
By way of example, the pool of function module identifiers may include sequentially connected function modules A, B, C. The function module identifier corresponding to the transaction failure processing request in the embodiment of the present application may be, for example, the function module B, where the corresponding next function module identifier is the function module C, and the target function module identifier is the function module C. The transaction processing speed and the transaction processing accuracy can be increased by accurately and rapidly determining the target function module identification.
Step S105, responding to the target function module identification corresponding to the end function module, obtaining a transaction processing result after the next transaction processing is successfully executed, and ending the transaction processing process.
Specifically, the transaction processing method further includes: and when the target function module identifier is the last function module identifier in the function module identifier pool, determining that the target function module identifier corresponds to the tail end function module.
The method comprises the steps of splitting a transaction into a plurality of functional modules, obtaining a transaction processing result of the functional module after the transaction processing of the functional module is successfully executed when the transaction is processed to the functional module corresponding to the last functional module identifier of the corresponding functional module identifier pool, and ending the transaction processing process.
In the embodiment, corresponding transaction identifications and function module identifications are obtained by responding to a transaction failure processing request; calling a message queue to determine corresponding transaction messages according to the transaction identifications and the function module identifications; executing retry logic based on the transaction message, and generating a functional module transaction success message in response to the retry success; determining a target function module identifier, and sending a function module transaction success message to a target function module corresponding to the target function module identifier so as to execute the next transaction processing; and responding to the target function module identification corresponding to the terminal function module, acquiring a transaction processing result after the next transaction processing is successfully executed, and ending the transaction processing process. Thereby improving the success rate and efficiency of processing the failed transaction.
Fig. 2 is a schematic flow chart of a transaction processing method according to an embodiment of the present application, and as shown in fig. 2, the transaction processing method includes:
step S201, responding to the transaction failure processing request, and acquiring a corresponding transaction identifier and a corresponding function module identifier.
Step S202, executing a function module expansion process in response to the fact that the function module identifier does not exist in the preset identifier list, further determining a position corresponding to the function module identifier, and logically inserting the function module corresponding to the function module identifier into the position.
The function modules are connected in series by unique identifiers of transactions, and if functions need to be expanded, only one topic needs to be added, and a publisher and a subscriber are determined. When the function module identifier corresponding to the transaction failure processing request does not exist in the preset identifier list, the execution main body can execute the function module expansion process, and can determine the position A of the function module identifier in the preset identifier list based on the type of the function module corresponding to the function module identifier, and insert the function module corresponding to the function module identifier into the position A in the preset identifier list.
Specifically, executing the function module expansion process includes: determining a publisher identifier and a subscriber identifier corresponding to the function module identifier; and adding a subscription theme, and executing function module expansion based on the subscription theme, the publisher identifier and the subscriber identifier.
By way of example, subscription topics may be pushed when a transaction fails, or may be pushed when a transaction retries. The execution subject does not specifically limit the pushing timing of the subscription subject.
Specifically, executing the function module expansion process includes: responding to the expansion failure of the functional module, generating an asynchronous expansion task, and sending the asynchronous expansion task to an asynchronous task pool; the task execution thread is invoked to execute each asynchronous task in the asynchronous task pool.
When the function module expansion fails, the execution body can generate an asynchronous expansion task based on the function module expansion and send the asynchronous expansion task to the asynchronous task pool so as to call a task execution thread to execute the corresponding asynchronous task when the current time reaches the task execution time corresponding to any one of the asynchronous tasks in the asynchronous task pool. Thereby ensuring the success rate of the expansion of the functional module.
Step S203, call the message queue to determine the corresponding transaction message according to the transaction identifier and the function module identifier.
The message queue may store transaction messages corresponding to failed transactions, where the failed transactions in the message queue may include failed transaction identifications and function module identifications corresponding to function modules when the transaction failure occurred. Thus, corresponding transaction messages in the message queue can be determined according to the transaction identification and the function module identification.
Step S204, executing retry logic based on the transaction message, and generating a function module transaction success message in response to the retry success.
The transaction message contains a unique identification of the transaction and data required for the transaction. The execution body may execute retry logic based on the unique identification of the transaction in the transaction message and the data required for the transaction to generate a functional module transaction success message when the retry is successful.
Step S205, the target function module identification is determined, and a function module transaction success message is sent to the target function module corresponding to the target function module identification to execute the next transaction processing.
After determining the target function module identifier, the execution body may send a function module transaction success message corresponding to the previous function module to the target function module corresponding to the target function module identifier, so that the target function module executes the next transaction processing.
Step S206, responding to the target function module identification corresponding to the end function module, obtaining a transaction processing result after the next transaction processing is successfully executed, and ending the transaction processing process.
The target function module identifier may be an identifier corresponding to the last function module in the transaction function module processing chain, that is, when the target function module identifier corresponds to the end function module, after the next transaction processing in step S205 is successful, a transaction processing result is obtained, the next transaction processing is not performed, and the transaction failure processing process is ended. The failed transaction is split into the plurality of functional modules, so that the plurality of functional modules of the transaction can be respectively retried, the situation that the transaction is retried from the beginning when the transaction failure occurs is avoided, the transaction functional modules can be expanded, and the situation of the transaction failure can be stably processed.
Fig. 3 is a schematic view of an application scenario of a transaction processing method according to an embodiment of the present application. The transaction processing method provided by the embodiment of the application is applied to the scene of processing the failed transaction. In the embodiment of the present application, each transaction function module may access a message queue, as shown in fig. 3, fig. 3 illustrates a retry mechanism of 3 function modules (for example, topicA, topicB, topicC) by way of example only, and the actual situation may include more modules, which is also within the scope of the embodiment of the present application. As shown in FIG. 3, the retry mechanism for the failed transaction is as follows:
1. the upstream component initiates a transaction;
2. the assembly transmits the transaction element assembly to the functional module topicA, and the logic processing module processor A processes the related logic of the functional module topicA, if the processing is successful, the message is consumed, and the related transaction element is transmitted to the functional module topicB; if the processing fails, the consumption is avoided, and the next time the message retry is monitored;
3. the functional module topicB monitors the message, the logic processing module processor b processes the relevant logic of the functional module topicB, if the processing is successful, the message is consumed, and relevant transaction elements are sent to the functional module topicC; if the processing fails, the consumption is avoided, and the next time the message retry is monitored;
4. the functional module topicC monitors the message, and sends the message to the logic processing module processor C to process the relevant logic of the functional module topicC, if the processing is successful, the message is consumed, and the transaction is ended; if the processing fails, the processing is not consumed, and the next message retry is waited for.
In the embodiment of the application, after the transaction starts, when the processing of a certain functional module fails, the function of the functional module is retried until the processing is successful and then the next functional module is executed until the transaction is ended. The modules are serially connected by unique identifiers of transactions. If the function needs to be expanded, only one topic needs to be added, and the publisher and the subscriber are determined. The transaction processing method of the embodiment of the application solves the defects of low consumption performance, long time consumption, low real-time performance and difficult function expansion of the traditional retry mechanism, and provides a simple, efficient and highly-expandable retry mechanism. This retry mechanism allows multiple steps of retries, allowing new functions to be added with minimal cost while compromising transaction success. After each step of execution is successful, the transaction sends an event message to a subscription topic of the next step, wherein the message content contains a unique identification of the transaction and data required by the transaction; with the unique identification of each piece of data in the queue as a key, messages are not consumed unless the transaction is successful. And when the function is newly added, the corresponding subscription topic can be flexibly added, the failed retry is supported, and the function module can be flexibly increased and reduced.
Fig. 4 is a schematic diagram of the main units of a transaction processing device according to an embodiment of the present application. As shown in fig. 4, the transaction processing apparatus 400 includes an identification acquisition unit 401, a transaction message determination unit 402, a message generation unit 403, a message transmission unit 404, and a transaction processing result acquisition unit 405.
An identifier obtaining unit 401 configured to obtain a corresponding transaction identifier and a function module identifier in response to a transaction failure processing request;
a transaction message determination unit 402 configured to invoke a message queue to determine a corresponding transaction message based on the transaction identification and the function module identification;
a message generation unit 403 configured to perform retry logic based on the transaction message, generate a functional module transaction success message in response to a retry success;
a message sending unit 404 configured to determine a target function module identifier, and send a function module transaction success message to a target function module corresponding to the target function module identifier to perform a next transaction process;
and a transaction processing result obtaining unit 405 configured to obtain a transaction processing result after the next transaction processing is successfully executed in response to the target function module identifier corresponding to the end function module, and end the transaction processing procedure.
In some embodiments, the transaction processing device further comprises a functional module extension unit, not shown in fig. 4, configured to: and executing a function module expansion process in response to the fact that the function module identifier does not exist in the preset identifier list, further determining the position corresponding to the function module identifier, and logically inserting the function module corresponding to the function module identifier into the position.
In some embodiments, the functional module extension unit is further configured to: determining a publisher identifier and a subscriber identifier corresponding to the function module identifier; and adding a subscription theme, and executing function module expansion based on the subscription theme, the publisher identifier and the subscriber identifier.
In some embodiments, the functional module extension unit is further configured to: responding to the expansion failure of the functional module, generating an asynchronous expansion task, and sending the asynchronous expansion task to an asynchronous task pool; the task execution thread is invoked to execute each asynchronous task in the asynchronous task pool.
In some embodiments, the message generation unit 403 is further configured to: in response to the retry failure, the transaction message is not consumed, and the retry is performed after waiting for the next time the transaction message is monitored.
In some embodiments, messaging unit 404 is further configured to: acquiring a corresponding function module identification pool based on the transaction identification; and determining the next function module identifier which is connected with the function module identifier in series and is adjacent to the function module identifier in the function module identifier pool as a target function module identifier.
In some embodiments, the transaction processing result acquisition unit 405 is further configured to: and when the target function module identifier is the last function module identifier in the function module identifier pool, determining that the target function module identifier corresponds to the tail end function module.
The transaction processing method and the transaction processing device of the present application have a corresponding relationship in terms of implementation content, and therefore, the description of the repeated content is not repeated.
Fig. 5 illustrates an exemplary system architecture 500 in which a transaction processing method or transaction processing device of an embodiment of the application may be applied.
As shown in fig. 5, the system architecture 500 may include terminal devices 501, 502, 503, a network 504, and a server 505. The network 504 is used as a medium to provide communication links between the terminal devices 501, 502, 503 and the server 505. The network 504 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.
A user may interact with the server 505 via the network 504 using the terminal devices 501, 502, 503 to receive or send messages or the like. Various communication client applications may be installed on the terminal devices 501, 502, 503, such as shopping class applications, web browser applications, search class applications, instant messaging tools, mailbox clients, social platform software, etc. (by way of example only).
The terminal devices 501, 502, 503 may be a variety of electronic devices having transaction failure handling screens and supporting web browsing, including but not limited to smartphones, tablets, laptop and desktop computers, and the like.
The server 505 may be a server providing various services, such as a background management server (by way of example only) that provides support for transaction failure processing requests received by users using the terminal devices 501, 502, 503. The background management server can respond to the transaction failure processing request to acquire a corresponding transaction identifier and a corresponding function module identifier; calling a message queue to determine corresponding transaction messages according to the transaction identifications and the function module identifications; executing retry logic based on the transaction message, and generating a functional module transaction success message in response to the retry success; determining a target function module identifier, and sending a function module transaction success message to a target function module corresponding to the target function module identifier so as to execute the next transaction processing; and responding to the target function module identification corresponding to the terminal function module, acquiring a transaction processing result after the next transaction processing is successfully executed, and ending the transaction processing process. Thereby improving the success rate and efficiency of processing the failed transaction.
It should be noted that, the transaction processing method provided in the embodiment of the present application is generally executed by the server 505, and accordingly, the transaction processing device is generally disposed in the server 505.
It should be understood that the number of terminal devices, networks and servers in fig. 5 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.
Referring now to FIG. 6, there is illustrated a schematic diagram of a computer system 600 suitable for use in implementing an embodiment of the present application. The terminal device shown in fig. 6 is only an example, and should not impose any limitation on the functions and the scope of use of the embodiment of the present application.
As shown in fig. 6, the computer system 600 includes a Central Processing Unit (CPU) 601, which can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 602 or a program loaded from a storage section 608 into a Random Access Memory (RAM) 603. In the RAM603, various programs and data required for the operation of the computer system 600 are also stored. The CPU601, ROM602, and RAM603 are connected to each other through a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.
The following components are connected to the I/O interface 605: an input portion 606 including a keyboard, mouse, etc.; an output portion 607 including a Cathode Ray Tube (CRT), a liquid crystal credit authorization query processor (LCD), and the like, and a speaker, and the like; a storage section 608 including a hard disk and the like; and a communication section 609 including a network interface card such as a LAN card, a modem, or the like. The communication section 609 performs communication processing via a network such as the internet. The drive 610 is also connected to the I/O interface 605 as needed. Removable media 611 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is installed as needed on drive 610 so that a computer program read therefrom is installed as needed into storage section 608.
In particular, according to embodiments of the present disclosure, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication portion 609, and/or installed from the removable medium 611. The above-described functions defined in the system of the present application are performed when the computer program is executed by a Central Processing Unit (CPU) 601.
The computer readable medium shown in the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium may include, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present application, however, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.
The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The units involved in the embodiments of the present application may be implemented in software or in hardware. The described units may also be provided in a processor, for example, described as: a processor includes an identification acquisition unit, a transaction message determination unit, a message generation unit, a message transmission unit, and a transaction processing result acquisition unit. Wherein the names of the units do not constitute a limitation of the units themselves in some cases.
As another aspect, the present application also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be present alone without being fitted into the device. The computer readable medium carries one or more programs which, when executed by one of the devices, cause the device to obtain a corresponding transaction identification and function module identification in response to a transaction failure processing request; calling a message queue to determine corresponding transaction messages according to the transaction identifications and the function module identifications; executing retry logic based on the transaction message, and generating a functional module transaction success message in response to the retry success; determining a target function module identifier, and sending a function module transaction success message to a target function module corresponding to the target function module identifier so as to execute the next transaction processing; and responding to the target function module identification corresponding to the terminal function module, acquiring a transaction processing result after the next transaction processing is successfully executed, and ending the transaction processing process.
The computer program product of the present application comprises a computer program which, when executed by a processor, implements the transaction processing method of the embodiments of the present application.
According to the technical scheme provided by the embodiment of the application, the success rate and the efficiency of processing the failed transaction can be improved.
The above embodiments do not limit the scope of the present application. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives can occur depending upon design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present application should be included in the scope of the present application.
Claims (16)
1. A transaction processing method, comprising:
responding to the transaction failure processing request, and acquiring a corresponding transaction identifier and a function module identifier;
calling a message queue to determine a corresponding transaction message according to the transaction identifier and the function module identifier;
executing retry logic based on the transaction message, and generating a function module transaction success message in response to the retry success;
determining a target function module identifier, and sending a function module transaction success message to a target function module corresponding to the target function module identifier so as to execute the next transaction processing;
and responding to the target function module identification corresponding to the tail end function module, acquiring a transaction processing result after the next transaction processing is successfully executed, and ending the transaction processing process.
2. The method of claim 1, wherein after the obtaining the corresponding transaction identifier and function module identifier, the method further comprises:
and executing a function module expansion process in response to the fact that the function module identifier does not exist in a preset identifier list, further determining a position corresponding to the function module identifier, and logically inserting the function module corresponding to the function module identifier into the position.
3. The method of claim 2, wherein the executing a function module extension process comprises:
determining a publisher identifier and a subscriber identifier corresponding to the function module identifier;
and adding a subscription theme, and executing function module expansion based on the subscription theme, the publisher identifier and the subscriber identifier.
4. The method of claim 2, wherein the executing a function module extension process comprises:
responding to the expansion failure of the functional module, generating an asynchronous expansion task, and sending the asynchronous expansion task to an asynchronous task pool;
and calling a task execution thread to execute each asynchronous task in the asynchronous task pool.
5. The method of claim 1, wherein after the executing retry logic based on the transaction message, the method further comprises:
and responding to the retry failure, not consuming the transaction message, and executing the retry after waiting for the next monitoring of the transaction message.
6. The method of claim 1, wherein the determining the target function module identity comprises:
acquiring a corresponding function module identification pool based on the transaction identification;
and determining the next function module identifier which is connected with the function module identifier in series and is adjacent to the function module identifier in the function module identifier pool as a target function module identifier.
7. The method of claim 6, wherein the method further comprises:
and when the target function module identifier is the last function module identifier in the function module identifier pool, determining that the target function module identifier corresponds to the tail end function module.
8. A transaction processing device, comprising:
the identification acquisition unit is configured to respond to the transaction failure processing request and acquire a corresponding transaction identification and a function module identification;
a transaction message determining unit configured to invoke a message queue to determine a corresponding transaction message according to the transaction identifier and the function module identifier;
a message generation unit configured to perform retry logic based on the transaction message, generate a functional module transaction success message in response to a retry success;
a message sending unit configured to determine a target function module identifier, and send a message that the function module transaction is successful to a target function module corresponding to the target function module identifier so as to execute a next transaction process;
and the transaction processing result acquisition unit is configured to respond to the target function module identification corresponding to the tail end function module, acquire a transaction processing result after the next transaction processing is successfully executed, and end the transaction processing process.
9. The apparatus of claim 8, further comprising a functional module extension unit configured to:
and executing a function module expansion process in response to the fact that the function module identifier does not exist in a preset identifier list, further determining a position corresponding to the function module identifier, and logically inserting the function module corresponding to the function module identifier into the position.
10. The apparatus of claim 9, wherein the functional module extension unit is further configured to:
determining a publisher identifier and a subscriber identifier corresponding to the function module identifier;
and adding a subscription theme, and executing function module expansion based on the subscription theme, the publisher identifier and the subscriber identifier.
11. The apparatus of claim 8, wherein the functional module extension unit is further configured to:
responding to the expansion failure of the functional module, generating an asynchronous expansion task, and sending the asynchronous expansion task to an asynchronous task pool;
and calling a task execution thread to execute each asynchronous task in the asynchronous task pool.
12. The apparatus of claim 9, wherein the message generation unit is further configured to:
and responding to the retry failure, not consuming the transaction message, and executing the retry after waiting for the next monitoring of the transaction message.
13. The apparatus of claim 8, wherein the messaging unit is further configured to:
acquiring a corresponding function module identification pool based on the transaction identification;
and determining the next function module identifier which is connected with the function module identifier in series and is adjacent to the function module identifier in the function module identifier pool as a target function module identifier.
14. A transaction processing electronic device, comprising:
one or more processors;
storage means for storing one or more programs,
the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method of any of claims 1-7.
15. A computer readable medium, on which a computer program is stored, characterized in that the program, when being executed by a processor, implements the method according to any of claims 1-7.
16. A computer program product comprising a computer program which, when executed by a processor, implements the method according to any of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311070883.9A CN117082149A (en) | 2023-08-24 | 2023-08-24 | Transaction processing method, device, electronic equipment and computer readable medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311070883.9A CN117082149A (en) | 2023-08-24 | 2023-08-24 | Transaction processing method, device, electronic equipment and computer readable medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117082149A true CN117082149A (en) | 2023-11-17 |
Family
ID=88719206
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311070883.9A Pending CN117082149A (en) | 2023-08-24 | 2023-08-24 | Transaction processing method, device, electronic equipment and computer readable medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117082149A (en) |
-
2023
- 2023-08-24 CN CN202311070883.9A patent/CN117082149A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108897854B (en) | Monitoring method and device for overtime task | |
| CN109873863B (en) | Asynchronous calling method and device of service | |
| CN112445868B (en) | Service message processing method and device | |
| CN111478781B (en) | Message broadcasting method and device | |
| CN109218338B (en) | Information processing system, method and device | |
| CN116450622B (en) | Method, apparatus, device and computer readable medium for data warehouse entry | |
| CN112445860B (en) | Method and device for processing distributed transaction | |
| CN116701020A (en) | Message delay processing method, device, equipment, medium and program product | |
| CN113127225A (en) | Method, device and system for scheduling data processing tasks | |
| CN111831503A (en) | Monitoring method based on monitoring agent and monitoring agent device | |
| CN111416833A (en) | Method and device for judging session termination | |
| CN117082149A (en) | Transaction processing method, device, electronic equipment and computer readable medium | |
| CN113765871B (en) | Method and device for managing fort machine | |
| CN115525411A (en) | Method, device, electronic equipment and computer readable medium for processing service request | |
| CN112241332B (en) | Interface compensation method and device | |
| CN112732728A (en) | Data synchronization method and system | |
| CN116010126B (en) | Service aggregation method, device and system | |
| CN117131071B (en) | Data processing method, device, electronic equipment and computer readable medium | |
| CN110750410B (en) | Method and device for monitoring database logs | |
| CN116339980A (en) | Service processing method, device, electronic equipment and computer readable medium | |
| CN117056019A (en) | Cluster processing method and device, electronic equipment and computer readable medium | |
| CN117333170A (en) | Service processing method, device, electronic equipment and storage medium | |
| CN113269605A (en) | Order processing method, device, equipment and computer readable medium | |
| CN116303566A (en) | Data query method and device | |
| CN113076256A (en) | Pressure testing method and device |
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 |