Accounting method and apparatus, storage medium, and terminal

Abstract

The embodiment of the specification discloses a kind of accounting method, device, storage medium and terminal, the payment accounting request of each payment account is respectively distributed to each payment account corresponding sub-database sub-table, and the accounting information corresponding to each payment accounting request is saved in each sub-database sub-table;Respectively from each payment account corresponding sub-database sub-table, obtain the target accounting information of pre-set quantity, and the target accounting information is accounted to the sub-database sub-table corresponding to target payment account.There is sub-database sub-table to single database, so that different accounts correspond to different sub-database sub-table, then all original high concurrency accounting request can be scattered to multiple sub-database sub-table by sub-database sub-table rule, so that the accounting pressure originally received by a single account is distributed to multiple sub-database sub-table.

Description

Technical Field

[0001] This specification relates to the field of data processing technology, and in particular to an accounting method, apparatus, storage medium, and terminal. Background Technology

[0002] The core of an internet finance system lies in online payment and refund processing, which in turn relies on an accounting system. With the development of the internet, various online transaction models are emerging. In the foreseeable future, scenarios with extremely high concurrency for single-account transactions will become increasingly common, exhibiting a trend towards high traffic, high concurrency, and normalization. This places high performance demands on accounting systems. Therefore, an accounting method capable of supporting high-concurrency operations is needed to improve the operational efficiency of the accounting system and ensure the security of account funds. Summary of the Invention

[0003] This specification provides an accounting method, apparatus, storage medium, and terminal, which can solve the technical problem that conventional accounting methods in related technologies cannot handle high-concurrency accounting requests.

[0004] Firstly, embodiments of this specification provide an accounting method, which includes:

[0005] Receive at least one payment accounting request initiated by a payment account for a target receiving account, allocate the payment accounting requests of each payment account to the corresponding database and table of each payment account, and save the accounting information corresponding to each payment accounting request in each database and table.

[0006] In response to the accounting task, a preset number of target accounting information are obtained from the corresponding database and table of each payment account, and the target accounting information is recorded in the corresponding database and table of the target receiving account.

[0007] Secondly, embodiments of this specification provide an accounting device, which includes:

[0008] The routing module is used to receive payment accounting requests initiated by at least one payment account for a target receiving account, allocate the payment accounting requests of each payment account to the corresponding database and table of each payment account, and save the accounting information corresponding to each payment accounting request in each database and table.

[0009] The accounting module is used to respond to accounting tasks by retrieving a preset number of target accounting information from the corresponding database and table of each payment account, and posting the target accounting information to the corresponding database and table of the target receiving account.

[0010] Thirdly, embodiments of this specification provide a computer program product containing instructions that, when run on a computer or processor, cause the computer or processor to perform the steps of the method described above.

[0011] Fourthly, embodiments of this specification provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the steps of the method described above.

[0012] Fifthly, embodiments of this specification provide a terminal including a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being adapted to be loaded by the processor and to execute the steps of the method described above.

[0013] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following:

[0014] This specification provides an accounting method that receives payment accounting requests initiated by at least one payment account for a target receiving account, allocates the payment accounting requests from each payment account to the corresponding database shards and tables, and stores the accounting information corresponding to each payment accounting request in each database shard and table. In response to the accounting task, a preset number of target accounting information are retrieved from the corresponding database shards and tables of each payment account, and the target accounting information is recorded in the database shard and table corresponding to the target receiving account. By sharding a single database, different accounts may correspond to different database shards and tables. Therefore, when a single receiving account simultaneously receives payment accounting requests from a large number of different payment accounts, the sharding rules can distribute all high-concurrency requests originally from the same database to multiple database shards and tables, thus distributing the accounting pressure originally received by a single account across multiple database shards and tables. This effectively handles extremely high accounting traffic asynchronously and improves the performance of accounting and receiving transactions. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 An exemplary system architecture diagram of an accounting method provided in the embodiments of this specification;

[0017] Figure 2 A flowchart illustrating an accounting method provided in an embodiment of this specification;

[0018] Figure 3 A flowchart illustrating an accounting method provided in an embodiment of this specification;

[0019] Figure 4 A flowchart illustrating the execution logic of an accounting method provided in an embodiment of this specification;

[0020] Figure 5 A flowchart illustrating an accounting method provided in an embodiment of this specification;

[0021] Figure 6 A data acquisition flowchart for a hotspot account identification method provided in the embodiments of this specification;

[0022] Figure 7 A structural framework diagram of an accounting method provided in the embodiments of this specification;

[0023] Figure 8 A structural block diagram of an accounting device provided in the embodiments of this specification;

[0024] Figure 9 This is a schematic diagram of the structure of a terminal provided in an embodiment of this specification. Detailed Implementation

[0025] To make the features and advantages of the embodiments of this specification more apparent and understandable, the technical solutions of the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the embodiments of this specification.

[0026] In the following description, when referring to the accompanying drawings, the same numbers in different drawings denote the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those described in this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the embodiments described in this specification as detailed in the appended claims.

