Financial business processing method, device, equipment, medium and program product

Abstract

The invention provides a financial service processing method which can be applied to the technical field of financial science and technology. The method comprises the following steps: pre-defining at least two event types and corresponding trigger logics in an event configuration center; in response to the real-time service request, writing the real-time event instance into an event instance processing table; according to the trigger logic of the loop event type, automatically generating loop event instances in batches and writing the loop event instances into an event instance processing table; continuously scanning event instances of which the processing states are to be processed in the event instance processing table, dynamically allocating computing resources according to priorities corresponding to event types, and calling corresponding event implementation classes to execute financial service logic; and after execution of the event implementation class is completed, writing a processing result into the target service table, and atomically updating a processing state of a corresponding event instance in the event instance processing table. The invention further provides a financial business processing device and equipment, a storage medium and a program product.

Description

Technical Field

[0001] This application relates to the field of financial technology, specifically to a financial business processing method, apparatus, equipment, medium, and program product. Background Technology

[0002] With the rapid development of financial services and the deepening of digital transformation, financial institutions need to handle a large number of business operations with varying time requirements every day, including but not limited to payment clearing, real-time reconciliation, day-end settlement, and regulatory report generation. Currently, financial business processing adopts a decentralized development model: each type of timed business (such as clearing and reconciliation) has its own independently written processing script, which is executed through fixed-period tasks or manual triggering. Summary of the Invention

[0003] In view of the above problems, this application provides a general and scalable financial transaction processing method, apparatus, device, medium and program product.

[0004] According to a first aspect of this application, a financial business processing method is provided, comprising: predefining at least two event types and corresponding triggering logic in an event configuration center, wherein the event types include real-time event types triggered in real time by the business application layer and cyclic event types triggered periodically by an event instance generation program; in response to a real-time business request, writing real-time event instances into an event instance processing table; automatically generating cyclic event instances in batches and writing them into the event instance processing table according to the triggering logic of the cyclic event type; continuously scanning event instances in the event instance processing table whose processing status is pending, dynamically allocating computing resources according to the priority corresponding to the event type, and calling the corresponding event implementation class to execute financial business logic;

[0005] After the event implementation class completes its execution, the processing result is written to the target business table, and the processing status of the corresponding event instance in the event instance processing table is atomically updated.

[0006] According to an embodiment of this application, the event instance processing table includes fields for event number, event type, processing status, insertion time, and completion time. The processing status includes pending, in progress, and completed.

[0007] According to an embodiment of this application, continuous scanning and dynamic allocation of computing resources are achieved through preemptive allocation, including: performing an atomic update operation on the database to change the processing status of an event instance from pending to executing and recording the identifier of the current execution node; and when the update operation is successful, determining that the current scheduling node has successfully acquired the exclusive execution right of the event instance.

[0008] According to an embodiment of this application, the dynamic allocation of computing resources based on the priority corresponding to the event type includes: allocating first priority thread pool resources for the real-time event type, allocating second priority thread pool resources for the cyclic event type, limiting the maximum concurrency of cyclic events through a flow control algorithm, wherein the response timeliness of the first priority thread pool is higher than that of the second priority thread pool; when there is a real-time event instance in the event instance processing table, pausing the scheduling of cyclic event instances until the real-time event is processed.

[0009] According to an embodiment of this application, the method further includes: when the event implementation class executes abnormally, rolling back the processing status of the corresponding event instance to pending processing, and incrementing the retry count field; calculating the next retry time according to the retry count field using an exponential backoff strategy; if the retry count field exceeds a preset threshold, setting the circuit breaker flag field to suspend the automatic scheduling of the event instance.

[0010] According to an embodiment of this application, the event implementation class is dynamically loaded through a service provider interface mechanism, and each event type corresponds to an independent class loader instance, so as to realize hot deployment and runtime isolation of business logic components.

