Distributed-based dynamic quota allocation system

Abstract

The application provides a kind of dynamic quota allocation system based on distribution, comprising: sub-account management module: create several sub-accounts and be associated with hot spot account, sub-account includes a basic account and auxiliary account for auxiliary payment, and each sub-account can be managed and dynamically configured separately;Transaction routing module: the routing information of sub-account and the information of transaction carrying capacity are stored in the distributed cache component of this module, and are maintained;Sub-account transaction module: responsible for specific transaction, parameter verification and state verification are carried out when receiving transaction request;Asynchronous processing module: check the current sub-account balance, uniformly dispatch quota to execute allocation task;Timing scheduling module: check the routing information of all sub-accounts, check the auxiliary account suspended transaction.The application can ensure that each account meets continuous business service, and has good support capability for large amount of deduction business.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically, to a distributed dynamic quota allocation system. Background Technology

[0002] In high-concurrency business scenarios, there are situations where a single account engages in frequent fund transfers with other accounts within a short period. In this scenario, a fast transaction response time is crucial to ensure efficient operation. However, this single account, acting as the hotspot for transactions, often becomes the performance bottleneck of the system.

[0003] In this scenario, even with excess system resources, the strong consistency constraint on funds within a single account means all related transactions can only be executed linearly, limiting transaction efficiency. Furthermore, it's difficult to scale up business load capacity using traditional technologies. Simply splitting popular accounts would have two consequences: firstly, it would reduce the capacity to handle large deductions; secondly, the uncertainty of transaction amounts and directions would make it impossible to guarantee that the split accounts would always have sufficient funds to meet the needs of continuous business services. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a distributed dynamic quota allocation system.

[0005] According to the present invention, a distributed dynamic quota allocation system is provided, the scheme of which is as follows:

[0006] A distributed dynamic quota allocation system includes:

[0007] Sub-account management module: Create several sub-accounts and associate them with hot accounts. Each sub-account contains a basic account and an auxiliary account for payment assistance. Each sub-account can be managed and dynamically configured separately.

[0008] Transaction routing module: This module stores and maintains the routing information and transaction capacity information of sub-accounts in its distributed cache component.

[0009] Sub-account transaction module: responsible for accepting specific transactions, and performing parameter verification and status verification when receiving transaction requests;

[0010] Asynchronous processing module: Checks the current sub-account balance and uniformly schedules the allocation task;

[0011] Scheduled module: Verify the routing information of all sub-accounts and check auxiliary accounts with suspended transactions.

[0012] Preferably, the sub-account management module includes: sub-account status management and sub-account parameter management. The status of each sub-account can be managed independently, including relevant statuses such as pending activation, deactivated, canceled, and normal. At the same time, the sub-account is also controlled by the overall status of the hot account. When a new sub-account is added, the status of a sub-account changes, or the entire hot account is canceled, the routing information will be changed through the transaction routing module to prevent transactions from being sent to unavailable sub-accounts.

[0013] Preferably, the sub-account parameter management includes: configuring parameters for each hot account, including the quota allocation range and minimum transaction capacity of each auxiliary account; the double safety limit and alarm limit of the basic account; the quota allocation frequency limit and large transaction threshold of the hot account itself.

[0014] Preferably, the transaction routing module includes: routing information update and transaction route selection. When a transaction occurs, if the transaction amount exceeds the threshold for large transactions, the routing information of the basic account is returned directly. Otherwise, the unique function of the cached data structure is used to randomly select a sub-account whose transaction carrying capacity is greater than the transaction amount and return its routing information.

[0015] Preferably, the asynchronous processing module includes asynchronous allocation checking and asynchronous allocation execution;

[0016] Among them, the asynchronous transfer check is mainly responsible for checking whether the balance of the current sub-account needs to be sent a transfer request message after a specific transaction, as well as synchronizing routing information;

[0017] The asynchronous allocation execution is mainly responsible for receiving quota allocation request messages and uniformly scheduling quota allocation tasks.

[0018] The sub-account transaction module adjusts the sub-account limit by increasing or decreasing it after verification, and triggers asynchronous transfer checks at the same time.

[0019] Preferably, the asynchronous transfer check process includes:

[0020] Step 1: Query the balance of the sub-account currently handling the transaction from the database;

[0021] Step 2: Update the balance cache in the distributed caching component;

[0022] Step 3: Update the transaction carrying capacity information of the corresponding route in the distributed caching component;

[0023] Step 4: Determine if the sub-account has passed the cooling-off period. If it has not passed the cooling-off period, end this process; otherwise, proceed to the next step.

[0024] Step 5: Determine the current sub-account type: If it is a basic account, proceed to step 6; if it is a secondary account, proceed to step 7.

[0025] Step 6: Basic Account Asynchronous Transfer Check Process, including the following steps:

[0026] Step 6.1: Query relevant configuration information through the distributed caching component. If the query fails, the entire process ends.

[0027] Step 6.2: Determine if the current balance is lower than the alarm limit. If the current balance is lower than the alarm limit, proceed to step 6.3; otherwise, proceed to step 6.5.

[0028] Step 6.3: Determine whether the cooling-off period for the alarm behavior of this sub-account has expired. If the alarm cooling-off period has expired, proceed to step 6.4; otherwise, proceed to step 6.5.

[0029] Step 6.4: Send an insufficient balance alarm message to the administrator through the distributed message queue component;

[0030] Step 6.5: Determine if the balance is lower than the emergency collection limit. If the balance is lower than the emergency collection limit, proceed to step 6.6; otherwise, proceed to step 6.7.

[0031] Step 6.6: Send an emergency aggregation request message to the asynchronous dispatch execution function through the distributed message queue component, and end the overall process;