[0027] The core of an internet finance system is online payment and refund processing, and the foundation of payment and refund is the accounting system. For conventional online accounting systems, the most basic bookkeeping methods are typically used. This involves enabling local database transactions and then applying a pessimistic locking mechanism to the account to ensure the accuracy of account balance updates in concurrent scenarios. The idea behind pessimistic locking is to always assume the worst-case scenario: every time data is accessed, it's assumed that someone else will also modify it, so a lock is applied each time. When modifying a record in the database, to prevent simultaneous modification by others, the data is locked to prevent concurrency until the current operation is completed, at which point the lock is released so that the data can be used by other operations. With pessimistic locking, database modification requests need to be processed one by one. While this ensures accurate amount updates, it is inefficient and has a performance bottleneck for a single account. If the number of requests exceeds a safety threshold, a lock-grabbing error will occur, leading to bookkeeping failure.

[0028] With the development of the internet, various online transaction models have emerged. The rapid development of diversified transaction models is usually accompanied by an explosion in transaction traffic. For example, live-streaming e-commerce, a new form of online shopping, often involves hosts using discounts, promotions, and free gifts to create a lively atmosphere and attract viewers to place orders, all in an effort to boost popularity, traffic, and sales. This type of online shopping traffic is characterized by "short but high peaks," "uncertain peak times," and "frequent peak times." When there are a large number of products, nearly a million items may be listed at a single time, requiring users to place orders quickly. In such cases, the receiving account will face an extremely high volume of concurrent payment requests. Furthermore, in the foreseeable future, scenarios with extremely high concurrency for single-account transactions will become increasingly common, exhibiting a trend of high traffic, high concurrency, and normalization. This poses a significant challenge to the accounting system's bookkeeping performance and database capacity. At this point, conventional standard accounting methods are no longer sufficient to achieve accurate accounting. Therefore, an accounting method that can support high-concurrency operations is needed to improve the operational efficiency and accounting performance of the accounting system, while ensuring the security of account funds.

[0029] Therefore, this specification provides an accounting method that allocates payment accounting requests from each payment account to the corresponding database and table of each payment account, and stores the accounting information corresponding to each payment accounting request in each database and table; and obtains a preset number of target accounting information from the corresponding database and table of each payment account, and records the target accounting information to the corresponding database and table of the target receiving account, so as to solve the technical problem that the conventional accounting method cannot solve the problem of high-concurrency accounting requests.

[0030] Please see Figure 1 , Figure 1 This is an exemplary system architecture diagram of an accounting method provided in the embodiments of this specification.

[0031] like Figure 1 As shown, the system architecture may include a terminal 101, a network 102, and a server 103. The network 102 serves as the medium for providing a communication link between the terminal 101 and the server 103. The network 102 may include various types of wired or wireless communication links, such as wired communication links including fiber optic cables, twisted-pair cables, or coaxial cables, and wireless communication links including Bluetooth communication links, Wireless-Fidelity (Wi-Fi) communication links, or microwave communication links, etc.

[0032] Terminal 101 can interact with server 103 via network 102 to receive messages from or send messages to server 103. Alternatively, terminal 101 can interact with server 103 via network 102 to receive messages or data sent to server 103 by other users. Terminal 101 can be hardware or software. When terminal 101 is hardware, it can be various electronic devices, including but not limited to smartwatches, smartphones, tablets, laptops, and desktop computers. When terminal 101 is software, it can be installed in the aforementioned electronic devices and can be implemented as multiple software programs or software modules (e.g., to provide distributed services) or as a single software program or software module; no specific limitation is made here.

[0033] In the embodiments of this specification, firstly, when terminal 101 receives a payment accounting request initiated by at least one payment account for a target receiving account, it allocates the payment accounting requests of each payment account to the corresponding sub-database and sub-table of each payment account, and saves the accounting information corresponding to each payment accounting request in each sub-database and sub-table; then, in response to the accounting task, terminal 101 obtains a preset amount of target accounting information from the sub-database and sub-table of each payment account, and records the target accounting information to the sub-database and sub-table of the target receiving account.

[0034] Server 103 can be a business server providing various services. It should be noted that server 103 can be either hardware or software. When server 103 is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When server 103 is software, it can be implemented as multiple software programs or software modules (e.g., used to provide distributed services), or as a single software program or software module; no specific limitations are made here.

[0035] Alternatively, the system architecture may not include server 103. In other words, server 103 may be an optional device in the embodiments of this specification. That is, the method provided in the embodiments of this specification can be applied to a system structure that only includes terminal 101. The embodiments of this specification do not limit this.

[0036] It should be understood that Figure 1 The number of terminals, networks, and servers shown is only illustrative; the number can be any number of terminals, networks, and servers depending on the implementation requirements.

[0037] Please see Figure 2 , Figure 2 This is a flowchart illustrating an accounting method provided in an embodiment of this specification. The executing entity in this embodiment can be a terminal performing the accounting, a processor within the terminal performing the accounting method, or an accounting service within the terminal performing the accounting method. For ease of description, the following example uses a processor within the terminal as the executing entity to illustrate the specific execution process of the accounting method.

