WO2022127674A1

WO2022127674A1 - Method for checking account limit, device, checking system, and storage medium

Info

Publication number: WO2022127674A1
Application number: PCT/CN2021/136571
Authority: WO
Inventors: 张鹏; 卢翔; 王永
Original assignee: 网联清算有限公司
Priority date: 2020-12-17
Filing date: 2021-12-08
Publication date: 2022-06-23
Also published as: CN114648408A

Abstract

A method for checking an account limit, a device (900, 1000), a checking system, and a storage medium. The method is executed by an execution node in a checking system and comprises: acquiring checking basic data of the first account from an account database of a first account, the checking basic data of the first account referring to limit allocation flow data for checking an account limit (S410); sending the checking basic data of the first account to a first associated execution node, and receiving a checking result, returned by the first associated execution node, of an account of the counterparty of the first account (S420); and according to the checking result of the account of the counterparty of the first account, determining an account limit checking result of the first account (S430). In said method, the account limit is checked according to the dimension of the account database, without the need of reading all the limit allocation flow data of all the account databases into a memory of a single server for checking, thereby avoiding the memory overflow of a server, and greatly improving the checking efficiency of the limit allocation flow data.

Description

Verification method, device, verification system and storage medium of account limit

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the priority of the Chinese patent application filed on December 17, 2020, with the application number of 202011498722.6 and the invention titled "A method, device and verification system for checking account limits, and storage medium", all of which are The contents are incorporated herein by reference.

technical field

The present application relates to the field of financial technologies, and in particular, to a method, device, and verification system and storage medium for checking account limits.

Background technique

The existing reserve fund system is a distributed account system, and the amount is dispersed among accounts at all levels. As shown in Figure 1, in order to ensure the stability and efficiency of the transaction, it is necessary to collect the quota received by the deposit sub-account through the deposit business into the data center (IDC) account, and then the IDC account will allocate the quota to multiple withdrawal sub-accounts , so that the gold withdrawal account can undertake the gold withdrawal business. This process is also called quota allocation.

During the above quota allocation process, due to the cross-database operation, uncontrollable factors such as the network will cause the quota to fail to be placed in the warehouse. Therefore, in order to check the integrity of the quota allocation, it is necessary to check the quota allocation and check whether the loan is balanced.

However, the inventors found that the existing method for checking the quota allocation flow has high requirements on the performance of the server performing the checking task, and the checking efficiency is not high.

SUMMARY OF THE INVENTION

Embodiments of the present application provide a method, a device, a verification system, and a storage medium for checking an account limit, so as to reduce the performance requirements of the verification task on the server and improve the verification efficiency.

The embodiment of the present application adopts the following technical solutions:

In a first aspect, an embodiment of the present application provides a method for checking account limits, wherein the method is executed by an execution node in a checking system, and the method includes:

Obtaining basic verification data of the first account from the account database of the first account, wherein the basic verification data of the first account refers to the quota transfer flow data used to verify the account quota;

sending the verification basic data of the first account to the first association execution node, and receiving the counterparty account verification result of the first account returned by the first association execution node;

According to the check result of the counterparty account of the first account, the check result of the account limit of the first account is determined.

Optionally, from the account database of the first account, obtaining the quota transfer flow data for checking the account quota as the verification basic data of the first account includes:

From the account database of the first account, the quota allocation flow data matching the batch ID to be verified is found as the verification basic data of the first account.

Optionally, the identification of the batch to be checked is determined according to the checking time of the first account; the method further includes:

After obtaining the account limit verification result of the first account, the verification time of the first account is updated.

Optionally, the method further includes:

Determine whether the check time of the first account satisfies the check condition;

Under the condition that the verification condition is satisfied, the step of acquiring, from the account database of the first account, the quota transfer flow data for performing account quota verification as the verification basic data of the first account is performed.

Optionally, the method further includes:

If the received check result of the counterparty account of the first account returned by the first association execution node is failed, then according to the result of the counterparty account check of the first account, determine the check result in the basic check data of the first account. The first difference flow data;

The first difference flow data is recorded in the check compensation table of the first account, so that account limit compensation can be performed according to the check compensation table.

Optionally, the method further includes:

determining the state of the account database of the second account corresponding to the first association execution node;

If the state of the account database of the second account is the offline state, record the verification basic data of the first account into the verification basic data cache table of the first account, so that the account in the second account When the database is in an online state, the account limit of the first account can be checked according to the checking basic data cache table.

Optionally, the first account is a centralized platform account or a dedicated account, and the method further includes: before sending the verification basic data of the first account to the first association execution node:

Determine the self-checking result of the centralized platform account or the special account according to the checking basic data of the centralized platform account or the special account;

If the self-check result is passed, the account check result of the centralized platform account or the dedicated account is directly determined to be passed;

If the self-check result is failed, the second differential pipeline data in the check basic data indicated by the self-check result is used as the data to be sent to the first associated execution node, or the 2. The difference flow data is recorded in the check compensation table of the centralized platform account or the special account, so that the account limit compensation can be performed according to the check compensation table.

Optionally, the method further includes:

Receive the checking task of the account limit, and perform the step of obtaining the limit transfer flow data for checking the account limit from the account database of the first account as the checking basic data of the first account according to the checking task of the account limit.

In a second aspect, an embodiment of the present application further provides a method for checking account limits, wherein the method is executed by an execution node in a checking system, and the method includes:

