Bank account hotspot upgrading method and device based on current limiting and pessimistic lock calculation

Abstract

The invention provides a bank account hotspot upgrading method and device based on current limiting and pessimistic lock calculation, and relates to the field of financial science and technology, and the method comprises the steps: receiving a request, and enabling an external system to initiate a bookkeeping request; hot spot judgment: checking an account hot spot mark, and if the account hot spot mark is marked, routing to a hot spot processing flow; if not, entering common account flow control; flow control: adopting funnel type two-stage flow limiting and pre-control, counting based on a first time window, and triggering flow control if a threshold value is exceeded; otherwise, directly entering hot spot identification; flow control: carrying out account-level flow limiting on non-hotspot accounts; hot spot identification: in a pessimistic lock transaction, checking a hot spot count, and if a threshold value is reached, routing to the hot spot for processing; otherwise, based on a second time window accumulative count, marking a hot spot if supercritical; and marking processing: registering and marking the identified hotspot account, and completing the bookkeeping according to a common account. According to the invention, through flow control and hotspot identification in a common account balance pessimistic lock, dynamic hotspot marking identification processing is completed.

Description

Technical Field

[0001] This invention relates to the field of financial technology, and in particular to a method and apparatus for upgrading bank account hotspots based on current limiting and pessimistic locking calculations. Background Technology

[0002] With the development of internet finance businesses, centralized single-account direct debit and payment services initiated by channels such as UnionPay, NetsUnion, and SuperNet are becoming increasingly frequent. For example, if an online merchant opens a settlement account at a bank, multiple individual customers may simultaneously transfer funds into this settlement account, leading to account hotspots. Traditional financial account services require control over account balances and limits during the settlement account accounting process. High-frequency operations on the same account can trigger account locking issues due to account hotspots, thus giving rise to various solutions for handling hotspot accounts.

[0003] Hotspot account solutions generally require marking accounts as hotspots first, and then guiding the system to a different logical branch than ordinary accounting based on the hotspot markings, thereby avoiding the problems caused by hotspot accounts. For the hotspot marking in this process, the existing technical solutions are basically asynchronous, and there are usually two hotspot identification methods: (1) Before the hotspot, provide an independent hotspot account marking API service. The channel end (counter, online banking, etc.) packages the account opening or signing business, and the customer completes the account hotspot marking operation through the channel end through active business processing, thereby marking the account as a hotspot. (2) After the hotspot, provide post-analysis and prediction marking. Based on the analysis of a large amount of account business data, it is determined whether the account has been hotspot or may be hotspot at a certain time, thereby forming a list of hotspot accounts. After the business operation personnel confirm, the accounts in the system are marked as hotspots.

[0004] Existing methods for automatically identifying hotspots in bank accounts have the following problems: asynchronous hotspot identification, based on pre-signing or post-analysis, cannot cope with sudden hotspots and lacks real-time performance; for ordinary accounts that are not marked as hotspots, when they suddenly become hotspots, there may be a large number of processing failures, resulting in a poor user experience; for ordinary accounts that are not marked as hotspots, when they suddenly become hotspots, it may cause system paralysis, which is highly risky.

[0005] Based on the above problems, there is an urgent need for a method for real-time upgrading of bank account hotspot identification. When an ordinary account suddenly becomes a hotspot, the hotspot upgrade of the account can be implemented immediately to avoid the risk of a large number of failed responses or system paralysis. Summary of the Invention

[0006] To address the problems in the background technology, this invention provides a method and apparatus for upgrading bank account hotspots based on rate limiting and pessimistic locking calculations. For the accounting of a single ordinary account with instantaneous high concurrency, it provides flow control and hotspot upgrade processing. Flow control reduces the account lock waiting time, and dynamic hotspot tagging and identification processing is completed through processing based on the pessimistic locking of the ordinary account balance, thereby guiding the accounting processing of ordinary accounts to switch to hotspot account processing.

