Method and device for ensuring consistency of available balances of hotspot accounts

Abstract

The invention provides a method and device for ensuring the consistency of available balances of hotspot accounts, and relates to the technical field of data processing. The method comprises the following steps: determining a main transaction corresponding to a deposit transaction of a hotspot account and a plurality of sub-transactions corresponding to the main transaction, wherein the plurality of sub-transactions comprise deposit balance sub-transactions; the hotspot accounts are accounts having high-frequency transactions at the same time; when the deposit balance sub-transaction is successfully executed, accumulating a deposit amount corresponding to the deposit transaction in a first record of the first data table according to an account identifier of the hotspot account; the first record is used for representing a locked amount of money of the hotspot account; when the sub-transactions corresponding to the main transaction are successfully executed, accumulating the deposit amount in a second record of a second data table according to the account identifier of the hotspot account, the second record being used for representing the releasable amount of the hotspot account; the available balance of the hotspot account is determined according to the third record, the first record and the second record in the account fund table; the third record is used for representing the balance of the hotspot account.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a method and device for ensuring consistency of available balance of a hotspot account. Background Art

[0002] In response to the national localization requirements, the core host system of the bank needs to be fully moved to the distributed system. However, due to various reasons such as database, hardware network, etc., the system performance of the distributed system is greatly reduced compared to the host system. Some corporate deposit accounts with large transaction volumes have hot account problems, which are mainly manifested in transaction timeouts or concurrent lock errors in high concurrency scenarios.

[0003] Existing solutions to the hot account problem include the multi-sub-account solution and the long transaction split sub-transaction solution. In solving hot issues such as real-time cash pool accounts, due to the complexity of product functions, there are many database tables involved in the transaction process for hot accounts. If a multi-sub-account solution is used, it is extremely complicated. For hot issues such as real-time cash pool accounts, it is more suitable to adopt the long transaction split sub-transaction solution. The so-called long transaction split sub-transaction solution refers to splitting the traditional transaction submitted once into multiple sub-transactions, and submitting each sub-transaction in stages, so as to reduce the lock time of a single table and improve the ability of the distributed system to process transactions per second for a single account.

[0004] However, the solution of splitting long transactions into sub-transactions may lead to inconsistency risks. This risk mainly exists in deposit transactions. After the deposit balance sub-transaction is submitted, if the subsequent sub-transactions or the main transaction fails to execute due to system downtime, the deposit balance sub-transaction needs to be rolled back. If during this period, the funds deposited in the account have been withdrawn by the customer, the deposit balance sub-transaction will fail to be rolled back, which will lead to inconsistencies between the customer account and the bank account.

[0005] Therefore, there is an urgent need for a method to resolve the inconsistency issues that may occur in deposit transactions of hotspot accounts. Summary of the invention

[0006] The present application provides a method and device for ensuring the consistency of the available balance of a hotspot account, so as to avoid the failure of the rollback of the deposit balance sub-transaction in the hotspot account deposit scenario, and ensure the consistency of the available balance of the hotspot account.

[0007] In a first aspect, the present application provides a method for ensuring consistency of available balance of a hotspot account, the method comprising:

[0008] Determine a main transaction corresponding to a deposit transaction of a hotspot account and multiple subtransactions corresponding to the main transaction, wherein the multiple subtransactions include a deposit balance subtransaction; the hotspot account is an account with high-frequency transactions at the same time;

[0009] When the deposit balance subtransaction is successfully executed, the deposit amount corresponding to the deposit transaction is accumulated in the first record of the first data table according to the account identifier of the hotspot account; the first record is used to indicate the locked amount of the hotspot account;

[0010] After all sub-transactions corresponding to the main transaction are executed successfully, the deposited amount is accumulated in the second record of the second data table according to the account identifier of the hotspot account, and the second record is used to indicate the releasable amount of the hotspot account; the available balance of the hotspot account is determined according to the third record in the account funds table, the first record and the second record; the third record is used to indicate the balance of the hotspot account.

[0011] The method for ensuring the consistency of the available balance of a hotspot account provided in the present application is applicable to the deposit scenario of a hotspot account. The deposit transaction of the hotspot account corresponds to a main transaction, and the main transaction corresponds to multiple sub-transactions. When the deposit balance sub-transaction in the multiple sub-transactions is successfully executed, the first record corresponding to the hotspot account in the first data table is updated, and the first record is used to indicate the amount of money locked or frozen in the hotspot account. The amount recorded in the first record is temporarily unavailable for use by the hotspot account; when all sub-transactions corresponding to the main transaction are successfully executed, the second record corresponding to the hotspot account in the second data table is updated, and the second record is used to indicate the amount that can be released or unfrozen in the hotspot account. Since the available balance of the hotspot account is associated with the first record and the second record, the second record is updated only after all sub-transactions are successfully executed. This ensures that the available balance of the hotspot account is updated only after all sub-transactions are successfully executed, thereby avoiding the problem of failure to roll back the deposit balance sub-transaction due to the deposited amount having been used by the hotspot account during the deposit balance sub-transaction, thereby ensuring the consistency of the available balance of the hotspot account.

[0012] In a possible design, the first data table is the account funds table, and the first record corresponds to a newly added field in the account funds table; the second data table is a newly added data table;

[0013] When the deposit balance sub-transaction is successfully executed, the method further includes:

[0014] The deposit amount is accumulated to the third record corresponding to the account identifier of the hotspot account in the account funds table.