Receive the basic verification data of the third account sent by the second association execution node, wherein the basic verification data of the third account refers to the quota transfer flow data used to verify the account quota;

According to the quota transfer flow data stored in the account database of the first account, the verification basic data of the third account is verified, and the verification result of the counterparty account of the third account is obtained;

Return the verification result of the counterparty account of the third account to the second association execution node.

Optionally, according to the quota transfer running data stored in the account database of the first account, the checking basic data of the third account is checked, and obtaining the counterparty account checking result of the third account includes:

If, in the verification basic data of the third account, the running water identifier of each piece of quota transfer running data can be found in the quota allocation running data of the first account, then the verification result of the counterparty account of the third account is determined. If it is passed, otherwise, it is determined that the verification result of the counterparty account of the third account is not passed.

In a third aspect, an embodiment of the present application further provides a device for checking account limits, which is applied to an execution node in a checking system, wherein the device is used to implement any of the aforementioned methods.

In a fourth aspect, an embodiment of the present application further provides a verification system, including a plurality of verification devices for account limits as described above.

In a fifth aspect, embodiments of the present application further provide a computer-readable storage medium, where the computer-readable storage medium stores one or more programs, and the one or more programs are used in a checking system including multiple application programs. When the execution node of the verification system executes, the execution node in the verification system is caused to execute any one of the aforementioned methods.

The above-mentioned at least one technical solution adopted in the embodiment of the present application can achieve the following beneficial effects: the method for checking the account limit in the embodiment of the present application can be performed by an execution node in the checking system. In the account database of the first account, obtain the quota transfer flow data for performing account quota verification as the verification basic data of the first account; then send the verification basic data of the first account to the first association execution node, and receive the first association data. The verification result of the counterparty account of the first account returned by the execution node; finally, the result of the account limit verification of the first account is determined according to the verification result of the counterparty account of the first account. In the embodiment of the present application, the account quota is checked according to the dimension of the account database, and there is no need to read all the quota allocation flow data of all account databases into the memory of a single server for verification, which avoids the memory overflow of the server and greatly improves the quota allocation. Checking efficiency of flow data.

Description of drawings

The drawings described herein are used to provide further understanding of the present application and constitute a part of the present application. The schematic embodiments and descriptions of the present application are used to explain the present application and do not constitute an improper limitation of the present application. In the attached image:

Fig. 1 is a schematic diagram of the allocation flow of an account limit in the prior art;

Fig. 2 is the structural representation of a kind of reserve fund system in the prior art;

3 is a schematic flowchart of a method for checking quota transfer running water data in the prior art;

4 is a schematic flowchart of a method for checking an account limit in an embodiment of the application;

5 is a schematic diagram of the correspondence between a verification system and an account database in an embodiment of the application;

FIG. 6 is a logical block diagram of checking an account limit in an embodiment of the application;

FIG. 7 is a schematic flowchart of another method for checking an account limit in an embodiment of the application;

Fig. 8 is a flow chart of checking the account limit of a first account when it assumes different roles in an embodiment of the application;

FIG. 9 is a schematic structural diagram of a device for checking account limits in an embodiment of the present application;

FIG. 10 is a schematic structural diagram of another device for checking account limits in an embodiment of the application;

FIG. 11 is a schematic structural diagram of a verification system in an embodiment of the present application.

specific embodiment

In order to make the objectives, technical solutions and advantages of the present application clearer, the technical solutions of the present application will be clearly and completely described below with reference to the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, but not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

The technical solutions provided by the embodiments of the present application will be described in detail below with reference to the accompanying drawings.

The account limit verification method of this application is mainly implemented by relying on the existing reserve fund system. As shown in FIG. 2, a schematic diagram of the hierarchical structure of a reserve fund system is provided, and the reserve fund system mainly includes a first-level account, a second-level account and a third-level account. The first-level account is the platform-level master account, which is mainly used to receive external remittance quota, and can allocate the external remittance quota to the second-level account; the second-level account is used to receive the quota allocated by the first-level account, and can The received quota allocated by the first-level account is allocated to the third-level account; the third-level account is used to undertake the transaction business facing the user. The reserve fund system may also include a special account for collecting part or all of the amount from the second-level account, and releasing the collected amount to the first-level account.

Generally, the above-mentioned first-level accounts can also be referred to as centralized platform accounts, and are collectively referred to as centralized platform accounts hereinafter. The second-level account can also be called an IDC account (ie, Internet Data Center, data center account), hereinafter collectively referred to as an IDC account, an IDC account can perform horizontal quota allocation and vertical quota allocation, wherein the vertical quota allocation includes receiving centralized platform accounts amount, the amount allocated to the withdrawal sub-account, and the amount received into the gold sub-account. Horizontal quota allocation is the quota allocation between different IDC accounts, that is, the second-level accounts may include multiple, and multiple second-level accounts can transfer quotas to each other. The third-level account can include a gold withdrawal sub-account and a gold deposit sub-account. The gold withdrawal sub-account directly undertakes the gold withdrawal business and can receive the quota allocated by the IDC account. The deposit sub-account directly undertakes the deposit business, and can collect the quota to the IDC account.