[0038] like Figure 2 As shown, accounting methods can include at least:

[0039] S202. Receive at least one payment account's payment accounting request for the target receiving account, allocate the payment accounting requests of each payment account to the corresponding database and table of each payment account, and save the accounting information corresponding to each payment accounting request in each database and table.

[0040] Optionally, the current online payment scenario faces extremely high concurrency in accounting requests, primarily targeting the high payment concurrency of a single receiving account. Under normal circumstances, all account data is stored in the same database. When a single receiving account receives a large number of payment accounting requests, the accounting processing for all accounts is carried out in one database. As the number of users and user operations increases, the amount of data in the database also increases, and the time required for reading and writing to the database also increases. The efficiency of the query and operation steps involved in each data processing becomes lower. However, for large-scale databases, high concurrency accounting requests from a single account can easily trigger the database capacity bottleneck, leading to accounting failure and resulting in account asset loss.

[0041] Alternatively, to alleviate the accounting pressure of a single account under high concurrency when the single database is too large, the database can be partitioned according to certain rules to obtain multiple separate shards and tables, and each shard and table can be managed separately. This can distribute the read and write pressure of the original database to each shard and table, disperse all payment traffic for a single database, and improve the overall accounting performance of the system. In this embodiment, users perform transactions such as payments, refunds, and receipts based on their own accounts. To evenly distribute the accounting pressure across different database shards and tables, the database can be partitioned according to the characteristics of all accounts' account numbers. For example, accounts can be divided based on the last digit of their account numbers: accounts with last digits in the range of "00-09" correspond to shard 1, accounts with last digits in the range of "10-19" correspond to shard 2, and so on. By assigning all accounts to corresponding shards and tables based on the last digit of their account numbers, the distribution of user accounts is roughly even, resulting in a roughly even distribution of accounting pressure across different shards and tables. This maximizes the read and write capabilities of each shard and table, improving accounting performance. In practical applications, there can be various database sharding rules, such as user account ID or user account level, which can be adjusted according to actual task requirements. This embodiment does not impose specific limitations on these rules.

[0042] Optionally, when a payment account initiates a payment to a target receiving account, the accounting system deploying the accounting method in the embodiments of this specification will receive at least one payment accounting request initiated by the payment account for the target receiving account. Since each payment account has its own corresponding database shard and table, the payment accounting request of each payment account should be routed and distributed to the corresponding database shard and table of each payment account, and the accounting information corresponding to each payment accounting request should be stored in each database shard and table. In this way, the read and write requests originally initiated to a single database are directly distributed to each database shard and table, and the high accounting traffic information is processed asynchronously in multiple database shards and tables to avoid accounting failure.

[0043] S204. In response to the accounting task, retrieve the preset number of target accounting information from the corresponding database and table of each payment account, and post the target accounting information to the corresponding database and table of the target receiving account.

[0044] Optionally, after multiple payment posting requests from multiple payment accounts are routed to the corresponding database shards and tables for each payment account, the next step is to post these postings to the corresponding database shard and table for the receiving account. Only after the receiving account data is successfully modified in the receiving account's database shard and table does the transaction process normally end. To alleviate the posting pressure on the receiving account's database shard and table, in response to the posting task, a preset number of target postings can be retrieved in batches from the corresponding database shards and tables of each payment account, and then posted to the corresponding database shard and table of the target receiving account. For example, 20 target postings can be retrieved from each database shard and table at a time, and then posted. After this is completed, another 20 target postings can be retrieved from each database shard and table and posted. This further reduces the posting pressure on the receiving account's database shard and table, improves posting performance, and better handles high-concurrency posting scenarios.

[0045] This specification provides an accounting method that receives payment accounting requests initiated by at least one payment account for a target receiving account, allocates the payment accounting requests from each payment account to the corresponding database shards and tables, and stores the accounting information corresponding to each payment accounting request in each database shard and table. In response to the accounting task, a preset number of target accounting information are retrieved from the corresponding database shards and tables of each payment account, and the target accounting information is recorded in the corresponding database shard and table of the target receiving account. By sharding a single database, different accounts may correspond to different database shards and tables. Therefore, when a single receiving account simultaneously receives payment accounting requests from a large number of different payment accounts, the sharding rules can distribute all high-concurrency requests originally from the same database to multiple database shards and tables, thus distributing the accounting pressure originally received by a single account to multiple database shards and tables. This effectively handles extremely high accounting traffic asynchronously and improves the performance of accounting and receiving transactions.

[0046] Please see Figure 3 , Figure 3 This is a flowchart illustrating an accounting method provided in an embodiment of this specification.

[0047] like Figure 3 As shown, accounting methods can include at least:

[0048] S302. Receive at least one payment account's payment accounting request for the target receiving account, allocate the payment accounting requests of each payment account to the corresponding database and table of each payment account, and save the accounting information corresponding to each payment accounting request in each database and table.