[0015] The first data table in the present application reuses the existing account funds table, and a new field is added to the account funds table to indicate the amount locked in the hotspot account; and the second data table is a newly added data table. When each sub-transaction is successfully executed, only the second data table needs to be updated, and there is no need to update the first data table. Because the concurrent pressure of the account funds table is relatively large, by adding a second data table, the operations on the account funds table can be reduced, thereby reducing the concurrent pressure of the account funds table.

[0016] In a possible design, after each sub-transaction corresponding to the main transaction is successfully executed, the deposit amount is accumulated in the second record of the second data table according to the account identifier of the hotspot account, including:

[0017] After all sub-transactions corresponding to the main transaction are successfully executed, a release instruction is determined; the release instruction includes the account identifier of the hotspot account and the deposit amount;

[0018] According to the release instruction, the deposit amount is accumulated in the second record corresponding to the account identifier of the hotspot account in the second data table.

[0019] The release instruction includes the account ID of the hotspot account and the deposit amount corresponding to the deposit transaction. First, a match is performed in the second data table based on the account ID of the hotspot account to determine the second record, and then the second record is updated based on the deposit amount included in the release instruction.

[0020] In a possible design, after the deposit balance sub-transaction is successfully executed, the following is further included:

[0021] Registering a release record to a cache, wherein the release record includes an account identifier of the hotspot account and the deposit amount;

[0022] After all sub-transactions corresponding to the main transaction are successfully executed, before the release instruction is determined, the method further includes:

[0023] Determining the release record in a cache according to the account identifier of the hotspot account;

[0024] Recording the account identifier of the hotspot account and the deposit amount included in the release record in a third data table;

[0025] After all sub-transactions corresponding to the main transaction are successfully executed, determining a release instruction includes:

[0026] After all sub-transactions corresponding to the main transaction are successfully executed, a release instruction is determined according to the third data table.

[0027] The existing solution sends a Kafka message based on the records in the cache after the main transaction ends. Since the records in the cache will be completely cleared after the main transaction ends, there is a possibility of message loss. The present application synchronizes the release records in the cache to the third data table after each sub-transaction is successfully executed, which is more persistent and ensures the reliability and consistency of the data, thereby ensuring that when the release instruction needs to be determined, the third data table has been updated, and the release instruction can be determined by reading the third data table, thereby improving the reliability of the release instruction determination.

[0028] In a possible design, the third data table further includes a transaction identification field;

[0029] After all sub-transactions corresponding to the main transaction are successfully executed, determining a release instruction according to the third data table includes:

[0030] After all subtransactions corresponding to the main transaction are successfully executed and the main transaction is committed, the account identifier of the hotspot account and the deposit amount are determined in the third data table according to the transaction identifier of the deposit transaction corresponding to the main transaction;

[0031] The release instruction is determined according to the account identifier of the hotspot account and the deposit amount.

[0032] After each sub-transaction is successfully executed, there are still some operations to be executed in the main transaction. In other words, the successful execution of each sub-transaction does not mean that the main transaction is committed. If the main transaction is not successfully committed, the deposit balance sub-transaction still needs to be rolled back. Therefore, the release instruction is determined only after all sub-transactions corresponding to the main transaction are successfully executed and the main transaction is committed.

[0033] In a possible design, after accumulating the deposit amount corresponding to the deposit transaction in the first record of the first data table according to the account identifier of the hotspot account, the method further includes:

[0034] If at least one of the multiple subtransactions fails to execute, the first record is reduced by the deposit amount.

[0035] If a subtransaction after the deposit balance subtransaction fails to execute, the deposit balance subtransaction needs to be rolled back, and accordingly, the first record needs to be subtracted from the deposit amount.

[0036] In a second aspect, the present application also provides a device for ensuring consistency of available balance of a hotspot account, the device comprising: a processing unit and a computing unit;

[0037] The processing unit is used to determine a main transaction corresponding to a deposit transaction of a hotspot account and a plurality of subtransactions corresponding to the main transaction, wherein the plurality of subtransactions include a deposit balance subtransaction; the hotspot account is an account with high-frequency transactions at the same time;

[0038] The calculation unit is used to accumulate the deposit amount corresponding to the deposit transaction in the first record of the first data table according to the account identifier of the hotspot account after the deposit balance subtransaction is successfully executed; the first record is used to indicate the locked amount of the hotspot account;

[0039] The calculation unit is also used to accumulate the deposit amount in the second record of the second data table according to the account identifier of the hotspot account after all sub-transactions corresponding to the main transaction are successfully executed, and the second record is used to indicate the releasable amount of the hotspot account; the available balance of the hotspot account is determined according to the third record in the account funds table, the first record and the second record; the third record is used to indicate the balance of the hotspot account.

[0040] In a possible design, the first data table is the account funds table, and the first record corresponds to a newly added field in the account funds table; the second data table is a newly added data table;

[0041] When the deposit balance sub-transaction is successfully executed, the calculation unit is further used to add the deposit amount to the third record corresponding to the account identifier of the hot account in the account funds table.

[0042] In one possible design, the computing unit is used to accumulate the deposit amount in the second record of the second data table according to the account identifier of the hotspot account after all subtransactions corresponding to the main transaction are successfully executed: when all subtransactions corresponding to the main transaction are successfully executed, determine a release instruction; the release instruction includes the account identifier of the hotspot account and the deposit amount; according to the release instruction, accumulate the deposit amount in the second record corresponding to the account identifier of the hotspot account in the second data table.

