Transaction asynchronous processing method

Abstract

The present application relates to the technical field of computer communication, in particular to a transaction asynchronous processing method, which comprises the following steps: S1, sending a transaction request to a server through a client; S2, verifying the received transaction request by a transaction verification method; S3, after verification, distributing the transaction request to a background processor using a message queue; S4, taking the transaction request from the message queue and starting to execute business logic by the background processor; S5, capturing abnormal errors in the processing process through an exception capture mechanism and performing a rollback operation; S6, tracking the progress and state of transaction processing in real time to ensure the normal operation of the system. The client is responsible for collecting user input transaction information, performing preliminary verification, and sending transaction requests to the server through HTTP / HTTPS protocol. The initial correctness and security of the transaction request are ensured.

Description

Technical Field

[0001] This invention relates to the field of computer communication technology, and more specifically, to a method for asynchronous transaction processing. Background Technology

[0002] Asynchronous transaction processing refers to transforming synchronous, waiting-to-complete transaction operations into a non-blocking process to improve system responsiveness and processing capacity. When a transaction request arrives, the system does not immediately execute all related processing steps. Instead, it first receives the request and quickly returns a confirmation message to the client, indicating that the request has been received and is being processed. Subsequently, the system asynchronously executes the actual transaction processing logic in the background, such as account verification and fund transfer, and may coordinate interactions between different services through message queues, event-driven architectures, etc., to ensure transaction integrity and consistency. During this process, if any problems are encountered, the system records error details and provides feedback to the user through pre-defined notification mechanisms (such as email, SMS, or in-app notifications). This method not only effectively reduces user waiting time and improves user experience but also enhances system scalability and stability, especially in high-concurrency scenarios, which is of great significance for ensuring the safe and efficient operation of financial services.

[0003] Existing asynchronous transaction processing methods increase system complexity by requiring the design and implementation of more intricate logic to manage transaction state transitions, error recovery, and eventual consistency guarantees. Since transaction results are not immediately returned to the user, it can lead to inconsistent user experiences, potentially causing confusion regarding transaction status, especially in cases of transaction failure or requiring manual intervention. Asynchronous processing can also introduce data inconsistencies, particularly in the event of network failures or system crashes; without proper design, this could result in the loss or duplication of some transactions. For applications requiring real-time feedback, such as high-frequency trading, asynchronous processing may not meet the low-latency requirements due to the delay between the request and final result confirmation. Therefore, providing asynchronous transaction processing methods is necessary. Summary of the Invention

[0004] The purpose of this invention is to provide an asynchronous transaction processing method to address the issues raised in the background section. In existing asynchronous transaction processing methods, asynchronous processing increases system complexity because it requires designing and implementing more complex logic to manage transaction state transitions, error recovery, and eventual consistency guarantees. Since the results of transaction processing are not immediately returned to the user, it can lead to inconsistent user experiences, potentially causing confusion regarding transaction status, especially in cases of transaction failure or requiring manual intervention. Asynchronous processing can also cause data inconsistencies, particularly in abnormal situations such as network failures or system crashes. Without proper design, this can result in the loss or duplication of some transactions. For applications requiring real-time feedback, such as high-frequency trading, asynchronous processing may not meet the low-latency requirements due to the delay between the request and the final result confirmation.

[0005] To achieve the above objectives, the present invention aims to provide an asynchronous transaction processing method, comprising the following steps:

[0006] S1. Send a transaction request to the server through the client;

[0007] S2. The server verifies the received transaction requests using a transaction verification method;

[0008] S3. After successful verification, the transaction request is distributed to the backend processor using a message queue.

[0009] S4. The background processor retrieves the transaction request from the message queue and begins executing the business logic;

[0010] S5. Capture abnormal errors during the processing through the exception handling mechanism and perform rollback operations;

[0011] S6. Real-time monitoring tracks the progress and status of transaction processing to ensure the normal operation of the system.

[0012] As a further improvement to this technical solution, the specific steps in S1 for the client to send a transaction request to the server are as follows:

[0013] S1.1 The user enters transaction information on the client;

[0014] S1.2 The client performs basic validation on the input information;

[0015] S1.3 The client sends the transaction request to the server via the HTTP / HTTPS protocol.