[0011] A second aspect of this application provides a financial business processing apparatus, comprising: an event configuration module for predefining at least two event types and corresponding triggering logic, wherein the event types include real-time event types triggered in real time by the business application layer and cyclic event types triggered periodically by an event instance generation program; a real-time event instance writing module for writing real-time event instances into an event instance processing table in response to real-time business requests; a cyclic event instance generation module for automatically generating cyclic event instances in batches and writing them into the event instance processing table according to the triggering logic of the cyclic event types; an event scheduling module for continuously scanning event instances in the event instance processing table whose processing status is pending, dynamically allocating computing resources according to the priority corresponding to the event type, and calling the corresponding event implementation class to execute financial business logic; and an event processing status update module for writing the processing result into a target business table after the event implementation class has been executed, and atomically updating the processing status of the corresponding event instance in the event instance processing table.

[0012] According to an embodiment of this application, the event instance processing table includes fields for event number, event type, processing status, insertion time, and completion time. The processing status includes pending, in progress, and completed.

[0013] According to an embodiment of this application, the event scheduling module is further configured to perform an atomic update operation on the database, modify the processing status of an event instance that is pending to an execution status and record the identifier of the current execution node; and when the update operation is successful, determine that the current scheduling node has successfully acquired the exclusive execution right of the event instance.

[0014] According to an embodiment of this application, the event scheduling module is further configured to allocate a first priority thread pool resource for the real-time event type, allocate a second priority thread pool resource for the cyclic event type, limit the maximum concurrency of the cyclic event through a flow control algorithm, and the response timeliness of the first priority thread pool is higher than that of the second priority thread pool; when there is a real-time event instance in the event instance processing table, the scheduling of the cyclic event instance is suspended until the real-time event is processed.

[0015] According to an embodiment of this application, the apparatus further includes an event rollback module.

[0016] The event rollback module is used to roll back the processing status of the corresponding event instance to pending processing when the event implementation class fails, and increment the retry count field by one; calculate the next retry time according to the retry count field using an exponential backoff strategy; if the retry count field exceeds a preset threshold, set the circuit breaker flag field to suspend the automatic scheduling of the event instance.

[0017] According to an embodiment of this application, the event implementation class is dynamically loaded through a service provider interface mechanism, and each event type corresponds to an independent class loader instance, so as to realize hot deployment and runtime isolation of business logic components.

[0018] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0019] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0020] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0021] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0022] Figure 1The illustrations depict application scenarios of financial transaction processing methods, apparatuses, devices, media, and program products according to embodiments of this application.

[0023] Figure 2 A flowchart illustrating a financial transaction processing method according to an embodiment of this application is shown schematically.

[0024] Figure 3 A flowchart illustrating a financial transaction processing method according to another embodiment of this application is shown schematically;

[0025] Figure 4 This schematically illustrates a structural block diagram of a financial transaction processing apparatus according to an embodiment of this application; and

[0026] Figure 5 A block diagram schematically illustrates an electronic device suitable for implementing a financial transaction processing method according to an embodiment of this application. Detailed Implementation

[0027] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0028] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0029] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0030] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0031] To address the aforementioned technical issues, embodiments of this application provide a financial business processing method, comprising: collecting transaction traffic characteristics from a production environment; generating a financial-grade disturbance scenario description file based on the transaction traffic characteristics and a preset scenario template library; dynamically injecting the financial-grade disturbance scenario into a test environment in a non-intrusive manner based on the disturbance scenario description file; collecting operational data from the test environment after initiating a test; performing multi-link analysis on the operational data and visualizing the analysis results.

[0032] Figure 1 The illustrations depict application scenarios of financial transaction processing methods, apparatuses, devices, media, and program products according to embodiments of this application.

[0033] like Figure 1 As shown, application scenario 100 according to this embodiment may include a financial event processing scenario. Network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. Network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0034] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0035] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0036] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0037] It should be noted that the financial transaction processing method provided in this application embodiment can generally be executed by server 105. Correspondingly, the financial transaction processing device provided in this application embodiment can generally be located in server 105. The financial transaction processing method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the financial transaction processing device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0038] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0039] It should be noted that the financial business processing method provided in this application embodiment can be applied to the field of financial technology technology, and can also be applied to any other field. The application field of the financial business processing method and device determined in this application embodiment is not limited.