In order to check the integrity of the quota allocation between different accounts, it is necessary to check the quota allocation. The prior art provides a method for checking the running water data of quota allocation. As shown in FIG. 3, the existing verification method is performing quota allocation. When verifying the transfer flow data, it is aimed at all the databases that need to check the quota transfer flow data. The server performing the verification task will allocate the flow verification task according to the received quota, collect the quota transfer flow data of all databases, and read them all into the memory. However, this scheme may have the following problems:

1) Read the quota allocation and running water data of all databases into the memory together. In the case of a large amount of data, it is easy to trigger memory overflow.

2) The quota allocation flow data of the entire reserve fund system is only checked and processed by one check task on one server. In the case of a large amount of data, the task time-consuming will increase. If the server executing the task is in an abnormal situation The downtime will cause the current data to be checked for the quota transfer and flow data to be checked for the entire system to fail.

Based on this, an embodiment of the present application provides a method for checking account limits. The method is executed by an execution node in a checking system. As shown in FIG. 4 , the method includes the following steps S410 to S430:

Step S410: Acquire basic verification data of the first account from the account database of the first account, wherein the basic verification data of the first account refers to the quota transfer flow data used to verify the account quota.

As shown in FIG. 5 , the verification system in this embodiment of the present application may be a server cluster, including multiple execution nodes, each execution node may be regarded as a verification server, and each execution node is connected to an account database of an account respectively , the verification system in this embodiment of the present application may be a server cluster deployed separately for the verification task of account limit, and of course, for cost considerations, it may also be implemented by an existing application server. The method for checking the account limit in the embodiment of the present application may be executed by multiple execution nodes in the checking system in parallel, so as to disperse the memory pressure faced by a server in the prior art when performing the checking task. It should be noted that the account in the embodiment of the present application may refer to an account at any level in the reserve fund system, and each account corresponds to an account database for recording and storing the quota allocation flow data of the account. For ease of understanding, the account databases corresponding to the gold deposit sub-accounts mentioned later may be collectively referred to as deposit databases, the account databases corresponding to gold withdrawal sub-accounts may be collectively referred to as gold withdrawal databases, and the account databases corresponding to IDC accounts may be collectively referred to as IDC databases.

When checking the account limit, firstly, the quota transfer flow data for checking the account limit can be obtained from the account database of the first account as the basic data of the first account. In the actual business scenario, when the quota is transferred between different databases, the corresponding flow will be generated. For example, when the quota of the deposit sub-account is successfully collected to the IDC account, the deposit database will correspondingly generate a quota deduction. When the quota of the IDC account is successfully allocated to the withdrawal sub-account, the IDC database will generate a corresponding quota deduction, and the withdrawal database will generate a corresponding quota increase. . Therefore, the data specifically checked in the embodiment of the present application may be the quota allocation flow data in each account database.

Step S420: Send the verification basic data of the first account to the first association execution node, and receive the counterparty account verification result of the first account returned by the first association execution node.

Normally, a piece of quota transfer flow data will carry information such as target account ID, counterparty account ID, quota, quota transfer type (plus/minus), and transfer time. In the embodiment of this application, the target account can be understood as an account whose account limit is currently being checked, and the counterparty account can be understood as an associated account that has a quota allocation relationship with the target account. The concepts of the two are relative, that is, It can be said that any account in the reserve fund system can be either the target account or the counterparty account of the target account. The quota refers to the size of the transferred quota, the quota transfer type refers to whether to increase the quota or deduct the quota, and the transfer time refers to the quota from the account. The time of the successful transfer.

Therefore, after obtaining the basic data of the first account in the embodiment of the present application, the basic data of the first account can be sent to the execution node where the counterparty account ID is located, namely the first account ID, according to the counterparty account ID carried in the basic data of the first account. On the associated execution node, the execution node where the counterparty account is located performs the check, and then receives the counterparty check result of the first account returned by the first associated execution node, so as to avoid reading all the quota transfer flow data into one server. memory overflow problem.

It should be noted that the above-mentioned "first associated execution node" refers to the execution node where the counterparty account of the first account is located, and the concept of "associated execution node" is also relative. For example, there is a quota allocation relationship between the first account and the second account. For the first account, the execution node where the second account is located is the associated execution node of the first account, and for the second account, the first account The execution node where it is located is the associated execution node of the second account.

Step S430: Determine the account limit check result of the first account according to the check result of the counterparty account of the first account.

During specific implementation, the check result of the counterparty account of the first account returned by the first association execution node may specifically be the result of the check pass and fail, and then the account limit check of the first account may be determined according to the check result of the counterparty account of the first account The result is a check pass or fail.

For example, for the deposit sub-account and the IDC account, after the deposit sub-account collects its quota to the IDC account, the deposit database will record a flow of deduction of the quota, and the IDC account receives the amount collected from the deposit sub-account. After the quota, the quota will be added to the IDC account, and then the IDC database will record an increase in the quota. When checking the quota transfer flow data, if there is data in the IDC database corresponding to the quota transfer flow data recorded in the deposit database, it means that the amount has been successfully transferred from the deposit sub-account to the IDC account. If the quota is not successfully transferred to the IDC account, follow-up measures need to be taken to ensure the integrity and consistency of the quota transfer flow data.

As mentioned above, the existing verification scheme is to read all the quota allocation and flow data into the memory of one server for unified verification. During this period, there will be problems such as server memory overflow, which will affect the data verification process and may also cause problems. In the case of server downtime, the verification of all quota transfer flow data fails, and the verification needs to be performed again. However, in the embodiment of the present application, the account quota is verified according to the dimension of the account database, and there is no need to transfer the quota of all account databases to the flow data. All are read into the memory for verification, which avoids the server's memory overflow, and the downtime of one execution node will not affect the verification process of other execution nodes, which improves the verification efficiency of the quota allocation flow data as a whole.