[0007] To achieve the above objectives, this invention provides a method for upgrading bank account hotspots based on rate limiting and pessimistic locking calculations, including: Receive accounting requests initiated by external systems; Determine if the current account has been marked as a hot account. If it has, route it to the hot account processing flow; if it has not, perform traffic control processing for ordinary accounts. The ordinary account flow control process includes a two-level funnel-style flow limiting process of flow pre-control and flow control. In the flow pre-control, the first time window of the account is checked and a pre-control count is performed. When the pre-control count exceeds the pre-control count threshold, the flow control is triggered. Otherwise, the process is routed to the ordinary account hotspot identification process in the pessimistic locking accounting transaction. For accounts that trigger flow control, check the hotspot status of the account again. If no hotspot is marked, perform account-level flow limiting and perform the hotspot identification process for ordinary accounts in pessimistic locking accounting transactions. In the hotspot identification process, if the current hotspot count data reaches the hotspot threshold, the accounting request is routed to the hotspot account balance processing process; otherwise, the second time window is checked and hotspot counting is performed. When the hotspot count reaches the preset hotspot threshold, the account is identified as a hotspot account. For identified hot accounts, register the account information to mark them as hotspots, and process the accounting request as a regular account balance.

[0008] As a further improvement of the present invention, the flow pre-control process includes: Initialize hotspot calculation information for each account and record the time interval between two consecutive accounting requests; If the time interval falls within the first time window, the pre-control count is increased.

[0009] As a further improvement of the present invention, the flow control includes: Initialize an account-level rate limiting instance for the account based on the traffic limit, interval time, and rate limiting policy in the configuration file; Before enabling account-level rate limiting, check the account's hotspot status again. If it is not marked as a hotspot, then enable account-level rate limiting. The rate limiting strategy includes queuing, delaying, or rapid failure.

[0010] As a further improvement of the present invention, the account's hotspot status is checked again, and if it has been marked as a hotspot, the rate limiting is expanded or canceled.

[0011] As a further improvement of the present invention, the hotspot identification is embedded in the pessimistic locking accounting transactions of ordinary accounts, including: Query the balance sheet to obtain hotspot configuration information, including hotspot counting thresholds and interval times; Determine whether the current hotspot count exceeds the hotspot threshold. If it does, route the accounting request to the hotspot account balance processing flow.

[0012] As a further improvement of the present invention, if the current hotspot count does not exceed the hotspot threshold, a second time window determination is performed to obtain the processing time interval between two consecutive accounting requests of the account. If the second time window is exceeded, the window time and hotspot count of the second time window are reset, and the accounting request is processed as a normal account balance.

[0013] As a further improvement of the present invention, if the processing time interval between two consecutive accounting requests of an account does not exceed the second time window, the hot spot count is accumulated based on the second time window to determine whether the new hot spot count has reached the hot spot threshold. If it has, the account is identified as a hot spot account and marked as a hot spot.

[0014] As a further improvement of the present invention, it is determined whether the new hotspot count has reached the hotspot threshold. If it has not reached the threshold, the hotspot count is updated only, and the accounting request is processed as a normal account balance.

[0015] The present invention also provides a bank account hotspot upgrade device based on rate limiting and pessimistic locking calculation, including: a request processing module, a traffic pre-control module, a traffic control module and a hotspot identification module, and the modules work together. The request processing module is used for: Receive and route external accounting requests; The flow pre-control module is used for: Account-level pre-flow control is performed on accounts that are not marked as hotspots. Potential hotspot accounts are identified based on the first time window and the pre-control counting threshold, and flow control is triggered. The flow control module is used for: Account-level traffic limiting will be implemented for potentially high-traffic accounts; The hotspot identification module is used for: Embedded in pessimistic locking transactions, it dynamically identifies and tags hot accounts.

[0016] As a further improvement of the present invention, the traffic control module checks the account hotspot status again and automatically adjusts the rate limiting strategy. If the account is upgraded to a hotspot, the rate limiting is expanded or canceled to match the high throughput processing capacity of the hotspot account.