[0043] In one possible design, after the deposit balance sub-transaction is successfully executed, the processing unit is further used to register a release record to the cache, wherein the release record includes the account identifier of the hotspot account and the deposit amount; the release record is determined in the cache according to the account identifier of the hotspot account; the account identifier of the hotspot account and the deposit amount included in the release record are recorded in a third data table; the processing unit is used to determine a release instruction after all sub-transactions corresponding to the main transaction are successfully executed: when all sub-transactions corresponding to the main transaction are successfully executed, determine the release instruction according to the third data table.

[0044] In one possible design, the third data table also includes a transaction identification field; the processing unit is used to determine the release instruction according to the third data table when all subtransactions corresponding to the main transaction are executed successfully: when all subtransactions corresponding to the main transaction are executed successfully and the main transaction is committed, determine the account identification of the hotspot account and the deposit amount in the third data table according to the transaction identification of the deposit transaction corresponding to the main transaction; and determine the release instruction according to the account identification of the hotspot account and the deposit amount.

[0045] In one possible design, after accumulating the deposit amount corresponding to the deposit transaction in the first record of the first data table according to the account identifier of the hotspot account, the calculation unit is further used to subtract the deposit amount from the first record if at least one sub-transaction among the multiple sub-transactions fails to execute.

[0046] In a third aspect, the present application also provides a device for ensuring consistency of available balance of a hotspot account, the device comprising: a processor, and a memory in communication with the processor;

[0047] The memory stores computer-executable instructions;

[0048] The processor executes the computer-executable instructions stored in the memory to implement the method described in the first aspect above.

[0049] In a fourth aspect, the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium includes a program, and when the program is executed on a device, the device executes the method as described in any one of the above-mentioned first aspects.

[0050] In a fifth aspect, the present application further provides a computer program product, wherein the computer program product comprises a computer program, and when the computer program is executed by a processor, the method described in the first aspect is implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0052] Figure 1 A schematic diagram of the SAGA mode flow chart provided in the embodiment of the present application;

[0053] Figure 2 A flow chart of a method for ensuring consistency of available balance of hotspot accounts provided in an embodiment of the present application;

[0054] Figure 3 A schematic diagram of a secondary zero-balance real-time cash pool member account collection function provided in an embodiment of the present application;

[0055] Figure 4 Provide transaction flow chart for the existing secondary zero balance real-time cash pool member account collection function;

[0056] Figure 5 This is the improved transaction flow chart of the secondary zero balance real-time cash pool member account collection function;

[0057] Figure 6 Schematic diagram of the structure of the device for ensuring the consistency of the available balance of the hotspot account provided in the embodiment of the present application Figure 1 ;

[0058] Figure 7 Schematic diagram of the structure of the device for ensuring the consistency of the available balance of the hotspot account provided in the embodiment of the present application Figure 2 . DETAILED DESCRIPTION

[0059] In order to make the purpose, technical scheme and advantages of the present application clearer, the technical scheme in the embodiment of the present application will be clearly and completely described below in conjunction with the drawings in the embodiment of the present application. Obviously, the described embodiment is only a part of the embodiment of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application. In the absence of conflict, the embodiments in the present application and the features in the embodiments can be arbitrarily combined with each other. In addition, although the logical order is shown in the flow chart, in some cases, the steps shown or described can be performed in an order different from that here.

[0060] The terms "first" and "second" in the specification and claims of the present application and the above-mentioned drawings are used to distinguish different objects, rather than to describe a specific order. In addition, the term "comprising" and any of their variations are intended to cover non-exclusive protection. For example, a process, method, system, product or device comprising a series of steps or units is not limited to the listed steps or units, but optionally also includes steps or units that are not listed, or optionally also includes other steps or units inherent to these processes, methods, products or devices. "Multiple" in the present application can mean at least two, for example, two, three or more, and the embodiments of the present application are not limited.

[0061] The following is a description of exemplary embodiments of the present application in conjunction with the accompanying drawings, including various details of the embodiments of the present application to facilitate understanding, which should be considered as merely exemplary. Therefore, those of ordinary skill in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of the present application. Similarly, for the sake of clarity and conciseness, the description of well-known functions and structures is omitted in the following description. It should be noted that in the embodiments of the present application, certain software, components, models and other existing solutions in the industry may be mentioned, which should be considered as exemplary, and their purpose is only to illustrate the feasibility of the implementation of the technical solution of the present application, but it does not mean that the applicant has or will necessarily use the solution.

[0062] In the technical solution of this application, the acquisition, transmission, storage, and use of data are in compliance with the requirements of relevant national laws and regulations.

[0063] The SAGA mode was first applied to distributed systems. It splits long transactions into multiple short sub-transactions and executes them separately to solve the performance problem of long transactions. The success of each short transaction is equivalent to a successful transaction. If one sub-transaction fails, the successfully executed sub-transaction is rolled back. For example, Figure 1 As shown, Figure 1 This is a simple example of the SAGA model. The main transaction of a transaction is divided into subtransaction 1, subtransaction 2 and subtransaction 3. When subtransactions 1 to 3 are all executed successfully, the transaction is considered successful and the transaction serial number is registered; if any of subtransactions 1 to 3 fails to execute, the successfully executed subtransaction is rolled back. Assuming that subtransaction 1 is executed successfully and subtransaction 2 fails to execute, the successfully executed subtransaction 1 needs to be rolled back. The SAGA model is suitable for business scenarios with long transactions that are not sensitive to intermediate results, such as the purchase of financial products, but it is not applicable to account transaction scenarios. It may happen that the account has been deducted or credited, but the transfer fails in the end.