In an embodiment of the present application, the obtaining, from the account database of the first account, the quota transfer flow data for performing account quota verification as the verification basic data of the first account includes: from the account of the first account The quota allocation flow data matching the batch identifier to be verified is found in the database as the verification basic data of the first account.

In order to improve the verification efficiency of the quota transfer running water data, in this embodiment of the present application, the quota transfer running water data in each account database may be verified in multiple verification batches. The length of the verification batch here can be flexibly set according to actual needs. Every 5 minutes serves as a check batch. Each account database will record the current verification batch identifier that has been verified. Therefore, when obtaining the quota transfer flow data for account quota verification from the account database of the first account, the current batch to be verified can be determined first. identification, and then find out from the account database of the first account the quota transfer flow data matching the batch identification to be verified as the current data to be verified for the first account, that is, verification basic data.

In an embodiment of the present application, the identification of the batch to be checked is determined according to the checking time of the first account; the method further includes: after obtaining the checking result of the account limit of the first account, checking the first account The check time is updated.

The verification batch identifier in the embodiment of the present application may be generated according to the verification time of the account. Since each piece of flow data will carry the allocation time, each time the data verification of a verification batch is completed, the verification can be performed according to the batch that has been verified. Transfer the running water data according to the quota, update the verification time of the first account, and use it as the basis for the next batch of verification. For example, assuming that the current verification time of the first account is 10:00 am, it means that the quota transfer flow data in the first account before 10:00 have been verified. This time, the transfer time can be adjusted at 10:00. From 00:00 to 10:05, the quota transfer and running water data within five minutes will be checked, and so on.

In an embodiment of the present application, the method further includes: determining whether the check time of the first account satisfies the check condition; if the check condition is met, performing the process of obtaining the account used for checking from the account database of the first account The quota transfer flow data of the quota verification is used as the step of verifying the basic data of the first account.

In the actual business scenario, when the account quota is transferred from the first account to the second account, a flow of quota deduction will be recorded in the account database of the first account, and the corresponding actual time is t1. There is a time difference. When the account database of the second account records a corresponding increase in the amount of flow, the corresponding actual time will become t2 (t2>t1). Therefore, if you want to adjust the flow of the first account at the time node of t1. The data is checked in real time. Due to the delay of the execution node corresponding to the second account, the quota of the first account has not actually fallen into the second account, and the corresponding flow record has not been generated in the account database of the second account. As a result, at the time node t1, the quota transfer flow data of the first account cannot find matching data in the account database of the second account, and thus cannot be checked. Therefore, in order to avoid the above situation, a buffer time, such as 5 minutes, can be properly reserved to ensure that the quota transfer running water data in a verification batch can be verified.

During the specific implementation, if the time interval between the checking time of the first account and the current actual time is greater than 5 minutes, then it is possible to continue to obtain the quota transfer flow data for checking the account quota from the account database of the first account as The step of checking the basic data of the first account; if it is not greater than the value, the above steps will not be performed, so as to prevent the individual quota transfer running water data from failing to be checked.

In an embodiment of the present application, the method further includes: if the received counterparty account verification result of the first account returned by the first association execution node is failed, then according to the counterparty account of the first account Checking the result, determining the first difference flow data in the check basic data of the first account; recording the first difference flow data in the check compensation table of the first account, so that compensation can be made according to the check Table for account limit compensation.

If the check result of the counterparty account of the first account returned by the first association execution node corresponding to the second account is failed, it means that the first account has at least one flow identifier of the quota transfer flow data that has not been found in the account database of the second account , that is, the second account did not successfully increase/deduct the amount carried in the transfer data. Therefore, at this time, it is possible to determine the amount that has not been found according to the check result of the counterparty account of the first account returned by the first associated execution node. Allocate the running data as the first differential running data of the first account, and then record the first differential running data in the verification compensation table of the first account, so that the account quota of the corresponding account can be compensated according to the verification and compensation table in the future, Guarantee the integrity and consistency of quota allocation.

In an embodiment of the present application, the method further includes: determining the status of the account database of the second account corresponding to the first association execution node; if the status of the account database of the second account is the offline status , then record the verification basic data of the first account into the verification basic data cache table of the first account, so that when the account database of the second account is in the online state, the verification basic data can be The cache table checks the account limit of the first account.

In an actual business scenario, due to account database failure and other reasons, the account database may need to be offline for maintenance from time to time. For this embodiment of the present application, only when the account database is online can the transfer and transfer of quota transfer flow data be performed. Check, so before checking the checking basic data of the first account, you can also determine the status of the account database of the second account corresponding to the first association execution node. If the status of the account database of the second account is offline , indicating that the account database cannot be accessed at this time, and thus the verification basic data of the first account cannot be verified. Therefore, the verification basic data of the first account can be recorded in the verification basic data cache table of the first account, so that the basic verification data of the first account can be recorded. After the account database of the second account is restored to use, the basic data for checking the first account can be checked according to the checking basic data cache table. The advantage of recording the verification basic data of the first account in the verification basic data compensation table is that after the account database of the second account is subsequently restored to use, there is no need to re-read the verification basic data of the first account into the memory, directly It is more efficient to call and check the data in the basic data compensation table.