[0017] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention improves the real-time performance, reliability, and overall performance of bank account systems in high-concurrency scenarios through a collaborative design of real-time dynamic identification, account-level flow control, and pessimistic locking mechanisms. Compared with existing technologies, this invention overcomes the problems of lack of real-time performance in asynchronous hotspot identification and processing failures or system paralysis caused by sudden traffic surges. It achieves seamless switching from ordinary accounts to hotspot accounts, ensuring business continuity and user experience. Specifically, the system can complete identification and flow control the instant an account suddenly becomes a hotspot, avoiding lock contention and resource exhaustion, while adapting to diverse business needs through parameterized configuration.

[0018] Compared to existing technologies that predict or identify hot accounts, this invention provides the ability to dynamically identify hot accounts. It can flexibly handle situations where any unmarked account suddenly becomes a hot account. Before hot account identification, account-level traffic control is added to reduce pessimistic locking contention time. At the same time, through a two-stage funnel-style rate limiting process, it avoids 99% of ordinary account accounting triggering rate limiting control and handles the instantaneous concurrency when 1% of ordinary accounts become hot accounts. Even with the introduction of account-level rate limiting control, this method can effectively control memory space. In addition, after a hot account upgrade, rate limiting can be expanded or canceled immediately to ensure normal system processing and normal business response, ultimately achieving real-time identification and upgrade of hot accounts.

[0019] This invention is based on pessimistic locking, which is a reliable primary means of accounting for ordinary accounts. During the accounting process, pessimistic locking can completely control the balance and avoid overdrafts under multi-threaded conditions. However, it also brings about lock contention issues under multi-threaded conditions. This invention continues the mechanism of balance pessimistic locking control and cleverly uses double counting judgment and precise counting control within the scope of pessimistic locking transactions to realize the upgrade of ordinary accounts to hot accounts. This approach, combined with rate limiting control, can effectively deal with the problems of instantaneous concurrent lock contention and hot account upgrades, while also avoiding the problem of processing conflicts between multiple threads under different hot account states under high concurrency. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of a bank account hotspot upgrade method based on rate limiting and pessimistic locking calculation, as disclosed in an embodiment of the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] The present invention will now be described in further detail with reference to the accompanying drawings: like Figure 1 As shown, this invention provides a method for upgrading bank account hotspots based on rate limiting and pessimistic locking. Financial accounts commonly use pessimistic locking for balance control to avoid overdraft risks. The industry generally uses asynchronous accounting and shadow accounts to handle hotspot accounts, but ordinary accounts before being marked as hotspots still use pessimistic locking to control balances and prevent overdraft risks during accounting processes. This invention can reduce account lock waiting time through rate control, and then complete dynamic hotspot labeling and identification processing based on the pessimistic locking of ordinary account balances, thereby guiding the accounting processing of ordinary accounts to switch to hotspot account processing, thus ensuring the availability and reliability of the system during the switch from ordinary accounts to hotspot accounts. The entire process includes four main processing modules: request processing, rate pre-control, rate control, and hotspot account identification, specifically including: S1. Receive accounting requests initiated by external systems; In a distributed environment, an external third-party system proactively initiates an accounting request to the bank's account system.

[0023] S2. Determine if the current account has been marked as a hot account. If it has, route to the hot account processing flow; if it has not, perform traffic control processing for ordinary accounts. Before processing the accounting entries, the system needs to determine whether the current account is already a hotspot. Furthermore, the determination of hot accounts needs to be based on account hotspot tags, and the hotspot tags need to be retrieved from the local storage of the account. Specifically, if a hotspot has been marked, the process will be routed through the "Hotspot Account Balance Processing" procedure, which is independent of this method and will not be explained in detail. If a hotspot has not been marked, it is a regular account and will be routed through the "Regular Account Traffic Control" procedure. S3. Ordinary account flow control processing includes two-level funnel-style flow limiting: flow pre-control and flow control. In flow pre-control, the first time window of the account is checked and a pre-control count is performed. When the pre-control count exceeds the pre-control count threshold, flow control is triggered. Otherwise, it is routed to the ordinary account hotspot identification process in the pessimistic locking accounting transaction. Among them, the business data flow needs to undergo "traffic pre-control processing" first. Since 99% of the account accounting requests are ordinary accounts and not hot accounts, traffic control for all accounts will generate additional system memory burden. Therefore, traffic pre-control processing is performed on account requests first, without actual flow control processing.

