Data processing method and device for hotspot account

Abstract

The invention discloses a data processing method and device for a hotspot account, the hotspot account is used as an entity account, the balance of the entity account is acquired, the balance of the entity account is dispersed to a plurality of pre-created shadow accounts, the shadow accounts are sub-accounts having a binding relationship with the entity account, and the sub-accounts are used for processing data of the entity account. In the process that the multiple shadow accounts carry out account transactions, cache bookkeeping and summarized detail bookkeeping of account balances are carried out among the multiple shadow accounts through a channel meeting a preset channel constraint condition, and the account transactions at least comprise a posting operation, a posting operation or a balance supplementing operation; the preset channel constraint condition is a constraint condition that all transactions of a plurality of shadow accounts specify bookkeeping in a single channel.

Description

Technical Field

[0001] The present application relates to the field of message processing technology, and more specifically, to a data processing method and device for hotspot accounts. Background Art

[0002] In a multi-threaded environment, when multiple threads try to access and modify the same account at the same time, the system will use a locking mechanism to prevent concurrency conflicts in order to ensure data consistency and accuracy. However, when operations on a certain account are very frequent, the lock resources of this account will become a point of contention in the system, causing a large number of threads to wait for the lock to be released, thereby reducing the processing power and efficiency of the entire system. In this case, the account becomes a hot account.

[0003] Therefore, how to prevent hotspot accounts from reducing the processing capacity and efficiency of the entire system is an urgent problem to be solved in this application. Summary of the invention

[0004] In view of this, the present application discloses a data processing method and device for hotspot accounts, aiming to improve the overall processing efficiency and system throughput of the system and avoid the situation where hotspot accounts reduce the processing capacity and efficiency of the entire system.

[0005] In order to achieve the above purpose, the disclosed technical solution is as follows:

[0006] In a first aspect, the present application discloses a data processing method for a hotspot account, the method comprising:

[0007] Treat the hotspot account as an entity account and obtain the balance of the entity account;

[0008] Distribute the balance of the entity account into multiple pre-created shadow accounts; wherein the shadow account is a sub-account that has a binding relationship with the entity account;

[0009] In the process of account transactions among multiple shadow accounts, cache accounting and summary detailed accounting of account balances are performed between the multiple shadow accounts through channels that meet preset channel constraints; wherein the account transactions at least include entry operations, exit operations or balance replenishment operations; the preset channel constraints are constraints for multiple shadow accounts, specifying that all transactions of the shadow accounts are accounted for in a single channel.

[0010] Preferably, the process of creating a shadow account includes:

[0011] The hotspot account is broken up to obtain a plurality of shadow accounts; wherein the data structure of the plurality of shadow accounts is consistent with the data structure of the hotspot account.

[0012] Preferably, in the process of performing account transactions among multiple shadow accounts, cache accounting and summary detailed accounting of account balances between multiple shadow accounts are performed through channels that meet preset channel constraints, including:

[0013] During the process of multiple shadow accounts performing entry operations, exit operations or balance replenishment operations, account balance accounting operations are performed between multiple shadow accounts through channels that meet preset constraints, as well as by caching the amounts in the database through timed asynchronous refresh and delayed batch transaction entry, and the summary detailed accounting of the balance is updated by timed asynchronous aggregation of multiple shadow account transactions.

[0014] Preferably, it also includes:

[0015] Add the hotspot account ID and cache account balance ID to the cache.

[0016] Preferably, it also includes:

[0017] When it is detected that the cache cluster is abnormal or the identifier cannot be read, the cache is downgraded through the update logic; the update logic is the logic for modifying the data in the database table.

[0018] Preferably, the process of the entry operation includes:

[0019] The shadow account and current timestamp changed during the account entry process are stored in the hotspot account identifier to obtain the account entry information;

[0020] The account entry information is stored in the entry flow table and set to a pending entry state, the account entry information in the entry flow table is batch processed, and the entry state is set to complete the entry operation process.

[0021] Preferably, the process of the withdrawal operation includes:

[0022] The shadow account and current timestamp changed during the account withdrawal process are stored in the hotspot account identifier, and the amount is deducted from the account ID corresponding to the hotspot account identifier;

[0023] Determine whether the amount after deduction is greater than or equal to 0;

[0024] If the amount after deduction is greater than or equal to 0, generate account outgoing information, record the account outgoing information in the outgoing flow table, and return the successful deduction information;

[0025] If the amount after deduction is less than 0, a message indicating insufficient amount is generated.

[0026] Preferably, the process of the balance replenishment operation includes:

[0027] Count the unrecorded transactions in the account transaction table and obtain the corresponding summary amount of the unrecorded transactions;