The status of each account database can be monitored uniformly by a public server, so that each execution node can obtain the status of each account database from the public server at any time, without the need for the execution nodes to inform each other of the status, which improves the overall check. Process efficiency.

Of course, before checking the checking basic data of the first account, if the status of the account database of the first account is found to be offline, then the data in the account database of the first account cannot be obtained at this time, and the account may not be obtained first. The account quota of the database is checked, and it will be checked after subsequent recovery.

It should be noted that the check compensation table and the check basic data cache table mentioned in the above-mentioned embodiments are set for each account. During specific implementation, the check compensation table and the check basic data cache table can be set in one account. The general table is used for unified management. Of course, two tables can also be set separately. The specific setting can be flexibly adjusted by those skilled in the art according to actual needs, which is not specifically limited here.

In an embodiment of the present application, the first account is a centralized platform account or a dedicated account, and the method further includes: according to the centralized platform, before sending the verification basic data of the first account to the first association execution node. The verification basic data of the account or the special account determines the self-verification result of the centralized platform account or the special account; if the self-verification result is passed, the account verification result of the centralized platform account or the special account is directly determined to be passed; if the self-verification result is passed If the result is not passed, the second differential pipeline data in the verification basic data indicated by the self-checking result is used as the data to be sent to the first associated execution node, or the second differential pipeline data is recorded. into the check compensation table of the centralized platform account or the dedicated account, so that account limit compensation can be performed according to the check compensation table.

For deposit sub-accounts, IDC accounts and gold-withdrawal sub-accounts, the quota allocation of these accounts is a cross-database operation, so if the current account to be checked for quota is any of the above types of accounts, you can use the account according to the account. The counterparty account ID carried in the verified quota transfer flow data will be sent directly to the execution node where the counterparty account is located for verification.

For the centralized platform account, the quota allocation of the centralized platform account will not only involve cross-database operations, but also the quota allocation within the database. Specifically, as mentioned above, the reserve system also includes special accounts. In actual business scenarios, the special accounts and the centralized platform accounts usually share a database. Therefore, for the quota allocation between the special accounts and the centralized platform accounts, then It will be recorded in a database, so if the current account for quota verification is a centralized platform account or a dedicated account, the quota transfer flow data recorded in the database can be divided into two categories according to the quota transfer ID, and then internal verification is performed, that is, self-verification. , if the self-check is passed, the account check result of the centralized platform account or the dedicated account is directly determined to be passed.

If the self-check fails, there may be the following two situations: One may be that the second difference flow data is the quota transfer flow within the centralized platform account or special account, and then directly record the check compensation corresponding to the centralized platform account or special account In the table, for account quota compensation; another possibility is that the second differential flow data is the flow data that has a quota allocation relationship with other-level account databases (such as second-level accounts, third-level accounts, etc.). The difference pipeline data is used as the data to be sent to the first associated execution node, so that the first associated execution node can externally check the second difference pipeline data.

In an embodiment of the present application, the method further includes: receiving an account limit check task, and obtaining a limit for performing account limit check from the account database of the first account according to the account limit check task. Allocate the running water data as the step of checking the basic data of the first account.

The method for checking account limits according to the embodiment of the present application may be executed in response to the issuance of a task for checking account limits. During specific implementation, the task server may send a certain task frequency, such as 5 minutes, to the execution node where each account database is located. An account limit check task is issued, and each execution node can perform account limit check in parallel according to the received account limit check task. Compared with only one execution node to process the limit check task of all account databases , which avoids the memory overflow of the execution node, and also avoids the failure of the quota check of all account databases due to the downtime of the execution node under abnormal conditions, which greatly improves the check efficiency of account quota.

As shown in FIG. 6 , a logical block diagram for checking the account limit is provided. First, determine the status of the account database of the first account. If the account database of the first account is offline, the account limit of the account database will not be checked. If the account database of the first account is online, the first account will In the account database of the first account, the quota transfer flow data used for checking the account quota is obtained as the verification basic data of the first account.

If the first account is any one of the gold deposit sub-account, IDC account or gold withdrawal sub-account, the account limit can be checked directly according to the account database of the second account corresponding to the first account. The status of the account database is judged. If the status of the account database of the second account is offline, the verification basic data of the first account cannot be verified at this time, and the verification basic data of the first account can be recorded in the first account. Check the basic data cache table, and then check after the account database of the second account is restored to use; if the status of the account database of the second account is an online state, then send the check basic data of the first account to the corresponding account of the second account. On the first association execution node, receive the check result of the counterparty account of the first account returned by the first association execution node corresponding to the second account, and update the account database of the first account if the check result of the counterparty account of the first account is passed If the verification time is not passed, the first difference flow data is determined according to the verification result of the counterparty account and recorded in the compensation verification table of the first account.

If the first account is a centralized platform account or a special account, the quota transfer flow data recorded in the account database of the centralized platform account or the special account can be divided into two categories according to the quota transfer identifier, and then internal verification is performed, that is, self-verification. If it passes, it is directly determined that the account check result of the centralized platform account or the special account is passed. If the self-check fails, it can be further determined whether the second difference flow data is the quota transfer flow within the centralized platform account or the special account, or whether it is related to other levels. The account database has the flow data of the quota allocation relationship. If it is the quota allocation flow within the centralized platform account or special account, it will be directly recorded in the verification compensation table corresponding to the centralized platform account or special account for account quota compensation; If the account database of other levels has flow data with a quota allocation relationship, it can be used as the data to be sent to the first associated execution node, so that the first associated execution node can externally check the second differential flow data.