[0024] Further, the flow pre-control process includes: Initialize hotspot calculation information for each account, record the time interval between two consecutive accounting requests for the account, and increase the pre-control count if the time interval falls within the first time window. Specifically, each account needs to initialize unique hotspot calculation information in local storage. If this information does not exist, it needs to be initialized, and the control count will be reset to 0. If the information already exists, a time window check is performed, including: for each business request (the last hotspot identification time needs to be recorded), a judgment is made based on the time window set in the pre-flow control. (1) If two consecutive accounting requests for the same account fall within the first time window, the pre-control count is increased; If the pre-controlled counting threshold is exceeded, it indicates that the account may need to be upgraded to a hotspot, requiring flow control intervention and redirection to traffic control processing; If the pre-controlled count has not been exceeded, flow control will not be implemented, and the process will directly jump to the hotspot identification process for ordinary accounts.

[0025] (2) If two consecutive accounting requests for the same account are processed within a time interval exceeding the first time window, the pre-control count and time stamp are reset, flow control is terminated, and the process is redirected to the regular account or the hot account.

[0026] S4. For accounts that trigger flow control, check the hotspot status of the account again. If no hotspot is marked, perform account-level flow limiting and perform the hotspot identification process for ordinary accounts in pessimistic locking accounting transactions. Among them, flow control includes: Based on the traffic limit, interval, and rate limiting policy in the configuration file, initialize an account-level rate limiting instance for the account; before enabling account-level rate limiting, check the hotspot status of the account again. If it is not marked as a hotspot, enable account-level rate limiting. Rate limiting policies include queuing, delay, or rapid failure.

[0027] Furthermore, recheck the account's hotspot status; if it has been marked as a hotspot, increase or decrease the rate limit.

[0028] Specifically, for accounts that can enter this processing flow, they are considered potential cases of ordinary accounts being upgraded to hot accounts. It is necessary to initialize flow control counter information for each account, retrieving information such as flow limits, intervals, and rate limiting policies from the configuration file to initialize account-level flow control instances. However, before instantiation, it is necessary to check again whether the current account has already become a hot account. Under multi-threaded concurrency, an account may have already been upgraded to a hot account, in which case flow control needs to be canceled (by default, hot account processing performance is extremely high). The processing includes: (1) Check if the current account has been marked as a "hot topic". (2) If it has been marked as a hotspot, considering that the processing performance of hotspot accounts is much higher than that of ordinary accounts, the rate limit can be expanded or canceled.

[0029] (3) If it is not marked as a hotspot, it means that it is currently in the pre-upgrade stage of the hotspot. In this case, account-level rate limiting control needs to be enabled immediately. At this time, the account information is extracted and combined with the rate limiting control count information to initialize the account-level rate limiting object. Based on the rate limiting service, rate limiting control is applied to other accounting requests of this account.

[0030] Flow control strategies can be set to queue delay, rapid failure, etc., to avoid thread pool resource exhaustion caused by congestion and waiting; requests processed through flow control will enter the next hotspot identification process.

[0031] S5. In the hotspot identification process, if the current hotspot count data reaches the hotspot threshold, the accounting request is routed to the hotspot account balance processing process; otherwise, the second time window is checked and hotspot counting is performed. When the hotspot count reaches the preset hotspot threshold, the account is identified as a hotspot account. Hotspot identification is embedded in the pessimistic locking accounting transactions of ordinary accounts, including: Query the balance sheet to obtain hotspot configuration information, including hotspot counting thresholds and interval times; Determine if the current hotspot count exceeds the hotspot threshold. If it does, route the accounting request to the hotspot account balance processing flow.