[0028] Update the summary amount corresponding to the unrecorded transaction into the balance table;

[0029] Update the data in the balance table to the cache account balance identifier.

[0030] The second aspect of the present application discloses a data processing device for a hotspot account, the device comprising:

[0031] An acquisition unit, used to treat the hotspot account as an entity account and obtain the balance of the entity account;

[0032] A dispersing unit, used to disperse the balance of the entity account into a plurality of pre-created shadow accounts; wherein the shadow account is a sub-account that has a binding relationship with the entity account;

[0033] An accounting unit is used to perform cache accounting and summary detailed accounting of account balances between multiple shadow accounts through channels that meet preset channel constraints during account transactions among multiple shadow accounts; wherein account transactions at least include entry operations, exit operations, or balance replenishment operations; and the preset channel constraints are constraints that specify accounting for all transactions of multiple shadow accounts in a single channel.

[0034] Preferably, the decentralized unit for creating the shadow account is specifically used for:

[0035] The hotspot account is broken up to obtain a plurality of shadow accounts; wherein the data structure of the plurality of shadow accounts is consistent with the data structure of the hotspot account.

[0036] Through the above technical scheme, it can be known that the present application discloses a data processing method and device for hotspot accounts, which takes the hotspot account as the entity account, obtains the balance of the entity account, and disperses the balance of the entity account into multiple pre-created shadow accounts, wherein the shadow account is a sub-account that has a binding relationship with the entity account, and in the process of account transactions of multiple shadow accounts, the cache accounting and summary detailed accounting of the account balance are performed between multiple shadow accounts through channels that meet the preset channel constraints, wherein the account transaction includes at least an entry operation, an exit operation or a balance replenishment operation, and the preset channel constraint is a constraint condition for all transactions of the shadow account to be specified for accounting in a single channel for multiple shadow accounts. Through the above scheme, the hotspot account is taken as the entity account, and the balance of the entity account is dispersed into multiple pre-created shadow accounts, which can reduce the number of locks on a single account, thereby improving the overall processing efficiency and system throughput of the system. Moreover, in the process of account transactions with multiple shadow accounts, through channels that meet the preset channel constraints, that is, the channel end applies for a separate internal account, namely, a shadow account, as the only channel to use the shadow account, and adds cache accounting and summary detailed accounting processing methods to each shadow account, optimizes the transfer logic between accounts, reduces the occurrence of single huge core hot spots, and achieves the goal of improving the user experience while ensuring the security of funds, and reduces the pressure on the core accounting system, thereby avoiding the situation where hot accounts reduce the processing capacity and efficiency of the entire system. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0038] Figure 1 A flowchart of a data processing method for hotspot accounts disclosed in an embodiment of the present application;

[0039] Figure 2 A schematic diagram of hotspot account processing performed by a channel end disclosed in an embodiment of the present application;

[0040] Figure 3 A schematic diagram of an optimization and transformation scheme for transferring between shadow accounts disclosed in an embodiment of the present application;

[0041] Figure 4 A schematic diagram of storing a modified shadow account and a current timestamp in a hotspot identifier according to an embodiment of the present application;

[0042] Figure 5 A schematic diagram of storing account entry information into an entry flow table disclosed in an embodiment of the present application;

[0043] Figure 6 A schematic diagram of the payment process disclosed in the embodiment of the present application;

[0044] Figure 7 A schematic diagram of a balance replenishment thread disclosed in an embodiment of the present application;

[0045] Figure 8 A schematic diagram of cache degradation disclosed in an embodiment of the present application;

[0046] Fig. 9 A schematic diagram of the structure of a data processing device for hotspot accounts disclosed in an embodiment of the present application;

[0047] Fig.10 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of the present application. DETAILED DESCRIPTION

[0048] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0049] In this application, the terms "comprises", "comprising" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprising a ..." does not exclude the presence of other identical elements in the process, method, article or device comprising the element.

[0050] As can be seen from the background technology, in a multi-threaded environment, when multiple threads try to access and modify the same account at the same time, the system will use a locking mechanism to prevent concurrency conflicts due to the need to ensure data consistency and accuracy. However, when operations on a certain account are very frequent, the lock resources of this account will become a competition point in the system, causing a large number of threads to wait for the release of the lock, thereby reducing the processing power and efficiency of the entire system. In this case, the account becomes a hot account. Therefore, how to prevent hot accounts from reducing the processing power and efficiency of the entire system is a problem that needs to be solved urgently in this application.