[0032] Step 6.7: Determine if the balance is lower than the normal collection limit. If the balance is lower than the normal collection limit, proceed to step 6.8; otherwise, end the entire process.

[0033] Step 6.8: Send a normal collection request message to the asynchronous dispatch execution function through the distributed message queue component, and end the overall process;

[0034] Step 7: Auxiliary account asynchronous transfer check process, including the following steps:

[0035] Step 7.1: Query relevant configuration information through the distributed caching component. If the query fails, the overall process ends.

[0036] Step 7.2: Determine if the current sub-account balance is lower than the suspended credit limit. If the sub-account balance is lower than the suspended credit limit, proceed to step 7.3; otherwise, proceed to step 7.5.

[0037] Step 7.3: Change the status of the auxiliary account to disabled using the sub-account status management function;

[0038] Step 7.4: Send an auxiliary account recovery request message to the asynchronous dispatch execution function through the distributed message queue component, and end the overall process;

[0039] Step 7.5: Determine if the current balance is lower than the transfer limit. If the balance is lower than the transfer limit, proceed to step 7.6; otherwise, proceed to step 7.7.

[0040] Step 7.6: Send an auxiliary account scheduling request message to the asynchronous dispatch execution function through the distributed message queue component, and end the overall process;

[0041] Step 7.7: Determine if the current balance is higher than the withdrawal limit. If the balance is higher than the withdrawal limit, proceed to step 7.8; otherwise, end the entire process.

[0042] Step 7.8: Send an auxiliary account scheduling request message to the asynchronous dispatch execution function through the distributed message queue component, and end the overall process.

[0043] Preferably, the asynchronous allocation execution includes two modes: one is the single allocation mode, which executes auxiliary account allocation requests and auxiliary account recovery requests; the other is the batch allocation mode, which automatically switches from the single allocation mode to the batch allocation mode when a normal collection request or an emergency collection request is received; if the current system is already in the batch allocation mode, it means that there is already an ongoing batch allocation task, and the current batch allocation request is discarded to prevent task conflicts or duplicate execution.

[0044] Preferably, the asynchronous allocation execution process includes:

[0045] Step 1: Receive a transfer request message from the distributed message queue;

[0046] Step 2: Determine if it is a batch transfer request. If it is a batch transfer request, proceed to Step 3; otherwise, proceed to Step 4.

[0047] Step 3: Switch the hot account transfer mode to batch transfer. If the switch fails, the process ends. If successful, proceed to Step 4.

[0048] Step 4: Determine the transfer type. If it is an emergency collection of basic account funds, proceed to Step 5. If it is a normal collection of basic account funds, proceed to Step 6. If it is a transfer of auxiliary account quota, proceed to Step 7. If it is a recovery transfer of auxiliary account funds, proceed to Step 8.

[0049] Step 5: Basic Account Emergency Aggregation Task Generation Process:

[0050] Step 5.1: Determine if the transfer mode is batch transfer mode. If not, end the process.

[0051] Step 5.2: Query all associated auxiliary accounts and generate a batch full collection task, then proceed to step 9;

[0052] Step 6: Basic Account General Collection Task Generation Process:

[0053] Step 6.1: Determine if the transfer mode is batch transfer mode. If not, end the process.

[0054] Step 6.2: Query the balance and configuration of all associated auxiliary accounts in the cache;

[0055] Step 6.3: Calculate the transfer amount based on the lower limit of the quota allocation for each auxiliary account and the current quota, generate a batch ordinary collection task, and then proceed to step 9;

[0056] Step 7: Auxiliary Account Quota Transfer Task Generation Process:

[0057] Step 7.1: Determine if the transfer mode is a single transfer mode. If not, end the process.

[0058] Step 7.2: Query the balance and configuration of the auxiliary account in the cache;

[0059] Step 7.3: Based on the auxiliary account's credit limit allocation range and the current credit limit, calculate the required transfer-out / transfer-in amount and generate a single transfer-in / transfer-out task; when transferring in an amount, the target amount after the transfer should be a certain percentage higher than the lower limit of the auxiliary account's credit limit allocation; when transferring out an amount, the target amount after the transfer should be a certain percentage lower than the upper limit of the auxiliary account's credit limit allocation to avoid excessively frequent transfers; if a single transfer-out task is generated, proceed directly to Step 9; otherwise, proceed to Step 7.4.

[0060] Step 7.4: For a single transfer task, determine whether the balance of the basic account is greater than the ordinary collection limit. If the balance of the basic account is greater than the ordinary collection limit, proceed to step 9; otherwise, end the overall process.

[0061] Step 8: Auxiliary Account Recovery Transfer Task Generation Process:

[0062] Step 8.1: Determine if the transfer mode is a single transfer mode. If not, end the process.

[0063] Step 8.2: Query the balance and configuration of the auxiliary account in the cache;

[0064] Step 8.3: Determine whether the current balance of the auxiliary account meets the conditions for activation. If it does, proceed to step 8.4; otherwise, proceed to step 8.5.

[0065] Step 8.4: Use the sub-account status management function to set the status of the auxiliary account to normal, and end the overall process;

[0066] Step 8.5: Calculate the amount to be transferred in based on the allocation range of the auxiliary account and the current quota, and generate a single transfer task; when transferring in the amount, the target amount after the transfer should be a certain percentage higher than the lower limit of the auxiliary account quota allocation to avoid too frequent transfers;

[0067] Step 8.6: Determine if the balance of the basic account is greater than the ordinary collection limit. If the balance of the basic account is greater than the ordinary collection limit, proceed to step 9; otherwise, end the entire process.