[0049] For details regarding step S302, please refer to the description in step S202; it will not be repeated here.

[0050] S304. In response to the first accounting task, retrieve the first preset quantity of first target accounting information from each sub-database and sub-table every first period, and save each first target accounting information to the buffer document table of the sub-database and sub-table corresponding to the target receiving account.

[0051] Optionally, please refer to Figure 4 , Figure 4 This is a flowchart illustrating the execution logic of an accounting method provided in an embodiment of this specification. Figure 4 As shown, when a payment account initiates a payment to a target receiving account, the accounting system that deploys the accounting method provided in the embodiments of this specification will receive at least one payment accounting request initiated by a payment account for the target receiving account, route and distribute the payment accounting requests of each payment account to the corresponding database and table of each payment account, and save the accounting information corresponding to each payment accounting request in each database and table.

[0052] Optionally, this accounting information needs to be posted to the corresponding database shard and table of the target receiving account. However, if pessimistic locking is used for all accounting information, lock contention errors can easily occur under high concurrency scenarios, leading to accounting failures. In this case, a buffered accounting method can be used. Buffered accounting refers to posting payment data to the database synchronously as a buffer document when posting to the receiving account. That is, the accounting data is first placed in the buffer document table, and then the accounting data in the buffer document table is retrieved by a scheduled task to perform real accounting, posting accounting document details, and updating the balance in the database, thereby improving accounting performance. However, the ordinary buffered accounting method still processes each document asynchronously when supplementing, so it still cannot break through the processing bottleneck of a single account. Moreover, when the number of documents is very large, the database statement execution of the buffer supplementing task may time out and fail to retrieve the buffer documents. In other words, when the database has a large amount of data, the database read and write speed will decrease, and the database will be unable to meet the retrieval of a large number of buffer documents, causing the buffer documents to time out or even become invalid.

[0053] Optionally, in the embodiments of this specification, after allocating each account to the corresponding sharded database and sharded table, the accounting pressure of a single sharded database and sharded table is reduced. Therefore, after using sharded databases and sharded tables, buffering the accounting for the target receiving account will further reduce the accounting calculation workload of the target receiving account and improve calculation efficiency. Please continue to refer to... Figure 4 When the accounting information needs to be returned to the corresponding sub-database and sub-table of the receiving account, the first accounting task can be responded to first. The first accounting task is used to instruct that the first preset quantity of first target accounting information be obtained from each sub-database and sub-table every first period, and each first target accounting information be saved to the buffer document table of the sub-database and sub-table corresponding to the target receiving account.

[0054] S306. In response to the second accounting task, every second period, retrieve the second preset number of second target accounting information from the buffer document table, and post the second target accounting information to the sub-database and sub-table corresponding to the target collection account.

[0055] Optionally, please refer to Figure 4 For all the first target accounting information already in the buffer document table, a second accounting task can be initiated. This second accounting task instructs the second period to retrieve a second preset quantity of second target accounting information from the buffer document table and post it to the corresponding database sub-table of the target receiving account. This posting is a true buffer replenishment, and ultimately all accounting information data will be stored in the target receiving account's database sub-table. The first and second periods can be the same or different, and similarly, the first and second preset quantities can also be the same or different. The specific settings for these data can be adjusted according to the database processing needs in the actual scenario, and this embodiment does not limit this.

[0056] Furthermore, compared to ordinary buffered accounting, which can only replenish accounts one by one in the real database, in order to further reduce the amount of calculation for replenishment, the total accounting amount of the second target accounting information obtained from the buffer document table can be calculated in batches. Based on the total accounting amount, the account amount corresponding to the target receiving account is modified. This can change multiple amount modifications into a single amount modification, reducing the number of database read and write operations. However, the receiving details of the target receiving account need to record detailed receiving information based on each receiving source. Therefore, it is still necessary to read and write one by one. That is, it is necessary to generate the account amount details of the target receiving account based on each second target accounting information.

[0057] In the embodiments of this specification, an accounting method is provided. Based on database sharding and table partitioning, when performing actual accounting for the target receiving account, firstly, according to the first accounting task, the first target accounting information is obtained from the database sharding and table partitioning of each payment account and placed in a buffer document table. Then, according to the second accounting task, the second target accounting information is obtained from the buffer document table and the actual accounting is performed in the database sharding and table partitioning of the target receiving account. This further reduces the accounting calculation workload of the target receiving account, improves calculation efficiency, enhances the performance of accounting and receiving, and adapts to scenarios with higher requirements for concurrent payment and receiving requests.

[0058] Please see Figure 5 , Figure 5 This is a flowchart illustrating an accounting method provided in an embodiment of this specification.

[0059] like Figure 5 As shown, accounting methods can include at least:

[0060] S502: Receive at least one payment account's payment accounting request for the target receiving account, allocate each payment account's payment accounting request to the corresponding database and table for each payment account, and save the accounting information corresponding to each payment accounting request in each database and table.

[0061] S504. In response to the accounting task, retrieve the preset number of target accounting information from the corresponding database and table of each payment account, and post the target accounting information to the corresponding database and table of the target receiving account.