[0051] In order to solve the above problems, the present application discloses a data processing method and device for hotspot accounts, which takes the hotspot account as an entity account, and disperses the balance of the entity account into multiple pre-created shadow accounts, which can reduce the number of locks on a single account, thereby improving the overall processing efficiency and system throughput of the system. And in the process of multiple shadow accounts conducting account transactions, through a channel that meets the preset channel constraint conditions, that is, the channel end applies for an internal account for separate use, that is, a shadow account, as the only channel to use the shadow account, add a cache accounting and summary detailed accounting processing method to each shadow account, optimize the transfer logic between accounts, reduce the occurrence of a single huge core hotspot, and achieve while ensuring the security of funds while improving the user experience, and reduce the pressure on the core accounting system, thereby avoiding the situation where the hotspot account reduces the processing capacity and efficiency of the entire system. The specific implementation method is specifically described through the following embodiments.

[0052] It should be noted that in the technical solution of this application, the collection, use, storage, transfer and other processing of the customer's account transactions (such as accounting, payment, balance replenishment, etc.), account information, etc. are in compliance with the provisions of relevant laws and regulations, and it is necessary to inform the customer and obtain the customer's consent or authorization. When applicable, the customer's account transactions, account information and other information are de-identified and / or anonymized and / or encrypted.

[0053] refer to Figure 1 FIG. 1 is a flow chart of a method for processing data for hotspot accounts disclosed in an embodiment of the present application. The method for processing data for hotspot accounts mainly includes the following steps:

[0054] S101: Take the hotspot account as an entity account and obtain the balance of the entity account.

[0055] A hot account is an account in a financial processing system that becomes a bottleneck in system performance because its data is frequently locked and released due to high concurrent access. Specifically, in a multi-threaded environment, when multiple threads try to access and modify the same account at the same time, the system uses a locking mechanism to prevent concurrent conflicts in order to ensure data consistency and accuracy. However, when operations on a certain account are very frequent, the lock resources of this account will become a point of contention in the system, causing a large number of threads to wait for the lock to be released, thereby reducing the processing power and efficiency of the entire system. In this case, the account becomes a so-called hot account.

[0056] S102: Distribute the balance of the entity account into a plurality of pre-created shadow accounts; wherein the shadow account is a sub-account that is bound to the entity account.

[0057] In S102, the hotspot account is broken up by splitting the sub-accounts to obtain multiple shadow accounts; wherein the data structure of the multiple shadow accounts is consistent with the data structure of the hotspot account.

[0058] Among them, sub-account splitting breaks up hotspot accounts by breaking up hot spots, that is, treating the hotspot account as a physical account, creating multiple shadow accounts bound to the account, and dispersing the physical account balance to each shadow account. Sub-account splitting can reduce hot spots while also preventing account deficits.

[0059] S103: During account transactions of multiple shadow accounts, cache accounting and summary detailed accounting of account balances are performed between the multiple shadow accounts through channels that meet preset channel constraints; wherein the account transactions at least include entry operations, exit operations or balance replenishment operations; and the preset channel constraints are constraints that specify accounting for all transactions of multiple shadow accounts in a single channel.

[0060] In S103, during the process of performing entry operations, exit operations or balance replenishment operations on multiple shadow accounts, account balances are recorded between multiple shadow accounts by periodically asynchronously refreshing the amounts in the database and delaying batch transaction entries through channels and caches that meet preset channel constraints, and the summary detailed accounting of the balances is updated by periodically asynchronously aggregating multiple shadow account transactions.

[0061] Cache accounting is to use cache (redis) instead of database to perform accounting operations. The amount in the database is refreshed asynchronously at regular intervals. Cache accounting makes memory accounting processing fast and can effectively reduce the concurrency pressure of database files (DateBase, DB) during peak scenarios. Among them, redis is a key-value database written in ANSI C language that can be based on memory and can be persistent.

[0062] The summary of detailed accounting will replace the update of balance with the insertion of dynamic account flow. The balance is updated by the scheduled asynchronous summary flow.

[0063] This solution involves the following two constraints:

[0064] 1. Accurate total amount: The hot account processing solution mentioned in this plan requires that the total amount of the account must be dynamically equal to the actual balance when the payment is charged or deducted, which means that the accounting must be accurate and there must not be any over-collection or over-deduction;

[0065] 2. Preset channel constraints (single channel accounting): If an account is to maintain balance control, it must be required that all inbound and outbound transactions of a single account can only be conducted in one channel. Otherwise, the account balance cannot be accurately controlled. Preset channel constraints prevent other systems or channels from making account changes to internal accounts and affecting balance control.

[0066] As the number of customers and merchants connected increases, the core account table of the channel payment service system has been locked during peak transactions, resulting in slow transactions. In view of the shortcomings of the above common processing solutions, and considering the subsequent docking scenarios of local life, in order to reserve performance for the subsequent growth of business transaction volume, channel payment needs to be transformed to handle hot accounts.