[0068] Step 9: Start processing the transfer task and determine the transfer task type: If it is a batch full collection task, proceed to step 10; if it is a batch ordinary collection task, proceed to step 11; if it is an auxiliary account recovery task, proceed to step 12; if it is a single transfer in / out task, proceed to step 13.

[0069] Step 10: Batch Full Amount Collection Task Processing Flow:

[0070] Step 10.1: Determine if the transfer mode is batch transfer mode. If not, end the process.

[0071] Step 10.2: Use the sub-account status management function to disable all auxiliary accounts;

[0072] Step 10.3: Concurrently transfer the full balance of all auxiliary accounts to the basic account, then proceed to Step 14;

[0073] Step 11: Batch ordinary data collection task processing flow:

[0074] Step 11.1: Determine if the transfer mode is batch transfer mode. If not, end the process.

[0075] Step 11.2: Based on the transfer amount calculated in Step 6, concurrently execute the transfer of funds from the auxiliary account to the basic account, and proceed to Step 14;

[0076] Step 12: Auxiliary Account Recovery Task Processing Procedure:

[0077] Step 12.1: Determine if the transfer mode is a single transfer mode. If not, end the process.

[0078] Step 12.2: Execute the fund transfer operation in the auxiliary account. If successful, proceed to step 12.3; otherwise, proceed to step 14.

[0079] Step 12.3: Use the sub-account status management function to set the status of this auxiliary account to normal, and proceed to step 14;

[0080] Step 13: Single Inbound / Outbound Task Processing Flow:

[0081] Step 13.1: Determine if the transfer mode is a single transfer mode. If not, end the process.

[0082] Step 13.2: Execute a single fund transfer in / out of the auxiliary account, proceed to step 14;

[0083] Step 14: Determine whether the transfer mode has been switched to batch transfer mode before this operation. If the transfer mode has been switched, proceed to step 15; otherwise, end the process.

[0084] Step 15: Switch the transfer mode back to single transfer mode and end the process.

[0085] Preferably, the timed scheduling module includes a route check timer and a sub-account availability check timer, both of which run once every 10 minutes, with staggered start times.

[0086] Preferably, the routing check timer will fully verify whether the routing information of all sub-accounts of all hot accounts is correct, including the completeness of the routing information, the accuracy of the mapping relationship between the sub-account status and the routing information, without changing the transaction carrying capacity information of the sub-accounts;

[0087] The sub-account availability check timer is responsible for checking all auxiliary accounts that have suspended trading due to their quota being less than the minimum transaction capacity. It determines the overall quota status of the corresponding hot accounts to decide whether to send a quota allocation message to the asynchronous processing module through the distributed message queue to request the auxiliary account to resume trading. If the quota allocation is successful, the auxiliary account status is changed through the sub-account status management function to restore its ability to accept external transactions.

[0088] Compared with the prior art, the present invention has the following beneficial effects:

[0089] 1. This invention divides popular accounts into sub-accounts that run independently in a distributed service and can independently handle transactions.

[0090] 2. In the transaction forwarding service, each transaction can be sent to a sub-account service that is sufficient to handle the transaction, based on the transaction amount and routing information.

[0091] 3. The system includes a sub-account management service that dynamically monitors and allocates credit limits to ensure these accounts can provide continuous business services. In cases of relatively or absolutely insufficient credit limits, this service can also concentrate credit limits by closing some or all auxiliary accounts, providing excellent support for large-amount deductions.

[0092] Other beneficial effects of the present invention will be explained in detail through the introduction of specific technical features and technical solutions in specific embodiments. Those skilled in the art should be able to understand the beneficial technical effects brought about by these technical features and technical solutions through the introduction of these technical features and technical solutions. Attached Figure Description

[0093] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0094] Figure 1 This is a schematic diagram of the overall system of the present invention;

[0095] Figure 2 This is a diagram illustrating the size relationship of the configuration items;

[0096] Figure 3 This is a flowchart illustrating the specific functions of the asynchronous processing module.

[0097] Figure 4 This is a flowchart illustrating the specific processing steps for the asynchronous dispatch execution function. Detailed Implementation

[0098] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.

[0099] This invention provides a distributed dynamic quota allocation system, referring to... Figure 1 As shown, the system specifically includes the following:

[0100] Sub-account management module: Create several sub-accounts and associate them with hot accounts. Each sub-account contains a basic account and an auxiliary account for payment assistance. Each sub-account can be managed and dynamically configured separately.

[0101] The sub-account management module includes: sub-account status management and sub-account parameter management. The status of each sub-account can be managed independently, including related statuses such as pending activation, deactivated, canceled, and normal. At the same time, sub-accounts are also controlled by the overall status of hot accounts. When a new sub-account is added, the status of a sub-account changes, or the entire hot account is canceled, the routing information will be changed through the transaction routing module to prevent transactions from being sent to unavailable sub-accounts.

[0102] Sub-account parameter management includes: configuring parameters for each hot account, including the quota allocation range and minimum transaction limit for each auxiliary account; the double safety limit and alarm limit for the basic account; the quota allocation frequency limit and the starting value for large transactions for the hot account itself.

[0103] Transaction Routing Module: This module stores and maintains the routing information and transaction capacity information of sub-accounts in its distributed cache component. The module includes routing information updates and transaction route selection. When a transaction occurs, if the transaction amount exceeds the large transaction threshold, the routing information of the primary account is returned directly. Otherwise, using the unique function of the cached data structure, a sub-account with a transaction capacity greater than the transaction amount is randomly selected, and its routing information is returned.

[0104] Sub-account transaction module: Responsible for receiving specific transactions, performing parameter and status verification upon receiving a transaction request. After successful verification, the sub-account transaction module increases or decreases the sub-account limit, and simultaneously triggers asynchronous transfer checks.