[0064] The TCC mode is a method for solving the consistency of distributed transactions, which can also be called the Try-Confirm-Cancel three-stage processing mode. As the name suggests, the TCC mode is divided into three processing stages, namely the Try stage, the Confirm stage, and the Cancel stage; among them, the Try stage: complete all business checks, fail if the check fails, and reserve necessary business resources if the check succeeds; Confirm stage: confirm the execution, no check is performed in this stage, and the business resources reserved in the Try stage are used; Cancel stage: cancel the execution and release the business resources reserved for the Try calculation; in a distributed system, each local subtransaction first performs a Try, and after all Try succeeds, the global transaction issues a Confirm instruction; if a subtransaction fails in the Try stage, the global transaction issues a Cancel instruction to release the business resources reserved in the Try stage. Taking a transfer transaction of 100 yuan as an example, the various stages of the TCC model are introduced: ① The transferor tries: checks the account status, available balance, etc. If the check passes, 100 yuan will be frozen; ② The transferee tries: checks whether the account status allows the transfer; ③ Both parties confirm: If both the transferor and the transferee try successfully, the transferor and the transferee will perform the Confirm operation respectively, that is, update the account balance, the transferor deducts 100 yuan, and the transferee increases 100 yuan; ④ One party cancels: If one party tries successfully and the other fails, the party that has tried successfully will be canceled to release business resources.

[0065] The SAGA model is simple to implement, but it is not suitable for account transaction scenarios. The TCC model is relatively complex to implement. Based on the shortcomings of these two existing solutions, this application proposes the following Figure 2 The method shown in the figure is executed by a server, or a chip or a functional module in the server, and this application does not limit this.

[0066] First, let's briefly introduce the transactions, sub-transactions, and main transactions involved in this application:

[0067] Transaction: In computer terms, a transaction refers to a program execution unit that accesses and possibly updates various data items in a database, usually written in a high-level database manipulation language or programming language. Transactions have four characteristics: atomicity, consistency, isolation, and persistence. The so-called atomicity of a transaction means that all operations in a transaction are either successful or failed. If an operation fails during the execution of a transaction, all operations that have been successfully executed before should be rolled back. In traditional banking core systems, in order to ensure the consistency of accounts, each core transaction is a transaction. As the distributed core system of a bank moves downward, each core transaction may be composed of multiple microservices. In this way, one microservice is a transaction.

[0068] Subtransactions: Each database operation of a transaction is split into more fine-grained transactions for processing, which is called a subtransaction. Splitting into subtransactions can reduce the table lock time of database update operations and increase the number of transactions processed per second for a single account. Therefore, subtransactions are one of the effective ways to solve the problem of hot accounts, especially for accounts that have signed complex products, such as real-time cash pool products with multi-level account systems. However, subtransactions may bring the risk of account inconsistency.

[0069] Main transaction: After a transaction is split into one or more sub-transactions, the original transaction is called the main transaction. The main transaction controls the scheduling relationship between each sub-transaction. Only when the main transaction is successfully submitted, the transaction is truly successful.

[0070] The following uses the server as the execution subject Figure 2 The method shown is described below, and the method specifically includes:

[0071] Step 200: Determine a main transaction corresponding to a deposit transaction of a hotspot account and multiple subtransactions corresponding to the main transaction, wherein the multiple subtransactions include a deposit balance subtransaction. A hotspot account is an account with high-frequency transactions at the same time.

[0072] For example, hot accounts are caused by hot scenarios. The so-called hot scenarios refer to customers or internal users who initiate transactions on the same account in an instant or over a period of time in online or batch mode from various channels. This exceeds the system's single-account transaction processing capacity, resulting in slow transactions or even transaction timeout failures. Accounts that are centrally processed in hot scenarios are hot accounts.

[0073] Exemplarily, a deposit transaction is a common transaction for a hotspot account. The deposit transaction for a hotspot account corresponds to a main transaction, and the main transaction corresponds to multiple subtransactions, including a deposit balance subtransaction, which is mainly used to update the account funds table.

[0074] For example, customer A transfers RMB 1,000 to customer B. For customer B, this transaction is a deposit transaction, and this deposit transaction corresponds to a main transaction and multiple sub-transactions, including a deposit balance sub-transaction.

[0075] Step 201: When the deposit balance subtransaction is successfully executed, the deposit amount corresponding to the deposit transaction is accumulated in the first record of the first data table according to the account identifier of the hotspot account, and the first record is used to indicate the locked amount of the hotspot account.

[0076] Exemplarily, the first data table may be an account fund table, and the main fields in the existing account fund table are shown in Table 1:

[0077] Field Name type Is it a primary key? Customer Account CHAR(32) Y Currency Code CHAR(3) Y Banknote code CHAR(1) Y Account Balance DECIMAL(19,2) N Timestamp DECIMAL(17,0) N

[0078] Table 1

[0079] As shown in Table 1, the account funds table mainly includes fields such as customer account number, currency code, banknote code, account balance and timestamp, among which the customer account number, currency code and banknote code fields are primary keys. For example, the customer account number field can uniquely identify a customer.

[0080] This application modifies the account funds table by adding a new field to the account funds table. The modified account funds table, i.e., the first data table, is shown in Table 2:

[0081] Field Name type Is it a primary key? Customer Account CHAR(32) Y Currency Code CHAR(3) Y Banknote code CHAR(1) Y Account Balance DECIMAL(19,2) N Subtransaction cumulative credit amount DECIMAL(19,2) N Timestamp DECIMAL(17,0) N

[0082] Table 2

[0083] As can be seen from Table 2, the newly added field in the account funds table is the cumulative credit amount of the sub-transaction, and the first record corresponds to the newly added field in the account funds table, that is, the first record is the cumulative credit amount of the sub-transaction; when the deposit balance sub-transaction is successfully executed, it will first be matched in the account funds table according to the customer's account ID, and the matched row is the corresponding data of the customer in the account funds table. The cumulative credit amount of the sub-transaction in this row can be called the first record, and then the deposit amount corresponding to the deposit transaction is accumulated to the first record.

