A quasi-real-time accounting method, device, and storage medium

Abstract

The present invention relates to a quasi-real-time accounting method, which comprises: creating a temporary table; when receiving an accounting request, starting a temporary table insertion thread; in the temporary table insertion thread, inserting information to be accounted into the created temporary table, and starting the accounting thread after completing the temporary table insertion; in the accounting thread, using redis distributed locks to perform accounting operation locking and accounting operations. Compared with the prior art, the present invention solves the accounting errors and duplicate accounting problems in high-concurrency scenarios, while avoiding the database deadlock problem caused by the existing lock table operation, and improves the query efficiency.

Description

Technical Field

[0001] The present invention relates to an accounting method, and in particular to a quasi-real-time accounting method, device and storage medium. Background Art

[0002] At present, the bank's financial system records the subject account and merchant account using a database table to record the beginning balance, debit balance, credit balance and ending balance. Each time a record is added or deleted, the ending balance of the previous record of this subject or merchant is first queried, and then the addition or deletion operation is performed based on this.

[0003] In the case of high concurrency, suppose a and b insert a record at the same time, then they query the ending balance of the previous record c at the same time (assuming it is 100). Assuming b inserts a record after a, b should take the ending balance of a, but now b's beginning balance is taken as c's ending balance of 100, and the continuity and correctness of the accounting is destroyed, resulting in accounting errors. The current technical solution is to lock the table when the program queries the ending balance and then release the lock when the business is completed. This kind of accounting operation by locking the table may cause database deadlock problems, and greatly reduce the efficiency of functional queries related to the subject account and merchant account, and even cause query timeouts, seriously affecting customer experience. Summary of the invention

[0004] The purpose of the present invention is to provide a quasi-real-time accounting method in order to overcome the defects of the above-mentioned prior art, solve the problems of accounting errors and repeated accounting in high-concurrency scenarios, and avoid the database deadlock problem caused by the existing lock table operation, thereby improving query efficiency.

[0005] The purpose of the present invention can be achieved by the following technical solutions:

[0006] A quasi-real-time accounting method, the method comprising:

[0007] Create a temporary table;

[0008] When receiving an accounting request, start the temporary table insertion thread;

[0009] In the temporary table insertion thread, insert the information that needs to be recorded into the created temporary table. After the temporary table insertion is completed, start the accounting thread;

[0010] In the accounting thread, redis distributed lock is used to lock and perform accounting operations.

[0011] Preferably, the information stored in the temporary table includes subject, merchant, amount, debit and credit direction, formula rule, type, and status information.

[0012] Preferably, when multiple accounting requests are made concurrently, one temporary table insertion thread is triggered respectively, and the multiple temporary table insertion threads run synchronously. After each temporary table insertion thread completes the insertion of temporary table information, one accounting thread is started accordingly.

[0013] Preferably, when multiple accounting threads are running concurrently, the concurrent running of the multiple accounting threads is controlled by redis distributed locks.

[0014] Preferably, when multiple accounting threads run concurrently, the redis distributed lock only locks the accounting operation in one of the accounting threads, and triggers scanning of the temporary table for accounting processing based on the accounting execution status field in redis.

[0015] Preferably, the specific execution process of the accounting thread includes:

[0016] S1. After starting the accounting thread, the redis distributed lock performs the accounting operation lock operation;

[0017] S2. Determine whether the accounting operation is locked successfully. If so, execute S3. Otherwise, change the accounting execution status field in redis to "Not Executed" and end the current thread.

[0018] S3. Change the accounting execution status field in redis to "executed";

[0019] S4, scan the temporary table for accounting processing;

[0020] S5. After the accounting operation is completed, check whether the accounting execution status field in redis is "executed". If so, release the lock of the accounting operation by the redis distributed lock and end the current thread. Otherwise, loop through steps S3 to S5.

[0021] Preferably, step S4 specifically includes: scanning the temporary table, obtaining the information currently required to be recorded in the temporary table, and modifying the corresponding status information to perform accounting processing.

[0022] Preferably, when there are multiple information items that need to be accounted for in the temporary table, all the accounting information items are obtained synchronously, the status information of all the obtained accounting information items is modified, and accounting processing is performed on the accounting information items one by one.

[0023] A quasi-real-time accounting device comprises a memory and a processor, wherein the memory is used to store a computer program, and the processor is used to implement the quasi-real-time accounting method when executing the computer program.

[0024] A storage medium stores a computer program, which implements the quasi-real-time accounting method when executed by a processor.

[0025] Compared with the prior art, the present invention has the following advantages:

[0026] The present invention divides the accounting logic into two types of threads, namely temporary table insertion threads and accounting threads, and optimizes the accounting process. The temporary table insertion threads can run concurrently, and the redis distributed lock is used to realize data atomic processing. The redis distributed lock locks the accounting operation instead of locking the accounting table in the database. The method of the present invention solves the accounting errors and repeated accounting problems in high concurrency scenarios, avoids the database deadlock problem caused by the existing table lock operation, and improves the query efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 The present invention is a flowchart of a quasi-real-time accounting method. DETAILED DESCRIPTION

[0028] The present invention is described in detail below in conjunction with the accompanying drawings and specific embodiments. Note that the following embodiments are merely illustrative in nature, and the present invention is not intended to limit its applicable objects or uses, and the present invention is not limited to the following embodiments.

[0029] Example 1

[0030] The present invention optimizes the bookkeeping method based on the existing technical solution. First, the system adds a temporary table to save the account, merchant, amount, debit and credit direction, formula rule, type (new, deleted), and status (initial, formal) information. Then, when adding or deleting a merchant account or a subject account, insert relevant data into the temporary table. Finally, the temporary table is scanned through multi-threaded triggering, and the program is run concurrently through the redis distributed lock control program, and the merchant account or subject account that needs to be added or deleted is uniformly bookkeeping.

[0031] Specifically, Figure 1 As shown, this embodiment provides a quasi-real-time accounting method, the method comprising:

[0032] Create a temporary table;

[0033] When receiving an accounting request, start the temporary table insertion thread;

[0034] In the temporary table insertion thread, insert the information that needs to be recorded (the merchant account and subject account related data that need to be added or deleted) into the created temporary table, and start the accounting thread after completing the temporary table insertion;

[0035] In the accounting thread, redis distributed lock is used to lock and perform accounting operations.

[0036] The information stored in the temporary table includes account, merchant, amount, debit and credit direction, formula rule, type (new, deleted), and status information (initial, official).

[0037] When multiple accounting threads are running concurrently, a temporary table insertion thread is triggered respectively. Multiple temporary table insertion threads run synchronously. After each temporary table insertion thread completes the insertion of temporary table information, a corresponding accounting thread is started. At the same time, the concurrent operation of multiple accounting threads is controlled by redis distributed locks. Specifically: when multiple accounting threads are running concurrently, the redis distributed lock only locks the accounting operation in one of the accounting threads, and triggers scanning of the temporary table for accounting processing based on the accounting execution status field in redis.

[0038] The specific execution process of the accounting thread includes:

[0039] S1. After starting the accounting thread, the redis distributed lock performs the accounting operation lock operation;

[0040] S2. Determine whether the accounting operation is locked successfully. If so, execute S3. Otherwise, it means that an accounting operation is currently being executed. Change the accounting execution status field in redis to "Not Executed" and end the current thread.

[0041] S3. Change the accounting execution status field in redis to "executed";

[0042] S4. Scan the temporary table for accounting processing, specifically:

[0043] Scan the temporary table, obtain the information currently required to be recorded in the temporary table, modify the corresponding status information (mark as having been recorded), and perform the recording process. When there are multiple information items that need to be recorded in the temporary table, all the recording information items are obtained synchronously, and the status information of all the obtained recording information items is modified (mark as having been recorded), and the recording process is performed on each recording information item. The recording process method is consistent with the existing recording method. First, query the database for the ending balance of the previous record of this account or merchant, and then perform addition or deletion operations on this basis.

[0044] S5. After the accounting operation is completed, check whether the accounting execution status field in redis is "executed". If so, release the lock of the accounting operation by the redis distributed lock and end the current thread. Otherwise, loop through steps S3 to S5.

[0045] Let's take a specific example to illustrate:

[0046] If two accounting requests a and b are received at the same time, the temporary table insertion thread a and the temporary table insertion thread b are started. The two temporary table insertion threads run concurrently and insert the corresponding information that needs to be accounted into the temporary table, including accounting information a and accounting information b. At this time, the status of the two accounting information is that the accounting processing is not completed. Then, after the temporary table information is inserted, the accounting thread a and the accounting thread b are started respectively. The accounting operation lock is allocated through the redis distributed lock. Assuming that the accounting thread a has completed the lock of the current accounting operation, the accounting thread b will change the accounting execution status field in redis to "not executed" and end the accounting thread b. At the same time, the accounting thread a will change the accounting execution status field in redis to "executed". The accounting thread a performs the accounting operation: first, scan the temporary table to obtain all the accounting information entries in the temporary table that have not completed the accounting processing, including accounting information a and accounting information b, and then perform the accounting processing. The accounting processing method is consistent with the existing accounting method. First, query the database for the ending balance of the previous record of this account or merchant, and then perform addition or deletion operations on this basis. After the accounting operation is completed, check whether the accounting execution status field in redis is "executed". If so, release the lock of the accounting operation by the redis distributed lock and end the current thread. Otherwise, it means that there is still accounting information that has not been processed in the temporary table (for example, during the accounting processing of the above-mentioned accounting thread a, there is a new accounting request c, and the temporary table insertion thread c and the corresponding accounting thread c are started. Since the redis distributed lock has not been released at this time, the accounting thread c cannot successfully lock the accounting operation of the current thread, so the accounting execution status field in redis will be modified to "not executed"). At this time, the accounting thread a needs to change the accounting execution status field in redis to "executed" and loop the above-mentioned accounting operation process.