[0105] Asynchronous processing module: Checks the current sub-account balance and uniformly schedules the allocation task. The asynchronous processing module includes asynchronous allocation check and asynchronous allocation execution; among them, the asynchronous allocation check is mainly responsible for checking whether the current sub-account balance needs to send an allocation request message after a specific transaction, and synchronizing routing information.

[0106] The asynchronous allocation execution is mainly responsible for receiving quota allocation request messages and uniformly scheduling quota allocation tasks.

[0107] Asynchronous allocation execution includes two modes: single allocation mode, which executes auxiliary account allocation requests and auxiliary account recovery requests; and batch allocation mode, which automatically switches from single allocation mode to batch allocation mode when a normal or emergency allocation request is received. If the system is already in batch allocation mode, it means that there is already an ongoing batch allocation task, and the current batch allocation request is discarded to prevent task conflicts or duplicate execution.

[0108] The scheduled scheduling module verifies the routing information of all sub-accounts and checks auxiliary accounts with suspended transactions. This module includes a routing check timer and a sub-account availability check timer, both running every 10 minutes to avoid peak times. The routing check timer performs a full verification of the routing information for all sub-accounts of all hot accounts, ensuring the completeness of the routing information and the accuracy of the mapping between sub-account status and routing information, without altering the transaction capacity information of the sub-accounts.

[0109] The sub-account availability check timer is responsible for checking all auxiliary accounts that have suspended trading due to their quota being less than the minimum transaction capacity. It determines the overall quota status of the corresponding hot accounts to decide whether to send a quota allocation message to the asynchronous processing module through the distributed message queue to request the auxiliary account to resume trading. If the quota allocation is successful, the auxiliary account status is changed through the sub-account status management function to restore its ability to accept external transactions.

[0110] The present invention will now be described in more detail.

[0111] A distributed dynamic quota allocation system, referring to Figure 1 As shown, it includes:

[0112] The sub-account management module includes sub-account status management and sub-account parameter management functions. Several sub-accounts are created and associated with a hot transaction account within this module. Each sub-account contains one and only one basic account and auxiliary payment accounts. The status of each sub-account can be managed independently, including states such as pending activation, deactivated, canceled, and normal. Sub-accounts are also controlled by the overall status of the hot account. When a new sub-account is added, a sub-account status changes, or the entire hot account is canceled, the routing information will be updated through the transaction routing module's routing information update function to prevent transactions from being sent to unavailable sub-accounts. The sub-account parameter management function allows for parameter configuration for each hot account, including the quota allocation range and minimum transaction limit for each auxiliary account; the double safety net limit and alarm limit for the basic account; the quota allocation frequency limit for the hot account itself; and the large transaction threshold. The large transaction threshold will be used in the transaction routing module. All configuration values ​​are cached in a distributed caching component. The size relationship of each configuration item is as follows: Figure 2 As shown.

[0113] Transaction routing module: Includes routing information update function and transaction route selection function: The routing information of sub-accounts, including their transaction carrying capacity information, is stored in the distributed cache component and maintained through the routing information update function; When a transaction occurs, if the transaction amount exceeds the threshold for large transactions, the routing information of the basic account is returned directly; otherwise, the unique function of the cache data structure (ZSET) is used to quickly and randomly select a sub-account whose transaction carrying capacity is greater than the transaction amount and return its routing information.

[0114] Sub-account transaction module: responsible for the main specific transaction acceptance. When a transaction request is received, it performs necessary parameter verification, status verification, etc. After the verification is passed, it increases or decreases the sub-account limit and triggers the asynchronous transfer check function.

[0115] The asynchronous processing module includes asynchronous transfer check and asynchronous transfer execution functions. The asynchronous transfer check is primarily responsible for checking, after a specific transaction, whether the current sub-account balance requires a transfer request message, and synchronizing routing information. The specific functional flow is as follows: Figure 3 As shown, for ease of understanding, the following terms will be used:

[0116] ① Cooling-off period: refers to the period of time after a quota transfer occurs, during which the next quota transfer cannot be initiated due to the configured quota transfer frequency limit;

[0117] ②Suspension Limit: This refers to the minimum transaction limit of the auxiliary account. When the current limit of the auxiliary account is lower than the minimum transaction limit, it will be suspended until the sub-account availability check timer allocates enough limit to restore the status.

[0118] ③ Transfer out and transfer in credit: refers to the upper and lower limits of the credit allocation range for the auxiliary account. When the current credit limit of the auxiliary account is higher than the upper limit of the credit allocation, a portion of the balance will be transferred to the basic account. When the current credit limit of the auxiliary account is lower than the lower limit of the credit allocation, a portion of the credit limit will be transferred from the basic account to the auxiliary account, so that the credit limit of the auxiliary account can fall within the credit allocation range.

[0119] ④ Regular Collection Limit and Emergency Collection Limit: These refer to the dual safety net limits for the basic account. The regular collection limit is the first safety net. When the current limit of the basic account is lower than the regular collection limit, requests to transfer funds out of the basic account will no longer be responded to. At the same time, any portion of the current limit of all auxiliary accounts that is above the minimum allocation limit will be transferred to the basic account. When the current limit of the basic account is lower than the emergency collection limit, all associated auxiliary accounts will be deactivated through the sub-account status management function, and all balances will be transferred to the basic account.

[0120] The specific functional flow includes:

[0121] Step 1: Query the balance of the sub-account currently handling the transaction from the database;

[0122] Step 2: Update the balance cache in the distributed caching component;

[0123] Step 3: Update the transaction carrying capacity information of the corresponding route in the distributed caching component;