[0062] For details regarding steps S502-S504, please refer to the detailed descriptions in steps S202-S204, which will not be repeated here.

[0063] S506. Receive at least one refund account's refund posting request for the target receiving account.

[0064] Optionally, in addition to receiving payments, an account's transaction activities may also include refunds. When a refunding account initiates a refund to the target receiving account, the accounting system that deploys the accounting method in the embodiments of this specification will receive at least one refund accounting request initiated by the refunding account against the target receiving account. These refund accounting requests will be recorded in the database and table corresponding to the target receiving account to complete the refund process.

[0065] S508. Determine whether the target receiving account is a hot account. If so, connect the target receiving account to the hot account database, which is built based on a high-performance accounting engine.

[0066] Optionally, since refunds require reducing the account balance of the target receiving account, using a buffered accounting method for refund accounting could lead to an overdraft of the account balance. Therefore, the current refund accounting still uses standard accounting to ensure fund security. However, standard accounting makes it very easy to detect account hotspots, especially when the target receiving account is receiving high-concurrency payment requests. If a refund peak occurs at this time, and the locking mechanism needs to be used frequently to process refunds, the target receiving account is very likely to exceed the performance bottleneck of the accounting system, resulting in accounting failure and becoming a hotspot account.

[0067] Optionally, to reduce the pressure on sharding and partitioning the target receiving account for refunds, a dedicated hot account database can be introduced. This hot account database is built on a high-performance accounting engine, and by packaging and offloading the accounting logic of the accounting system to the storage layer, network read / write and disk read / write costs are reduced. By specifically handling refund accounting for hot accounts in the hot account database, it can handle the high-concurrency refund accounting requests while the account is considered a hot account, reducing hot account error handling time, improving refund accounting capabilities, and significantly enhancing the user transaction experience.

[0068] Furthermore, during the transaction process of the target receiving account, the status of the target receiving account can be continuously monitored to determine whether it is a hot account. If so, the target receiving account is added to the hot account database, and all its refund requests are processed in the hot account database after the target receiving account becomes a hot account. Figure 4 As shown, the accounting system also connects to a hot account database, which allows the system to switch hot accounts to the hot account database when they are detected, and process related refund and accounting requests.

[0069] Specifically, when determining whether a target receiving account is a hot account, two scenarios may occur. First, in a payment scenario, if the concurrency of payment recording requests exceeds a first preset hotspot threshold, the target receiving account is confirmed as a hotspot account. Payment recording methods employing database sharding and buffered recording can handle most concurrent payment recording scenarios, thus this is generally considered a predictive hotspot account. However, in a refund scenario, if the concurrency of refund recording requests exceeds a second preset hotspot threshold, refund lock-grabbing errors will surge significantly. Refund lock-grabbing requires self-healing according to hotspot self-healing rules, thus this is generally considered a self-healing hotspot account, and the target receiving account is confirmed as a hotspot account. The first and second preset hotspot thresholds can be flexibly set depending on the payment and refund scenarios, and this specification does not specifically limit them in the embodiments.

[0070] Please refer to details. Figure 6 , Figure 6 This is a data acquisition flowchart for a hotspot account identification method provided in an embodiment of this specification. Figure 6 As shown, to determine whether the target payment account is a hot account, data tracking can be implemented first. By setting up a post-interceptor to capture the account lock interface and using an asynchronous thread pool to process the counting logic, the error messages for refund lock grabbing corresponding to the target payment account can be counted. During the data processing stage, the number of account lock grabbing errors is counted, and the hot account and its corresponding statistical value are updated to the Key-Value database (KV database) according to the hot key (hot account) - value (statistical value) correspondence. If the statistical value is greater than the second preset hot threshold, the target payment account is confirmed as a hot account, and the hot account is automatically switched to the hot account database.

[0071] S5010. Record the accounting information corresponding to the payment accounting requests of each payment account to the hot account database.

[0072] Optionally, when the target receiving account is a hot account, the target receiving account will be switched to the hot account database. After that, a dual write operation can be performed on the target receiving account, that is, the accounting information corresponding to the payment accounting request is recorded in the database and table corresponding to the target receiving account, and the accounting information corresponding to the payment accounting request is also recorded in the hot account database, further ensuring the security and stability of the receiving accounting information after the target receiving account becomes a hot account.

[0073] Please refer to details. Figure 7 , Figure 7 This is a structural framework diagram illustrating an implementation of an accounting method provided in this specification. Figure 7 As shown, when an accounting request arrives at the accounting system, the accounting decision unit selects the accounting method to be used, which includes at least one ordinary accounting method and the accounting method provided in the embodiments of this specification. Then, the accounting engine calling unit calls the database shard and table corresponding to the target receiving account according to the decided accounting method, and calls the hot account database when the target receiving account is a hot account. The data of the database shard and table corresponding to the target receiving account and the hot account database are synchronized to jointly handle the high-concurrency accounting requests of hot accounts.