[0040] The following will be based on Figure 1 The described scene, through Figures 2-3 The financial transaction processing method according to the embodiments of this application will be described in detail.

[0041] Figure 2 A flowchart illustrating a financial transaction processing method according to an embodiment of this application is shown.

[0042] like Figure 2 As shown, the financial business processing method of this embodiment includes operations S310 to S350, which can be executed by a server or other computing device.

[0043] In operation S210, at least two event types and corresponding triggering logic are predefined in the event configuration center.

[0044] According to embodiments of this application, the event types include real-time event types triggered in real time by the business application layer and cyclic event types triggered periodically by the event instance generation program.

[0045] In one example, taking the collaborative processing flow of real-time payment clearing and scheduled end-of-day reconciliation under the same event-driven architecture as an example, before the system goes live, the operations and maintenance personnel pre-define the real-time payment clearing event (triggered by business requests, priority 9) and the recurring end-of-day reconciliation event (automatically generated at 23:00 every day, priority 5) in the event configuration center, and configure the data persistence to the event configuration table in the database for subsequent modules to read. The specific configuration is shown below:

[0046] Configure the real-time event type as "Payment Settlement":

[0047] Event type code: EVENT_PAYMENT_SETTLE; Trigger logic: Triggered in real time by calling the API interface in the business application layer, with no time period limit; Priority level: highest; Event implementation class path: com.xxx.xxx.xxx; Maximum number of retries: 3; Resource quota: Exclusive thread pool with a maximum of 20 threads.

[0048] Configure the recurring event type "End-of-Day Reconciliation":

[0049] Event type code: EVENT_END_OF_DAY_RECON. Triggering logic: Automatically created by the event instance generator at 23:00 daily; Priority level: Medium; Event implementation class path: com.xxx.xxxx.xxx; Maximum number of retries: 5; Resource quota: Shared thread pool with a maximum of 50 threads, but rate limiting is required via token bucket, for example, a maximum of 10 instances can be processed per second.

[0050] When operating S220, in response to a real-time business request, the real-time event instance is written to the event instance processing table.

[0051] In one example, when a user initiates an interbank transfer request through mobile banking, the business application layer receives the real-time business request, immediately constructs a payment clearing event instance, generates an event number using a distributed unique number generation algorithm, marks the event type as payment clearing, initializes the processing status to pending, and embeds business parameters such as transaction serial number, payee / payee account, and amount into the event instance processing table along with the highest priority and the current timestamp. At this point, the user interface immediately returns that the transaction has been accepted, achieving asynchronous decoupling of the request.

[0052] In operation S230, based on the triggering logic of the cyclic event type, cyclic event instances are automatically generated in batches and written into the event instance processing table.

[0053] In one example, at a fixed daily preset, the event instance generation program is woken up by a timer. It scans the event configuration center and finds that the triggering conditions for the end-of-day reconciliation task are met. It then generates one thousand reconciliation event instances in batches. Each instance corresponds to a merchant, and the event type is uniformly set to end-of-day reconciliation. The processing status is also initialized to pending, with a medium priority. The instances include parameters such as merchant number, reconciliation date, and file path. They are all written to the event instance processing table at once through batch insertion.

[0054] In operation S240, the event instances in the event instance processing table that are pending processing are continuously scanned. Computing resources are dynamically allocated according to the priority corresponding to the event type, and the corresponding event implementation class is called to execute financial business logic.

[0055] In one example, the three distributed scheduling nodes deployed in the system each independently start a scanning thread. After executing a query every second to obtain the list of pending events, they enter the preemptive allocation phase: the scheduling node performs an atomic update operation on the payment clearing event instance, changing the status from pending to executing and recording the current node identifier. The database row-level locking mechanism is used to ensure that only one node updates successfully. If the number of affected rows returned is positive, it is determined that the preemption is successful and the node obtains the exclusive execution right of the instance. Similarly, the other nodes compete for the other instances in parallel.