Every time the check time of the account database is updated, the check time of the account database can be compared with the current actual time to determine whether the check time of the account database still satisfies the check conditions. Check the account limit, if it is satisfied, continue to perform the above checking process.

The embodiment of the present application also provides another method for checking account limits. The method is executed by an execution node in the checking system. As shown in FIG. 7 , the method includes the following steps S710 to S730:

Step S710: Receive basic verification data of the third account sent by the second association execution node, wherein the basic verification data of the third account refers to quota transfer flow data used for verification of account quotas.

Step S720: Check the checking basic data of the third account according to the quota transfer flow data stored in the account database of the first account, and obtain the checking result of the counterparty account of the third account.

Step S730: Return the verification result of the counterparty account of the third account to the second association execution node.

As mentioned above, since the concepts of the target account and the counterparty account are relative, the current execution node where the first account is located in this embodiment of the present application can send the verification of the first account to the first associated execution node where the second account is located. Basic data, you can also receive the verification basic data of the third account sent by the second association execution node where the third account is located, and then check the received third account in the account database of the first account corresponding to this execution node. The basic data is retrieved and matched to obtain the counterparty account verification result of the third account; finally, the counterparty account verification result of the third account is returned to the second associated execution node.

In an embodiment of the present application, according to the quota transfer data stored in the account database of the first account, the verification basic data of the third account is verified, and the verification result of the counterparty account of the third account is obtained. Including: if in the verification basic data of the third account, the flow identifier of each piece of quota transfer flow data can be found in the limit transfer flow data of the first account, determining the counterparty account of the third account The verification result is passed, otherwise, the verification result of the counterparty account of the third account is determined to be failed.

Under normal circumstances, the quota transfer flow data will also carry a flow identification (UUID), which can be regarded as a unique identification generated for a quota transfer record. If the quota is 100,000, a running water ID such as 000000001 will be generated in the deposit database, and a running water of the quota deduction will be generated based on this, and then the running water logo will be pushed to the IDC account, and the IDC account will receive the 100,000 credit After the quota is successfully added to the IDC account, the flow indicator pushed from the deposit sub-account A will be directly used as its own flow indicator to generate an increase in the amount of flow, so that the subsequent verification of the flow data of the quota transfer is carried out. , you can check the running water mark in the running water data according to the quota adjustment. Similarly, the transfer time recorded in the quota transfer flow is also generated by the deposit sub-account A and pushed to the IDC account, and the IDC account directly uses the transfer time pushed by the deposit sub-account A as the actual time when the quota transfer actually occurred, thus ensuring that The allocation times recorded in the two running waters are the same, that is, they are all within one verification batch.

During the specific implementation, if in the verification basic data of the third account, the running water identifier of each piece of quota transfer running water data can be found in the quota allocation running water data of the first account, then it is determined to verify the quota allocation running water data of the third account Passed, otherwise it is determined that the verification of the quota transfer flow data for the third account has not passed. That is to say, for a quota transfer, on the premise that the quota transfer is successful, the running water marks recorded in the account databases of both parties should be the same, so that when checking, only the running water marks can be checked to ensure the verification efficiency. For other flow information in the quota transfer flow, such as quota, quota adjustment logo, etc., can not be checked or can be checked selectively, because in actual business scenarios, there is generally no problem with this flow information.

It should be noted that the "first account", "second account" and "third account" mentioned in the above-mentioned embodiments do not have fixed meanings, and are only set to distinguish different accounts when they assume different roles. The "first associated execution node" and the "second associated execution node" are also set to distinguish accounts on different execution nodes when they assume different roles. For example, when the "first account" is used as the sender of the verification basic data, it can send the verification basic data of the first account to the first association execution node where the "second account" is located for verification, and receive the return of the first association execution node. When the "first account" is the receiver of the basic data for verification, it can receive the basic data of the third account sent by the second associated execution node where the "third account" is located for verification, and verify the results. Return to the second associated execution node. For ease of understanding, as shown in FIG. 8 , a flow chart of checking the account amount of the first account when it assumes different roles is provided.

The embodiment of the present application also provides an account limit verification device 900, which is applied to an execution node in a verification system. As shown in FIG. 9, the device 900 includes: a verification basic data acquisition unit 910 and a verification basic data sending unit 920 and the first check result determination unit 930 .

The verification basic data obtaining unit 910 is used to obtain the verification basic data of the first account from the account database of the first account, wherein the verification basic data of the first account refers to the quota transfer flow data used for checking the account quota ;

The verification basic data sending unit 920 is configured to send the verification basic data of the first account to the first association execution node, and receive the counterparty account verification result of the first account returned by the first association execution node;

The first verification result determination unit 930 is configured to determine the account limit verification result of the first account according to the verification result of the counterparty account of the first account.

In an embodiment of the present application, the verification basic data acquisition unit 910 is specifically configured to: find out from the account database of the first account the quota transfer flow data matching the batch identifier to be verified as the first The reconciliation basic data of the account.