[0032] Furthermore, if the current hotspot count does not exceed the hotspot threshold, a second time window determination is performed to obtain the processing time interval between two consecutive accounting requests for the account. If it exceeds the second time window, the window time and hotspot count of the second time window are reset, and the accounting request is processed as a normal account balance.

[0033] The system obtains the processing time interval between two consecutive accounting requests for an account. If the interval does not exceed the second time window, it determines whether the new hotspot count has reached the hotspot threshold based on the cumulative hotspot count within the second time window. If it does, the account is identified as a hotspot and marked as such.

[0034] Determine if the new hotspot count has reached the hotspot threshold. If not, update the hotspot count only and process the accounting request as a regular account balance.

[0035] Specifically, hotspot identification is the process of identifying hotspots for ordinary accounts, and there are several scenarios: under high concurrency with a single account, the thread entering this stage is still an ordinary account; under high concurrency with a single account, the thread entering this stage is already a hotspot account; or it may simply be a single thread request from an ordinary account, not a hotspot account. Therefore, this process involves multiple repeated hotspot verifications, ultimately deciding whether to escalate the hotspot escalation. The processing includes: (1) Hotspot identification is embedded in the ordinary account accounting process, and the balance sheet needs to be locked and queried first.

[0036] (2) Query hotspot configuration information, including hotspot counting threshold and hotspot interval time. This data is stored in the balance table (to ensure performance, no additional IO is added).

[0037] (3) Determine whether the current count data has exceeded the hotspot threshold (in a multi-threaded environment, it may have been accumulated to the threshold by other threads). If it exceeds the hotspot count threshold, directly enter the hotspot balance processing flow. This flow is independent of this method and will not be elaborated again. If it does not exceed the hotspot count threshold, perform a time window determination, determine the time interval between two consecutive processing steps, and reset the time and count settings for cases where the time window is exceeded. For cases where the time window is not exceeded, it is considered that the hotspot threshold has been reached, and jump to the hotspot marker.

[0038] S6. For the identified hot accounts, register the account information as hotspots to implement hotspot marking, and process the accounting request as a regular account balance; The number of hotspot records is accumulated. If the number of hotspot records exceeds the hotspot threshold, it means that the account requesting this time has triggered the hotspot threshold and the account information is registered as a hotspot. At the same time, this processing is still treated as a normal account balance. These two data processing will be managed in the same transaction. If the number of hotspot records does not exceed the hotspot threshold, only the count is updated and it continues to be treated as a normal account balance.

[0039] The present invention also provides a bank account hotspot upgrade device based on rate limiting and pessimistic locking calculation, comprising: a request processing module, a traffic pre-control module, a traffic control module and a hotspot identification module, wherein each module works in concert; The request processing module is used for: Receive and route external accounting requests; The flow pre-control module is used for: Account-level pre-flow control is performed on accounts that are not marked as hotspots. Potential hotspot accounts are identified based on the first time window and the pre-control counting threshold, and flow control is triggered. The flow control module is used for: Account-level traffic limiting will be implemented for potentially high-traffic accounts; The hotspot identification module is used for: Embedded in pessimistic locking transactions, it dynamically identifies and tags hot accounts.

[0040] The traffic control module re-checks the account's hotspot status and automatically adjusts the rate limiting strategy. If an account is upgraded to a hotspot, the rate limiting is expanded or canceled to match the high throughput processing capacity of the hotspot account. In this invention, a hot account refers to an account where a large number of balance increases occur concurrently within seconds, making the account balance data hot data; flow control refers to controlling the maximum flow that can be processed in parallel under high concurrency, in units of seconds or other times. Example 1:

[0041] A distributed banking account system processes accounting requests in parallel across multiple nodes. Configurable parameters include a first and second time window of 1 second, a pre-controlled counting threshold of 5 transactions, and a hotspot threshold of 10 transactions. The system receives accounting requests from the settlement account of merchant "ABC" on an e-commerce platform. The account is initially a regular account (not marked as a hotspot). At the instant a promotional activity begins, the system simultaneously receives 100 transfer requests from individual users to this account; the steps include: Step 1, Receiving Accounting Requests: An external system (such as an e-commerce platform) initiates a transfer request, including the account "ACC123", the amount of 100 yuan, and the timestamp 2026-01-21 13:35:05; the bank system receives the request, parses the account information, and puts the request into the system queue. Step 2, Hotspot Judgment: Based on the request data of account "ACC123", the system queries the hotspot markers in local storage (such as cache or database). If the query shows that "ACC123" is already a hotspot account (for example, it has been marked in a previous request), then it will be directly routed to the hotspot account processing flow, and the process ends. Example 2:

[0042] Based on the scenario in Example 1, step 1 is the same as in Example 1; Step 2, Hotspot Judgment: Based on the request data of account "ACC123", the system queries the hotspot markers in local storage (such as cache or database). The query shows that "ACC123" was not initially marked as a hotspot, and the route is routed to the "normal account traffic control" process.

[0043] Step 3, General Account Traffic Control: Based on the request data of account "ACC123", the system checks whether there is hotspot calculation information (such as counter and timestamp) for "ACC123" in the local storage; if the check result is not found, the information is initialized, the counter is reset to 0, the timestamp is set to the current time, and the time interval between the current request and the last request is compared. If the time interval is 0.5s, the pre-control counter is increased to 1. If the counter does not exceed the pre-control counter threshold, flow control is not triggered, and the process jumps to hotspot identification. Step 4, Hotspot Identification (completed within a pessimistic locking transaction): The cumulative number of hotspots increases (e.g., from 7 to 8). Determine if the cumulative number exceeds the hotspot threshold (10 times). If the count is less than 10 times, only update the count and continue processing the accounting request as a normal account. Example 3:

[0044] Based on the scenario of Example 1, steps 1 and 2 are the same as in Example 2; Step 3, Ordinary Account Traffic Control: Based on the request data of account "ACC123", the system checks whether there is hot calculation information (such as counter and timestamp) for "ACC123" in the local storage; if the check result is that the counter is 4, and the time interval between the current request and the previous request is 0.5s, if the interval is ≤1 second, the pre-control counter is increased to 5, and when the threshold pre-control counter threshold is reached, traffic control is triggered. Step 4, Traffic Control Processing: Based on the request data from account "ACC123", the system checks the account's hotspot status again (to avoid escalating to a hotspot under multi-threaded conditions). The check shows the account is still in the normal state, therefore account-level traffic control is enabled. The system retrieves the traffic control parameters from the configuration file (traffic limit = 10 times / second, policy = queuing delay) and initializes the rate limiting instance for "ACC123". Then, rate limiting is executed, including: if the request does not exceed the limit, allowing it to proceed and entering hotspot identification; Step 5, Hotspot Identification (Embedded Pessimistic Locking Transaction): Through flow control requests, the process is executed within a database pessimistic locking transaction to ensure the atomicity of balance query and hotspot identification. This includes: first locking the account balance table, querying the current balance and hotspot configuration information (hotspot threshold = 10 times, interval = 5 seconds), counting 9 hotspots, which is less than the hotspot threshold of 10, then judging the time window, the interval between the current request and the previous request is ≤ 5 seconds, accumulating the count (from 9 to 10), reaching the hotspot threshold, and jumping to hotspot marking.

[0045] Step 6, Hotspot Marking (completed within a pessimistic locking transaction): For accounting requests that jump from hotspot identification, if the cumulative count reaches 10 and the hotspot threshold is reached, the account is marked as a hotspot within the same transaction, the account status is updated, and the accounting request is completed as a normal account (ensuring atomicity). After that, the account request follows the hotspot account processing flow.