[0016] As a further improvement to this technical solution, in step S2, the specific steps by which the server verifies the received transaction request using the transaction verification method are as follows:

[0017] S2.1 The server receives a transaction request from the client;

[0018] S2.2 Verify the received transaction request using the transaction verification method;

[0019] S2.3. Once the verification is successful, return a confirmation message to the client, informing them that the request has been accepted;

[0020] S2.4 When verification fails, return an error message and terminate the process.

[0021] As a further improvement to this technical solution, the specific process of verifying the received transaction request using the transaction verification method in S2.2 is as follows:

[0022] S2.21. Check if the request format meets expectations and verify that the fields in the request body are complete;

[0023] S2.22. Check if the user credentials in the request are valid, and verify whether the user is logged in and has the permission to execute the transaction;

[0024] S2.23. Check whether the transaction amount is within a reasonable range to prevent abnormally large transactions;

[0025] S2.24. Check if the user account exists and is in normal status.

[0026] As a further improvement to this technical solution, in step S3, after successful verification, the specific steps for allocating the transaction request to the background processor using a message queue are as follows:

[0027] S3.1 Generate a unique transaction ID for the transaction request;

[0028] S3.2 Encapsulate the relevant information of the transaction request into a message object;

[0029] S3.3 Send the message object to the message queue;

[0030] S3.4 Record the time and related information of the transaction request entering the message queue for subsequent auditing and troubleshooting.

[0031] As a further improvement to this technical solution, in step S4, the specific steps by which the background processor retrieves a transaction request from the message queue and begins executing the business logic are as follows:

[0032] S4.1 The background processor receives messages from the message queue;

[0033] S4.2 Parse the message content and extract the transaction request information;

[0034] S4.3 Execute the corresponding business logic according to the transaction type;

[0035] S4.4 Update the transaction status and record detailed transaction processing logs.

[0036] As a further improvement to this technical solution, step S4.3, which involves executing the corresponding business logic based on the transaction type, is as follows:

[0037] S4.31. Determine the business logic to be executed based on the extracted transaction type field;

[0038] S4.32. Invoke the corresponding business service according to the transaction type;

[0039] S4.33, Execute specific business logic;

[0040] S4.34. During the execution of business logic, record the intermediate states and the results of key operations.

[0041] As a further improvement to this technical solution, the specific steps in S5 for capturing abnormal errors during the processing through an exception capture mechanism and performing a rollback operation are as follows:

[0042] S5.1. In business logic processing, exceptions are captured through an exception handling mechanism, and exception information is recorded.

[0043] S5.2 Transaction management allows for the rollback of executed operations in the event of an exception;

[0044] S5.3. Based on the exception type and business logic, determine the specific operations that need to be rolled back;

[0045] S5.4 After the rollback operation is completed, restore the system to its initial state to ensure data consistency.

[0046] As a further improvement to this technical solution, in S5.1, the specific process of capturing and recording exception information in business logic processing through an exception capture mechanism is as follows:

[0047] S5.11. Use a try-catch block to enclose business logic code blocks that may throw exceptions;

[0048] S5.12. Catch exceptions in the catch block to ensure that exceptions do not interrupt the entire processing flow;

[0049] S5.13. Record the exception type, message, and stack trace;

[0050] S5.14 Record exception information to the log file.

[0051] As a further improvement to this technical solution, in S6, the specific steps to ensure the normal operation of the system by real-time monitoring and tracking of the progress and status of transaction processing are as follows:

[0052] S6.1 Define the key metrics that need to be monitored and set reasonable thresholds for each metric. Trigger an alarm when a metric exceeds the threshold.

[0053] Key metrics include transaction processing time, transaction success rate, system load, and error rate.

[0054] S6.2 Record detailed log information at each key point in the transaction processing;

[0055] The key points include transaction ID, processing time, and status changes;

[0056] S6.3 Use the monitoring tool Grafana to create monitoring dashboards that display real-time data for key metrics;

[0057] S6.4 Record the time, cause, and handling process of the fault.

[0058] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0059] 1. In this asynchronous transaction processing method, the client is responsible for collecting user-input transaction information, performing preliminary validation, and sending the transaction request to the server via HTTP / HTTPS protocol. This ensures the initial correctness and security of the transaction request. The server performs detailed validation on the received transaction request, including checking the request format, verifying user credentials, reviewing the reasonableness of the transaction amount, and confirming the user's account status. The server generates a unique transaction ID, encapsulates the relevant information of the transaction request into a message object, and sends it to a message queue. Simultaneously, the time and related information of the transaction request entering the message queue are recorded.