[0067] The current main businesses of the channel payment service system include payment and fee-paying businesses on personal channels such as shopping platforms (such as Bodou and credit card points), social security payments, and phone recharges, providing cashiering and settlement capabilities for customers and connected merchants.

[0068] The following is an explanation of the account processing before the transformation (existing technology) and the hotspot account processing of channel payment after the transformation (this solution):

[0069] Before the transformation, the funds behind each cashier transaction (payment / refund) were:

[0070] a. Customer's bank card《—》account clearing;

[0071] b. Card voucher internal account《—》clearing account;

[0072] c. Internal Points Account《—》Clearing Account;

[0073] d. Margin internal account《—》clearing account;

[0074] e. Merchant settlement account: Clearing account; ......

[0076] If 10 concurrent transactions are generated instantaneously, not only will each internal account generate 10 concurrent transactions, but the "channel payment dedicated clearing account" will also generate n*10 concurrent transactions, resulting in an instantaneous increase in pressure on the entire accounting system.

[0077] Assume that 10 customers each need to pay a total order amount of 30 yuan. After the customer jumps to the cashier page, he selects a 10 yuan voucher, 1,000 Bo beans (equivalent to 10 yuan), and a 10 yuan bank card deduction. The merchant sets up real-time settlement and charges a 0.1% handling fee;

[0078] Then according to the method before the transformation, it will produce:

[0079] Receiving side:

[0080] 10 transactions*10 yuan (card and voucher internal account -> dedicated clearing account);

[0081] 10 transactions*10 yuan (transfer between internal accounts of Bodou -> dedicated clearing account);

[0082] 10 transactions*10 yuan (customer account payment -> special clearing account).

[0083] Clearing side:

[0084] 10 transactions*29.97 yuan (dedicated clearing account -> merchant account collection);

[0085] 10 transactions*0.03 yuan (special clearing account -> internal handling fee account);

[0086] A total of 50 transfer transactions were generated within the bank’s core.

[0087] Except for the 10 transactions of "customer account payment" and "merchant account collection" that must be recorded in real time, the remaining internal account transactions can be aggregated and merged into one transaction. After the transformation (this solution), Figure 2 shown. Figure 2 A schematic diagram showing hotspot account processing at the channel end.

[0088] Figure 2 In the example, 1 transaction * 100 yuan (card and voucher internal account -> channel payment dedicated clearing account); among them, -> means transfer, which represents the direction of the amount flow, for example, the card and voucher internal account transfers 100 yuan to the clearing account;

[0089] 1 transaction*100 yuan (transfer between internal accounts of Bodou -> channel payment special clearing account);

[0090] 10 transactions*10 yuan (customer account payment -> channel payment special clearing account).

[0091] Clearing side:

[0092] 10 transactions*29.97 yuan (dedicated clearing account -> merchant account collection);

[0093] 1 transaction*0.3 yuan (special clearing account -> internal handling fee account);

[0094] A total of 23 transfer transactions were generated within the bank’s core.

[0095] Through this solution, the following inter-account transfer processing solution is set up between the internal accounts dedicated to payment in each channel, which can reduce the pressure to 10+10+(n-2)*1. This will achieve the effect of reducing the pressure on core hot accounts, where n is the number of transactions in and out of the actual account.

[0096] This solution (after transformation) is based on the practical experience of the channel payment service system project. Through the core idea of ​​sub-account splitting and the elimination of hot spots, the single account business is split into a larger number of internal accounts (i.e. shadow accounts). The channel side applies for a separate shadow account as the only channel to use the shadow account, and adds cache accounting and summary detailed accounting processing methods to each shadow account, optimizes the transfer logic between shadow accounts, reduces the occurrence of a single huge core hot spot, and achieves the goal of improving the user experience while ensuring the security of funds, and reduces the pressure on the core accounting system.

[0097] However, the channel side can also handle hotspot accounts, the core of which is the following two points:

[0098] (1) By drawing on the core idea and hot spots of sub-account splitting, a single account business is split into a larger number of shadow accounts. The channel side applies for a single shadow account as the only channel to use the shadow account. The only channel is used to achieve the preset channel constraint "single channel accounting" to prevent other systems or channels from making changes to the internal account and affecting balance control.

[0099] (2) Add cache accounting and summary detailed accounting processing methods between shadow accounts to optimize the transfer logic between accounts and reduce the occurrence of single huge core hotspots.

[0100] This section mainly provides an optimization solution for transferring between shadow accounts. The main design ideas of cache accounting + summary and detailed accounting are as follows:

[0101] Rely on redis to cache account balances for outgoing payments, and rely on delayed batch transaction entry to accurately update balances and improve performance. Rely on redis to cache account balances for outgoing payments. The core feature of redis is single-threaded. Multiple balance change threads enter redis, and each thread still queues up and operates in sequence. After processing one, the next one will proceed. There will be no dirty reads caused by thread crossing. The overall process is as follows Figure 3 As shown, each system can be applied to its own accounting processing and transfer according to its own business scenarios. Figure 3 A schematic diagram showing the optimization and transformation plan for transfers between shadow accounts is shown.

[0102] Figure 3 In the example, Thread A is thread A, ThreadB is thread B, and Thread C is thread C. SeqNo is the sequence number; AccountNo is the operation account; DebitType is the debit type; Amt is the amount; State is the state, 0 is pending, 1 is already accounted; AccountName is the name of the operation account; Balance is the balance of the operation account.

[0103] Thread A +50 yuan, thread B -50 yuan, thread C -100 yuan. Because the redis balance check is greater than 0, threads A and B can successfully modify the balance. Thread C is intercepted because the balance is less than 0 after deduction. Then after redis operation of thread A and thread B, each will generate a transaction to be credited, with the amount of +50 and -50 respectively, and the operation account is 1101013030100004.

[0104] There is batch processing later (see below for details) Figure 7 Balance replenishment process), count the amount to be credited, +50+(-50)=0, the total amount is +0 yuan, which is deposited into the operating account.

[0105] Preliminary preparation:

[0106] (1) Addition of new database DB. If there is a similar function table, it can be reused:

[0107] Account information table (account number, account name, balance...);

[0108] Account entry table (account entry number, account number, counterparty account number, accounting type, transaction amount, accounting status, transfer batch serial number, etc.);

[0109] Accounting record table (transfer batch serial number, account number, counterparty account number, accounting type, transaction amount, transaction time...).

[0110] (2) Redis adds the following two keys, as shown in Table 1:

[0111]

[0112] Table 1

[0113] In Table 1, a hotspot account (hotspot_account) identifier and a cache account balance (hotspot_account_currentbalance) identifier are added to the cache.

[0114] SortedSet refers to the ordered set data structure in Redis, which is implemented by hash table. The member Member of each element in the set is unique, but the score Score of the associated member can be repeated. Redis sorts the members in the set from large to small by score.

[0115] (3) Data initialization:

[0116] Synchronize the account balance in the account information table to hotspot_account_currentbalanace.

[0117] Combination of the process of entry operation Figure 4 and Figure 5 Provide explanation. Figure 4 A schematic diagram of storing the changed shadow account and the current timestamp into the hotspot identifier. Figure 5 A schematic diagram of storing account entry information in an entry flow table.

[0118] Figure 4 In the process of account entry, the shadow account and the current timestamp changed are stored in the hotspot account identifier (hotspot_account) to obtain the account entry information.

[0119] Figure 4 In the example, ThreadA, ThreadB, and ThreadC refer to multiple operations that modify the balance coming in at the same time;

[0120] Score and member are special terms in the ZSet data structure in redis;

[0121] In Redis, a sorted set (ZSET) is an ordered data structure. Each element in a ZSET is a tuple consisting of a unique member (member) and an associated score (score). Specifically:

[0122] score is a floating point value that indicates the ranking weight of the member. Redis sorts the members in ZSET according to the scores, with members with smaller scores at the front and members with larger scores at the back.

[0123] member is the only element in ZSET and can be any string;

[0124] In this way, ZSET can be used to implement functions such as leaderboards and priority queues, because it can efficiently sort and query elements by score.

[0125] Figure 5 In the process, the account entry information is stored in the entry flow table and set to the pending entry status. The account entry information in the entry flow table is batch processed and set to the entered status. When the transaction first comes in, it is in the pending entry status. After the batch processing is summarized, it is changed to the entered status to complete the entry process. For details on batch processing, see Figure 7 The balance replenishment process.

[0126] Figure 5 In the table, SeqNo is the sequence number; AccountNo is the operation account; DebitType is the debit type; Amt is the amount; and State is the state.

[0127] The process of the withdrawal operation is as follows Figure 6 shown.

[0128] Figure 6 In the process, the amount of the account ID corresponding to hotspot_account_currentbalanace is deducted to determine whether the amount after deduction is greater than or equal to 0. If the amount after deduction is greater than or equal to 0, the account outgoing information is obtained, the account outgoing information is recorded in the outgoing flow table, and the deduction success information is returned. If the amount after deduction is less than 0, the message of insufficient amount and transaction failure is directly returned.

[0129] The process of balance replenishment operation is as follows Figure 7 shown.

[0130] Figure 7 , query the data in the hotspot account cache;

[0131] Perform a for loop on the obtained account list, and each loop is an independent transaction;

