Ordered multi-thread batch bookkeeping method based on bank core system
By adopting an ordered multi-threaded batch accounting method in the bank core system, the performance degradation and transaction waiting problems caused by concurrent threads in traditional systems are solved, efficient, stable and accurate accounting processing is achieved, and resource utilization is optimized.
Patent Information
- Application Number
- CN202411546021.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-31
- Publication Date
- 2025-03-28
AI Technical Summary
When traditional bank core systems deal with concurrent threads, frequent locking and releasing of account resource locks lead to degradation of system performance, and multiple transactions will cause transaction waiting problems to be made on the same account, reducing system efficiency.
The orderly multi-threaded batch accounting method based on the core banking system is adopted. Multi-threaded parallel processing and batch accounting are realized through technical means such as creating account model cache, thread pool selection and creation, accounting entry and exit parameter encapsulation, adaptive reconstruction, thread accounting result analysis, database interactive operation batch processing mode, thread accounting result batch storage, handling accounting exceptions and thread management, etc.
It improves accounting efficiency, enhances system stability, improves data accuracy, and optimizes resource utilization, which can better cope with trading pressure during peak periods.
Smart Images
Figure CN119718698A_ABST
Abstract
Description
Technical Field
[0001] The invention belongs to the technical field of computer programming, and in particular is an orderly multi-threaded batch accounting method based on a bank core system. Background Art
[0002] With the increasing development and widespread application of computer network technology, the traditional way of bank business processing has undergone tremendous changes. From single deposit and loan business to today's comprehensive financial business, the amount and complexity of data that the bank system needs to process has increased significantly, and the transaction volume of account processing business has also increased accordingly.
[0003] However, in the traditional processing method, only one thread among all concurrent threads can hold the resource lock of the current account, and other threads must wait for the lock to be released before they can perform accounting processing. This causes the account to be frequently locked and released, becoming a hot spot in the accounting database, seriously affecting system performance.
[0004] When multiple transactions need to be recorded for the same account at the same time, a transaction waiting problem will arise, that is, a transaction needs to wait for the previous transaction to be recorded before it can continue, which increases the transaction processing time and reduces system efficiency. Summary of the invention
[0005] In view of the above problems, the present invention is proposed to provide an orderly multi-threaded batch accounting method based on a core system of a bank, which overcomes the above problems or at least partially solves the above problems.
[0006] To achieve the above object, the present invention adopts the following technical solutions:
[0007] An orderly multi-threaded batch accounting method based on a bank core system, the method comprising:
[0008] Conduct difference analysis between batch accounting and online accounting;
[0009] Create account model cache;
[0010] Thread pool selection and creation;
[0011] Thread creation scheme selection;
[0012] Encapsulate accounting input and output parameters;
[0013] Adaptive restructuring of bookkeeping operations;
[0014] Parse the thread accounting results;
[0015] Create database interactions and use batch mode;
[0016] Thread accounting results are stored in batches;
[0017] Handling accounting anomalies;
[0018] After accounting is completed, thread management and database interaction operation management are carried out.
[0019] Optionally, create an account model cache including:
[0020] Lock the accounts involved in the transaction through row locks and cache the accounts in memory;
[0021] During the batch accounting process, when the account is involved, the balance of the account is increased or decreased, and the attributes are changed directly in the cache;
[0022] After the batch accounting process is completed, when it is confirmed that it can be submitted for storage, all account change information accumulated in the cache will be processed in batches.
[0023] Optionally, thread pool selection and creation use ThreadPoolExecutor as the implementation of thread pool.
[0024] Optionally, the thread creation solution is to create threads by implementing the Callable interface and combining it with FutureTask.
[0025] Optionally, encapsulation of accounting input and output parameters includes:
[0026] Integrate the basic accounting input parameters, updated account status information, and unique accounting sequence number to form the input parameter set of the accounting operation;
[0027] The encapsulated parameters are used as direct inputs to the thread tasks, and each accounting task is executed based on the latest and most accurate data;
[0028] Expand the return parameters of the original accounting operation and add accounting or business flow model as the return value.
[0029] Optionally, adaptively reconstructing the accounting service includes adaptively reconstructing the online version of the accounting module to adapt to the multi-threaded operating environment.
[0030] Optionally, the thread accounting results are parsed using FutureTask as the thread execution and the accounting results are returned.
[0031] Optionally, batch storage of thread accounting results is performed by adopting a batch processing mode of database interactive operation to process data when processing batch storage operations of thread accounting results.
[0032] Optionally, handling accounting anomalies includes adopting a refined processing strategy to subdivide the abnormal scenarios into multiple categories for targeted processing.
[0033] Optionally, after accounting is completed, thread management and database interaction management are performed, including interrupting the thread that is executing the task, closing the thread pool to release thread resources, and closing the database interaction operation to end the database session and release the database connection and memory resources.
[0034] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are:
[0035] 1. Improve accounting efficiency: The ordered multi-threaded batch accounting method can handle multiple accounting tasks at the same time, which greatly shortens the accounting time compared to the traditional single-threaded accounting method. You no longer need to wait for one task to complete before proceeding to the next one. Multi-threaded parallel processing significantly increases the accounting speed. The batch processing function can account for multiple transactions at one time, reducing repeated operations and system overhead, and further improving efficiency.
[0036] 2. Enhance system stability: Traditional accounting technology solutions may encounter performance bottlenecks when facing a large number of concurrent transactions, causing system freezes or even crashes. The ordered multi-threaded batch accounting method effectively avoids this situation by reasonably allocating thread resources and ensures the stable operation of the system; this method can better cope with the transaction pressure during peak hours and ensure that the bank's core system can provide customers with reliable services at any time.
[0037] 3. Improve data accuracy: The orderly accounting method ensures the order of transactions and avoids data errors that may be caused by chaotic accounting order. Each thread records according to established rules, so that the consistency and integrity of the data are better guaranteed; data verification and error handling can be performed during batch accounting, and possible problems can be discovered and corrected in a timely manner, improving data accuracy.
[0038] 4. Optimize resource utilization: Traditional solutions may sometimes cause idle or over-occupied resources. The ordered multi-threaded batch accounting method can dynamically adjust the number of threads and resource allocation according to the system load, make full use of system resources, and improve resource utilization; this optimized resource utilization method not only reduces hardware costs, but also provides more room for the bank's business expansion. BRIEF DESCRIPTION OF THE DRAWINGS
[0039] Figure 1 A flowchart of an orderly multi-threaded batch accounting method based on a bank core system is provided in an embodiment of the present application. DETAILED DESCRIPTION
[0040] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.
[0041] See also Figure 1 This embodiment provides an orderly multi-threaded batch accounting method based on a bank core system, comprising the following steps:
[0042] S1. Analyze the differences between batch accounting and online accounting.
[0043] Step S1 Analysis of the differences between batch accounting and online accounting is to compare the differences between the two accounting modes; since batch accounting uses multi-threading, its execution order is disordered and thread transactions run independently of the main transaction, which is in sharp contrast to the strict requirements of the bank's core accounting system on transaction consistency and execution order. Therefore, before implementing batch accounting, we need to pre-process account balance changes and the allocation of accounting sequence numbers to ensure the accuracy of subsequent operations.
[0044] S2. Create an account model cache.
[0045] Step S2 creates an account model cache, the core value of which is to optimize the account processing efficiency during batch accounting.
[0046] Creating an account model cache includes:
[0047] The mechanism first locks the account involved in the transaction through a row lock and caches the account in memory; in the subsequent batch accounting process, whenever the account is involved, the system directly increases or decreases the balance of the account and changes the attributes in the cache. This process does not require frequent reading or writing of data from the database, but accumulates all changes in the cached account model; after the entire batch accounting process is completed and it is confirmed that it can be submitted to the warehouse, the system will batch-enter all the account change information accumulated in the cache. The significant advantage of this approach is that it greatly reduces the number of database operations and avoids the performance bottleneck caused by frequent lock acquisition, release, and update query operations. By integrating multiple independent database operations into one batch operation, it not only improves the processing speed, but also reduces the occupation of database resources, thereby improving the overall performance and stability of the system.
[0048] S3. Thread pool selection and creation.
[0049] Step S3 thread pool selection and creation is a key step in optimizing performance and managing accounting threads in application scenarios involving multi-threaded batch accounting. The thread pool significantly reduces overhead by reducing the frequent creation and destruction of threads, thereby improving the system's response speed and throughput. In response to this requirement, it is recommended to use ThreadPoolExecutor as the implementation of the thread pool because it provides highly flexible configuration options. Through ThreadPoolExecutor, we can accurately specify parameters such as the number of core threads, the maximum number of threads, the idle survival time of non-core threads, and the type of work queue. These configurations allow us to manage the thread pool in a detailed and effective manner according to the needs of the actual application scenario, ensuring that batch accounting tasks can be executed efficiently and orderly.
[0050] S4. Selection of thread creation scheme.
[0051] Step S4: Thread creation scheme selection. It is recommended to implement the Callable interface and combine it with FutureTask to create threads. After the threads are submitted, they are managed by the above four thread pools. FutureTask is used as a wrapper for this execution body because it provides methods to check whether the calculation is completed, wait for the calculation to be completed, and obtain the calculation results. This combination not only enhances the flexibility of thread execution, but also improves the robustness of error handling. It is the preferred solution for processing multi-threaded tasks that require result feedback and exception management.
[0052] S5. Encapsulate the accounting input and output parameters.
[0053] Step S5 encapsulates the accounting input and output parameters, which is a deep optimization of the accounting module data processing flow. Through the refined assembly strategy, it not only improves the execution efficiency of the accounting operation, but also significantly enhances its accuracy. Specifically, it includes:
[0054] We innovatively integrate the basic accounting input parameters, updated account status information, and the unique accounting sequence number to form the input parameter set for the accounting operation.
[0055] In a multi-threaded accounting scenario, these carefully encapsulated parameters serve as direct inputs to thread tasks, and each accounting task is executed based on the latest and most accurate data, thus ensuring the consistency, accuracy, efficiency and orderliness of the accounting process.
[0056] In addition, we have also comprehensively expanded the return parameters of the original accounting operation, adding accounting or business flow models as return values. This improvement enables the main transaction to directly obtain the detailed flow information generated after the accounting operation, which is convenient for subsequent batch insertion, update or other related processing, greatly simplifying the data processing process and improving the flexibility and efficiency of the overall business processing.
[0057] S6. Adaptively restructure the accounting business.
[0058] Step S6 adaptively reconstructs the accounting business, aiming to adaptively reconstruct the original online accounting module to adapt to the multi-threaded operating environment. Under this architecture, the core responsibilities of the accounting module are refined into feasibility verification of accounting operations, execution of accounting logic, and assignment of values to business flow models (but not directly executing database entry operations). The results of these operations are returned in the form of models as the execution results of the threads. The returned result set is then processed uniformly under the control of the main transaction to perform batch insertion and update operations of accounting flows or business flows. This transformation plan ensures the consistency of the overall transaction and the compliance of the execution order, and improves the system's concurrent processing capabilities and transaction management efficiency by optimizing the processing flow.
[0059] S7. Analyze the thread accounting results.
[0060] Step S7 parses the thread accounting results. In the scenario where FutureTask is used as the thread execution and the accounting results are returned, the parsing process of the thread accounting results particularly emphasizes respecting the thread submission order. This means that when executing accounting tasks in a concurrent environment, we need to ensure that we can obtain and parse the return results of each thread one by one in the order in which the threads are submitted. This process not only involves processing the results of successfully completed accounting tasks, but also properly encapsulating and recording the task information that failed for some reason. Through this process, we ensure the orderliness and integrity of the accounting results, providing a solid foundation for subsequent batch processing or error recovery. In the end, whether it is a successful or failed result, it will be uniformly returned after proper encapsulation, so that the main thread or upper-level application can perform further processing or display.
[0061] S8. Create database interaction operations and use batch mode.
[0062] Step S8 creates database interaction operations and uses batch processing mode, which is to create and use batch database interaction operations and use batch processing mode. It can effectively manage and collect execution results in the above 8 processes, and then batch account processing is performed on these results, thereby significantly improving the overall execution efficiency of batch accounting flow insertion and household update.
[0063] S9. Thread accounting results are stored in batches.
[0064] Step S9: Batch storage of thread accounting results. When processing batch storage of thread accounting results, we use the batch processing mode of database interaction to perform efficient data processing. This mode allows us to accumulate multiple database operations (such as insert, update, etc.) and execute them at one time, thereby significantly improving the efficiency of data processing. In this process, in order to ensure the consistency and integrity of the data, it is recommended to uniformly call the commit method of the database interaction operation after the batch operation is completed to commit all changes in an atomic manner.
[0065] In addition, in order to effectively manage memory usage and prevent memory overflow caused by excessive data accumulation, we should avoid flushing the database after all the data to be processed is completely written to the memory. Instead, it is recommended to adopt a batch flushing strategy, that is, after processing about 100 to 500 data, call the flushStatements method to force and clear the accumulated database operations. This can maintain the efficiency of the operation and effectively control memory usage to ensure the stable operation of the system.
[0066] S10. Process accounting exceptions.
[0067] Step S10 handles accounting exceptions, aiming to comprehensively cover and efficiently respond to various types of abnormal situations that may occur during the entire batch accounting life cycle. To this end, we have adopted a refined processing strategy to subdivide the abnormal scenarios into multiple categories for targeted processing. Specifically, we distinguish between fault-tolerant scenarios such as 'single accounting fails but does not affect the overall submission', and scenarios with strict consistency requirements such as 'a single failure causes the entire batch to fail'. Through this classified processing method, we can not only ensure that other successful operations can continue to be promoted in the event of partial failures and maintain the overall stability and efficiency of the system, but also promptly interrupt and process the entire batch when data consistency needs to be strictly guaranteed, thereby effectively avoiding data inconsistency or error accumulation.
[0068] S11. After accounting is completed, thread management and database interaction operation management are performed.
[0069] Step S11: Thread management and database interaction management after accounting is completed, refers to a series of cleanup and resource release steps that must be performed when the accounting operation (whether successful or failed) is completed. Specifically, this includes effectively interrupting the thread that is executing the task (if applicable), closing the thread pool to release thread resources, and closing the database interaction operation to end the database session and release the database connection and memory resources associated with it. Through this series of management measures, we can ensure the effective use of system resources, avoid problems such as memory leaks and database connection exhaustion, and thus ensure the stability and reliability of the system.
[0070] This example can improve bookkeeping efficiency: the ordered multi-threaded batch bookkeeping method can handle multiple bookkeeping tasks at the same time, which greatly shortens the bookkeeping time compared to the traditional single-threaded bookkeeping method. You no longer need to wait for one task to complete before proceeding to the next one. Multi-threaded parallel processing significantly increases the bookkeeping speed. The batch processing function can bookkeeping multiple transactions at once, reducing repeated operations and system overhead, and further improving efficiency.
[0071] This example can enhance system stability: Traditional accounting technology solutions may encounter performance bottlenecks when facing a large number of concurrent transactions, causing system freezes or even crashes. The ordered multi-threaded batch accounting method effectively avoids this situation by reasonably allocating thread resources, ensuring the stable operation of the system; this method can better cope with transaction pressure during peak hours and ensure that the bank's core system can provide customers with reliable services at any time.
[0072] This example can improve data accuracy: the orderly accounting method ensures the order of transactions and avoids data errors that may be caused by chaotic accounting order. Each thread records according to the established rules, so that the consistency and integrity of the data are better guaranteed; data verification and error handling can be performed during batch accounting, and possible problems can be discovered and corrected in a timely manner, improving data accuracy.
[0073] This example can optimize resource utilization: Traditional solutions may sometimes have idle or over-occupied resources. The ordered multi-threaded batch accounting method can dynamically adjust the number of threads and resource allocation according to the system load, fully utilize system resources, and improve resource utilization; this optimized resource utilization method not only reduces hardware costs, but also provides more room for the bank's business expansion.
[0074] The above contents are further detailed descriptions of the present invention in combination with specific preferred embodiments, and it cannot be determined that the specific implementation of the present invention is limited to these descriptions. For ordinary technicians in the technical field to which the present invention belongs, several simple deductions or substitutions can be made without departing from the concept of the present invention, which should be regarded as falling within the protection scope of the present invention.
Claims
1. An orderly multi-threaded batch accounting method based on a bank core system, characterized in that: The method comprises: Conduct difference analysis between batch accounting and online accounting; Create account model cache; Thread pool selection and creation; Thread creation scheme selection; Encapsulate accounting input and output parameters; Adaptive restructuring of bookkeeping operations; Parse the thread accounting results; Create database interactions and use batch mode; Thread accounting results are stored in batches; Handling accounting anomalies; After accounting is completed, thread management and database interaction operation management are carried out.
2. The method of orderly multi-threaded batch accounting based on a bank core system as claimed in claim 1, characterized in that: Creating an account model cache includes: Lock the accounts involved in the transaction through row locks and cache the accounts in memory; During the batch accounting process, when the account is involved, the balance of the account is increased or decreased, and the attributes are changed directly in the cache; After the batch accounting process is completed, when it is confirmed that it can be submitted for storage, all account change information accumulated in the cache will be processed in batches.
3. The method of orderly multi-threaded batch accounting based on a bank core system as claimed in claim 1, characterized in that: Thread pool selection and creation use ThreadPoolExecutor as the implementation of thread pool.
4. The method of orderly multi-threaded batch accounting based on a bank core system as claimed in claim 1, characterized in that: The thread creation solution is to create threads by implementing the Callable interface and combining it with FutureTask.
5. The orderly multi-threaded batch accounting method based on the bank core system as claimed in claim 1, characterized in that: Encapsulation of accounting input and output parameters includes: Integrate the basic accounting input parameters, updated account status information, and unique accounting sequence number to form the input parameter set of the accounting operation; The encapsulated parameters are used as direct inputs to the thread tasks, and each accounting task is executed based on the latest and most accurate data; Expand the return parameters of the original accounting operation and add accounting or business flow model as the return value.
6. The method of orderly multi-threaded batch accounting based on a bank core system as claimed in claim 1, characterized in that: The adaptive reconstruction of the bookkeeping business includes the adaptive reconstruction of the online bookkeeping module to adapt to the multi-threaded operating environment.
7. The method of orderly multi-threaded batch accounting based on a bank core system as claimed in claim 1, characterized in that: The thread accounting results are parsed in the scenario where FutureTask is used as the thread to execute and return the accounting results.
8. The method of orderly multi-threaded batch accounting based on a bank core system as claimed in claim 1, characterized in that: Batch storage of thread accounting results is to use the batch processing mode of database interactive operation to process data when processing batch storage operations of thread accounting results.
9. The method of orderly multi-threaded batch accounting based on a bank core system as claimed in claim 1, characterized in that: Handling accounting anomalies includes adopting refined processing strategies and subdividing abnormal scenarios into multiple categories for targeted processing.
10. The method of orderly multi-threaded batch accounting based on a bank core system as claimed in claim 1, characterized in that: After accounting is completed, thread management and database interaction operation management are performed, including interrupting the thread that is executing the task, closing the thread pool to release thread resources, and closing the database interaction operation to end the database session and release the database connection and memory resources.