[0060] 2. In this asynchronous transaction processing method, the background processor retrieves the transaction request message object from the message queue, calls the corresponding business service based on the transaction type, and executes the specific business logic. During transaction processing, an exception handling mechanism captures potential errors and performs rollback operations to ensure data consistency and integrity. Real-time monitoring helps to promptly identify and resolve problems, ensuring system stability and high performance. Simultaneously, the recorded log information provides crucial information for subsequent auditing and troubleshooting. Attached Figure Description

[0061] Figure 1 This is a flowchart of the overall method of the present invention. Detailed Implementation

[0062] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0063] Example:

[0064] Please see Figure 1 As shown, this embodiment provides an asynchronous transaction processing method, including the following steps:

[0065] S1. Send a transaction request to the server through the client;

[0066] Specifically, the client is responsible for receiving user transaction requests, performing initial data validation to ensure the input information is formatted correctly and meets logical requirements. Then, it sends the transaction request to the server via HTTP / HTTPS. The client also needs to be able to process the server's response, whether it's a confirmation message or an error message, and display the corresponding results to the user, ensuring the user understands the processing status of the transaction request.

[0067] In this example, the specific steps for sending a transaction request from the client to the server are as follows:

[0068] S1.1 The user enters transaction information on the client;

[0069] Specifically, transaction information typically includes, but is not limited to, the identity information of both parties (such as account numbers and names), the transaction amount, the payment method (such as credit card, Alipay, WeChat Pay, etc.), a detailed description of the goods or services, and transaction notes. This information constitutes the core elements of a transaction, ensuring its accuracy and legality.

[0070] S1.2 The client performs basic validation on the input information;

[0071] Specifically, basic validation ensures that user input conforms to the expected format and logic, preventing errors in subsequent processing or transaction failures due to input mistakes. Common basic validations include:

[0072] Format validation: Checks whether the entered email address, phone number, date, etc., conform to the standard format.

[0073] Required field validation: Ensure that all necessary fields have been filled in, such as transaction amount and payer account.

[0074] Reasonableness check: Check whether the input value is reasonable, such as the transaction amount cannot be negative, the date cannot be earlier than the current date, etc.

[0075] CAPTCHA verification: If CAPTCHA is involved, it is necessary to verify whether the CAPTCHA entered by the user is correct in order to prevent automated attacks or accidental operations.

[0076] Security verification: Check the input for potential security threats, such as SQL injection or XSS attacks.

[0077] S1.3 The client sends the transaction request to the server via the HTTP / HTTPS protocol.

[0078] Specifically, HTTP (Hypertext Transfer Protocol) is the most widely used network protocol on the internet, primarily used for data communication between browsers and web servers, supporting operations such as clients requesting web page resources from servers. HTTPS (Hypertext Transfer Protocol Secure), on the other hand, is the secure version of HTTP. It uses the SSL / TLS protocol to encrypt data during transmission, ensuring that information is not eavesdropped on or tampered with during transmission between the client and server. It is commonly used in scenarios requiring the protection of sensitive information, such as online payments and login authentication. Simply put, HTTPS adds an SSL / TLS security layer to HTTP, thus providing a more secure data transmission method.

[0079] S2. The server verifies the received transaction requests using a transaction verification method;

[0080] Specifically, the server acts as an intermediary layer. It receives transaction requests from clients and performs detailed verification, including checking the request format, verifying user credentials, reviewing the reasonableness of the transaction amount, and confirming the user's account status. Upon successful verification, the server generates a unique transaction ID and encapsulates the relevant transaction request information into a message object, which is then sent to a message queue. Furthermore, the server needs to record the time and related information of the transaction request entering the message queue for subsequent auditing and troubleshooting.

[0081] In this example, the specific steps by which the server verifies the received transaction request using the transaction verification method are as follows:

[0082] S2.1 The server receives a transaction request from the client;

[0083] S2.2 Verify the received transaction request using the transaction verification method;

[0084] Specifically, the process of verifying received transaction requests using the transaction verification method is as follows:

[0085] S2.21. Check if the request format meets expectations and verify that the fields in the request body are complete;

[0086] S2.22. Check if the user credentials in the request are valid, and verify whether the user is logged in and has the permission to execute the transaction;

[0087] S2.23. Check whether the transaction amount is within a reasonable range to prevent abnormally large transactions;

[0088] S2.24. Check if the user account exists and is in normal status.

[0089] S2.3. Once the verification is successful, return a confirmation message to the client, informing them that the request has been accepted;

[0090] S2.4 When verification fails, return an error message and terminate the process.

[0091] Specifically, the implementation process is as follows:

[0092]

[0093]

[0094]

[0095]

[0096] The process by which the server verifies received transaction requests using transaction verification plays a crucial role. This process ensures that only legitimate and valid transaction requests proceed to subsequent processing, thereby improving system security and reliability. Specifically, by checking the request format, verifying user credentials, reviewing the reasonableness of the transaction amount, and confirming the user's account status, illegal operations can be effectively prevented, erroneous transactions reduced, and timely feedback provided to users. When verification passes, even if the actual transaction processing is completed asynchronously in the background, the user quickly receives confirmation that the request has been accepted, improving the user experience; conversely, if verification fails, an error message is immediately provided, allowing the user to correct the problem promptly. In short, this verification process is a key link in ensuring that asynchronous transaction processing is both efficient and secure.

[0097] S3. After successful verification, the transaction request is distributed to the backend processor using a message queue.

[0098] In this example, after successful verification, the specific steps for using a message queue to distribute the transaction request to the backend processor are as follows:

[0099] S3.1 Generate a unique transaction ID for the transaction request;

[0100] S3.2 Encapsulate the relevant information of the transaction request into a message object;

[0101] Specifically, a message object is a data structure used to pass data and instructions between system components. In asynchronous transaction processing methods, a message object typically contains all the necessary information for a transaction request so that consumers in the message queue (such as background processors) can understand and process the request. A typical message object might contain the following:

[0102] Transaction ID: A unique identifier used to uniquely identify each transaction request for easy tracking and management.

[0103] User information: Basic information such as the user's account and name who initiated the transaction.

[0104] Transaction details: including transaction amount, transaction type (such as purchase, refund, etc.), description of goods or services, etc.

[0105] Source information: The source of the transaction request, such as the client's IP address, device information, etc.

[0106] Timestamp: The time when the transaction request was generated, used for sorting and auditing.

[0107] Status information: The current status of the transaction, such as "pending", "processing", "completed", etc.

[0108] Additional information: This may also include some additional metadata, such as security tokens, session IDs, etc., which helps with authentication and permission checks during processing.

[0109] S3.3 Send the message object to the message queue;

[0110] Specifically, a message queue is an asynchronous communication mechanism used to pass messages between different components of an application. By acting as a buffer between the sender and receiver, storing and forwarding messages, it decouples components and improves the scalability and reliability of the system. Message queues ensure the ordered delivery and reliable handling of messages, guaranteeing no message loss even under high concurrency or when some system components fail. Common uses include task scheduling, log processing, and data synchronization, helping to build efficient and stable distributed systems.

[0111] S3.4 Record the time and related information of the transaction request entering the message queue for subsequent auditing and troubleshooting.

[0112] Specifically, in asynchronous transaction processing, using message queues to distribute verified transaction requests to backend processors plays a crucial role in decoupling the frontend and backend, improving system throughput and fault tolerance. Specifically, by generating a unique transaction ID for each request and encapsulating its related information into a message object and sending it to the message queue, it ensures that transaction requests are delivered to the backend processor in order and reliably, maintaining good performance even under high concurrency. Simultaneously, recording the time and related information of transaction requests entering the message queue helps track the entire transaction processing process, facilitating subsequent auditing and troubleshooting, and ensuring the transparency and traceability of transaction processing. This approach not only improves system response speed and processing efficiency but also enhances system stability and maintainability.

[0113] S4. The background processor retrieves the transaction request from the message queue and begins executing the business logic;

[0114] Specifically, the background processor retrieves the transaction request message object from the message queue and executes the specific transaction processing logic, such as account verification and fund transfer. The background processor typically runs in a separate service, allowing it to process multiple transaction requests in parallel, improving system processing capacity and response speed. After processing, the background processor sends the result back to the server, which then notifies the client of the final transaction status. If problems are encountered during processing, the background processor also logs errors for subsequent analysis and resolution.