[0056] After a successful preemption, the scheduler dynamically allocates computing resources according to the priority corresponding to the event type. All payment and settlement instances are put into the first priority thread pool, which has a fixed number of threads to ensure millisecond-level response. End-of-day reconciliation instances are put into the second priority thread pool, which shares more threads but is subject to the flow control algorithm to limit the number of tasks processed per second. When there are pending tasks in the first priority thread pool, the scheduler actively suspends task allocation in the second priority thread pool until the real-time event queue is empty.

[0057] In operation S250, after the event implementation class has been executed, the processing result is written to the target business table, and the processing status of the corresponding event instance in the event instance processing table is atomically updated.

[0058] According to embodiments of this application, event implementation classes are dynamically loaded through a service provider interface mechanism, and each event type corresponds to an independent class loader instance, so as to achieve hot deployment and runtime isolation of business logic components.

[0059] In one example, the scheduler dynamically loads event implementation classes through a service provider interface mechanism. Specifically, it creates an independent class loader instance for each event type, breaking the traditional parent delegation model of class loading. For example, when loading the payment clearing processor, it isolates the database driver version it depends on, avoiding dependency conflicts with the reconciliation processor and achieving hot deployment and runtime isolation. The event implementation classes execute business logic in a sandbox environment. The payment processor reads the transactions to be cleared from the transaction details table, calls the core system interface to complete the fund transfer and calculate the handling fee, and the reconciliation processor reads the reconciliation file and checks it against the transaction details one by one. Both complete the three-stage operation of reading data, processing calculations, and writing results in independent transactions. Finally, within the same transaction boundary, the processing results are written to the target business table, and the status of the corresponding record in the event instance processing table is atomically updated to "completed" and the completion time is recorded. The average processing time, backlog, and timeout rate of each event type are monitored in real time through the insertion time and completion time fields of the event instance processing table. When the average delay of payment clearing events exceeds the threshold or the number of pending events exceeds the limit, the highest level alarm is triggered, providing financial business with a unified event-driven capability that combines real-time performance and reliability.

[0060] The financial business processing method provided in this application embodiment predefines real-time and cyclic dual-track event types in the configuration center, unifies heterogeneous business requests into the instance processing table, and the scheduler dynamically allocates resources based on priority to ensure millisecond-level response of real-time events and controlled execution of batch tasks. Combined with atomic state updates, it constructs a full-link tracing closed loop, which solves the problems of poor scalability, timeliness conflicts, resource contention and monitoring difficulties in traditional solutions, and realizes zero-scheduling development for business expansion, zero-blocking of critical business, and minute-level fault location.

[0061] According to an embodiment of this application, the event instance processing table includes fields for event number, event type, processing status, insertion time, and completion time. The processing status includes pending, in progress, and completed.

[0062] In one example, the daily end-of-day fund collection business is used to illustrate the synergistic effect of the fields in the event instance processing table. A recurring event type, "Fund Collection," is predefined in the event configuration center, triggered daily at 5 PM with a priority level of six. When the event instance generation program detects the current time as 5 PM, it creates one hundred collection event instances in batches and writes them to the event instance processing table. Each record contains the following fields: The event number is a globally unique long integer value generated using the snowflake algorithm, such as 9876500000000001, serving as a technical primary key to ensure no duplication in a distributed environment. The scheduler relies on this field for precise locking when preempting tasks, preventing multiple nodes from processing the same instance. The event type field stores a string constant, used by the scheduler to filter out tasks of this type during scanning. This field also serves as a foreign key to the event configuration center, dynamically obtaining the corresponding implementation class path and resource quota. The processing status field uses integers 0, 1, and 2 to represent the three states: pending, in progress, and completed, respectively. Initializing to 0 upon insertion, the scheduling node A, upon successfully preempting, performs an atomic update, setting the state to 1 and writing the node identifier. At this point, other nodes cannot preempt again due to unmet state conditions. After the business logic is executed, the state is set to 2 within the same transaction, completing the loop. If node A crashes during execution, its database connection is lost, causing the transaction to roll back. The state automatically reverts from 1 to 0, and the instance re-enters the preemptible queue, where it is taken over by a healthy node, achieving self-healing. Both the insertion time and completion time fields are millisecond-level timestamps. The monitoring system calculates the actual processing time by subtracting the insertion time from the completion time in real time. When the average processing time for real-time payment events exceeds 100 milliseconds, a delay alarm is triggered. Simultaneously, the system monitors the instance's waiting time in the queue by subtracting the insertion time from the current time. If reconciliation events wait for more than two hours, their priority is automatically increased to prevent task starvation. Operations personnel can accurately trace the entire lifecycle of any event through these two time fields, meeting financial regulatory requirements.