[0074] S5012. Post the accounting information corresponding to the refund posting requests of each refund account to the corresponding database and table of the target receiving account.

[0075] Optionally, for refund accounting requests received by the target receiving account, the process is generally the same as for payment accounting requests, requiring accounting in the corresponding database shard and table. However, for refund accounting requests received after the target receiving account becomes a hot account, the accounting information corresponding to the refund accounting requests of each refund account is recorded in the hot account database to obtain the refund accounting result. When it is detected that the target receiving account has been restored to a normal account, the refund accounting result is then saved to the corresponding database shard and table. Based on the hot account automatic discovery, judgment, and switching mechanism, the processing time for hot account errors is greatly reduced, fund security is ensured, refund accounting capabilities are improved, and user experience is greatly enhanced.

[0076] In the embodiments of this specification, an accounting method is provided. For refund accounting scenarios, it is first determined whether the target receiving account is a hot account. If so, the target receiving account is connected to the hot account database. The hot account database is built based on a high-performance accounting engine, which enables the hot account database to handle the processing pressure of high-concurrency refund accounting requests while the account is a hot account, reducing the hot account error handling time, improving refund accounting capabilities, and greatly improving the user transaction experience. Furthermore, after the target receiving account is switched to the hot account database, a dual write operation is performed on the target receiving account. The payment accounting information is recorded in the corresponding database shard and table of the target receiving account, and at the same time, the payment accounting information is also recorded in the hot account database, further ensuring the security and stability of the receiving accounting information after the target receiving account becomes a hot account.

[0077] Please see Figure 8 , Figure 8 This is a structural block diagram of an accounting device provided as an embodiment of this specification. Figure 8 As shown, the accounting device 800 includes:

[0078] The routing module 810 is used to receive payment accounting requests initiated by at least one payment account for a target receiving account, allocate the payment accounting requests of each payment account to the corresponding database and table of each payment account, and save the accounting information corresponding to each payment accounting request in each database and table.

[0079] The accounting module 820 is used to respond to accounting tasks by retrieving a preset number of target accounting information from the corresponding database and table of each payment account, and posting the target accounting information to the corresponding database and table of the target receiving account.

[0080] Optionally, the accounting module 820 is also configured to, in response to the first accounting task, retrieve a first preset quantity of first target accounting information from each sub-database and sub-table every first period, and save each first target accounting information to the buffer document table of the sub-database and sub-table corresponding to the target receiving account; and in response to the second accounting task, retrieve a second preset quantity of second target accounting information from the buffer document table every second period, and record the second target accounting information to the sub-database and sub-table corresponding to the target receiving account.

[0081] Optionally, the accounting module 820 is also used to calculate the total accounting amount of all second target accounting information, modify the account amount corresponding to the target receiving account based on the total accounting amount, and generate account amount details of the target receiving account based on each second target accounting information.

[0082] Optionally, the accounting device 800 further includes: a refund module, used to receive a refund accounting request initiated by at least one refund account for the target receiving account; and to record the accounting information corresponding to the refund accounting requests of each refund account to the corresponding database and table of the target receiving account.

[0083] Optionally, the accounting device 800 also includes: a hot account judgment module, used to determine whether the target receiving account is a hot account; if so, the target receiving account is connected to the hot account database, which is built based on a high-performance accounting engine; a refund module, used to record the accounting information corresponding to the refund accounting requests of each refund account into the hot account database to obtain the refund accounting result; when the target receiving account is detected to be an ordinary account, the refund accounting result is saved to the corresponding database and table of the receiving account.

[0084] Optionally, the accounting device 800 further includes a hotspot account determination module, which is further configured to confirm the target receiving account as a hotspot account if the concurrency of receiving and accounting requests exceeds a first preset hotspot threshold, and / or confirm the target receiving account as a hotspot account if the concurrency of refund accounting requests exceeds a second preset hotspot threshold.

[0085] Optionally, the accounting device 800 also includes a hotspot account accounting module, which is also used to record the accounting information corresponding to the payment accounting requests of each payment account into the hotspot account database.

[0086] Optionally, the accounting device 800 also includes a hotspot account judgment module, which is also used to determine the number of refund lock-grabbing errors corresponding to the target receiving account. When the number of refund lock-grabbing errors exceeds a second preset hotspot threshold, the target receiving account is confirmed as a hotspot account.

[0087] Optionally, database sharding and table partitioning are obtained by splitting the database according to the number characteristics of all accounts.

[0088] This specification provides an accounting device, comprising a distribution module for receiving payment accounting requests initiated by at least one payment account for a target receiving account, distributing the payment accounting requests of each payment account to the corresponding database shards and tables, and storing the accounting information corresponding to each payment accounting request in each database shard and table; and an accounting module for responding to the accounting task by retrieving a preset number of target accounting information from the corresponding database shards and tables of each payment account, and posting the target accounting information to the corresponding database shard and table of the target receiving account. By sharding a single database, different accounts may correspond to different database shards and tables. When a single receiving account simultaneously receives payment accounting requests from a large number of different payment accounts, the database sharding rules can be used to distribute all high-concurrency requests originally from the same database to multiple database shards and tables, thus distributing the accounting pressure originally received by a single account to multiple database shards and tables, effectively processing extremely high accounting traffic asynchronously, and improving the performance of accounting and collection.