[0124] Step 4: Determine if the sub-account has passed the cooling-off period. If it has not passed the cooling-off period, end this process; otherwise, proceed to the next step.

[0125] Step 5: Determine the current sub-account type: If it is a basic account, proceed to step 6; if it is a secondary account, proceed to step 7.

[0126] Step 6: Basic Account Asynchronous Transfer Check Process, including the following steps:

[0127] Step 6.1: Query relevant configuration information through the distributed caching component, including double minimum guarantee limit, alarm-related configuration, etc. If the query fails, the overall process ends.

[0128] Step 6.2: Determine if the current balance is lower than the alarm limit. If the current balance is lower than the alarm limit, proceed to step 6.3; otherwise, proceed to step 6.5.

[0129] Step 6.3: Determine whether the cooling-off period for the alarm behavior of this sub-account has expired. If the alarm cooling-off period has expired, proceed to step 6.4; otherwise, proceed to step 6.5.

[0130] Step 6.4: Send an insufficient balance alarm message to the administrator through the distributed message queue component;

[0131] Step 6.5: Determine if the balance is lower than the emergency collection limit. If the balance is lower than the emergency collection limit, proceed to step 6.6; otherwise, proceed to step 6.7.

[0132] Step 6.6: Send an emergency aggregation request message to the asynchronous dispatch execution function through the distributed message queue component, and end the overall process;

[0133] Step 6.7: Determine if the balance is lower than the normal collection limit. If the balance is lower than the normal collection limit, proceed to step 6.8; otherwise, end the entire process.

[0134] Step 6.8: Send a normal collection request message to the asynchronous dispatch execution function through the distributed message queue component, and end the overall process;

[0135] Step 7: Auxiliary account asynchronous transfer check process, including the following steps:

[0136] Step 7.1: Query relevant configuration information through the distributed caching component, including the quota allocation range, minimum transaction capacity, etc. If the query fails, the overall process ends.

[0137] Step 7.2: Determine if the current sub-account balance is lower than the suspended credit limit. If the sub-account balance is lower than the suspended credit limit, proceed to step 7.3; otherwise, proceed to step 7.5.

[0138] Step 7.3: Change the status of the auxiliary account to disabled using the sub-account status management function;

[0139] Step 7.4: Send an auxiliary account recovery request message to the asynchronous dispatch execution function through the distributed message queue component, and end the overall process;

[0140] Step 7.5: Determine if the current balance is lower than the transfer limit. If the balance is lower than the transfer limit, proceed to step 7.6; otherwise, proceed to step 7.7.

[0141] Step 7.6: Send an auxiliary account scheduling request message to the asynchronous dispatch execution function through the distributed message queue component, and end the overall process;

[0142] Step 7.7: Determine if the current balance is higher than the withdrawal limit. If the balance is higher than the withdrawal limit, proceed to step 7.8; otherwise, end the entire process.

[0143] Step 7.8: Send an auxiliary account scheduling request message to the asynchronous dispatch execution function through the distributed message queue component, and end the overall process.

[0144] The asynchronous allocation execution function is primarily responsible for receiving quota allocation request messages and uniformly scheduling quota allocation tasks. This function has two modes: single-transfer mode, which can execute auxiliary account allocation requests and auxiliary account recovery requests; and batch transfer mode. When a normal or emergency collection request is received, the system will automatically switch from single-transfer mode to batch transfer mode. However, if the system is already in batch transfer mode, it means there is already an ongoing batch transfer task. To prevent task conflicts or duplicate execution, this batch transfer request will be discarded. The specific processing flow is as follows: Figure 4 As shown, for ease of understanding, the following terms will be used:

[0145] ① Allocation Request: Refers to all quota allocation requests received from the distributed message queue.

[0146] ② Batch transfer request: refers to ordinary collection requests and emergency collection requests issued by the basic account.

[0147] The specific functional flow includes:

[0148] Step 1: Receive a transfer request message from the distributed message queue;

[0149] Step 2: Determine if it is a batch transfer request. If it is a batch transfer request, proceed to Step 3; otherwise, proceed to Step 4.

[0150] Step 3: Switch the hot account transfer mode to batch transfer. If the switch fails, the process ends. If successful, proceed to Step 4.

[0151] Step 4: Determine the transfer type. If it is an emergency collection of basic account funds, proceed to Step 5. If it is a normal collection of basic account funds, proceed to Step 6. If it is a transfer of auxiliary account quota, proceed to Step 7. If it is a recovery transfer of auxiliary account funds, proceed to Step 8.

[0152] Step 5: Basic Account Emergency Aggregation Task Generation Process:

[0153] Step 5.1: Determine if the transfer mode is batch transfer mode. If not, end the process.

[0154] Step 5.2: Query all associated auxiliary accounts and generate a batch full collection task, then proceed to step 9;

[0155] Step 6: Basic Account General Collection Task Generation Process:

[0156] Step 6.1: Determine if the transfer mode is batch transfer mode. If not, end the process.

[0157] Step 6.2: Query the balance and configuration of all associated auxiliary accounts in the cache;

[0158] Step 6.3: Calculate the transfer amount based on the lower limit of the quota allocation for each auxiliary account and the current quota, generate a batch ordinary collection task, and then proceed to step 9;

[0159] Step 7: Auxiliary Account Quota Transfer Task Generation Process:

[0160] Step 7.1: Determine if the transfer mode is a single transfer mode. If not, end the process.

[0161] Step 7.2: Query the balance and configuration of the auxiliary account in the cache;