[0132] At the beginning of the loop, the processing account row is locked and the data to be recorded is queried from the recording flow table;

[0133] Determine whether there is a transaction in the account entry flow table;

[0134] If there is no transaction in the account entry table, it means that the account only has an outgoing transaction record and failed due to insufficient balance. You only need to correct the redis data and perform the step of determining whether the current cache balance is greater than or equal to 0.

[0135] If there is a transaction in the account entry flow table, the amount data in all the transaction flows to be entered for this account will be summarized and updated to the account information table, and a transfer record will be recorded in the account record table, and the record status of the account entry flow table will be updated at the same time;

[0136] If the total amount is less than or equal to 0, the step of determining whether the current cache balance is greater than or equal to 0 is executed; if the total amount is greater than 0, the total amount is atomically added to the cache account balance of redis, and the step of determining whether the current cache balance is greater than or equal to 0 is executed; atomic addition is an operation of redis, which represents the amount to be added at a time, and the operation command is ZINCRBY;

[0137] Determine whether the current cache balance is greater than or equal to 0;

[0138] If the current cache balance is greater than or equal to 0, check the score of the account in hostspot_account, that is, the time of the last entry. If the timestamp in the score differs from the current time by more than 10 seconds, the account can be deleted.

[0139] If the current cache balance is less than 0, query the newly added unrecorded data in the account entry flow table and determine whether there is any flow in the account entry flow table;

[0140] If there is a transaction in the account entry flow table, the amount data in all the transaction flows to be entered for this account will be summarized and updated to the account information table, and a transfer record will be recorded in the account record table. At the same time, the record status of the account entry flow table will be updated, and the balance in the current account information table will be updated to the cached account balance. Check the score of this account in hostspot_account, that is, the time of the last entry. If the difference between the timestamp in the score and the current time is greater than 10 seconds, the account can be deleted.

[0141] If there is no transaction in the transaction table, update the balance in the current account information table to the cached account balance, check the score of the account in hostspot_account, that is, the time of the last transaction. If the timestamp in the score differs from the current time by more than 10 seconds, the account can be deleted.

[0142] Count the unrecorded transactions in the account transaction table, obtain the summary amount corresponding to the unrecorded transactions, update the summary amount corresponding to the unrecorded transactions to the balance table, and update the data in the balance table to the cache account balance identifier (hotspot_account_currentbalanace).

[0143] Since redis itself is only used for balance control, when the redis cluster is abnormal or down and the key cannot be read, the original update logic can be used to downgrade the cache. When the cache cluster is detected to be abnormal or the identifier (such as the hot account identifier or the cache account balance identifier, etc.) cannot be read, the cache is downgraded through the update logic; the update logic is the logic for modifying the data in the database table. Figure 8 The accounting logic shown. Figure 8 A schematic diagram showing cache degradation is shown.

[0144] Cache shutdown / abnormal means that the Redis cluster is unavailable and cannot provide services normally.

[0145] hotspot_account is the hotspot account. Figure 8 The expression is that there is a redis key called hotspot_account, where member records the account and score records the most recent operation time of the account;

[0146] SeqNo is the detailed serial number (i.e. the primary key of the table);

[0147] AccountNo is the account number;

[0148] DebitType is the accounting method (INCR for deposit, DECR for withdrawal);

[0149] Amt is the amount;

[0150] State is the status (0 means pending, 1 means already credited);

[0151] TransSeqNo is the serial number for entry (the serial number for actual transfer of money during delayed entry of batches, generally the core serial number).

[0152] Assume that there is an existing account A with a balance of 100 yuan, and now there is a -50 operation on account A. Then the implementation method is:

[0153] update account setbanlance=balance-50where account_no=A;

[0154] The update method is the most basic accounting processing method. Once redis cannot be used, the transformation plan cannot be implemented, and it is necessary to return to the most original update method to operate the account.

[0155] The transformation of channel payment hotspot accounts has now completed the test environment stress test. The applicant has learned through experiments that when the database CPU usage is high, the single account transfer TPS can be increased from 90 to 240, and the number of times the core transfer interface is sent is reduced by 90%, greatly improving the transaction capacity.

[0156] Other in-bank systems, whether they are channel systems or core systems that can directly operate accounts, can refer to the above solutions for construction when encountering hot accounts, but at the same time, they should also prepare redis downgrade and circuit breaker response plans for their own usage scenarios to avoid affecting normal trading business. The goal is to increase the maximum concurrency of system business, provide favorable support for the development of business, and create value for business.