In an embodiment of the present application, the identification of the batch to be checked is determined according to the check time of the first account; the device further includes: an update unit, configured to obtain the account limit check result of the first account after obtaining the check result of the account limit of the first account. , to update the checking time of the first account.

In an embodiment of the present application, the apparatus further includes: a checking condition determining unit, configured to determine whether the checking time of the first account satisfies the checking condition; In an account database of an account, the step of acquiring the quota transfer flow data for performing account quota verification as the verification basic data of the first account.

In an embodiment of the present application, the apparatus further includes: a verification basic data receiving unit, configured to receive verification basic data of a second account sent by the first association execution node, where the second account is compatible with the first association execution node. A counterparty account to which an account performs quota transfer; a second verification result determination unit, configured to determine the second verification based on the verification basic data of the second account and the quota transfer flow data stored in the account database of the first account. The counterparty account verification result of the account; the verification result returning unit is configured to return the counterparty account verification result of the second account to the first associated execution node.

In an embodiment of the present application, the second verification result determination unit is specifically configured to: if in the verification basic data of the second account, the running water identifier of each piece of quota transfer running water data can be stored in the first account If it is found in the quota transfer flow data of the second account, it is determined that the verification result of the counterparty account of the second account is passed; otherwise, the verification result of the counterparty account of the second account is determined to be failed.

In an embodiment of the present application, the apparatus further includes: a first differential flow data determination unit, configured to: if the received counterparty account verification result of the first account returned by the first association execution node is failed, Then, according to the check result of the counterparty account of the first account, determine the first difference flow data in the check basic data of the first account; the difference flow data recording unit is used to record the first difference flow data to the In the check compensation table of the first account, the account limit compensation can be performed according to the check compensation table.

In an embodiment of the present application, the apparatus further includes: an account database state determination unit, configured to determine the state of the account database of the second account corresponding to the first association execution node; the checking basic data recording unit, using If the state of the account database of the second account is the offline state, then record the verification basic data of the first account in the verification basic data cache table of the first account, so that the second account's When the account database is in an online state, the account limit of the first account can be checked according to the checking basic data cache table.

In an embodiment of the present application, the first account is a centralized platform account or a dedicated account, and the apparatus further includes: a self-check result determination unit, configured to determine according to the checking basic data of the centralized platform account or the dedicated account The self-check result of the centralized platform account or the special account; the account check result determination unit of the centralized platform is used to directly determine the account check result of the centralized platform account or the special account to be passed if the self-check result is passed; the second difference A pipeline data determination unit, configured to use the second difference pipeline data in the verification basic data indicated by the self-check result as the data to be sent to the first associated execution node if the self-check result is failed. data, or record the second difference flow data in the check compensation table of the centralized platform account or the dedicated account, so that account limit compensation can be performed according to the check compensation table.

In an embodiment of the present application, the device further includes: a verification task receiving unit, configured to receive a verification task of the account limit, to perform the verification task from the account database of the first account according to the verification task of the account limit, to obtain the The step of using the quota transfer flow data for the account quota verification as the verification basic data of the first account.

This embodiment of the present application further provides another apparatus 1000 for checking account limits. As shown in FIG. 10 , the apparatus 1000 is executed by an execution node in a checking system, and the apparatus 1000 includes: a checking basic data receiving unit 1010, a checking The basic data checking unit 1020 and the checking result returning unit 1030, wherein:

The verification basic data receiving unit 1010 is configured to receive the verification basic data of the third account sent by the second association execution node, wherein the verification basic data of the third account refers to the quota transfer running water data for performing account quota verification;

The checking basic data checking unit 1020 is configured to transfer the running data according to the quota stored in the account database of the first account, check the checking basic data of the third account, and obtain the checking result of the counterparty account of the third account;

The verification result returning unit 1030 is configured to return the verification result of the counterparty account of the third account to the second association execution node.

In an embodiment of the present application, the verification basic data verification unit 1020 is specifically configured to: if in the verification basic data of the third account, the running water identifier of each piece of quota transfer running water data can be stored in the first account If it is found in the quota transfer flow data of the third account, it is determined that the verification result of the counterparty account of the third account is passed; otherwise, the verification result of the counterparty account of the third account is determined to be failed.

It can be understood that the above device for checking account limits can implement each step of the method for checking account limits performed by the execution nodes in the checking system provided in the foregoing embodiments, and the relevant explanations about the checking methods for account limits are all applicable to account limits The verification device is not repeated here.

11 is a schematic structural diagram of a verification system according to an embodiment of the present application. The verification system includes a plurality of devices for verifying account limits as described above, and the devices for checking account limits are specifically configured to execute:

According to the check result of the counterparty account of the first account, the check result of the account limit of the first account is determined. Or, for executing:

The embodiments of the present application also provide a computer-readable storage medium, where the computer-readable storage medium stores one or more programs, and the one or more programs include instructions, and the instructions, when included in a checking system including multiple application programs When executed by the execution node of , the execution node in the verification system can be made to execute the method executed by the device for checking the account limit in the embodiment shown in FIG. 9 or FIG. 10 , and is specifically used to execute:

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block in the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to the processor of a general purpose computer, special purpose computer, embedded processor or other programmable data processing device to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing device produce Means for implementing the functions specified in a flow or flow of a flowchart and/or a block or blocks of a block diagram.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory result in an article of manufacture comprising instruction means, the instructions The apparatus implements the functions specified in the flow or flow of the flowcharts and/or the block or blocks of the block diagrams.

