Transaction processing method and device
By receiving transaction requests in the banking business system and automatically repeating the task when it fails, combined with asynchronous processing and multi-threading technology, the transfer failure problem caused by backend exceptions is solved, and self-operation and maintenance and efficient transaction processing are achieved.
Patent Information
- Application Number
- CN202110523758.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-05-13
- Publication Date
- 2025-08-08
- Estimated Expiration
- 2041-05-13
AI Technical Summary
There are a large number of transfer requests caused by backend exceptions in the banking business system, which requires manual intervention and reduced work efficiency.
Generate transaction tasks by receiving transaction requests, use task execution threads to execute transaction tasks, and trigger exception processing threads to automatically repeat execution when they fail. Combined with asynchronous processing of front-end and back-end servers and multi-threaded high concurrency methods, message queues and adjustment threads are used to monitor the back-end status, and automatically adjust transaction frequency and resource configuration.
It realizes automatic handling of back-end abnormal situations, reduces manual intervention, improves the work efficiency of system maintenance personnel, and reduces operation and maintenance costs and equipment costs.
Smart Images

Figure CN113129151B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of automatic programming, and in particular to a transaction processing method and device. Background Art
[0002] At present, a large number of business transactions often occur in the banking business system, such as salary payments by enterprises and institutions, and payment of water, electricity, coal and living expenses. Such account transactions have increasingly high real-time requirements.
[0003] In the prior art, when a large number of transfer requests fail due to back-end anomalies, manual intervention is required to handle the situation, which reduces work efficiency and increases the workload of system maintenance personnel. Summary of the Invention
[0004] In view of this, an embodiment of the present invention provides a transaction processing method and device that can automatically handle back-end abnormal situations, realize self-operation and maintenance of the system, reduce human intervention, and improve the work efficiency of system maintenance personnel.
[0005] To achieve the above object, according to one aspect of an embodiment of the present invention, a transaction processing method is provided, comprising:
[0006] receiving one or more transaction requests, wherein the transaction request indicates transaction information of a current transaction;
[0007] generating one or more transaction tasks corresponding to the one or more transaction requests;
[0008] Utilizing a task execution thread to execute the one or more transaction tasks according to the transaction information;
[0009] When the transaction task fails to be executed, the task execution thread triggers the exception handling thread, so that the failed transaction task is processed by the exception handling thread and then executed again.
[0010] Optionally, when the transaction task fails to execute, the failed transaction task is marked as abnormal, so that the exception processing thread extracts the transaction task according to the abnormal mark of the transaction task.
[0011] Optionally, when the execution time of the transaction task is greater than a preset time threshold, it is determined that the transaction task has failed to be executed.
[0012] Optionally, the transaction processing method further comprises: configuring the task execution thread on a backend server;
[0013] The one or more transaction requests are received by a front-end server, and the one or more transaction tasks are generated by a back-end server.
[0014] Optionally, generating the one or more transaction tasks by using a back-end server includes:
[0015] Obtaining, using the front-end server based on the transaction information, batch information corresponding to the transaction request;
[0016] The one or more transaction tasks are generated using the back-end server according to the batch information; wherein the same batch information corresponds to the same transaction task.
[0017] Optionally, the front-end server converts the one or more transaction requests into a first message in JSON format according to the batch information, and stores the first message in a first message queue, which is set in the front-end server;
[0018] The back-end server is used to extract the first message from the first message queue, and the transaction task is generated according to the first message.
[0019] Optionally, the backend server is configured with a database, and the task execution thread executes the one or more transaction tasks according to the transaction information, including:
[0020] extracting the one or more transaction tasks from the database using a scheduling thread, and storing the extracted one or more transaction tasks in a second message queue;
[0021] The task execution thread extracts the transaction task from the second message queue and executes the extracted transaction task according to the transaction information.
[0022] Optionally, the transaction processing method further includes:
[0023] Using a regulation thread to monitor the working status of the back-end server and / or the number of unexecuted transaction tasks;
[0024] When the working status of the back-end server is abnormal, regulating the scheduling thread to stop extracting the transaction task from the database; and / or
[0025] When the number of the unexecuted transaction tasks meets a first preset condition, the frequency and / or the number of the transaction tasks extracted by the scheduling thread from the database are regulated.
[0026] Optionally, the abnormal working status of the backend server includes: outbound call backend abnormality and / or flow control abnormality.
[0027] Optionally, the first preset condition includes: the number of the transaction tasks is greater than a preset first threshold, or the growth frequency of the transaction tasks is greater than a preset frequency.
[0028] Optionally, when the adjustment thread monitors that flow control occurs on the backend server, the method further includes:
[0029] The frequency and / or quantity of the transaction tasks extracted from the database by the scheduling thread is reduced.
[0030] Optionally, when the number of the unexecuted transaction tasks is greater than a preset second threshold, the method further includes:
[0031] Cloud resources are called and a virtual machine is created using the cloud resources, so as to execute the transaction task using the virtual machine.
[0032] Optionally, when the number of the unexecuted transaction tasks is greater than a preset second threshold,
[0033] Determine whether the number of task execution threads is not less than a preset third threshold; if so, execute the call to cloud resources; if not, utilize the local resources of the back-end server to increase the task execution threads, or increase the frequency and / or number of the scheduling thread extracting the transaction tasks from the database; wherein the third threshold is obtained based on the maximum number of threads configurable by the back-end server.
[0034] Optionally, when the number of the unexecuted transaction tasks is less than a preset fourth threshold, the method further includes:
[0035] Destroy the virtual machine on the backend server to release the cloud resources.
[0036] Optionally, the transaction information includes any one or more of the following: payment account, total payment amount, payment object name, transaction institution name, receiving account, receiving object name and the receiving amount corresponding to the receiving account.
[0037] According to another aspect of an embodiment of the present invention, a transaction processing device is provided, comprising: a receiving module, a task generating module, a task executing module and an exception handling module, wherein:
[0038] A receiving module, configured to receive one or more transaction requests, wherein the transaction request indicates transaction information of a current transaction;
[0039] A task generating module, configured to generate one or more transaction tasks corresponding to the one or more transaction requests;
[0040] A task execution module, configured to execute the one or more transaction tasks according to the transaction information using a task execution thread;
[0041] The exception handling module is used to trigger the exception handling thread by the task execution thread when the transaction task fails to be executed, so that the failed transaction task is processed by the exception handling thread and then executed again.
[0042] According to another aspect of an embodiment of the present invention, there is provided an electronic device, including:
[0043] one or more processors;
[0044] a storage device for storing one or more programs,
[0045] When the one or more programs are executed by the one or more processors, the one or more processors implement the transaction processing method provided by the present invention.
[0046] According to another aspect of an embodiment of the present invention, a computer-readable medium is provided, on which a computer program is stored. When the program is executed by a processor, the transaction processing method provided by the present invention is implemented.
[0047] One embodiment of the above invention has the following advantages or beneficial effects: by generating one or more transaction tasks from one or more received transaction requests, and executing these one or more transaction tasks via a task execution thread, if a transaction task fails, the task execution thread triggers an exception handling thread to process the failed transaction task, thereby rescheduling and re-executing the failed transaction task. By rescheduling the failed transaction task, the system can automatically operate and maintain itself in the event of backend anomalies, reducing human intervention and improving the efficiency of system operators.
[0048] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS
[0049] The accompanying drawings are provided for a better understanding of the present invention and are not intended to limit the present invention.
[0050] Figure 1 is a schematic diagram of the main process of a transaction processing method according to an embodiment of the present invention;
[0051] Figure 2 is a schematic diagram of the main process of another transaction processing method according to an embodiment of the present invention;
[0052] Figure 3 is a schematic diagram of the main process of another transaction processing method according to an embodiment of the present invention;
[0053] Figure 4 is a schematic diagram of the main process of another transaction processing method according to an embodiment of the present invention;
[0054] Figure 5 is a schematic diagram of the architecture of a transaction processing method according to an embodiment of the present invention;
[0055] Figure 6 is a schematic diagram of main modules of a transaction processing device according to an embodiment of the present invention;
[0056] Figure 7 is an exemplary system architecture diagram in which embodiments of the present invention may be applied;
[0057] Figure 8 It is a schematic diagram of the structure of a computer system of a terminal device or server suitable for implementing an embodiment of the present invention. DETAILED DESCRIPTION
[0058] The following description of exemplary embodiments of the present invention is made in conjunction with the accompanying drawings, in which various details of the embodiments of the present invention are included to facilitate understanding. These details should be considered as merely exemplary. Therefore, it should be appreciated by those skilled in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.
[0059] Figure 1 FIG. 1 is a schematic diagram of the main process of a transaction processing method according to an embodiment of the present invention. Figure 1 As shown, the transaction processing method includes:
[0060] Step S101: Receive one or more transaction requests, where the transaction request indicates transaction information of a current transaction.
[0061] In an embodiment of the present invention, a front-end microserver receives one or more transaction requests, wherein the transaction request may be a transfer request indicating transfer information. The one or more transaction requests may be transfer requests from a payment account to one or more receiving accounts, such as payroll processing for enterprises and institutions, or migrant worker supervision payments processed by a banking system. They may also be transfer requests from one or more payment accounts to a receiving account, such as utility bill payments, housing fund deductions, and social security deductions.
[0062] In an embodiment of the present invention, transaction information may include any one or more of the following: payment account number, total payment amount, payment object name, transaction institution name, receiving account number, payment object name, and the corresponding payment amount of the receiving account number. For example, when processing a company's salary payment, the front-end server receives the company's salary payment request, which indicates transfer information. The transfer information includes: payment account number, total payment amount, payment object name, transaction institution name, receiving account number, payment object name, and the corresponding payment amount of the receiving account number. The payment account number is the company's account number, the total payment amount is the total amount of the wages issued, the payment object name is the company name, the transaction institution name is the name of the bank institution conducting the transaction (including branches), the payment account number is the employee's bank card number, the payment object name is the employee's name, and the payment amount is the employee's salary amount.
[0063] Step S102: generating one or more transaction tasks corresponding to the one or more transaction requests.
[0064] In the embodiment of the present invention, Figure 2 As shown, step S102 includes:
[0065] Step S201: using the front-end server to obtain batch information corresponding to the transaction request based on the transaction information;
[0066] Step S202: generating the one or more transaction tasks using a backend server according to the batch information; wherein the same batch information corresponds to the same transaction task.
[0067] In this embodiment of the present invention, in step S201, the front-end microserver parses, stores, verifies, checks, and decomposes the transaction information to obtain batch information. This decomposition separates interbank transfer transactions and intrabank transactions into different batches, thereby improving transfer efficiency. The batch information includes a batch number and batch details. The batch details include the recipient account number, recipient name, and recipient amount. The batch number corresponds to the batch details, and for example, one batch number corresponds to multiple batch details.
[0068] For example, the front-end server receives a salary payment request from an enterprise, which indicates transfer information. The front-end server parses, verifies, and checks the transfer information. After decomposition, it obtains batch information. The batch information includes the batch number and batch details. The batch details include the name of the payment object, such as the account name, the payment account number, such as the bank card number, and the payment amount, such as the salary amount. Multiple batch details correspond to the same batch number, as shown in Table 1.
[0069] Table 1
[0070]
[0071] In the embodiment of the present invention, Figure 3 As shown, step S202 includes:
[0072] Step S2021: Using the front-end server, convert the one or more transaction requests into a first message in JSON format according to the batch information, and store the first message in a first message queue, wherein the first message queue is set in the front-end server; the first message queue is such as a Kafka message queue.
[0073] Step S2022: Utilize the backend server to extract the first message from the first message queue and generate a transaction task based on the first message, wherein the same batch of information corresponds to the same transaction task.
[0074] In this embodiment of the present invention, in step S2022, the backend server is configured with a consumer thread and a database. The consumer thread extracts the first message from the first message queue at a preset interval (i.e., a timer), converts the first message into a second message, and stores it in the database, thereby generating a transaction task. The format of the second message matches the format of the database and includes batch information, i.e., a batch number and batch details. Each batch number corresponds to a transaction task.
[0075] In an embodiment of the present invention, step S2022 further includes: marking the generated one or more transaction tasks to mark the status of the transaction tasks. Specifically, the status of the batch information corresponding to the generated one or more transaction tasks is marked as A000.
[0076] In an embodiment of the present invention, step S102 also includes: performing idempotency judgment on the second message stored in the front-end server to prevent the second message from being repeatedly delivered, avoiding the occurrence of multiple identical batches of information, and causing repeated execution of transaction tasks.
[0077] The embodiment of the present invention uses the front-end server to convert the transaction request into a first message in JSON format, and uses the back-end server (consumer thread) to periodically extract the first message from the first message queue and send it to the database, which can improve the efficiency of transaction execution and alleviate the operating pressure of the front-end server and / or back-end server.
[0078] Step S103: Utilize the task execution thread to execute the one or more transaction tasks according to the transaction information.
[0079] In the embodiment of the present invention, the back-end server is configured with a database, such as Figure 4 As shown, step S103 includes:
[0080] Step S301: extracting one or more transaction tasks from a database using a scheduling thread, and storing the extracted one or more transaction tasks in a second message queue;
[0081] Step S302: the task execution thread extracts transaction tasks from the second message queue and executes the extracted transaction tasks according to batch information.
[0082] In an embodiment of the present invention, in step S301, the back-end server is configured with a database, and the scheduling thread extracts one or more transaction tasks from the database and stores them in a second message queue (such as a Kafka message queue). Specifically, the scheduling thread extracts the batch number corresponding to the one or more transaction tasks from the database, marks the status of the one or more transaction tasks corresponding to the batch number, and stores the batch number in the second message queue. For example, the scheduling thread extracts the batch number corresponding to the transaction task with a status of A000 from the database, marks the status as A001, and stores the batch number in the second message queue.
[0083] In the embodiment of the present invention, the transaction tasks extracted from the database by the scheduling thread are unexecuted transaction tasks.
[0084] In an embodiment of the present invention, a scheduling thread extracts one or more transaction tasks from a database according to a preset time interval, wherein the preset time interval can be dynamically adjusted, and the number of extracted transaction tasks can also be dynamically adjusted. By adjusting the preset time and the number of transaction tasks, the frequency and number of transaction tasks extracted by the scheduling thread from the database can be adjusted.
[0085] In an embodiment of the present invention, the scheduling thread may be a scheduled Quartz task, which may periodically extract one or more transaction tasks with a status of A000 from the database, and then change the status of the transaction tasks to A001 and store them in the second message queue.
[0086] In this embodiment of the present invention, the backend server is configured with a task execution thread. Step S302 includes: the task execution thread extracts a batch number from the second message queue, retrieves the batch details corresponding to the batch number from the database based on the extracted batch number, and performs transaction processing using the thread pool. For example, the task execution thread extracts batch numbers 1 and 2 from the second message queue, retrieves the batch details corresponding to batch numbers 1 and 2 from the database based on the batch numbers 1 and 2, respectively, and performs transfer processing based on the batch details. The core system then confirms the transfer processing, confirming that the transfer is successful.
[0087] In an embodiment of the present invention, the task execution thread extracts messages from the second message queue and needs to perform deserialization processing to obtain the batch number. According to the batch number, the batch details corresponding to the batch number are obtained from the database, and the batch information is locked to prevent other threads from calling it again, and the thread pool thread is used to execute the transaction.
[0088] In an embodiment of the present invention, when a task execution thread uses a thread pool to execute a transaction, it can mark the status of different stages of the transaction execution to record the progress of the transaction execution. This allows the node where the transaction task failed to execute to be known when the transaction execution fails, so that when the transaction task is re-executed, it can be started directly from the node where the execution failed, thereby improving work efficiency.
[0089] For example, when processing a transfer, the thread pool includes the accounting processing stage, and may also include the accounting pre-processing or accounting post-processing stages. Different stages will mark the batch status differently. Pre-processing, for example, when a company pays wages on behalf of others, before the transfer, for the user's convenience, the details of a batch are combined into one accounting record; accounting processing, refers to the transfer processing process; post-processing, for example, when collecting living expenses, after the transfer is completed, the details of a batch are combined into one accounting record. By marking the status of transaction tasks at different execution stages, it is possible to determine which stage to start from when re-executing the transaction task in the event of an anomaly on the backend. For example, after a server interruption and restart, if the pre-processing of the account has been completed when transferring the details, there is no need to repeat the pre-processing of the account, thus avoiding incorrect accounts.
[0090] In an embodiment of the present invention, a fixed number of threads in the thread pool will be initialized when the system starts. The number of threads can be adjusted as needed. For example, the number of threads can be adjusted by increasing or decreasing the number of threads of a single server, or by increasing or decreasing the number of servers.
[0091] In the embodiment of the present invention, step S103 further includes step S303:
[0092] Step S303: using a regulation thread to monitor the working status of the backend server and / or the number of unexecuted transaction tasks;
[0093] When the working status of the back-end server is abnormal, regulating the scheduling thread to stop extracting the transaction task from the database; and / or
[0094] When the number of the unexecuted transaction tasks meets a first preset condition, the frequency and / or the number of the transaction tasks extracted by the scheduling thread from the database are regulated.
[0095] In an embodiment of the present invention, the adjustment thread uses a periodic polling method to monitor the backend server's operating status and / or the number of unexecuted transaction tasks, and monitors the number of active threads in the thread pool. Specifically, the backend server's operating status, the number of unexecuted transaction tasks, and the number of active threads in the thread pool are all recorded in a created service operation status table, and the adjustment thread monitors the service operation status table by periodically polling. The backend server's operating status includes whether the service is normal and whether it is under flow control. Abnormal operating status of the backend server includes abnormal outbound call backend and / or flow control. The number of active threads in the thread pool is the number of threads in the thread pool currently executing transaction tasks, and the number of unexecuted transaction tasks represents the busyness of the backend server.
[0096] In an embodiment of the present invention, the core system green light check thread can periodically send a green light detection probe to the core system to detect whether the back-end service (such as outbound call back-end service, whether the server is interrupted, etc.) is normal, and the "whether the service is normal" in the service operation status table is updated accordingly. If the back-end service is detected to be normal, "yes" is recorded; if it is abnormal, "no" is recorded, and the adjustment thread obtains the working status of the back-end server through polling.
[0097] In an embodiment of the present invention, when the working status of the back-end server is abnormal, including outbound call back-end abnormality and / or flow control abnormality, the adjustment thread regulates the scheduling thread to stop scheduling, that is, the adjustment thread regulates the scheduling thread to stop extracting transaction tasks from the database. After the working status of the back-end server returns to normal, the scheduling thread resumes scheduling, that is, the scheduling thread resumes extracting transaction tasks from the database.
[0098] In an embodiment of the present invention, when the number of unexecuted transaction tasks meets a first preset condition, the frequency and / or number of transaction tasks retrieved from the database by the scheduling thread are adjusted. Unexecuted transaction tasks are transaction tasks that have not been retrieved by the scheduling thread. The first preset condition includes: the number of transaction tasks is greater than a preset first threshold, and / or the frequency of increase in the number of transaction tasks is greater than a preset frequency. In other words, when the adjustment thread monitors that the frequency of increase in unexecuted transaction tasks is greater than a preset frequency, and / or the number of unexecuted transaction tasks is greater than the first preset threshold, the adjustment thread adjusts the scheduling thread to increase the frequency and / or number of transaction tasks retrieved from the database. For example, the adjustment thread may extract batch numbers of 100 transaction tasks from the database every 5 minutes and send them to the second message queue. If the adjustment thread monitors that the number of unexecuted transaction tasks continues to increase, such as exceeding a preset first threshold of 100, and / or the frequency of increase is greater than a preset frequency of 30 tasks per minute, the adjustment thread adjusts the scheduling thread to extract 120 transaction tasks from the database every 3 minutes and send them to the second message queue. This avoids triggering flow control, ensures relatively stable operation, and implements intelligent adjustment of the scheduling frequency.
[0099] In an embodiment of the present invention, when the number of unexecuted transaction tasks is greater than a preset second threshold, the method further includes:
[0100] Cloud resources are called and a virtual machine is created using the cloud resources, so as to execute the transaction task using the virtual machine.
[0101] In an embodiment of the present invention, when the adjustment thread monitors that the number of unexecuted transaction tasks is greater than a preset second threshold (such as 300), the public cloud API is called, a virtual machine is created using the public cloud API, and the transaction tasks are executed using the created virtual machine, thereby increasing the number of threads in the thread pool by creating the virtual machine.
[0102] In an embodiment of the present invention, when the number of unexecuted transaction tasks is greater than a preset second threshold,
[0103] Determine whether the number of task execution threads is not less than a preset third threshold; if so, execute the call to cloud resources; if not, utilize the local resources of the back-end server to increase the task execution threads, or increase the frequency and / or number of the scheduling thread extracting the transaction tasks from the database; wherein the third threshold is obtained based on the maximum number of threads configurable by the back-end server.
[0104] For example, when the adjustment thread monitors that the number of unexecuted transaction tasks is greater than a preset second threshold, it determines whether the number of task execution threads is not less than a preset third threshold. When the number of task execution threads is not less than the preset third threshold, it calls the public cloud API to create a virtual machine, and uses the virtual machine to execute the transaction task; when the number of task execution threads is less than the preset third threshold, it uses the local resources of the back-end server to increase the number of task execution threads. For example, the number of back-end servers can be increased or the number of threads opened on each server can be increased, thereby increasing the number of task execution threads.
[0105] In an embodiment of the present invention, when the number of unexecuted transaction tasks is less than a preset fourth threshold, the method further includes: destroying the virtual machine on the backend server to release cloud resources.
[0106] In this embodiment of the present invention, when the number of unexecuted transaction tasks is less than a preset fourth threshold, and when it is determined that the number of task execution threads is less than a preset fifth threshold, if so, the virtual machine on the backend server is destroyed to release cloud resources. For example, if the number of unexecuted transaction tasks (40) is less than the preset fourth threshold (50), and the number of task execution threads (5) is less than the preset fifth threshold (7), indicating that local resources are sufficient to schedule transaction tasks, the virtual machine created on the backend server can be destroyed to release cloud resources.
[0107] In an embodiment of the present invention, when the adjustment thread detects that the backend server is experiencing flow control, the process further includes: reducing the frequency at which the scheduling thread retrieves transaction tasks from the front-end server and / or reducing the number of transaction tasks retrieved. Specifically, when flow control occurs on the backend server, the scheduling thread's scheduling frequency and the number of transaction tasks retrieved are reduced to reduce pressure on the backend server. For example, if the scheduling thread retrieves 100 transaction tasks from the database and sends them to the second message queue every 5 minutes, and the adjustment thread detects that the backend server is experiencing flow control, the scheduling thread may be adjusted to retrieve 80 transaction tasks from the database and send them to the second message queue every 10 minutes.
[0108] In an embodiment of the present invention, the back-end server is further configured with a task write-back thread for extracting successfully executed transaction tasks and forming a return message to return to the front-end server, so that users can know the transaction processing results.
[0109] In the embodiment of the present invention, Figure 5 As shown, the back-end server includes a first back-end server and a second back-end server. The consumer thread, scheduling thread, exception handling thread and adjustment thread are configured in the first back-end server, and the task execution thread is configured in the second back-end server. The consumer thread of the first back-end server extracts the first message from the first message queue and lands it in the database, and extracts the batch number from the database and sends it to the second message queue. The second back-end server obtains the batch number from the second message queue, and then obtains the batch details from the database according to the batch number to perform transfer processing, thereby realizing the decoupling of the first back-end server and the second back-end server. The first back-end server and the second back-end server independently perform pre-processing and transaction processing, making the entire system run more smoothly, reducing the pressure on the back-end operation, and also reducing the pressure on system operation and maintenance personnel.
[0110] Step S104: When the transaction task fails to be executed, the task execution thread triggers the exception handling thread, so that the exception handling thread repeats the transaction task.
[0111] In the embodiment of the present invention, step S104 further includes: when the transaction task fails to be executed, marking the failed transaction task as abnormal, so that the exception handling thread extracts and executes the failed transaction task according to the abnormal mark of the transaction task.
[0112] In this embodiment of the present invention, a transaction task execution failure includes a transaction failure due to a backend server exception and / or a transaction failure due to a flow control anomaly. A transaction task execution failure includes the failure of one or more transactions in the batch details. For example, in the batch details corresponding to batch number 1 in Table 1, the transfer to Zhang San may have failed due to a backend anomaly or a flow control anomaly. This indicates that the transaction task for batch number 1 has failed and needs to be re-executed.
[0113] In this embodiment of the present invention, when a transaction task's execution duration exceeds a preset duration threshold, the task is determined to have failed. A duration threshold, T0, is set for each transaction task's execution duration. For a particular transaction task, if the execution duration is T and T > T0, the task is determined to have failed, and the failed task's status is marked as abnormal. A transaction task's execution duration exceeding the preset duration threshold may be due to a server or flow control anomaly, indicating that the task has failed.
[0114] In an embodiment of the present invention, when a transaction task fails to execute, the task execution thread marks the failed transaction task as abnormal, and also marks the details of the transaction failure, and updates the service operation status table at the same time. The adjustment thread determines that a backend abnormality (outbound call backend abnormality, flow control abnormality) occurs by polling the service operation status table, and the adjustment thread controls the scheduling thread to stop extracting transaction tasks from the database.
[0115] In this embodiment of the present invention, the exception handling thread retrieves a transaction task with an exception flag from the database, unlocks it, changes the exception flag status, and then stores the transaction task in the second message queue. The task execution thread then retrieves the transaction task from the second message queue and repeatedly executes it. For example, the exception handling thread retrieves a transaction task with a status flag of A999 from the database, unlocks it, changes the status flag to A001, and then stores it in the second message queue. The task execution thread then retrieves the transaction task with a status flag of A001 from the second message queue to execute the transaction.
[0116] In an embodiment of the present invention, when an outbound call backend exception causes a transaction task to fail to execute, the task execution thread will mark the status of the failed batch task as abnormal, such as marking it as A999, to indicate that the batch task is a transaction task that needs to be re-executed, and at the same time update the service operation status table, record "Is the service abnormal?" as "Yes", and adjust the thread through the rotation of the service operation status table. According to the service abnormality recorded in the service operation status table, the scheduling thread stops the scheduling of the transaction task, that is, the scheduling thread stops extracting the transaction task from the database, and resumes scheduling after the service returns to normal.
[0117] In an embodiment of the present invention, when a transaction task fails to execute due to a flow control exception, for example, when one or more batch details in a transaction task fail to execute, in addition to marking the status of the transaction task as abnormal, one or more batch details of the failed transaction are also marked, so that when the failed transaction task is re-executed, the batch details of the successful transaction are no longer executed repeatedly, and the batch details of the failed transaction only need to be executed.
[0118] For example, when the flow control is abnormal, as shown in Table 1, in batch number 1, the transfer to Zhang San fails, and the status of the detail is failed, the status of the batch is set to A999, and the detail of the failed transaction is marked as waiting to be rerun (06), and the service operation status table is updated at the same time, and "whether flow control" is recorded as "yes".
[0119] The transaction processing method provided in the embodiment of the present invention adopts asynchronous processing of the front-end server and the back-end server, and adopts a multi-threaded high-concurrency method to perform transaction processing, which meets the real-time requirements. It adopts a message queue to reduce the pressure of transaction peaks, making the entire transaction process relatively smooth, and reducing the pressure on system operation and maintenance personnel and the back-end server; it can automatically adjust the frequency of transaction initiation and automatically expand and shrink the capacity according to the working status of the back-end server and its own busyness, realize full utilization of resources, and greatly reduce equipment costs; and it adds the processing of back-end abnormal situations and realizes automatic processing, thereby enhancing the stability of the system, reducing operation and maintenance costs, and improving work efficiency.
[0120] According to a second aspect of an embodiment of the present invention, a transaction processing device 600 is provided. Figure 6 FIG. 1 is a schematic diagram of the main modules of a transaction processing device according to an embodiment of the present invention. Figure 6 As shown, the transaction processing device 600 includes: a receiving module 601, a task generating module 602, a task executing module 603 and an exception handling module 604, wherein:
[0121] Receiving module 601, configured to receive one or more transaction requests, wherein the transaction request indicates transaction information of a current transaction;
[0122] A task generating module 602 is configured to generate one or more transaction tasks corresponding to the one or more transaction requests;
[0123] A task execution module 603 is configured to execute the one or more transaction tasks according to the transaction information using a task execution thread;
[0124] The exception handling module 604 is configured to trigger the exception handling thread from the task execution thread when the transaction task fails to be executed, so that the exception handling thread repeats the transaction task.
[0125] According to a third aspect of an embodiment of the present invention, there is provided an electronic device, including:
[0126] one or more processors;
[0127] a storage device for storing one or more programs,
[0128] When the one or more programs are executed by the one or more processors, the one or more processors implement the transaction processing method provided by the embodiment of the present invention.
[0129] According to a fourth aspect of an embodiment of the present invention, a computer-readable medium is provided, on which a computer program is stored. When the program is executed by a processor, the transaction processing method provided by an embodiment of the present invention is implemented.
[0130] Figure 7 An exemplary system architecture 700 is shown to which the transaction processing method or transaction processing apparatus according to the embodiment of the present invention can be applied.
[0131] like Figure 7 As shown, system architecture 700 may include multiple servers 701, 702, 703, and 704, and a network 705. Network 705 is used to provide a medium for communication links between multiple servers 701, 702, 703, and 704. Network 705 may include various connection types, such as wired or wireless communication links or fiber optic cables.
[0132] Servers 701, 702, 703, and 704 may be servers that provide various services, such as backend management servers that support shopping websites browsed by users using terminal devices. The backend management servers may analyze and process received data, such as data acquisition requests, and feed the corresponding data back to the terminal devices.
[0133] It should be noted that the transaction processing device provided in the embodiment of the present invention is generally set in the servers 701, 702, 703, and 704.
[0134] It should be understood that Figure 7 The number of networks and servers in the embodiment is merely illustrative. Any number of terminal devices, networks, and servers may be provided as required.
[0135] Reference below Figure 8 , which shows a schematic structural diagram of a computer system 800 of a terminal device suitable for implementing an embodiment of the present invention. Figure 8 The terminal device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.
[0136] like Figure 8As shown, the computer system 800 includes a central processing unit (CPU) 801, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 802 or a program loaded from a storage unit 808 into a random access memory (RAM) 803. Various programs and data required for the operation of the system 800 are also stored in the RAM 803. The CPU 801, the ROM 802, and the RAM 803 are connected to each other via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.
[0137] The following components are connected to the I / O interface 805: an input section 806 including a keyboard, a mouse, and the like; an output section 807 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and a speaker; a storage section 808 including a hard disk; and a communication section 809 including a network interface card such as a LAN card or a modem. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to the I / O interface 805 as needed. A removable medium 811, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 810 as needed, so that computer programs read therefrom can be installed into the storage section 808 as needed.
[0138] In particular, according to the embodiments disclosed in the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 809, and / or installed from a removable medium 811. When the computer program is executed by the central processing unit (CPU) 801, the above-mentioned functions defined in the system of the present invention are performed.
[0139] It should be noted that the computer-readable medium described in the present invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media can include, but are not limited to, an electrical connection having one or more conductors, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In the present invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. This propagated data signal can take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. Program code embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wireline, optical fiber cable, RF, or any suitable combination thereof.
[0140] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present invention. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the above-mentioned module, program segment, or a part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.
[0141] The modules described in the embodiments of the present invention may be implemented in software or hardware. The modules described may also be located within a processor. For example, a processor may be described as comprising a receiving module, a task generation module, a task execution module, and an exception handling module. The names of these modules do not, in some cases, limit the modules themselves. For example, a receiving module may also be described as a "module for receiving one or more transaction requests."
[0142] As another aspect, the present invention further provides a computer-readable medium, which may be included in the device described in the above embodiments, or may exist independently and not incorporated into the device. The computer-readable medium carries one or more programs. When executed by the device, the one or more programs cause the device to: receive one or more transaction requests, each indicating transaction information of a current transaction; generate one or more transaction tasks corresponding to the one or more transaction requests; execute the one or more transaction tasks based on the transaction information using a task execution thread; and, if the execution of the transaction task fails, trigger the exception handling thread, causing the failed transaction task to be re-executed after being processed by the exception handling thread.
[0143] According to the technical solution of an embodiment of the present invention, one or more transaction tasks are generated from one or more received transaction requests. These are then executed by a task execution thread. When a transaction task fails, the task execution thread triggers an exception handling thread to process the failed transaction task, allowing it to be rescheduled and executed again. By rescheduling failed transaction tasks, the system achieves self-operation and maintenance in the event of backend anomalies, reducing human intervention and improving the efficiency of system operators. The frequency of transaction execution is intelligently controlled by the adjustment thread, enabling automatic scaling. The use of message queues reduces the pressure of transaction peaks, ensuring stable system operation and reducing pressure on the backend system.
[0144] The above specific embodiments do not limit the scope of protection of the present invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention are intended to be included within the scope of protection of the present invention.
Claims
1. A transaction processing method, characterized in that: include: Receiving, using a front-end server, one or more transaction requests, wherein the transaction request indicates transaction information of a current transaction; Using a backend server to generate one or more transaction tasks corresponding to the one or more transaction requests; configuring a task execution thread on the backend server; Utilizing the task execution thread to execute the one or more transaction tasks according to the transaction information, and marking statuses of different execution stages of the one or more transaction tasks, so as to obtain a node where the transaction task execution fails when the transaction task execution fails; When the transaction task fails to execute, the task execution thread triggers the exception handling thread, so that the failed transaction task is processed by the exception handling thread and then repeatedly executed starting from the node where the execution failed; The method further includes: when the transaction task fails to be executed, marking the failed transaction task as abnormal, so that the exception processing thread extracts the transaction task according to the abnormal mark of the transaction task.
2. The method according to claim 1, characterized in that When the execution time of the transaction task is greater than a preset time threshold, it is determined that the transaction task has failed to be executed.
3. The method according to claim 1, characterized in that The generating of the one or more transaction tasks by using the back-end server includes: Obtaining, using the front-end server based on the transaction information, batch information corresponding to the transaction request; The one or more transaction tasks are generated using the back-end server according to the batch information; wherein the same batch information corresponds to the same transaction task.
4. The method according to claim 3, characterized in that Converting the one or more transaction requests into a first message in JSON format using the front-end server according to the batch information, and storing the first message in a first message queue, where the first message queue is set in the front-end server; The back-end server is used to extract the first message from the first message queue, and the transaction task is generated according to the first message.
5. The method according to claim 4, characterized in that The backend server is configured with a database, and the task execution thread executes the one or more transaction tasks according to the transaction information, including: extracting the one or more transaction tasks from the database using a scheduling thread, and storing the extracted one or more transaction tasks in a second message queue; The task execution thread extracts the transaction task from the second message queue and executes the extracted transaction task according to the batch information.
6. The method according to claim 5, characterized in that Also includes: Using a regulation thread to monitor the working status of the back-end server and / or the number of unexecuted transaction tasks; When the working status of the back-end server is abnormal, regulating the scheduling thread to stop extracting the transaction task from the database; and / or When the number of the unexecuted transaction tasks meets a first preset condition, the frequency and / or the number of the transaction tasks extracted by the scheduling thread from the database are regulated.
7. The method according to claim 6, characterized in that The abnormal working state of the back-end server includes: outbound call back-end abnormality and / or flow control abnormality.
8. The method according to claim 6, characterized in that The first preset condition includes: the number of the transaction tasks is greater than a preset first threshold, or the growth frequency of the transaction tasks is greater than a preset frequency.
9. The method according to claim 6, characterized in that When the adjustment thread monitors that flow control occurs on the backend server, the method further includes: The frequency and / or quantity of the transaction tasks extracted from the database by the scheduling thread is reduced.
10. The method according to claim 6, characterized in that When the number of the unexecuted transaction tasks is greater than a preset second threshold, the method further includes: Cloud resources are called and a virtual machine is created using the cloud resources, so as to execute the transaction task using the virtual machine.
11. The method according to claim 9, characterized in that When the number of the unexecuted transaction tasks is greater than a preset second threshold, Determine whether the number of task execution threads is not less than a preset third threshold; if so, execute a call to cloud resources; if not, utilize the local resources of the back-end server to increase the task execution threads, or increase the frequency and / or number of the scheduling thread extracting the transaction tasks from the database; wherein the preset third threshold is obtained based on the maximum number of threads configurable by the back-end server.
12. The method according to claim 10, characterized in that When the number of the unexecuted transaction tasks is less than a preset fourth threshold, the method further includes: Destroy the virtual machine on the backend server to release the cloud resources.
13. The method according to any one of claims 1 to 12, characterized in that: The transaction information includes any one or more of the following: payment account number, total payment amount, payment object name, transaction institution name, payment account number, payment object name and payment amount corresponding to the payment account number.
14. A transaction processing device, characterized in that: include: Receiving module, task generation module, task execution module and exception handling module, among which, A receiving module, configured to receive one or more transaction requests using a front-end server, wherein the transaction request indicates transaction information of a current transaction; A task generation module is configured to generate one or more transaction tasks corresponding to the one or more transaction requests using a backend server; and configure a task execution thread on the backend server; a task execution module, configured to execute the one or more transaction tasks according to the transaction information using the task execution thread, and to mark statuses of different execution stages of the one or more transaction tasks, so as to obtain a node where the transaction task fails to execute when the transaction task fails to execute; An exception handling module, configured to trigger the exception handling thread from the task execution thread when the transaction task fails to execute, so that the failed transaction task is processed by the exception handling thread and then repeatedly executed starting from the node where the execution failed; The exception handling module is further configured to: when the transaction task fails to be executed, mark the failed transaction task as abnormal, so that the exception handling thread extracts the transaction task according to the abnormal mark of the transaction task.
15. An electronic device, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 13.
16. A computer-readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 13 is implemented.
Citation Information
Patent Citations
Task scheduling method and device
CN110245011A
Operation and maintenance method and device for bank system, electronic equipment and medium
CN110427304A