[0157] In the embodiment of the present application, the hotspot account is used as the entity account, and the balance of the entity account is dispersed into multiple pre-created shadow accounts, which can reduce the number of times a single account is locked, thereby improving the overall processing efficiency and system throughput of the system. In addition, in the process of account transactions among multiple shadow accounts, through a channel that meets the preset channel constraint conditions, that is, the channel end applies for a separate internal account, that is, a shadow account, as the only channel to use the shadow account, add a cache accounting and summary detailed accounting processing method to each shadow account, optimize the transfer logic between accounts, reduce the occurrence of a single huge core hotspot, and achieve the goal of improving the user experience while ensuring the safety of funds, and reduce the pressure on the core accounting system, thereby avoiding the situation where the hotspot account reduces the processing capacity and efficiency of the entire system.

[0158] Based on the above real-time Figure 1 A data processing method for hotspot accounts is disclosed, and an embodiment of the present application also discloses a data processing device for hotspot accounts, such as Fig. 9 As shown, the data processing device for hotspot accounts includes:

[0159] The acquisition unit 901 is used to use the hotspot account as an entity account and obtain the balance of the entity account;

[0160] A dispersing unit 902 is used to disperse the balance of the entity account into a plurality of pre-created shadow accounts; wherein the shadow account is a sub-account that is bound to the entity account;

[0161] The accounting unit 903 is used to perform cache accounting and summary detailed accounting of account balances between multiple shadow accounts through channels that meet preset channel constraints during account transactions among multiple shadow accounts; wherein account transactions at least include entry operations, exit operations, or balance replenishment operations; and the preset channel constraints are constraints that specify that all transactions of multiple shadow accounts be accounted for in a single channel.

[0162] Furthermore, a dispersing unit 902 for creating a shadow account is specifically used to disperse the hotspot account to obtain multiple shadow accounts; wherein the data structure of the multiple shadow accounts is consistent with the data structure of the hotspot account.

[0163] Furthermore, the accounting unit 903 is specifically used to perform accounting operations of account balances between multiple shadow accounts through channels that meet preset constraints, as well as cache the amount in the database for periodic asynchronous refresh and delayed batch transaction entry during the process of performing entry operations, exit operations or balance replenishment operations on multiple shadow accounts, and to update the summary detailed accounting of the balance by periodically asynchronously aggregating multiple shadow account transactions.

[0164] Furthermore, the data processing device for the hotspot account also includes:

[0165] The adding unit is used to add the hotspot account identifier and the cache account balance identifier in the cache.

[0166] Furthermore, the data processing device for the hotspot account also includes:

[0167] The update unit is used to downgrade the cache through the update logic when it is detected that the cache cluster is abnormal or the identifier cannot be read; the update logic is the logic for modifying the data in the database table.

[0168] Furthermore, the accounting unit 903 of the entry operation includes:

[0169] A first storage module is used to store the shadow account and the current timestamp changed during the account entry process into the hotspot account identifier to obtain the account entry information;

[0170] The second storage module is used to store the account entry information in the entry flow table and set the pending entry status, batch process the account entry information in the entry flow table, and set the entered status to complete the entry operation process.

[0171] Furthermore, the accounting unit 903 of the payment operation includes:

[0172] The third storage module is used to store the shadow account and the current timestamp changed during the account withdrawal process into the hotspot account identifier, and deduct the amount from the account ID corresponding to the hotspot account identifier;

[0173] A judgment module is used to judge whether the amount after deduction is greater than or equal to 0;

[0174] The generation module is used to generate a message indicating insufficient amount if the amount after deduction is less than 0.

[0175] Furthermore, the accounting unit 903 for the balance replenishment operation includes:

[0176] The statistics acquisition module is used to count the unrecorded transactions in the account transaction table and obtain the summary amount corresponding to the unrecorded transactions;

[0177] The first updating module is used to update the summary amount corresponding to the unrecorded transaction into the balance table;

[0178] The second updating module is used to update the data in the balance table to the cache account balance identifier.

[0179] In the embodiment of the present application, the hotspot account is used as the entity account, and the balance of the entity account is dispersed into multiple pre-created shadow accounts, which can reduce the number of times a single account is locked, thereby improving the overall processing efficiency and system throughput of the system. In addition, in the process of account transactions among multiple shadow accounts, through a channel that meets the preset channel constraint conditions, that is, the channel end applies for a separate internal account, that is, a shadow account, as the only channel to use the shadow account, add a cache accounting and summary detailed accounting processing method to each shadow account, optimize the transfer logic between accounts, reduce the occurrence of a single huge core hotspot, and achieve the goal of improving the user experience while ensuring the safety of funds, and reduce the pressure on the core accounting system, thereby avoiding the situation where the hotspot account reduces the processing capacity and efficiency of the entire system.

[0180] An embodiment of the present application further provides a storage medium, which includes stored instructions, wherein when the instructions are executed, the device where the storage medium is located is controlled to execute the data processing method for the hotspot account as described above.