[0063] According to an embodiment of this application, continuous scanning and dynamic allocation of computing resources are achieved through preemptive allocation, including: performing an atomic update operation on the database to change the processing status of an event instance from pending to executing and recording the identifier of the current execution node; and when the update operation is successful, determining that the current scheduling node has successfully acquired the exclusive execution right of the event instance.

[0064] In one example, a preemptive allocation mechanism is demonstrated using a distributed bank reconciliation scenario: The system initiates a daily end-of-day reconciliation job each evening, generating 10,000 pending event instances stored in a processing table, all in a pending state. Simultaneously, scheduling nodes deployed in three data centers begin scanning, each querying for batches of tasks with a pending status.

[0065] For example, node A performs an atomic database update operation on one hundred event numbers. The update statement changes the processing status from "pending" to "executing" and writes a unique identifier to node A. The update condition is strictly limited to the processing status being equal to "pending." This operation achieves atomicity at the database level through row-level locking, ensuring that only one transaction can lock and modify the target row at a time. The database returns eighty-seven affected rows, and node A determines that it has successfully acquired exclusive execution rights to these eighty-seven event instances. For the remaining thirteen event numbers, since other nodes have already locked them, the number of affected instances is zero. Node A immediately releases these instances and continues scanning for the next batch of tasks.

[0066] For example, node B and node A attempt to update overlapping task batches almost simultaneously. However, since the database row lock is already held by node A, node B's update operation waits for a short period before the lock times out and is released. Ultimately, the number of affected instances is zero, and the preemption is determined to have failed. Therefore, a new batch of instances is retrieved and the attempt is made again to avoid invalid retries.

[0067] For example, once node A successfully preempts the instance, the execution node marker in the 87 instance records is written into node A's information. When subsequent business logic is completed, the status can only be updated to "completed" if this marker matches, thus preventing abnormal scenarios: If node A crashes, its held instances will automatically roll back due to uncommitted transactions, restoring the processing status to "pending," clearing the execution marker, and allowing other nodes to re-preempt; if node A survives but a network partition occurs, and other nodes mistakenly judge A as invalid and attempt to preempt the same instance, the number of affected nodes will be zero due to the mismatched execution marker, completely eliminating duplicate processing. Furthermore, after node A successfully preempts the instance, the scheduler checks the processing table for high-priority real-time payment events, immediately suspends the allocation of reconciliation task threads, temporarily stores the 87 reconciliation instances in a local queue, prioritizes processing all payment events, and then releases resources to execute reconciliation, ensuring millisecond-level response times for real-time business.

[0068] Through the above mechanism, the system, with zero external coordination component dependency, relies entirely on the atomicity and isolation characteristics of the database to achieve task mutual exclusion, fault self-healing and priority scheduling in a distributed environment, ensuring that each reconciliation event is executed exactly once within its lifecycle.

[0069] Figure 3 A flowchart illustrating a financial transaction processing method according to another embodiment of this application is shown.

[0070] like Figure 3 As shown, this includes operations S310 to S330.