[0089] This specification provides a computer program product containing instructions that, when run on a computer or processor, cause the computer or processor to perform the steps of any of the methods described above.

[0090] This specification also provides a computer storage medium that can store multiple instructions adapted for loading by a processor and executing the steps of any of the methods described in the above embodiments.

[0091] Please see Figure 9 , Figure 9 This is a schematic diagram of the structure of a terminal provided in an embodiment of this specification. Figure 9 As shown, terminal 900 may include: at least one terminal processor 901, at least one network interface 904, user interface 903, memory 905, and at least one communication bus 902.

[0092] The communication bus 902 is used to enable communication between these components.

[0093] The user interface 903 may include a display screen and a camera. Optionally, the user interface 903 may also include a standard wired interface and a wireless interface.

[0094] The network interface 904 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0095] The terminal processor 901 may include one or more processing cores. The terminal processor 901 connects to various parts within the terminal 900 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 905, and by calling data stored in the memory 905. Optionally, the terminal processor 901 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The terminal processor 901 may integrate one or more of the following: a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), and a modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also be implemented as a separate chip without being integrated into the terminal processor 901.

[0096] The memory 905 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 905 may include a non-transitory computer-readable storage medium. The memory 905 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 905 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), instructions for implementing the various method embodiments described above, etc.; the data storage area may store data involved in the various method embodiments described above, etc. Optionally, the memory 905 may also be at least one storage device located remotely from the aforementioned terminal processor 901. Figure 9 As shown, the memory 905, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an accounting program.

[0097] exist Figure 9In the terminal 900 shown, the user interface 903 is mainly used to provide an input interface for the user and to obtain the user's input data; while the terminal processor 901 can be used to call the accounting program stored in the memory 905 and specifically perform the following operations:

[0098] Receive at least one payment accounting request initiated by a payment account for a target receiving account, allocate the payment accounting requests of each payment account to the corresponding database and table of each payment account, and save the accounting information corresponding to each payment accounting request in each database and table.

[0099] In response to the accounting task, a preset number of target accounting information are obtained from the corresponding database and table of each payment account, and the target accounting information is recorded in the corresponding database and table of the target receiving account.

[0100] In some embodiments, when the terminal processor 901 performs a task in response to an accounting task, by retrieving a preset number of target accounting information from the sub-databases and sub-tables corresponding to each payment account and posting the target accounting information to the sub-database and sub-tables corresponding to the target receiving account, the following steps are specifically executed: In response to a first accounting task, every first period, a first preset number of first target accounting information is retrieved from each sub-database and sub-table, and each first target accounting information is saved to the buffer document table of the sub-database and sub-tables corresponding to the target receiving account; In response to a second accounting task, every second period, a second preset number of second target accounting information is retrieved from the buffer document table, and the second target accounting information is posted to the sub-database and sub-tables corresponding to the target receiving account.

[0101] In some embodiments, when the terminal processor 901 executes the following steps when posting the second target accounting information to the database sub-table corresponding to the target receiving account: calculating the total accounting amount of all second target accounting information, modifying the account amount corresponding to the target receiving account based on the total accounting amount; and generating account amount details of the target receiving account based on each second target accounting information.

[0102] In some embodiments, the terminal processor 901 further performs the following steps: receiving a refund accounting request initiated by at least one refund account for the target receiving account; and recording the accounting information corresponding to the refund accounting requests of each refund account to the corresponding database and table of the target receiving account.

[0103] In some embodiments, the terminal processor 901 further performs the following steps: determining whether the target receiving account is a hot account; if so, connecting the target receiving account to the hot account database, which is built based on a high-performance accounting engine; when the terminal processor 901 executes the accounting information corresponding to the refund accounting requests of each refund account to the sharded database and sharded table corresponding to the target receiving account, it specifically performs the following steps: accounting information corresponding to the refund accounting requests of each refund account to the hot account database to obtain the refund accounting result; when the target receiving account is detected to be a regular account, the refund accounting result is saved to the sharded database and sharded table corresponding to the receiving account.

[0104] In some embodiments, when the terminal processor 901 determines whether the target receiving account is a hot account, it specifically performs the following steps: if the concurrency of receiving and recording requests exceeds a first preset hot account threshold, the target receiving account is confirmed as a hot account; and / or if the concurrency of refund recording requests exceeds a second preset hot account threshold, the target receiving account is confirmed as a hot account.

[0105] In some embodiments, after the terminal processor 901 accesses the target receiving account to the hotspot account database, it further performs the following steps: recording the accounting information corresponding to the payment accounting requests of each payment account to the hotspot account database.