[0084] For example, suppose the fund table of an account is as shown in Table 3:

[0085] Customer Account Account Balance Subtransaction cumulative credit amount 111222 20000 0 222333 1200 0 333444 50000 0

[0086] Table 3

[0087] There are three customers in Table 3, and their account numbers are 111222, 222333 and 333444, respectively. Their corresponding account balances are 20000, 1200 and 50000, respectively. Assume that customer A transfers 1000 to customer B, and customer B's account ID is 222333. According to customer B's account ID, a match is made in Table 3. Customer B's account ID 222333 is the same as the customer account number in the second row of Table 3. Therefore, the second row of Table 3 is the data corresponding to customer B, and the accumulated credit amount of the subtransaction in the second row is the first record. Before the deposit balance subtransaction corresponding to this transfer transaction is successfully executed, the first record is 0; when the deposit balance subtransaction is successfully executed, the transaction amount 1000 corresponding to the deposit transaction is accumulated to the first record, so the first record is changed from 0 to 1000.

[0088] Further illustratively, when the deposit balance subtransaction is successfully executed, the deposit amount must be accumulated to the third record corresponding to the account identifier of the hotspot account in the account funds table. The third record is used to indicate the balance of the hotspot account, corresponding to the account balance field in the account funds table. For example, the third record corresponding to customer B is the account balance of row 2 in Table 3. Before the deposit balance subtransaction is successfully executed, the third record corresponding to customer B is 1200; after the deposit balance subtransaction is successfully executed, the deposit amount of 1000 should be accumulated to the third record, and the third record is changed from 1200 to 2200. Therefore, when the deposit balance subtransaction corresponding to the transfer of 1,000 yuan from customer A to customer B is successfully executed, the account funds table is updated from Table 3 to Table 4, as shown below:

[0089] Customer Account Account Balance Subtransaction cumulative credit amount 111222 20000 0 222333 2200 1000 333444 50000 0

[0090] Table 4

[0091] It can be seen from Table 4 that the current first record of the customer with account number 222333 is 1000. Since the first record is used to indicate the locked amount of the hotspot account, that is to say, the current locked amount of the customer with account number 222333 is 1000 yuan, which customer B cannot currently use.

[0092] It should be noted that, in addition to being able to reuse the existing account funds table, the first data table can also add a new data table as the first data table. The newly added data table includes customer account numbers and sub-transaction cumulative credit amount fields. Similarly, the sub-transaction cumulative credit amount field is used to indicate the locked amount of the hotspot account. However, compared with reusing the existing account funds table, this method has poorer performance, because if the first data table reuses the existing account funds table, after the deposit balance sub-transaction is successfully executed, only the account funds table needs to be updated. If the first data table is a newly added data table, after the deposit balance sub-transaction is successfully executed, not only the account balance field in the account funds table needs to be updated, but also the sub-transaction cumulative released credit amount field in the first data table needs to be updated. In other words, two tables need to be updated, so the performance is poor.

[0093] Further illustratively, when the deposit balance sub-transaction is successfully executed, not only the first data table needs to be updated, but also the release record needs to be registered in the cache, wherein the release record includes the account ID and deposit amount of the hotspot account; still taking the transfer of 1,000 yuan from customer A to customer B as an example, when the deposit balance sub-transaction is successfully executed, the release record registered in the cache is: account ID: 222333, amount: 1,000.

[0094] Step 202: After all sub-transactions corresponding to the main transaction are executed successfully, the deposit amount is accumulated in the second record of the second data table according to the account identifier of the hotspot account, and the second record is used to indicate the releasable amount of the hotspot account; the available balance of the hotspot account is determined based on the third record, the first record and the second record in the account funds table.

[0095] For example, since multiple users may have transactions at the same time, all of which need to operate the account funds table, the concurrent pressure on the account funds table is relatively large. In order to reduce the concurrent pressure on the account funds table, this application adds a data table, recorded as the second data table. When each sub-transaction in the main transaction is successfully executed, there is no need to operate the account funds table, and only the second data table needs to be updated. The newly added second data table can also be called the sub-transaction amount release table, and the main fields are shown in Table 5:

[0096] Field Name type Is it a primary key? Customer Account CHAR(32) Y Currency Code CHAR(3) Y Banknote code CHAR(1) Y Subtransaction cumulatively released credit amount DECIMAL(19,2) N Timestamp DECIMAL(17,0) N

[0097] Table 5

[0098] Among them, the sub-transaction cumulative released credit amount field in Table 5 is the second record, which is used to indicate the releasable amount of the hotspot account.

[0099] Exemplarily, the available balance of the hotspot account is determined based on the third record, the first record and the second record in the account funds table. According to step 201, the third record in the account funds table is the account balance, the first record is used to indicate the locked amount of the hotspot account, and the second record is used to indicate the releasable amount of the hotspot account. Then the available balance of the hotspot account can be determined by the following formula: Available balance of the hotspot account = the third record in the account funds table - the first record in the first data table + the second record in the second data table. For example, after the deposit balance subtransaction of customer A transferring 1,000 yuan to customer B is successfully executed, the third record in the account funds table is 2,200, and the first record in the first data table is 1,000. At this time, the second data table has not been updated. Assuming that the second record of the second data table is 0, the available balance of the account = 2,200-1,000+0=1,200. In other words, before all subtransactions in the main transaction are successfully executed, the available balance of customer B remains unchanged, avoiding the situation where the 1,000 yuan transferred by customer A to customer B has been used by customer B when the deposit balance subtransaction needs to be rolled back later, resulting in the failure of the deposit balance subtransaction to roll back.