[0046] Advantages of this invention: Compared to existing technologies that predict or identify hot accounts, this invention provides the ability to dynamically identify hot accounts. It can flexibly handle situations where any unmarked account suddenly becomes a hot account. Before hot account identification, account-level traffic control is added to reduce pessimistic locking contention time. At the same time, through a two-stage funnel-style rate limiting process, it avoids 99% of ordinary account accounting triggering rate limiting control and handles the instantaneous concurrency when 1% of ordinary accounts become hot accounts. Even with the introduction of account-level rate limiting control, this method can effectively control memory space. In addition, after a hot account upgrade, rate limiting can be expanded or canceled immediately to ensure normal system processing and normal business response, ultimately achieving real-time identification and upgrade of hot accounts.

[0047] This invention is based on pessimistic locking, which is a reliable primary means of accounting for ordinary accounts. During the accounting process, pessimistic locking can completely control the balance and avoid overdrafts under multi-threaded conditions. However, it also brings about lock contention issues under multi-threaded conditions. This invention continues the mechanism of balance pessimistic locking control and cleverly uses double counting judgment and precise counting control within the scope of pessimistic locking transactions to realize the upgrade of ordinary accounts to hot accounts. This approach, combined with rate limiting control, can effectively deal with the problems of instantaneous concurrent lock contention and hot account upgrades, while also avoiding the problem of processing conflicts between multiple threads under different hot account states under high concurrency.

[0048] This invention utilizes a dynamic identification mechanism embedded in the accounting process to identify hotspots in real time during sudden high concurrency events in ordinary accounts (such as during promotional activities), without relying on pre-contractual agreements or post-event analysis. Furthermore, by using real-time judgment of counting thresholds and time windows, this invention completes identification within pessimistic locking transactions, ensuring the system responds to hotspot changes within seconds and reducing business failure rates.

[0049] This invention employs a two-stage funnel design combining pre-flow control and flow control, avoiding unnecessary flow control for 99% of ordinary accounts and enabling flow limiting only for 1% of potentially hot accounts. This reduces memory usage and computational overhead (reducing resource consumption by approximately 50%), while account-level isolation ensures that concurrency in a single account does not affect other accounts, achieving precise flow control.

[0050] This invention integrates hotspot identification into pessimistic locking transactions for ordinary accounts, which not only preserves the reliability of balance control (completely avoiding multi-threaded overdrafts), but also realizes hotspot upgrade through dual counting judgment. It first alleviates lock contention through flow control, and then atomically completes hotspot marking within the lock scope, thereby improving the system throughput under high concurrency and eliminating the risk of data inconsistency.

[0051] This invention supports dynamic adjustment of parameters such as pre-flow control threshold and hotspot counting threshold, enabling the system to quickly adapt to business changes (such as fluctuations in activity traffic); operators can optimize performance in real time through configuration files without downtime to modify code, thus reducing operation and maintenance costs.

[0052] This invention can handle multi-node concurrency without introducing a central node. Through local storage and pessimistic locking coordination, it ensures that hotspot identification for a single account is consistently performed in the distributed system. This eliminates the risk of new hotspots (such as the central node becoming a bottleneck) and enhances the horizontal scalability of the system. This invention supports elastic scaling in cloud-native environments through decentralized design.

[0053] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for upgrading bank account hotspots based on rate limiting and pessimistic locking calculations, characterized in that, include: Receive accounting requests initiated by external systems; Determine if the current account has been marked as a hot account. If it has, route the application to the hot account processing flow. If not marked, normal account traffic control will be applied; The ordinary account flow control process includes a two-level funnel-style flow limiting process of flow pre-control and flow control. In the flow pre-control, the first time window of the account is checked and a pre-control count is performed. When the pre-control count exceeds the pre-control count threshold, the flow control is triggered. Otherwise, the process is routed to the ordinary account hotspot identification process in the pessimistic locking accounting transaction. For accounts that trigger flow control, check the hotspot status of the account again. If no hotspot is marked, perform account-level flow limiting and perform the hotspot identification process for ordinary accounts in pessimistic locking accounting transactions. In the hotspot identification process, if the current hotspot count data reaches the hotspot threshold, the accounting request is routed to the hotspot account balance processing process; otherwise, the second time window is checked and hotspot counting is performed. When the hotspot count reaches the preset hotspot threshold, the account is identified as a hotspot account. For identified hot accounts, register the account information to mark them as hotspots, and process the accounting request as a regular account balance.