[0106] In some embodiments, when the terminal processor 901 executes the following steps when it determines that the target receiving account is a hot account if the concurrency of refund accounting requests exceeds the second preset hotspot threshold: determine the number of refund lock-grabbing errors corresponding to the target receiving account, and when the number of refund lock-grabbing errors exceeds the second preset hotspot threshold, confirm that the target receiving account is a hotspot account.

[0107] In some embodiments, database sharding and table partitioning are obtained by splitting the database according to the number characteristics of all accounts.

[0108] In the several embodiments provided in this specification, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0109] The modules described as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0110] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this specification are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in or transmitted through a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The aforementioned available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)).

[0111] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0112] In addition, it should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.) and signals involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data shall comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0113] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0114] The above is a description of an accounting method, apparatus, storage medium, and terminal provided in the embodiments of this specification. For those skilled in the art, based on the ideas of the embodiments of this specification, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation on the embodiments of this specification.

Claims

1. An accounting method, the method comprising: Receive at least one payment accounting request initiated by a payment account for a target receiving account, allocate the payment accounting requests of each payment account to the corresponding database and table of each payment account, and save the accounting information corresponding to each payment accounting request in each database and table. In response to the accounting task, a preset number of target accounting information is obtained from the corresponding database and table of each payment account, and the target accounting information is recorded in the corresponding database and table of the target receiving account. In response to the accounting task, the process of retrieving a preset number of target accounting information from the corresponding database and table of each payment account, and posting the target accounting information to the corresponding database and table of the target receiving account includes: In response to the first accounting task, the first preset number of first target accounting information is obtained from each sub-database and sub-table every first period, and each first target accounting information is saved to the buffer document table of the sub-database and sub-table corresponding to the target receiving account. In response to the second accounting task, every second period, a second preset number of second target accounting information is obtained from the buffer document table, and the second target accounting information is recorded in the sub-database and sub-table corresponding to the target receiving account.

2. The method according to claim 1, wherein posting the second target accounting information to the sub-database and sub-table corresponding to the target receiving account includes: Calculate the total accounting amount for all second target accounting information, and modify the account amount corresponding to the target receiving account based on the total accounting amount; The account amount details of the target receiving account are generated based on the accounting information of each second target.

3. The method according to claim 1, further comprising: Receive at least one refund account's refund posting request for the target receiving account; The accounting information corresponding to the refund requests of each refund account will be recorded in the corresponding database and table of the target receiving account.

4. The method according to claim 3, further comprising: Determine whether the target receiving account is a hot account. If so, connect the target receiving account to the hot account database, which is built based on a high-performance accounting engine. The step of posting the accounting information corresponding to the refund requests of each refund account to the sub-database and sub-table corresponding to the target receiving account includes: The accounting information corresponding to the refund accounting requests of each refund account is recorded in the hot account database to obtain the refund accounting results; When the target receiving account is detected to be a regular account, the refund accounting result is saved to the corresponding database and table of the receiving account.

5. The method according to claim 4, wherein determining whether the target receiving account is a "hotspot" account includes: If the concurrency of the payment recording requests exceeds a first preset hotspot threshold, the target receiving account is confirmed as a hotspot account; and / or if the concurrency of the refund recording requests exceeds a second preset hotspot threshold, the target receiving account is confirmed as a hotspot account.

6. The method according to claim 5, further comprising, after connecting the target receiving account to the hotspot account database: The accounting information corresponding to the payment accounting requests of each payment account is recorded in the hot account database.

7. The method according to claim 5, wherein confirming the target receiving account as a hotspot account if the concurrency of the refund accounting requests exceeds a second preset hotspot threshold includes: The number of refund lock-grabbing errors corresponding to the target payment account is determined. When the number of refund lock-grabbing errors exceeds the second preset hotspot threshold, the target payment account is confirmed as a hotspot account.

8. The method according to claim 1, wherein the database sharding and table partitioning are obtained by partitioning the database according to the number characteristics of all accounts.

9. An accounting device, the device comprising: The routing module is used to receive payment accounting requests initiated by at least one payment account for a target receiving account, allocate the payment accounting requests of each payment account to the corresponding database and table of each payment account, and save the accounting information corresponding to each payment accounting request in each database and table. The accounting module is used to respond to accounting tasks by obtaining a preset number of target accounting information from the corresponding database and table of each payment account, and recording the target accounting information to the corresponding database and table of the target receiving account. The accounting module is also used to respond to the first accounting task, obtain a first preset number of first target accounting information from each sub-database and sub-table every first period, and save each first target accounting information to the buffer document table of the sub-database and sub-table corresponding to the target receiving account; In response to the second accounting task, every second period, a second preset number of second target accounting information is obtained from the buffer document table, and the second target accounting information is recorded in the sub-database and sub-table corresponding to the target receiving account.

10. A computer program product comprising instructions that, when run on a computer or processor, cause the computer or processor to perform the steps of the method as claimed in any one of claims 1 to 8.

11. A computer storage medium storing a plurality of instructions adapted for loading by a processor and performing the steps of the method as claimed in any one of claims 1 to 8.

12. A terminal comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the steps of the method as claimed in any one of claims 1 to 8.

Images