[0181] The present application also provides an electronic device, whose structural diagram is as follows: Fig.10 As shown, it specifically includes a memory 1001 and one or more instructions 1002, wherein the one or more instructions 1002 are stored in the memory 1001 and are configured to be executed by one or more processors 1003 to execute the one or more instructions 1002 to perform the above-mentioned data processing method for the hotspot account.

[0182] For the aforementioned method embodiments, for the sake of simplicity, they are all described as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the order of the actions described, because according to the present application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0183] It should be noted that each embodiment in this specification is described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same or similar parts between the embodiments can be referred to each other. For the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0184] The steps in the methods of the embodiments of the present application can be adjusted in order, combined, and deleted according to actual needs.

[0185] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are merely used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations.

[0186] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

[0187] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A data processing method for hotspot accounts, characterized in that: The method comprises: Treat the hotspot account as an entity account and obtain the balance of the entity account; Distribute the balance of the entity account into multiple pre-created shadow accounts; wherein the shadow account is a sub-account that has a binding relationship with the entity account; In the process of account transactions among multiple shadow accounts, cache accounting and summary detailed accounting of account balances are performed between the multiple shadow accounts through channels that meet preset channel constraints; wherein the account transactions at least include entry operations, exit operations or balance replenishment operations; the preset channel constraints are constraints for multiple shadow accounts, specifying that all transactions of the shadow accounts are accounted for in a single channel.

2. The method according to claim 1, characterized in that The process of creating a shadow account includes: The hotspot account is broken up to obtain a plurality of shadow accounts; wherein the data structure of the plurality of shadow accounts is consistent with the data structure of the hotspot account.

3. The method according to claim 1, characterized in that In the process of account transactions among multiple shadow accounts, cache accounting and summary detailed accounting of account balances are performed between multiple shadow accounts through channels that meet preset channel constraints, including: During the process of multiple shadow accounts performing entry operations, exit operations or balance replenishment operations, account balance accounting operations are performed between multiple shadow accounts through channels that meet preset constraints, as well as by caching the amounts in the database through timed asynchronous refresh and delayed batch transaction entry, and the summary detailed accounting of the balance is updated by timed asynchronous aggregation of multiple shadow account transactions.

4. The method according to claim 1, characterized in that Also includes: Add the hotspot account ID and cache account balance ID to the cache.

5. The method according to claim 4, characterized in that Also includes: When it is detected that the cache cluster is abnormal or the identifier cannot be read, the cache is downgraded through the update logic; the update logic is the logic for modifying the data in the database table.

6. The method according to claim 1, characterized in that The process of bookkeeping operation includes: The shadow account and current timestamp changed during the account entry process are stored in the hotspot account identifier to obtain the account entry information; The account entry information is stored in the entry flow table and set to a pending entry state, the account entry information in the entry flow table is batch processed, and the entry state is set to complete the entry operation process.

7. The method according to claim 1, characterized in that The process of the withdrawal operation includes: The shadow account and current timestamp changed during the account withdrawal process are stored in the hotspot account identifier, and the amount is deducted from the account ID corresponding to the hotspot account identifier; Determine whether the amount after deduction is greater than or equal to 0; If the amount after deduction is greater than or equal to 0, generate account outgoing information, record the account outgoing information in the outgoing flow table, and return the successful deduction information; If the amount after deduction is less than 0, a message indicating insufficient amount is generated.

8. The method according to claim 1, characterized in that The process of balance replenishment operation includes: Count the unrecorded transactions in the account transaction table and obtain the corresponding summary amount of the unrecorded transactions; Update the summary amount corresponding to the unrecorded transaction into the balance table; Update the data in the balance table to the cache account balance identifier.

9. A data processing device for hotspot accounts, characterized in that: The device comprises: An acquisition unit, used to treat the hotspot account as an entity account and obtain the balance of the entity account; A dispersing unit, used to disperse the balance of the entity account into a plurality of pre-created shadow accounts; wherein the shadow account is a sub-account that has a binding relationship with the entity account; An accounting unit is used to perform cache accounting and summary detailed accounting of account balances between multiple shadow accounts through channels that meet preset channel constraints during account transactions among multiple shadow accounts; wherein account transactions at least include entry operations, exit operations, or balance replenishment operations; and the preset channel constraints are constraints that specify accounting for all transactions of multiple shadow accounts in a single channel.

10. The device according to claim 9, characterized in that Create decentralized units of shadow accounts, specifically for: The hotspot account is broken up to obtain a plurality of shadow accounts; wherein the data structure of the plurality of shadow accounts is consistent with the data structure of the hotspot account.

Images