[0100] Exemplarily, in order to ensure that there is a basis for generating a release instruction, after each sub-transaction corresponding to the main transaction is successfully executed and before the release instruction is determined, the release record in the cache is synchronized to the third data table, because the release record in the cache may be cleared; specifically, first determine the release record in the cache according to the account identifier of the hotspot account; then record the account identifier and deposit amount of the hotspot account included in the release record in the third data table; wherein the third data table may be a newly added data table, which may be called a sub-transaction release flow table, and the main fields in the third data table are shown in Table 6:

[0101] Field Name type Is it a primary key? Transaction Date CHAR(8) Y Global incident tracking number CHAR(25) Y Sequence Number CHAR(3) Y Handling Status Codes CHAR(2) N Customer Account CHAR(32) N Transaction amount DECIMAL(19,2) N Next resend time CHAR(17) N Timestamp CHAR(17) N

[0102] Table 6

[0103] Among them, the global time tracking number in Table 6 can be understood as a transaction identifier, for example, a transaction number; when all sub-transactions corresponding to the main transaction are executed successfully, the transaction identifier of the deposit transaction corresponding to the main transaction, the account identifier of the hotspot account, and the deposit amount corresponding to the deposit transaction are recorded in the third data table; there can be multiple release records in the same deposit transaction, which are identified by sequence numbers and can be released separately; the processing status includes an unexecuted state, a successful state, and a failed state, and the processing status code corresponds to the processing state. For example, 01 can be used to identify the unexecuted state, 02 can be used to identify the successful state, and 03 can be used to identify the failed state; in addition, the present application also sets a scheduled scanning task. When the scheduled task scans a record with an unexecuted state or a failed state, it can be processed repeatedly until it succeeds. Figure 6 The next retransmission time in is the time for repeated processing.

[0104] Determining the release instruction based on the third data table has the following advantages: the database table storage method has better consistency, because a successful transaction will definitely be recorded in the database table, and a failed transaction will definitely not be recorded; while the message triggering method has the risk of message loss, which may result in less released amount, thereby affecting the user's available balance.

[0105] Further illustratively, when all subtransactions corresponding to the main transaction are successfully executed and the main transaction is committed, the account identifier and deposit amount of the hotspot account are determined in the third data table according to the transaction identifier of the deposit transaction corresponding to the main transaction, and then the release instruction is determined according to the account identifier and deposit amount of the hotspot account, and finally, according to the release instruction, the deposit amount is accumulated in the second record corresponding to the account identifier of the hotspot account in the second data table. The release instruction can be monitored by a preset process, and when the preset process monitors the release instruction, the second data table is updated according to the release instruction.

[0106] For example, assuming that the account ID of the hot account included in the release instruction is 222333 and the deposit amount is 1,000 yuan, first match it in the second data table according to the account ID 222333, and the cumulative released credit amount of the sub-transaction contained in the matching result is the second record. Assuming that the second record is initially 0, then according to the release instruction, the deposit amount of 1,000 is added to the second record, and the second record is changed from 0 to 1,000. At this point, the account available balance = the third record of the account funds table - the first record of the first data table + the second record of the second data table = 2,200 - 1,000 + 1,000 = 2,200, and the available balance of customer B increases from 1,200 yuan to 2,200 yuan.

[0107] It should be noted that after the deposit amount corresponding to the deposit transaction is accumulated in the first record of the first data table according to the account identifier of the hotspot account, if at least one sub-transaction in the main transaction fails to execute, the deposit amount is subtracted from the first record.

[0108] The following is an example of the collection function of a secondary zero-balance real-time cash pool member account to explain the method proposed in this application:

[0109] like Figure 3 As shown in the figure, there are three member accounts under the main account M, namely member account A, member account B and member account C. If one of them makes a payment to member account C, the amount transferred needs to be linked to the main account M; among them, the payment account to member account C corresponds to Figure 3 In process ①, the amount transferred is collected into the main account M corresponding to Figure 3 The process in ②. Figure 3 A total of 4 database records are updated, namely: update of the account deposit funds table of member account C (for example, update of detailed serial number, etc.), update of the account cash pool limit table of member account C (increase of deposit amount), update of the account deposit funds table of master account M (increase of account balance), and update of the account cash pool limit table of master account M (increase of subordinate collection amount, i.e. collection amount of member account C).

[0110] Before adopting the method proposed in this application, Figure 3 The transaction flow chart corresponding to the transaction shown is as follows Figure 4As shown, it is divided into multiple sub-transactions, namely C-account status check, C-deposit balance sub-transaction, C-cash pool quota sub-transaction, M-account status check, M-deposit balance sub-transaction, and M-cash pool quota sub-transaction. In the deposit function, after the deposit balance sub-transaction of member account C, that is, C-deposit balance sub-transaction is successfully executed, the balance and available balance of member account C are increased; if the subsequent sub-transaction or the main transaction ultimately fails to execute, it is necessary to roll back the C-deposit balance sub-transaction. The funds may have been withdrawn before the rollback, resulting in the failure of the rollback of the C-deposit balance sub-transaction, resulting in inconsistent accounts.