2. The bank account hotspot upgrade method based on rate limiting and pessimistic locking calculation as described in claim 1, characterized in that, The flow pre-control process includes: Initialize hotspot calculation information for each account and record the time interval between two consecutive accounting requests; If the time interval falls within the first time window, the pre-control count is increased.

3. The bank account hotspot upgrade method based on rate limiting and pessimistic locking calculation as described in claim 1, characterized in that, The flow control includes: Initialize an account-level rate limiting instance for the account based on the traffic limit, interval time, and rate limiting policy in the configuration file; Before enabling account-level rate limiting, check the account's hotspot status again. If it is not marked as a hotspot, then enable account-level rate limiting. The rate limiting strategy includes queuing, delaying, or rapid failure.

4. The bank account hotspot upgrade method based on rate limiting and pessimistic locking calculation as described in claim 1 or 3, characterized in that: The system then re-checks the account's hotspot status; if it has been marked as a hotspot, the rate limiting is either increased or decreased.

5. The bank account hotspot upgrade method based on rate limiting and pessimistic locking calculation as described in claim 1, characterized in that, The hotspot identification is embedded in the pessimistic locking accounting transactions of ordinary accounts, including: Query the balance sheet to obtain hotspot configuration information, including hotspot counting thresholds and interval times; Determine whether the current hotspot count exceeds the hotspot threshold. If it does, route the accounting request to the hotspot account balance processing flow.

6. The method for upgrading bank account hotspots based on rate limiting and pessimistic locking calculation as described in claim 1, characterized in that, If the current hotspot count does not exceed the hotspot threshold, a second time window determination is performed to obtain the processing time interval between two consecutive accounting requests for the account. If it exceeds the second time window, the window time and hotspot count of the second time window are reset, and the accounting request is processed as a normal account balance.

7. The bank account hotspot upgrade method based on rate limiting and pessimistic locking calculation as described in claim 6, characterized in that, The system obtains the processing time interval between two consecutive accounting requests for an account. If the interval does not exceed the second time window, it determines whether the new hotspot count has reached the hotspot threshold based on the cumulative hotspot count within the second time window. If it does, the account is identified as a hotspot and marked as such.

8. The bank account hotspot upgrade method based on rate limiting and pessimistic locking calculation as described in claim 7, characterized in that, Determine whether the new hotspot count has reached the hotspot threshold. If not, only update the hotspot count and process the accounting request as a regular account balance.

9. A bank account hotspot upgrade device based on rate limiting and pessimistic locking calculation, implementing the bank account hotspot upgrade method based on rate limiting and pessimistic locking calculation as described in any one of claims 1 to 8, characterized in that, include: The request processing module, traffic pre-control module, traffic control module, and hotspot identification module work together. The request processing module is used for: Receive and route external accounting requests; The flow pre-control module is used for: Account-level pre-flow control is performed on accounts that are not marked as hotspots. Potential hotspot accounts are identified based on the first time window and the pre-control counting threshold, and flow control is triggered. The flow control module is used for: Account-level traffic limiting will be implemented for potentially high-traffic accounts; The hotspot identification module is used for: Embedded in pessimistic locking transactions, it dynamically identifies and tags hot accounts.

10. The bank account hotspot upgrade device based on rate limiting and pessimistic locking calculation according to claim 9, characterized in that: The traffic control module rechecks the account's hotspot status and automatically adjusts the rate limiting strategy. If the account is upgraded to a hotspot, the rate limiting is expanded or canceled to match the high throughput processing capacity of the hotspot account.

Images