[0162] Step 7.3: Based on the auxiliary account's credit limit allocation range and the current credit limit, calculate the required transfer-out / transfer-in amount and generate a single transfer-in / transfer-out task. When transferring in an amount, the target amount after the transfer should be a certain percentage higher than the lower limit of the auxiliary account's credit limit allocation; when transferring out an amount, the target amount after the transfer should be a certain percentage lower than the upper limit of the auxiliary account's credit limit allocation to avoid excessively frequent transfers. If a single transfer-out task is generated, proceed directly to Step 9; otherwise, proceed to Step 7.4.

[0163] Step 7.4: For a single transfer task, determine whether the balance of the basic account is greater than the ordinary collection limit. If the balance of the basic account is greater than the ordinary collection limit, proceed to step 9; otherwise, end the overall process.

[0164] Step 8: Auxiliary Account Recovery Transfer Task Generation Process:

[0165] Step 8.1: Determine if the transfer mode is a single transfer mode. If not, end the process.

[0166] Step 8.2: Query the balance and configuration of the auxiliary account in the cache;

[0167] Step 8.3: Determine whether the current balance of the auxiliary account meets the conditions for activation. If it does, proceed to step 8.4; otherwise, proceed to step 8.5.

[0168] Step 8.4: Use the sub-account status management function to set the status of the auxiliary account to normal, and end the overall process;

[0169] Step 8.5: Based on the auxiliary account's credit limit allocation range and the current credit limit, calculate the required transfer amount and generate a single transfer task. When transferring the amount, the target amount after the transfer should be a certain percentage higher than the lower limit of the auxiliary account's credit limit allocation to avoid excessively frequent transfers.

[0170] Step 8.6: Determine if the balance of the basic account is greater than the ordinary collection limit. If the balance of the basic account is greater than the ordinary collection limit, proceed to step 9; otherwise, end the entire process.

[0171] Step 9: Start processing the transfer task and determine the transfer task type: If it is a batch full collection task, proceed to step 10; if it is a batch ordinary collection task, proceed to step 11; if it is an auxiliary account recovery task, proceed to step 12; if it is a single transfer in / out task, proceed to step 13.

[0172] Step 10: Batch Full Amount Collection Task Processing Flow:

[0173] Step 10.1: Determine if the transfer mode is batch transfer mode. If not, end the process.

[0174] Step 10.2: Use the sub-account status management function to disable all auxiliary accounts;

[0175] Step 10.3: Concurrently transfer the full balance of all auxiliary accounts to the basic account, then proceed to Step 14;

[0176] Step 11: Batch ordinary data collection task processing flow:

[0177] Step 11.1: Determine if the transfer mode is batch transfer mode. If not, end the process.

[0178] Step 11.2: Based on the transfer amount calculated in Step 6, concurrently execute the transfer of funds from the auxiliary account to the basic account, and proceed to Step 14;

[0179] Step 12: Auxiliary Account Recovery Task Processing Procedure:

[0180] Step 12.1: Determine if the transfer mode is a single transfer mode. If not, end the process.

[0181] Step 12.2: Execute the fund transfer operation in the auxiliary account. If successful, proceed to step 12.3; otherwise, proceed to step 14.

[0182] Step 12.3: Use the sub-account status management function to set the status of this auxiliary account to normal, and proceed to step 14;

[0183] Step 13: Single Inbound / Outbound Task Processing Flow:

[0184] Step 13.1: Determine if the transfer mode is a single transfer mode. If not, end the process.

[0185] Step 13.2: Execute a single fund transfer in / out of the auxiliary account, proceed to step 14;

[0186] Step 14: Determine whether the transfer mode has been switched to batch transfer mode before this operation. If the transfer mode has been switched, proceed to step 15; otherwise, end the process.

[0187] Step 15: Switch the transfer mode back to single transfer mode and end the process.

[0188] The timed scheduling module includes a route check timer and a sub-account availability check timer. Both timers run every 10 minutes, staggered to avoid peak times. The route check timer performs a full check of the routing information for all sub-accounts of all hot accounts to ensure its accuracy, including the completeness of the routing information and the accuracy of the mapping relationship between sub-account status and routing information. It does not change the transaction capacity information of sub-accounts. The sub-account availability check timer checks all auxiliary accounts that have suspended transactions due to their limits being less than the minimum transaction capacity limit. It assesses the overall limit situation of the corresponding hot accounts to determine whether to send a limit allocation request to the asynchronous processing module via a distributed message queue. If the limit allocation is successful, the auxiliary account status is changed through the sub-account status management function to restore its ability to accept transactions. From an overall system design perspective, this algorithm system is as follows: Figure 1 As shown.

[0189] This invention provides a distributed dynamic credit limit allocation system. By non-uniformly dividing frequently used accounts, each sub-account operates independently in a distributed service and can independently handle transactions. Simultaneously, in the transaction forwarding service, each transaction can be sent to a sub-account service sufficient to handle it based on the transaction amount and routing information. Furthermore, a sub-account governance service dynamically monitors and allocates credit limits to ensure these accounts can meet continuous business service needs. In cases of relatively or absolutely insufficient credit limits, this service can also concentrate credit limits by closing some or all auxiliary accounts, providing excellent support for large-amount deduction transactions.

[0190] Those skilled in the art will understand that, besides implementing the system and its various devices, modules, and units provided by this invention in the form of purely computer-readable program code, the same functions can be achieved entirely through logical programming of the method steps, making the system and its various devices, modules, and units of this invention function in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, the system and its various devices, modules, and units provided by this invention can be considered as a hardware component, and the devices, modules, and units included therein for implementing various functions can also be considered as structures within the hardware component; alternatively, the devices, modules, and units for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0191] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.

Claims