[0071] In operation S310, a first-priority thread pool resource is allocated for the real-time event type.

[0072] In operation S320, a second-priority thread pool resource is allocated for the cyclic event type, and the maximum concurrency of the cyclic event is limited by a flow control algorithm.

[0073] According to an embodiment of this application, the response timeliness of the first priority thread pool is higher than that of the second priority thread pool.

[0074] In operation S330, when there is a real-time event instance in the event instance processing table, the scheduling of the loop event instance is paused until the real-time event processing is completed.

[0075] In one example, taking peak-hour resource scheduling in a payment system as an example, the dynamic allocation and isolation mechanism of a two-tier priority thread pool is demonstrated: Two types of thread pool resources are configured in the system. The first-priority thread pool is dedicated to real-time payment settlement events, reserving a fixed number of exclusive threads to ensure that the entire process from event preemption to execution is completed within milliseconds. The second-priority thread pool handles recurring reconciliation events. Although it has a larger number of threads, it is constrained by a flow control algorithm, activating a maximum of ten threads per second to process new instances, preventing batch tasks from instantly exhausting system resources. There is a clear difference in response time between the two types of thread pools; the average response time of the first-priority thread pool is two orders of magnitude faster than that of the second-priority pool. When users initiate payment requests intensively during the evening shopping peak, the number of real-time payment event instances in the event instance processing table rapidly increases to five hundred. The scheduler detects that the first-priority thread pool has pending tasks and immediately sends a pause signal to the second-priority thread pool. The recurring reconciliation instances that are currently executing cease acquiring new tasks after completing their current transaction, while the unstarted reconciliation instances wait in the queue. All fifty payment threads are running at full capacity, processing fund transfers one by one. Once the payment queue is cleared, the scheduler resumes scheduling the reconciliation threads to continue processing the backlogged instances.

[0076] This mechanism ensures that critical payment services receive absolute priority when resources are scarce through hard isolation of priorities. It completely avoids payment delays or timeouts caused by batch processing tasks crowding out online transaction resources in traditional architectures, and achieves stable and controllable financial-grade service quality.

[0077] According to an embodiment of this application, the method further includes: when the event implementation class executes abnormally, rolling back the processing status of the corresponding event instance to pending processing, and incrementing the retry count field; calculating the next retry time according to the retry count field using an exponential backoff strategy; if the retry count field exceeds a preset threshold, setting the circuit breaker flag field to suspend the automatic scheduling of the event instance.

[0078] In one example, if the event implementation class fails during execution due to an exception such as a missing reconciliation file, the scheduler catches the exception, rolls back the transaction, resets the state to pending, increments the retry counter, and calculates the next retry time using an exponential backoff strategy, adding the current time to the exponentially increasing time interval. If the number of retries exceeds a threshold, a circuit breaker is set to suspend scheduling. If a scheduling node crashes during execution, its transaction is automatically rolled back and the database lock is released. The event instance returns to the pending state, and other healthy nodes can preempt and execute it in the next scan, achieving self-healing. The exponential backoff strategy optimizes the retry interval caused by momentary jitter from a fixed duration to an exponentially increasing one, alleviating database pressure. The circuit breaker mechanism automatically isolates faulty tasks when the retries exceed the threshold, preventing unnecessary resource consumption.

[0079] Based on the above-described financial transaction processing method, this application also provides a financial transaction processing apparatus. The following will be combined with... Figure 4 The device is described in detail.

[0080] Figure 4 A schematic block diagram of a financial transaction processing apparatus according to an embodiment of this application is shown.

[0081] like Figure 4 As shown, the financial business processing device 400 of this embodiment includes an event configuration module 410, a real-time event instance writing module 420, a cyclic event instance generation module 430, an event scheduling module 440, and an event processing status update module 450.

[0082] The event configuration module 410 is used to predefine at least two event types and corresponding triggering logic. The event types include real-time event types triggered in real time by the business application layer and cyclic event types triggered periodically by the event instance generation program. In one embodiment, the event configuration module 410 can be used to execute the operation S210 described above, which will not be repeated here.