[0115] In this example, the specific steps for the background processor to retrieve a transaction request from the message queue and begin executing the business logic are as follows:

[0116] S4.1 The background processor receives messages from the message queue;

[0117] S4.2 Parse the message content and extract the transaction request information;

[0118] S4.3 Execute the corresponding business logic according to the transaction type;

[0119] In this example, the process of executing the corresponding business logic based on the transaction type is as follows:

[0120] S4.31. Determine the business logic to be executed based on the extracted transaction type field;

[0121] S4.32. Invoke the corresponding business service according to the transaction type;

[0122] Specifically, a business service refers to a functional module or service in a software system that is responsible for executing specific business logic. In asynchronous transaction processing methods, business services are typically responsible for handling specific transaction operations, such as account verification, fund transfer, and order creation.

[0123] S4.33, Execute specific business logic;

[0124] Specifically, business logic refers to the program code within a software system that implements specific business rules and processes. It defines how the system processes data and executes operations to meet business needs and objectives. In asynchronous transaction processing methods, business logic specifically includes operations such as verifying transaction information, executing fund transfers, and updating account status, ensuring that each step complies with business rules and security requirements. Through carefully designed business logic, the system can accurately and efficiently process various transaction requests while maintaining data consistency and integrity.

[0125] S4.34. During the execution of business logic, record the intermediate states and the results of key operations.

[0126] Specifically, the implementation process is as follows:

[0127]

[0128]

[0129]

[0130]

[0131] By extracting the transaction type field, the required business logic is determined, and the corresponding business services are invoked to perform specific business operations, such as account verification and fund transfer. This process not only improves the system's flexibility and scalability but also ensures that different types of transactions are handled appropriately. Simultaneously, recording intermediate states and the results of key operations during business logic execution provides crucial evidence for subsequent auditing, troubleshooting, and anomaly handling, enhancing the system's transparency and traceability. This approach helps improve the efficiency and accuracy of transaction processing while reducing the probability of errors and anomalies.

[0132] S4.4 Update the transaction status and record detailed transaction processing logs.

[0133] S5. Capture abnormal errors during the processing through the exception handling mechanism and perform rollback operations;

[0134] In this example, the specific steps for capturing exceptions during processing and performing a rollback operation using the exception handling mechanism are as follows:

[0135] S5.1. In business logic processing, exceptions are captured through an exception handling mechanism, and exception information is recorded.

[0136] In this example, the specific process of capturing and recording exception information during business logic processing using an exception handling mechanism is as follows:

[0137] S5.11. Use a try-catch block to enclose business logic code blocks that may throw exceptions;

[0138] Specifically, the try-catch structure is a commonly used exception handling mechanism in programming languages, used to catch and handle exceptions that may occur during code execution. Specifically, the try block contains code that may throw exceptions, while the catch block is used to catch and handle these exceptions. When the code in the try block throws an exception, the program immediately jumps to the corresponding catch block to execute the exception handling logic, rather than interrupting the execution of the entire program. This ensures that the program can gracefully handle errors when encountering exceptions, continuing execution or taking appropriate remedial measures. The try-catch structure is an important tool for improving program robustness and reliability.

[0139] The implementation process is as follows:

[0140]

[0141]

[0142]

[0143] S5.12. Catch exceptions in the catch block to ensure that exceptions do not interrupt the entire processing flow;

[0144] S5.13. Record the exception type, message, and stack trace;

[0145] Specifically, the exception type refers to the specific class or type that throws the exception. Each exception type typically corresponds to a specific error or exceptional condition. Exception types help developers quickly identify the nature of the exception and take appropriate action.

[0146] An exception message is a brief description of the specific circumstances when an exception occurred, usually a string. Exception messages provide detailed information about the cause of the exception, helping developers understand the specific reason for the problem.

[0147] A stack trace is a list of method calls that shows the execution path of the program when an exception occurred. Stack traces help developers pinpoint where the exception occurred, understanding which method and line of code threw it, making debugging and fixing problems easier.

[0148] S5.14 Record exception information to the log file.