1. A distributed-based dynamic credit allocation system, characterized in that, include: Sub-account management module: Create several sub-accounts and associate them with hot accounts. Each sub-account contains a basic account and an auxiliary account for payment assistance. Each sub-account can be managed and dynamically configured separately. Transaction routing module: This module stores and maintains the routing information and transaction capacity information of sub-accounts in its distributed cache component. Sub-account transaction module: responsible for accepting specific transactions, and performing parameter verification and status verification when receiving transaction requests; Asynchronous processing module: Checks the current sub-account balance and uniformly schedules the allocation task; Scheduled scheduling module: Verify the routing information of all sub-accounts and check auxiliary accounts with suspended transactions; The sub-account parameter management includes: configuring parameters for each hot account, including the quota allocation range and minimum transaction limit for each auxiliary account; the double safety limit and alarm limit for the basic account; the quota allocation frequency limit and large transaction threshold for the hot account itself; The transaction routing module includes: routing information update and transaction route selection. When a transaction occurs, if the transaction amount exceeds the threshold for large transactions, the routing information of the basic account is returned directly. Otherwise, the unique function of the cached data structure is used to randomly select a sub-account whose transaction carrying capacity is greater than the transaction amount and return its routing information. The asynchronous processing module includes asynchronous allocation checking and asynchronous allocation execution; Among them, the asynchronous transfer check is mainly responsible for checking whether the balance of the current sub-account needs to be sent a transfer request message after a specific transaction, as well as synchronizing routing information; The asynchronous allocation execution is mainly responsible for receiving quota allocation request messages and uniformly scheduling quota allocation tasks. The sub-account transaction module increases or decreases the sub-account limit after verification, and triggers asynchronous transfer checks at the same time. The asynchronous allocation execution includes two modes: one is the single allocation mode, which executes auxiliary account allocation requests and auxiliary account recovery requests; the other is the batch allocation mode, which automatically switches from the single allocation mode to the batch allocation mode when a normal collection request or an emergency collection request is received. If the current system is already in the batch allocation mode, it means that there is already an ongoing batch allocation task, and the current batch allocation request is discarded to prevent task conflicts or duplicate execution.

2. The distributed-based dynamic credit allocation system of claim 1, wherein, The sub-account management module includes: sub-account status management and sub-account parameter management. The status of each sub-account can be managed independently, including related statuses such as pending activation, deactivated, canceled, and normal. At the same time, sub-accounts are also controlled by the overall status of hot accounts. When a new sub-account is added, the status of a sub-account changes, or the entire hot account is canceled, the routing information will be changed through the transaction routing module to prevent transactions from being sent to unavailable sub-accounts.

3. The distributed-based dynamic credit allocation system of claim 1, wherein, The asynchronous transfer check process includes: Step 1: Query the balance of the sub-account currently handling the transaction from the database; Step 2: Update the balance cache in the distributed caching component; Step 3: Update the transaction carrying capacity information of the corresponding route in the distributed caching component; Step 4: Determine if the sub-account has passed the cooling-off period. If it has not passed the cooling-off period, end this process; otherwise, proceed to the next step. Step 5: Determine the current sub-account type: If it is a basic account, proceed to step 6; if it is a secondary account, proceed to step 7. Step 6: Basic Account Asynchronous Transfer Check Process, including the following steps: Step 6.1: Query relevant configuration information through the distributed caching component. If the query fails, the entire process ends. Step 6.2: Determine if the current balance is lower than the alarm limit. If the current balance is lower than the alarm limit, proceed to step 6.3; otherwise, proceed to step 6.

5. Step 6.3: Determine whether the cooling-off period for the alarm behavior of this sub-account has expired. If the alarm cooling-off period has expired, proceed to step 6.4; otherwise, proceed to step 6.

5. Step 6.4: Send an insufficient balance alarm message to the administrator through the distributed message queue component; Step 6.5: Determine if the balance is lower than the emergency collection limit. If the balance is lower than the emergency collection limit, proceed to step 6.6; otherwise, proceed to step 6.

7. Step 6.6: Send an emergency aggregation request message to the asynchronous dispatch execution function through the distributed message queue component, and end the overall process; Step 6.7: Determine if the balance is lower than the normal collection limit. If the balance is lower than the normal collection limit, proceed to step 6.8; otherwise, end the entire process. Step 6.8: Send a normal collection request message to the asynchronous dispatch execution function through the distributed message queue component, and end the overall process; Step 7: Auxiliary account asynchronous transfer check process, including the following steps: Step 7.1: Query relevant configuration information through the distributed caching component. If the query fails, the overall process ends. Step 7.2: Determine if the current sub-account balance is lower than the suspended credit limit. If the sub-account balance is lower than the suspended credit limit, proceed to step 7.3; otherwise, proceed to step 7.

5. Step 7.3: Change the status of the auxiliary account to disabled using the sub-account status management function; Step 7.4: Send an auxiliary account recovery request message to the asynchronous dispatch execution function through the distributed message queue component, and end the overall process; Step 7.5: Determine if the current balance is lower than the transfer limit. If the balance is lower than the transfer limit, proceed to step 7.6; otherwise, proceed to step 7.

7. Step 7.6: Send an auxiliary account scheduling request message to the asynchronous dispatch execution function through the distributed message queue component, and end the overall process; Step 7.7: Determine if the current balance is higher than the withdrawal limit. If the balance is higher than the withdrawal limit, proceed to step 7.8; otherwise, end the entire process. Step 7.8: Send an auxiliary account scheduling request message to the asynchronous dispatch execution function through the distributed message queue component, and end the overall process.