[0083] The real-time event instance writing module 420 is used to write real-time event instances into the event instance processing table in response to real-time service requests. In one embodiment, the real-time event instance writing module 420 can be used to perform the operation S220 described above, which will not be repeated here.

[0084] The loop event instance generation module 430 is used to automatically generate loop event instances in batches and write them into the event instance processing table according to the triggering logic of the loop event type. In one embodiment, the loop event instance generation module 430 can be used to perform the operation S230 described above, which will not be repeated here.

[0085] The event scheduling module 440 is used to continuously scan the event instances in the event instance processing table that are in a pending processing state, dynamically allocate computing resources according to the priority corresponding to the event type, and call the corresponding event implementation class to execute financial business logic. In one embodiment, the event scheduling module 440 can be used to execute the operation S240 described above, which will not be repeated here.

[0086] The event processing status update module 450 is used to write the processing result into the target business table after the event implementation class has been executed, and to atomically update the processing status of the corresponding event instance in the event instance processing table. In one embodiment, the event processing status update module 450 can be used to execute the operation S250 described above, which will not be repeated here.

[0087] According to an embodiment of this application, the event instance processing table includes fields for event number, event type, processing status, insertion time, and completion time. The processing status includes pending, in progress, and completed.

[0088] According to an embodiment of this application, the event scheduling module is further configured to perform an atomic update operation on the database, modify the processing status of an event instance that is pending to an execution status and record the identifier of the current execution node; and when the update operation is successful, determine that the current scheduling node has successfully acquired the exclusive execution right of the event instance.

[0089] According to an embodiment of this application, the event scheduling module is further configured to allocate a first priority thread pool resource for the real-time event type, allocate a second priority thread pool resource for the cyclic event type, limit the maximum concurrency of the cyclic event through a flow control algorithm, and the response timeliness of the first priority thread pool is higher than that of the second priority thread pool; when there is a real-time event instance in the event instance processing table, the scheduling of the cyclic event instance is suspended until the real-time event is processed.

[0090] According to an embodiment of this application, the apparatus further includes an event rollback module.

[0091] The event rollback module is used to roll back the processing status of the corresponding event instance to pending processing when the event implementation class fails, and increment the retry count field by one; calculate the next retry time according to the retry count field using an exponential backoff strategy; if the retry count field exceeds a preset threshold, set the circuit breaker flag field to suspend the automatic scheduling of the event instance.

[0092] According to an embodiment of this application, the event implementation class is dynamically loaded through a service provider interface mechanism, and each event type corresponds to an independent class loader instance, so as to realize hot deployment and runtime isolation of business logic components.

[0093] According to embodiments of this application, any multiple modules among the event configuration module 410, real-time event instance writing module 420, cyclic event instance generation module 430, event scheduling module 440, and event processing status update module 450 can be merged into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the event configuration module 410, real-time event instance writing module 420, cyclic event instance generation module 430, event scheduling module 440, and event processing status update module 450 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the event configuration module 410, the real-time event instance writing module 420, the loop event instance generation module 430, the event scheduling module 440, and the event processing status update module 450 can be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0094] Figure 5 A block diagram schematically illustrates an electronic device suitable for implementing a financial transaction processing method according to an embodiment of this application.

[0095] like Figure 5 As shown, an electronic device 500 according to an embodiment of this application includes a processor 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage portion 508 into a random access memory (RAM) 503. The processor 501 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 501 may also include onboard memory for caching purposes. The processor 501 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0096] RAM 503 stores various programs and data required for the operation of electronic device 500. Processor 501, ROM 502, and RAM 503 are interconnected via bus 504. Processor 501 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 502 and / or RAM 503. It should be noted that the programs may also be stored in one or more memories other than ROM 502 and RAM 503. Processor 501 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0097] According to embodiments of this application, the electronic device 500 may further include an input / output (I / O) interface 505, which is also connected to a bus 504. The electronic device 500 may also include one or more of the following components connected to the input / output (I / O) interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the input / output (I / O) interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 510 as needed so that computer programs read from it can be installed into the storage section 508 as needed.