These computer program instructions can also be loaded on a computer or other programmable data processing device to cause a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process such that The instructions provide steps for implementing the functions specified in the flow or blocks of the flowcharts and/or the block or blocks of the block diagrams.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

Memory may include forms of non-persistent memory, random access memory (RAM) and/or non-volatile memory in computer readable media, such as read only memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media includes both persistent and non-permanent, removable and non-removable media, and storage of information may be implemented by any method or technology. Information may be computer readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), Flash Memory or other memory technology, Compact Disc Read Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, Magnetic tape cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media, such as modulated data signals and carrier waves.

It should also be noted that the terms "comprising", "comprising" or any other variation thereof are intended to encompass a non-exclusive inclusion such that a process, method, article or device comprising a series of elements includes not only those elements, but also Other elements not expressly listed, or which are inherent to such a process, method, article of manufacture, or apparatus are also included. Without further limitation, an element qualified by the phrase "comprising a..." does not preclude the presence of additional identical elements in the process, method, article of manufacture, or device that includes the element.

It will be appreciated by those skilled in the art that the embodiments of the present application may be provided as a method, a system or a computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The above descriptions are merely examples of the present application, and are not intended to limit the present application. Various modifications and variations of this application are possible for those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this application shall be included within the scope of the claims of this application.

Claims

A method for checking account limits, wherein the method is executed by an execution node in a checking system, and the method includes:

Obtaining basic verification data of the first account from the account database of the first account, wherein the basic verification data of the first account refers to the quota transfer flow data used to verify the account quota;

sending the verification basic data of the first account to the first association execution node, and receiving the counterparty account verification result of the first account returned by the first association execution node;

According to the check result of the counterparty account of the first account, the check result of the account limit of the first account is determined.
The method according to claim 1, wherein the obtaining, from the account database of the first account, the quota transfer flow data for performing account quota verification as the verification basic data of the first account comprises:

From the account database of the first account, the quota allocation flow data matching the batch identifier to be verified is found as the verification basic data of the first account.
The method according to claim 2, wherein the identification of the batch to be checked is determined according to the checking time of the first account; the method further comprises:

After obtaining the account limit verification result of the first account, the verification time of the first account is updated.
The method of claim 3, wherein the method further comprises:

Determine whether the check time of the first account satisfies the check condition;

Under the condition that the verification condition is satisfied, the step of acquiring, from the account database of the first account, the quota transfer flow data for performing account quota verification as the verification basic data of the first account is performed.
The method of claim 1, wherein the method further comprises:

If the received check result of the counterparty account of the first account returned by the first association execution node is failed, then according to the result of the counterparty account check of the first account, determine the check result in the basic check data of the first account. The first difference flow data;

The first difference flow data is recorded in the check compensation table of the first account, so that account limit compensation can be performed according to the check compensation table.
The method of claim 1, wherein the method further comprises:

determining the state of the account database of the second account corresponding to the first association execution node;

If the state of the account database of the second account is the offline state, record the verification basic data of the first account into the verification basic data cache table of the first account, so that the account in the second account When the database is in an online state, the account limit of the first account can be checked according to the checking basic data cache table.
The method according to claim 1, wherein, the first account is a centralized platform account or a dedicated account, and before sending the verification basic data of the first account to the first association execution node, the method further comprises:

Determine the self-checking result of the centralized platform account or the special account according to the checking basic data of the centralized platform account or the special account;

If the self-check result is passed, the account check result of the centralized platform account or the dedicated account is directly determined to be passed;

If the self-check result is failed, the second differential pipeline data in the check basic data indicated by the self-check result is used as the data to be sent to the first associated execution node, or the 2. The difference flow data is recorded in the check compensation table of the centralized platform account or the special account, so that the account limit compensation can be performed according to the check compensation table.
The method according to any one of claims 1 to 7, wherein the method further comprises:

Receive the checking task of the account limit, and perform the step of obtaining, from the account database of the first account, the limit transfer running data for checking the account limit as the checking basic data of the first account according to the checking task of the account limit.
A method for checking account limits, wherein the method is executed by an execution node in a checking system, and the method includes:

Receive the basic verification data of the third account sent by the second association execution node, wherein the basic verification data of the third account refers to the quota transfer flow data used to verify the account quota;

According to the quota transfer flow data stored in the account database of the first account, the verification basic data of the third account is verified, and the verification result of the counterparty account of the third account is obtained;

Return the verification result of the counterparty account of the third account to the second association execution node.
The method according to claim 9, wherein, according to the quota transfer data stored in the account database of the first account, the verification basic data of the third account is verified to obtain the counterparty account verification of the third account Results include:

If, in the verification basic data of the third account, the running water identifier of each piece of quota transfer running data can be found in the quota allocation running data of the first account, then the verification result of the counterparty account of the third account is determined. If it is passed, otherwise, it is determined that the verification result of the counterparty account of the third account is not passed.
A device for checking account amount, applied to an execution node in a checking system, wherein the device is used to implement any one of the methods of claims 1 to 8, or any of the methods of claims 9 to 10.
A checking system, comprising a plurality of checking devices for account limits as claimed in claim 11 .
A computer-readable storage medium storing one or more programs that, when executed by an execution node in a checking system including a plurality of application programs, cause the checking The execution node in the system executes the method according to any one of the claims 1-8, or executes the method according to any one of the claims 9-10.