4. The distributed-based dynamic credit allocation system of claim 1, wherein, The asynchronous allocation execution process includes: Step 1: Receive a transfer request message from the distributed message queue; Step 2: Determine if it is a batch transfer request. If it is a batch transfer request, proceed to Step 3; otherwise, proceed to Step 4. Step 3: Switch the hot account transfer mode to batch transfer. If the switch fails, the process ends. If successful, proceed to Step 4. Step 4: Determine the transfer type. If it is an emergency collection of basic account funds, proceed to Step 5. If it is a normal collection of basic account funds, proceed to Step 6. If it is a transfer of auxiliary account quota, proceed to Step 7. If it is a recovery transfer of auxiliary account funds, proceed to Step 8. Step 5: Basic Account Emergency Aggregation Task Generation Process: Step 5.1: Determine if the transfer mode is batch transfer mode. If not, end the process. Step 5.2: Query all associated auxiliary accounts and generate a batch full collection task, then proceed to step 9; Step 6: Basic Account General Collection Task Generation Process: Step 6.1: Determine if the transfer mode is batch transfer mode. If not, end the process. Step 6.2: Query the balance and configuration of all associated auxiliary accounts in the cache; Step 6.3: Calculate the transfer amount based on the lower limit of the quota allocation for each auxiliary account and the current quota, generate a batch ordinary collection task, and then proceed to step 9; Step 7: Auxiliary Account Quota Transfer Task Generation Process: Step 7.1: Determine if the transfer mode is a single transfer mode. If not, end the process. Step 7.2: Query the balance and configuration of the auxiliary account in the cache; Step 7.3: Based on the auxiliary account's credit limit allocation range and the current credit limit, calculate the required transfer-out / transfer-in amount and generate a single transfer-in / transfer-out task; when transferring in an amount, the target amount after the transfer should be a certain percentage higher than the lower limit of the auxiliary account's credit limit allocation; when transferring out an amount, the target amount after the transfer should be a certain percentage lower than the upper limit of the auxiliary account's credit limit allocation to avoid excessively frequent transfers; if a single transfer-out task is generated, proceed directly to Step 9; otherwise, proceed to Step 7.

4. Step 7.4: For a single transfer task, determine whether the balance of the basic account is greater than the ordinary collection limit. If the balance of the basic account is greater than the ordinary collection limit, proceed to step 9; otherwise, end the overall process. Step 8: Auxiliary Account Recovery Transfer Task Generation Process: Step 8.1: Determine if the transfer mode is a single transfer mode. If not, end the process. Step 8.2: Query the balance and configuration of the auxiliary account in the cache; Step 8.3: Determine whether the current balance of the auxiliary account meets the conditions for activation. If it does, proceed to step 8.4; otherwise, proceed to step 8.

5. Step 8.4: Use the sub-account status management function to set the status of the auxiliary account to normal, and end the overall process; Step 8.5: Calculate the amount to be transferred in based on the allocation range of the auxiliary account and the current quota, and generate a single transfer task; when transferring in the amount, the target amount after the transfer should be a certain percentage higher than the lower limit of the auxiliary account quota allocation to avoid too frequent transfers; Step 8.6: Determine if the balance of the basic account is greater than the ordinary collection limit. If the balance of the basic account is greater than the ordinary collection limit, proceed to step 9; otherwise, end the entire process. Step 9: Start processing the transfer task and determine the transfer task type: If it is a batch full collection task, proceed to step 10; if it is a batch ordinary collection task, proceed to step 11; if it is an auxiliary account recovery task, proceed to step 12; if it is a single transfer in / out task, proceed to step 13. Step 10: Batch Full Amount Collection Task Processing Flow: Step 10.1: Determine if the transfer mode is batch transfer mode. If not, end the process. Step 10.2: Use the sub-account status management function to disable all auxiliary accounts; Step 10.3: Concurrently transfer the full balance of all auxiliary accounts to the basic account, then proceed to Step 14; Step 11: Batch ordinary data collection task processing flow: Step 11.1: Determine if the transfer mode is batch transfer mode. If not, end the process. Step 11.2: Based on the transfer amount calculated in Step 6, concurrently execute the transfer of funds from the auxiliary account to the basic account, and proceed to Step 14; Step 12: Auxiliary Account Recovery Task Processing Procedure: Step 12.1: Determine if the transfer mode is a single transfer mode. If not, end the process. Step 12.2: Execute the fund transfer operation in the auxiliary account. If successful, proceed to step 12.3; otherwise, proceed to step 14. Step 12.3: Use the sub-account status management function to set the status of this auxiliary account to normal, and proceed to step 14; Step 13: Single Inbound / Outbound Task Processing Flow: Step 13.1: Determine if the transfer mode is a single transfer mode. If not, end the process. Step 13.2: Execute a single fund transfer in / out of the auxiliary account, proceed to Step 14; Step 14: Determine whether the transfer mode has been switched to batch transfer mode before this operation. If the transfer mode has been switched, proceed to step 15; otherwise, end the process. Step 15: Switch the transfer mode back to single transfer mode and end the process.

5. The distributed-based dynamic credit allocation system of claim 1, wherein, The timed scheduling module includes a route check timer and a sub-account availability check timer, both of which run once every 10 minutes, with staggered start times.

6. The distributed-based dynamic credit allocation system of claim 5, wherein, The routing check timer will fully verify the routing information of all sub-accounts of all hot accounts to ensure its accuracy, including the completeness of the routing information, the accuracy of the mapping relationship between the sub-account status and the routing information, without changing the transaction carrying capacity information of the sub-accounts. The sub-account availability check timer is responsible for checking all auxiliary accounts that have suspended trading due to their quota being less than the minimum transaction capacity. It determines the overall quota status of the corresponding hot accounts to decide whether to send a quota allocation message to the asynchronous processing module through the distributed message queue to request the auxiliary account to resume trading. If the quota allocation is successful, the auxiliary account status is changed through the sub-account status management function to restore its ability to accept external transactions.

Images