[0149] Specifically, using a try-catch block to enclose business logic code blocks that might throw exceptions allows for the capture and handling of exceptions when they occur, preventing them from interrupting the entire processing flow. After catching an exception in the catch block, the exception type, message, and stack trace are recorded and logged to a log file. This process not only helps developers promptly identify and locate problems but also provides detailed evidence for subsequent auditing and troubleshooting, ensuring the transparency and reliability of transaction processing. In this way, the system can maintain stable operation when encountering exceptions while ensuring data consistency and integrity.

[0150] S5.2 Transaction management allows for the rollback of executed operations in the event of an exception;

[0151] S5.3. Based on the exception type and business logic, determine the specific operations that need to be rolled back;

[0152] Specifically, a rollback operation refers to reversing executed database operations during transaction processing when an exception or error occurs, restoring the database state to its state before the transaction began. Rollback ensures data consistency and integrity, preventing data inconsistencies caused by partial successes and partial failures. Specifically, rollback operations are typically performed automatically by the database management system, restoring the database to its initial state at the start of the transaction by undoing all committed changes.

[0153] S5.4 After the rollback operation is completed, restore the system to its initial state to ensure data consistency.

[0154] Specifically, by capturing and recording exceptions occurring during business logic processing, the system can promptly detect and handle problems. Using transaction management to roll back executed operations in the event of an exception ensures data integrity and consistency. The specific rollback operations are determined based on the exception type and business logic, further refining the precision of exception handling. After the rollback operation is complete, the system's initial state is restored, avoiding data inconsistencies caused by partial successes and failures. This series of steps not only improves the system's robustness and reliability but also ensures the transparency and traceability of transaction processing.

[0155] S6. Real-time monitoring tracks the progress and status of transaction processing to ensure the normal operation of the system.

[0156] In this example, the specific steps to ensure the normal operation of the system by monitoring and tracking the progress and status of transaction processing in real time are as follows:

[0157] S6.1 Define the key metrics that need to be monitored and set reasonable thresholds for each metric. Trigger an alarm when a metric exceeds the threshold.

[0158] Key metrics include transaction processing time, transaction success rate, system load, and error rate.

[0159] Specifically, the implementation process is as follows:

[0160]

[0161]

[0162]

[0163]

[0164] By defining key metrics that need to be monitored and setting reasonable thresholds for each metric, the system ensures that potential problems can be detected and responded to in a timely manner during system operation. When a metric exceeds the set threshold, the system will automatically trigger an alarm to notify relevant personnel to intervene, thereby ensuring the stability and reliability of the system.

[0165] S6.2 Record detailed log information at each key point in the transaction processing;

[0166] The key points include transaction ID, processing time, and status changes;

[0167] S6.3 Use the monitoring tool Grafana to create monitoring dashboards that display real-time data for key metrics;

[0168] Specifically, Grafana is an open-source metrics and visualization suite primarily used for visualizing time-series data. It supports various data sources, such as Prometheus, InfluxDB, Elasticsearch, and MySQL, and helps users monitor and analyze various system metrics and log data through rich charts and dashboards. Grafana provides powerful query and data processing capabilities, as well as flexible alerting mechanisms, and is widely used in system monitoring, network monitoring, application performance monitoring, and other fields.

[0169] S6.4 Record the time, cause, and handling process of the fault.

[0170] Specifically, key metrics are defined and reasonable thresholds are set. Alerts are triggered when metrics exceed these thresholds, helping to promptly identify and resolve potential problems. Detailed log information is recorded, including transaction IDs, processing times, and status changes, providing crucial data for troubleshooting and auditing. Monitoring dashboards are created using Grafana to display key metric data in real time, providing an intuitive view of system operation. Recording the time, cause, and handling process of failures helps in summarizing experiences, optimizing the system, and ensuring the stability and reliability of transaction processing. This series of steps not only improves system transparency and maintainability but also ensures the efficiency and security of transaction processing.

[0171] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely preferred examples and are not intended to limit the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention.

Claims

1. An asynchronous transaction processing method, characterized in that: Includes the following steps: S1. Send a transaction request to the server through the client; S2. The server verifies the received transaction requests using a transaction verification method; S3. After successful verification, the transaction request is distributed to the backend processor using a message queue. S4. The background processor retrieves the transaction request from the message queue and begins executing the business logic; S5. Capture abnormal errors during the processing through the exception handling mechanism and perform rollback operations; S6. Real-time monitoring tracks the progress and status of transaction processing to ensure the normal operation of the system.