[0111] After adopting the method proposed in this application, Figure 3 The transaction flow chart corresponding to the transaction shown is as follows Figure 5 As shown, the improvements are mainly reflected in Figure 5 In the dotted box: ① When the deposit balance subtransaction updates the deposit balance, the frozen amount is increased synchronously, and the available balance does not change; ② The deposit balance subtransaction increases the registration of the release instruction; ③ At the end of the main transaction, the release subtransaction flow table, that is, the third data table, is registered; the main transaction flow table and the amount release subtransaction flow table are registered synchronously, and either succeed together or fail together, to ensure that the subtransaction release flow table must be registered when the transaction is successful; ④ The main transaction ends successfully, and the subtransaction amount release table, that is, the second data table, is updated to release the temporarily locked funds.

[0112] Specifically, in the improved deposit function, in the deposit balance subtransaction of member account C, the balance and frozen amount of member account C are increased synchronously, the available balance of the account remains unchanged, and the registration release record is added to the cache in the deposit balance subtransaction, and is registered in the subtransaction release flow table at the end of the transaction; after the main transaction is successfully submitted, the amount release operation is immediately executed, that is, the subtransaction amount release table (second data table) is updated, and the amount is accumulated to the second record in the second data table. At this point, the available balance of member account C is officially increased, and the deposited funds are allowed to be used by member account C. Since the amount release operation is synchronized with the transaction, there is no business impact. If the intermediate subtransaction or subsequent main transaction fails to execute, the rollback operation is performed on the previous subtransaction in reverse order. Since the deposited funds are temporarily frozen, this part of the funds cannot be withdrawn, which can ensure that the deposit balance subtransaction can be unconditionally rolled back successfully, thereby ensuring the consistency of accounts.

[0113] The method proposed in the present application for ensuring the consistency of the available balance of hot accounts temporarily locks the amount deposited in the deposit transaction, and releases the temporarily locked amount when the main transaction is successfully submitted. The release of the temporarily locked amount is achieved by adding a new data table, rather than updating the original account funds table. This solves the risk of failure in rolling back the deposit balance sub-transaction, and does not increase additional operations on the account funds table, nor does it increase the concurrency pressure on the account funds table.

[0114] Figure 6 and Figure 7 A schematic diagram of a possible device for ensuring the consistency of available balances in hotspot accounts provided in an embodiment of the present application. These devices for ensuring the consistency of available balances in hotspot accounts can be used to implement the functions of the server in the above method embodiment, and thus can also achieve the beneficial effects of the above method embodiment.

[0115] like Figure 6 As shown, the apparatus 600 for ensuring consistency of available balance of hotspot accounts includes a processing unit 610 and a computing unit 620. The apparatus 600 for ensuring consistency of available balance of hotspot accounts is used to implement the above Figure 2 The functions of the server in the method embodiment are shown.

[0116] When the device 600 for ensuring the consistency of the available balance of the hotspot account is used to implement Figure 2 The functions of the server in the method embodiment shown are:

[0117] The processing unit 610 is used to determine a main transaction corresponding to a deposit transaction of a hotspot account and multiple subtransactions corresponding to the main transaction, wherein the multiple subtransactions include a deposit balance subtransaction; the hotspot account is an account with high-frequency transactions at the same time;

[0118] The calculation unit 620 is used to accumulate the deposit amount corresponding to the deposit transaction in the first record of the first data table according to the account identifier of the hotspot account after the deposit balance subtransaction is successfully executed; the first record is used to indicate the locked amount of the hotspot account;

[0119] The calculation unit 620 is also used to accumulate the deposit amount in the second record of the second data table according to the account identifier of the hotspot account after all sub-transactions corresponding to the main transaction are successfully executed, and the second record is used to indicate the releasable amount of the hotspot account; the available balance of the hotspot account is determined according to the third record in the account funds table, the first record and the second record; the third record is used to indicate the balance of the hotspot account.

[0120] In a possible design, the first data table is the account funds table, and the first record corresponds to a newly added field in the account funds table; the second data table is a newly added data table;

[0121] When the deposit balance sub-transaction is successfully executed, the calculation unit 620 is further configured to add the deposit amount to a third record corresponding to the account identifier of the hotspot account in the account funds table.

[0122] In one possible design, the calculation unit 620 is used to accumulate the deposit amount in the second record of the second data table according to the account identifier of the hotspot account after all sub-transactions corresponding to the main transaction are executed successfully: when all sub-transactions corresponding to the main transaction are executed successfully, determine a release instruction; the release instruction includes the account identifier of the hotspot account and the deposit amount; according to the release instruction, accumulate the deposit amount in the second record corresponding to the account identifier of the hotspot account in the second data table.

[0123] In one possible design, after the deposit balance sub-transaction is successfully executed, the processing unit 610 is also used to register a release record to the cache, wherein the release record includes the account identifier of the hotspot account and the deposit amount; the release record is determined in the cache according to the account identifier of the hotspot account; the account identifier of the hotspot account and the deposit amount included in the release record are recorded in a third data table; the processing unit 610 is used to determine a release instruction after each sub-transaction corresponding to the main transaction is successfully executed: when each sub-transaction corresponding to the main transaction is successfully executed, determine a release instruction according to the third data table.

[0124] In one possible design, the third data table also includes a transaction identification field; the processing unit 610 is used to determine the release instruction according to the third data table when all subtransactions corresponding to the main transaction are successfully executed: when all subtransactions corresponding to the main transaction are successfully executed and the main transaction is committed, determine the account identification of the hotspot account and the deposit amount in the third data table according to the transaction identification of the deposit transaction corresponding to the main transaction; and determine the release instruction according to the account identification of the hotspot account and the deposit amount.