[0047] The present invention divides the accounting logic into two types of threads, namely, temporary table insertion threads and accounting threads, and optimizes the accounting process. The temporary table insertion threads can run concurrently, and the redis distributed lock is used to realize data atomic processing. The redis distributed lock locks the accounting operation instead of locking the accounting table in the database. The method of the present invention solves the accounting errors and repeated accounting problems in high-concurrency scenarios, and avoids the database deadlock problem caused by the existing table lock operation and improves the query efficiency.

[0048] Example 2

[0049] This embodiment provides a quasi-real-time accounting device, including a memory and a processor, the memory is used to store a computer program, and the processor is used to implement the quasi-real-time accounting method described in Example 1 when executing the computer program. The quasi-real-time accounting method has been described in detail in Example 1 and will not be repeated in this embodiment.

[0050] Example 3

[0051] This embodiment provides a storage medium on which a computer program is stored. When the computer program is executed by a processor, the quasi-real-time accounting method described in Embodiment 1 is implemented. The quasi-real-time accounting method has been described in detail in Embodiment 1 and will not be described in detail in this embodiment.

[0052] The above embodiments are merely examples and do not limit the scope of the present invention. These embodiments can also be implemented in various other ways, and various omissions, substitutions, and changes can be made without departing from the technical concept of the present invention.

Claims

1. A quasi-real-time accounting method, characterized in that: The method includes: Create a temporary table; When receiving an accounting request, start the temporary table insertion thread; In the temporary table insertion thread, insert the information that needs to be recorded into the created temporary table. After the temporary table insertion is completed, start the accounting thread; In the accounting thread, redis distributed lock is used to lock and perform accounting operations; When multiple accounting requests are made concurrently, a temporary table insertion thread is triggered respectively. Multiple temporary table insertion threads run synchronously. After each temporary table insertion thread completes the insertion of temporary table information, a corresponding accounting thread is started. When multiple accounting threads are running concurrently, the concurrent operation of multiple accounting threads is controlled by redis distributed locks; When multiple accounting requests are made concurrently, when multiple accounting threads are running concurrently, the redis distributed lock only locks the accounting operation in one of the accounting threads, and triggers scanning of the temporary table for accounting processing based on the accounting execution status field in redis; The specific execution process of the accounting thread includes: S1. After starting the accounting thread, the redis distributed lock performs the accounting operation lock operation; S2. Determine whether the accounting operation is locked successfully. If so, execute S3. Otherwise, change the accounting execution status field in redis to "not executed" and end the current thread. S3. Change the accounting execution status field in redis to "executed"; S4, scan the temporary table for accounting processing; S5. After the accounting operation is completed, check whether the accounting execution status field in redis is "executed". If so, release the lock of the accounting operation by the redis distributed lock and end the current thread. Otherwise, loop through steps S3 to S5.

2. A quasi-real-time accounting method according to claim 1, characterized in that: The information stored in the temporary table includes subject, merchant, amount, debit and credit direction, formula rule, type, and status information.

3. A quasi-real-time accounting method according to claim 1, characterized in that: Step S4 specifically includes: scanning the temporary table, obtaining the information currently required to be recorded in the temporary table, and modifying the corresponding status information to perform accounting processing.

4. A quasi-real-time accounting method according to claim 3, characterized in that: When there are multiple information items that need to be recorded in the temporary table, all the accounting information items are obtained synchronously, the status information of all the obtained accounting information items is modified, and the accounting information items are processed one by one.

5. A quasi-real-time accounting device, characterized in that: The invention comprises a memory and a processor, wherein the memory is used to store a computer program, and the processor is used to implement the quasi-real-time accounting method according to any one of claims 1 to 4 when executing the computer program.

6. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the quasi-real-time accounting method as claimed in any one of claims 1 to 4 is implemented.

Images