2. The asynchronous transaction processing method according to claim 1, characterized in that: In step S1, the specific steps for the client to send a transaction request to the server are as follows: S1.1 The user enters transaction information on the client; S1.2 The client performs basic validation on the input information; S1.3 The client sends the transaction request to the server via the HTTP / HTTPS protocol.

3. The asynchronous transaction processing method according to claim 1, characterized in that: In step S2, the specific steps by which the server verifies the received transaction request using the transaction verification method are as follows: S2.1 The server receives a transaction request from the client; S2.2 Verify the received transaction request using the transaction verification method; S2.

3. Once the verification is successful, return a confirmation message to the client, informing them that the request has been accepted; S2.4 When verification fails, return an error message and terminate the process.

4. The asynchronous transaction processing method according to claim 3, characterized in that: In step S2.2, the specific process of verifying the received transaction request using the transaction verification method is as follows: S2.

21. Check if the request format meets expectations and verify that the fields in the request body are complete; S2.

22. Check if the user credentials in the request are valid, and verify whether the user is logged in and has the permission to execute the transaction; S2.

23. Check whether the transaction amount is within a reasonable range to prevent abnormally large transactions; S2.

24. Check if the user account exists and is in a normal state.

5. The asynchronous transaction processing method according to claim 1, characterized in that: In step S3, after successful verification, the specific steps for allocating the transaction request to the backend processor using a message queue are as follows: S3.1 Generate a unique transaction ID for the transaction request; S3.2 Encapsulate the relevant information of the transaction request into a message object; S3.3 Send the message object to the message queue; S3.4 Record the time and related information of the transaction request entering the message queue for subsequent auditing and troubleshooting.

6. The asynchronous transaction processing method according to claim 1, characterized in that: In step S4, the specific steps by which the background processor retrieves a transaction request from the message queue and begins executing the business logic are as follows: S4.1 The background processor receives messages from the message queue; S4.2 Parse the message content and extract the transaction request information; S4.3 Execute the corresponding business logic according to the transaction type; S4.4 Update the transaction status and record detailed transaction processing logs.

7. The asynchronous transaction processing method according to claim 6, characterized in that: S4.3, the process of executing the corresponding business logic according to the transaction type is as follows: S4.

31. Determine the business logic to be executed based on the extracted transaction type field; S4.

32. Invoke the corresponding business service according to the transaction type; S4.33, Execute specific business logic; S4.

34. During the execution of business logic, record intermediate states and the results of key operations.

8. The asynchronous transaction processing method according to claim 1, characterized in that: In step S5, the specific steps for capturing abnormal errors during the processing and performing a rollback operation through the exception capture mechanism are as follows: S5.

1. In business logic processing, exceptions are captured through an exception handling mechanism, and exception information is recorded. S5.2 Transaction management allows for the rollback of executed operations in the event of an exception; S5.

3. Based on the exception type and business logic, determine the specific operations that need to be rolled back; S5.4 After the rollback operation is completed, restore the system to its initial state to ensure data consistency.

9. The asynchronous transaction processing method according to claim 8, characterized in that: In S5.1, the specific process of capturing and recording exception information during business logic processing through an exception handling mechanism is as follows: S5.

11. Use a try-catch block to enclose business logic code blocks that may throw exceptions; S5.

12. Catch exceptions in the catch block to ensure that exceptions do not interrupt the entire processing flow; S5.

13. Record the exception type, message, and stack trace; S5.

14. Record exception information to the log file.

10. The asynchronous transaction processing method according to claim 1, characterized in that: In step S6, the specific steps for ensuring the normal operation of the system by real-time monitoring and tracking of the progress and status of transaction processing are as follows: S6.1 Define the key metrics that need to be monitored and set reasonable thresholds for each metric. Trigger an alarm when a metric exceeds the threshold. Key metrics include transaction processing time, transaction success rate, system load, and error rate. S6.2 Record detailed log information at each key point in the transaction processing; The key points include transaction ID, processing time, and status changes; S6.3 Use the monitoring tool Grafana to create monitoring dashboards that display real-time data for key metrics; S6.4 Record the time, cause, and handling process of the fault.

Images