[0125] In one possible design, after accumulating the deposit amount corresponding to the deposit transaction in the first record of the first data table according to the account identifier of the hotspot account, the calculation unit 620 is further used to subtract the deposit amount from the first record if at least one sub-transaction among the multiple sub-transactions fails to execute.

[0126] For a more detailed description of the processing unit 610 and the computing unit 620, please refer to Figure 2 The relevant description in the method embodiment shown is directly obtained and will not be repeated here.

[0127] like Figure 7As shown, the apparatus 700 for ensuring the consistency of the available balance of the hotspot account includes a processor 710 and an interface circuit 720. The processor 710 and the interface circuit 720 are coupled to each other. It is understood that the interface circuit 720 can be a transceiver or an input-output interface. Optionally, the apparatus 700 for ensuring the consistency of the available balance of the hotspot account can also include a memory 730 for storing instructions executed by the processor 710 or storing input data required by the processor 710 to execute instructions or storing data generated after the processor 710 executes instructions.

[0128] When the device 700 for ensuring the consistency of the available balance of the hotspot account is used to implement Figure 2 When the method is shown, the processor 710 is used to implement the function of the above-mentioned processing unit 610, and the interface circuit 720 is used to implement the function of the above-mentioned calculation unit 620.

[0129] The division of units in the embodiments of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation. In addition, each functional unit in each embodiment of the present application may be integrated into a processor, or may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0130] Although the preferred embodiments of the present application have been described, those skilled in the art may make other changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications falling within the scope of the present application.

[0131] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A method for ensuring the consistency of available balance of hotspot accounts, characterized in that: The method includes: Determine a main transaction corresponding to a deposit transaction of a hotspot account and multiple subtransactions corresponding to the main transaction, wherein the multiple subtransactions include a deposit balance subtransaction; the hotspot account is an account with high-frequency transactions at the same time; When the deposit balance subtransaction is successfully executed, the deposit amount corresponding to the deposit transaction is accumulated in the first record of the first data table according to the account identifier of the hotspot account; the first record is used to indicate the locked amount of the hotspot account; After all sub-transactions corresponding to the main transaction are executed successfully, the deposited amount is accumulated in the second record of the second data table according to the account identifier of the hotspot account, and the second record is used to indicate the releasable amount of the hotspot account; the available balance of the hotspot account is determined according to the third record in the account funds table, the first record and the second record; the third record is used to indicate the balance of the hotspot account.

2. The method according to claim 1, characterized in that The first data table is the account funds table, and the first record corresponds to a newly added field in the account funds table; the second data table is a newly added data table; When the deposit balance sub-transaction is successfully executed, the method further includes: The deposit amount is accumulated to the third record corresponding to the account identifier of the hotspot account in the account funds table.

3. The method according to claim 1, characterized in that After all sub-transactions corresponding to the main transaction are successfully executed, the deposit amount is accumulated in the second record of the second data table according to the account identifier of the hotspot account, including: After all sub-transactions corresponding to the main transaction are successfully executed, a release instruction is determined; the release instruction includes the account identifier of the hotspot account and the deposit amount; According to the release instruction, the deposit amount is accumulated in the second record corresponding to the account identifier of the hotspot account in the second data table.

4. The method according to claim 3, characterized in that When the deposit balance sub-transaction is successfully executed, it also includes: Registering a release record to a cache, wherein the release record includes an account identifier of the hotspot account and the deposit amount; After all sub-transactions corresponding to the main transaction are successfully executed, before the release instruction is determined, the method further includes: Determining the release record in a cache according to the account identifier of the hotspot account; Recording the account identifier of the hotspot account and the deposit amount included in the release record in a third data table; After all sub-transactions corresponding to the main transaction are successfully executed, determining a release instruction includes: After all sub-transactions corresponding to the main transaction are successfully executed, a release instruction is determined according to the third data table.

5. The method according to claim 4, characterized in that The third data table also includes a transaction identification field; After all sub-transactions corresponding to the main transaction are successfully executed, determining a release instruction according to the third data table includes: After all subtransactions corresponding to the main transaction are successfully executed and the main transaction is committed, the account identifier of the hotspot account and the deposit amount are determined in the third data table according to the transaction identifier of the deposit transaction corresponding to the main transaction; The release instruction is determined according to the account identifier of the hotspot account and the deposit amount.

6. The method according to claim 1, characterized in that After accumulating the deposit amount corresponding to the deposit transaction in the first record of the first data table according to the account identifier of the hotspot account, the method further includes: If at least one of the multiple subtransactions fails to execute, the first record is reduced by the deposit amount.

7. A device for ensuring the consistency of available balance of hotspot accounts, characterized in that: The device comprises: a processing unit and a computing unit; The processing unit is used to determine a main transaction corresponding to a deposit transaction of a hotspot account and a plurality of subtransactions corresponding to the main transaction, wherein the plurality of subtransactions include a deposit balance subtransaction; the hotspot account is an account with high-frequency transactions at the same time; The calculation unit is used to accumulate the deposit amount corresponding to the deposit transaction in the first record of the first data table according to the account identifier of the hotspot account after the deposit balance subtransaction is successfully executed; the first record is used to indicate the locked amount of the hotspot account; The calculation unit is also used to accumulate the deposit amount in the second record of the second data table according to the account identifier of the hotspot account after all sub-transactions corresponding to the main transaction are successfully executed, and the second record is used to indicate the releasable amount of the hotspot account; the available balance of the hotspot account is determined according to the third record in the account funds table, the first record and the second record; the third record is used to indicate the balance of the hotspot account.

8. A device for ensuring consistency of available balance of hotspot accounts, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 6 when executed by a processor.

10. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 6 when being executed by a processor.

Images