[0098] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0099] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the 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. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 502 and / or RAM 503 and / or one or more memories other than ROM 502 and RAM 503 described above.

[0100] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code enables the computer system to implement the financial business processing method provided in the embodiments of this application.

[0101] When the computer program is executed by the processor 501, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0102] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 509, and / or installed from a removable medium 511. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0103] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 509, and / or installed from the removable medium 511. When the computer program is executed by the processor 501, it performs the functions defined in the system of this application embodiment. According to embodiments of this application, the apparatus, device, device, module, unit, etc., described above can be implemented by computer program modules.

[0104] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0105] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0106] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A financial transaction processing method, characterized in that, include: At least two event types and corresponding triggering logic are predefined in the event configuration center. The event types include real-time event types triggered by the business application layer in real time and cyclic event types triggered by the event instance generation program periodically scanning. In response to real-time business requests, write real-time event instances into the event instance processing table; Based on the triggering logic of the described cyclic event type, automatically generate cyclic event instances in batches and write them into the event instance processing table; The system continuously scans event instances in the event instance processing table that are pending processing, dynamically allocates computing resources according to the priority corresponding to the event type, and calls the corresponding event implementation class to execute financial business logic. After the event implementation class completes its execution, the processing result is written to the target business table, and the processing status of the corresponding event instance in the event instance processing table is atomically updated.

2. The method according to claim 1, characterized in that, The event instance processing table includes fields for event number, event type, processing status, insertion time, and completion time. The processing status includes pending, in progress, and completed.

3. The method according to claim 1, characterized in that, Continuous scanning and dynamic allocation of computing resources are achieved through preemptive allocation, including: Perform an atomic update operation on the database, changing the processing status of event instances from pending to executing and recording the current execution node identifier; and When the update operation is successful, it is determined that the current scheduling node has successfully acquired exclusive execution rights for the event instance.

4. The method according to claim 1, characterized in that, The dynamic allocation of computing resources based on the priority corresponding to the event type includes: First priority thread pool resources are allocated to the real-time event type, and second priority thread pool resources are allocated to the cyclic event type. The maximum concurrency of cyclic events is limited by a flow control algorithm. The response timeliness of the first priority thread pool is higher than that of the second priority thread pool. When a real-time event instance exists in the event instance processing table, the scheduling of the looping event instance is paused until the real-time event is processed.

5. The method according to claim 1, characterized in that, The method further includes: When the event implementation class encounters an exception, the processing status of the corresponding event instance is rolled back to pending processing, and the retry count field is incremented by one. The next retry time is calculated based on the retry count field using an exponential backoff strategy. If the retry count field exceeds a preset threshold, the circuit breaker flag field is set to suspend the automatic scheduling of the event instance.

6. The method according to claim 1, characterized in that, The event implementation classes are dynamically loaded through the service provider interface mechanism. Each event type corresponds to an independent class loader instance to achieve hot deployment and runtime isolation of business logic components.

7. A financial transaction processing device, characterized in that, The device includes: The event configuration module is used to predefine at least two event types and corresponding triggering logic. The event types include real-time event types triggered by the business application layer in real time and cyclic event types triggered by the event instance generation program periodically scanning. The real-time event instance writing module is used to write real-time event instances into the event instance processing table in response to real-time business requests. The loop event instance generation module is used to automatically generate loop event instances in batches and write them into the event instance processing table according to the triggering logic of the loop event type. The event scheduling module is used to continuously scan the event instances in the event instance processing table that are pending processing, dynamically allocate computing resources according to the priority corresponding to the event type, and call the corresponding event implementation class to execute financial business logic. The event processing status update module is used to write the processing result into the target business table after the event implementation class has been executed, and to atomically update the processing status of the corresponding event instance in the event instance processing table.

8. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 6.

Images