Bank account hotspot identification upgrading parallel processing method and device based on optimistic lock

Abstract

The invention provides a bank account hotspot identification upgrading parallel processing method and device based on an optimistic lock, and relates to the field of financial science and technology, and the method comprises the steps: receiving an account operation request initiated by an external system; judging whether the account is marked as a hotspot account or not; if the account is not marked as the hotspot account, hotspot window checking is carried out, and the hotspot window checking comprises the steps that a preset time window is determined, and concurrent operation in the time window is detected; counting concurrent operations in the time window based on an optimistic lock mechanism, wherein the optimistic lock mechanism comprises version number control and cyclic update operations; when the counting result exceeds a preset hotspot threshold value, automatically upgrading the account to a hotspot account, and switching to a hotspot processing mode; wherein in the account hotspot identification process, the account supports parallel execution of common account processing operation and hotspot account processing operation. According to the invention, the real-time dynamic identification of the account hotspots is realized, the processing stability of multiple concurrent accounts is improved, and the normal processing of the system and the normal response of the service are ensured.

Description

Technical Field

[0001] This invention relates to the field of financial technology, and in particular to the field of high-concurrency account processing technology, specifically to a method and apparatus for upgrading and parallel processing of bank account hotspot identification based on optimistic locking. 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 parallel processing of hotspot identification and upgrading of bank accounts based on optimistic locking. By using a cyclic optimistic locking counting method, hotspot marking and identification are performed before ordinary account table locking processing. This can effectively prevent lock contention caused by pessimistic locking of ordinary accounts, while providing high-performance processing and identification capabilities to complete dynamic hotspot marking and identification processing. This guides the accounting processing of ordinary accounts to switch to hotspot account processing, providing security control and hotspot upgrading processing for the instantaneous high concurrency of a single ordinary account.

[0007] To achieve the above objectives, the present invention provides a parallel processing method for hotspot identification and upgrading of bank accounts based on optimistic locking, including: receiving an account operation request initiated by an external system; Determine whether the account has been marked as a hot account; If the account is not marked as a hotspot account, a hotspot window check is performed, which includes: determining a preset time window and detecting concurrent operations within the time window; The concurrent operations within the time window are counted based on an optimistic locking mechanism, wherein the optimistic locking mechanism includes version number control and cyclic update operation. When the count exceeds the preset hotspot threshold, the account will be automatically upgraded to a hotspot account and switched to hotspot processing mode; In the process of identifying account hotspots, the account supports the parallel execution of ordinary account processing operations and hotspot account processing operations.

[0008] As a further improvement of the present invention, the hotspot window check specifically includes: When the first account operation is triggered, the start time of the time window is recorded, and the window period is the start time plus a preset duration. For subsequent account operations, determine whether they fall within the aforementioned time window: If it falls within the time window, it participates in the concurrent operation count of that time window; If the time window falls outside the specified time window, a new time window will be created. The account operation that triggers the creation of a time window will directly enter the normal account processing flow after the time window is created.

[0009] As a further improvement of the present invention, the optimistic locking-based counting mechanism includes: When the concurrent operation count of an account operation is detected within the specified time window, query the current count value and version number. Update the counter value and version number using the query results as the update condition; If the update is successful, a threshold comparison is performed with the preset hotspot threshold. If the update fails, it will be retried repeatedly until the maximum number of attempts is reached, at which point the system will respond directly to the account's operation.

[0010] As a further improvement of the present invention, if the update is successful, the account operation enters a synchronous parallel processing flow.

[0011] As a further improvement of the present invention, threshold determination is performed with the preset hotspot threshold, including: If the updated count value does not exceed the preset hotspot threshold, the account operation will proceed to the normal account processing flow. If the updated count value exceeds the preset hotspot threshold, the account will be automatically upgraded to a hotspot account, and the operation of the account will enter an asynchronous parallel processing flow.

[0012] As a further improvement of the present invention, the account is automatically upgraded to a hot account, and the operation of this account enters an asynchronous parallel processing flow, including: When the thread that triggers the upgrade of an account to a hot account is in the process of upgrading, the hot account markers of some threads of that account instantly change to upgrading, not upgraded, and upgraded, and at the same time enter the normal account processing flow. Subsequent threads of that account enter the hot account balance processing flow. At this time, the threads that are upgrading, not upgraded, and upgraded are processed synchronously and in parallel in the normal account processing flow. When the thread that triggered the account upgrade to a hot account is upgraded to a hot account thread, that thread also enters the hot account balance processing flow, and the account operation enters the asynchronous parallel processing flow.

[0013] As a further improvement of the present invention, the switching of the hotspot processing mode includes asynchronous parallel processing and synchronous parallel processing: During the process of upgrading an account to a hotspot, other operations do not need to wait and can directly enter the hotspot account balance processing flow for asynchronous parallel processing. In the normal account processing flow, threads that are compatible with hotspot upgrades are processed synchronously and in parallel through temporary transaction registration and balance aggregation.

[0014] As a further improvement of the present invention, the synchronous parallel processing specifically includes: In the processing of ordinary accounts, pessimistic locking is used for balance inquiries; Register temporary transaction records for balance verification under concurrent conditions; Summarize temporary transaction amounts to prevent overdrafts; Update temporary transaction status and officially mark an account as a hot account when it is upgraded.

[0015] The present invention also provides a bank account hotspot identification and upgrade parallel processing device based on optimistic locking, including a hotspot routing module, a hotspot window checking module, an optimistic locking counting module and a parallel processing module. The device operates in a distributed environment and does not introduce a central node. The hotspot routing module is used for: Receive requests and determine the account's hotspot status; The hotspot window checking module is used for: Manage time windows and concurrent detection; The optimistic locking counting module is used for: Implement concurrent safe counting; The parallel processing module is used for: It supports both asynchronous and synchronous processing flows.

[0016] As a further improvement of the present invention, the device also provides real-time hotspot identification and upgrade capabilities, which are triggered immediately when a hotspot occurs, without the need for prior prediction or post-event analysis; it supports high-concurrency requests and eliminates thread waiting through optimistic locking.

[0017] Compared with the prior art, the beneficial effects of the present invention are as follows: Compared with the existing technology that predicts or identifies hot accounts, this invention provides the ability to dynamically identify hot accounts. It can flexibly deal with situations where any unmarked hot account suddenly becomes a hot account in an instant, ensuring normal system processing and normal business response, and realizing the real-time dynamic identification capability of account hotspots.

[0018] Compared to rate limiting and pessimistic locking identification approaches, this invention does not introduce rate limiting technology, thus avoiding increasing the overall complexity of the system.

[0019] This invention introduces optimistic locking, which avoids lock waiting problems caused by multi-threaded exclusive lock contention through loop counting and version number control. It also solves the business timeout problem of accounts before being upgraded to hotspots under high concurrency, and can quickly respond to and handle failures, avoiding the risk of system downtime.

[0020] This invention's device can simultaneously process both hot accounts and regular accounts, effectively solving thread safety and balance security issues in multi-threaded identification processes. Compared to serial identification devices based on optimistic locking, this invention's device does not experience proactive response failures; compared to identification devices based on flow control and optimistic locking, this invention does not experience rate-limiting response failures. Therefore, this device provides a superior user experience during the identification process, can respond 100% to situations where regular accounts suddenly become hot accounts, and improves system resilience. Attached Figure Description

[0021] Figure 1This is a flowchart of a parallel processing method for real-time upgrading of hotspot identification of bank accounts based on optimistic locking, as disclosed in one embodiment of the present invention. Detailed Implementation

[0022] 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.

[0023] The present invention will now be described in further detail with reference to the accompanying drawings: like Figure 1 As shown, the present invention provides a parallel processing method for hotspot identification and upgrading of bank accounts based on optimistic locking. Typically, financial accounts use pessimistic locking for balance control to avoid overdraft risk. The industry commonly uses asynchronous accounting and shadow accounts to handle hotspot accounts. However, ordinary accounts before being marked as hotspots still use pessimistic locking to control balances and prevent overdraft risk during accounting processes. Under high concurrency, pessimistic lock contention can lead to performance degradation. The present invention provides parallel hotspot identification of bank accounts based on optimistic locking, which can provide security control and hotspot upgrading processing for accounting of a single ordinary account during instantaneous high concurrency. The invention uses a cyclic optimistic locking counting method to mark and identify hotspots before ordinary account table locking processing, effectively preventing lock contention caused by pessimistic locking of ordinary accounts. It also provides high-performance processing and identification capabilities, completing dynamic hotspot marking and identification processing, thereby guiding the accounting processing of ordinary accounts to switch to hotspot account processing. Specifically, it includes: S1. Receive account operation requests initiated by external systems; In this process, an external third-party system proactively initiates an accounting request to the bank's account system.

[0024] S2. Determine if the account has been marked as a hot account; Before processing the accounting entries, the system needs to determine whether the current account is already a hotspot.

[0025] If it is not a popular account, you will be redirected to S3.

[0026] If the account is already in high demand, the operation request will directly enter the asynchronous parallel processing flow.

[0027] S3. If the account is not marked as a hotspot account, a hotspot window check is performed. The hotspot window check includes: determining a preset time window and detecting concurrent operations within the time window. The hotspot window check specifically includes: When the first account operation is triggered, record the start time of the time window, and use the start time plus a preset duration as the time window period. For subsequent account operations, determine whether they fall within the time window: If it falls within the time window, participate in the concurrent operation count of this time window; If it falls outside the time window, re-establish the time window; The account operation that triggers the establishment of the time window directly enters the normal account processing flow after the time window is established.

[0028] Specifically, the recognition process needs to strictly control the time window period. For example, if an account has more than y concurrent transactions within x time units, this account needs to be regarded as a hot spot. However, the opening and closing periods of the x time units are uncertain. Record the start time of the first business trigger as m, and use the time slice of m + x as the window. So there are the following situations: (1) If the time window is empty, it means this is the first bookkeeping trigger business, and register the time window as m~m + x. Since this is the first business, there is no need to participate in the hot spot recognition process, and this business can directly enter the normal account processing flow; (2) If the time window is not empty, and the time of this business < m + x, it means this business falls within the time window of the previous business, and jump to S4 for judgment of the count; (3) If the time window is not empty, but the time of this business > m + x, it means this business falls outside the time window of the previous business, and the time window needs to be re-recorded. Then this business is the first business of the new time window, and this business can directly enter the normal account processing and does not need to participate in the recognition process.

[0029] S4. Count the concurrent operations within the time window based on the optimistic lock mechanism, where the optimistic lock mechanism includes version number control and loop update operations; Among them, the counting mechanism based on the optimistic lock includes: When it is checked that the account operation participates in the concurrent operation count of this time window, query the current count value and version number; Use the query result as the update condition to update the count value and version number; If the update is successful, perform a threshold judgment with the preset hot spot threshold; If the update fails, retry in a loop until the maximum number of attempts is reached and then directly respond to this account operation.

[0030] Furthermore, if the update is successful, this account operation enters the synchronous parallel processing flow.

[0031] Performing a threshold judgment with the preset hot spot threshold includes: If the updated count value does not exceed the preset hotspot threshold, the account operation will proceed to the normal account processing flow. If the updated count value exceeds the preset hotspot threshold, the account will be automatically upgraded to a hotspot account, and operations on that account will enter an asynchronous parallel processing flow.

[0032] Furthermore, the account is automatically upgraded to a hot account, and operations on that account enter an asynchronous parallel processing flow, including: When the thread that triggers the upgrade of an account to a hot account is in the process of upgrading, the hot account markers of some threads of that account instantly change to upgrading, not upgraded, and upgraded, and at the same time enter the normal account processing flow. Subsequent threads of that account enter the hot account balance processing flow. At this time, the threads that are upgrading, not upgraded, and upgraded are processed synchronously and in parallel in the normal account processing flow. When the thread that triggered the account upgrade to a hot account is upgraded to a hot account thread, that thread also enters the hot account balance processing flow, and the account operation enters the asynchronous parallel processing flow.

[0033] Specifically, the optimistic locking counting method is used to avoid the performance degradation caused by high-concurrency pessimistic locking contention. Therefore, an optimistic locking self-looping mechanism exists: S4.1 Query the current count status (value, version number); S4.2 Use the query results as update conditions to update the count value and version number; S4.2.1 If the update result is 1, the counting is considered successful, proceed to S5; S4.2.2 If the result is 0, the recognition count fails, and the loop is entered to try querying and updating again; S4.2.3 If the number of loops exceeds the set limit, the business response will be directly identified to avoid timeout; S4.3 Determine whether to use hotspot preprocessing; S4.3.1 If the hotspot threshold is not exceeded, proceed to the normal account processing procedure; S4.3.2 If the hotspot threshold is exceeded, asynchronous parallel processing will be initiated.

[0034] S5. When the counting result exceeds the preset hotspot threshold, the account will be automatically upgraded to a hotspot account and switched to hotspot processing mode. The switching of hotspot processing modes includes asynchronous parallel processing and synchronous parallel processing: During the process of upgrading an account to a hotspot, other operations do not need to wait and can directly enter the hotspot account balance processing flow for asynchronous parallel processing. In the normal account processing flow, threads that are compatible with hotspot upgrades are processed synchronously and in parallel through temporary transaction registration and balance aggregation.

[0035] Furthermore, synchronous parallel processing specifically includes: In the processing of ordinary accounts, pessimistic locking is used for balance inquiries; Register temporary transaction records for balance verification under concurrent conditions; Summarize temporary transaction amounts to prevent overdrafts; Update temporary transaction status and officially mark an account as a hot account when it is upgraded.

[0036] Specifically, Asynchronous parallel processing is a hot account solution based on asynchronous accounting, which controls the processing of real-time balances. This process does not require waiting for an account to be fully upgraded to hot account status. While the thread triggering the threshold is in the "upgrading" phase, other threads immediately enter the hot account balance processing flow without waiting. At this point, there are synchronous parallel balance processing threads. Threads that have already fully upgraded to hot accounts also enter this process. At this point, there are no synchronous parallel balance processing threads.

[0037] Synchronous parallel processing is necessary during high-concurrency account processing. At any given moment, threads marked as "Upgrading," "Not Upgrading," or "Upgraded" might simultaneously enter the normal account processing flow. In this situation, it's crucial to handle the accounting entries for all three data states concurrently within the normal account processing workflow. Therefore, synchronous parallel processing intrudes upon the general account processing flow. The specific process is as follows: (1) Balance Sheet Pessimistic Locking Query For general account processing, the balance will first be pessimistically locked to ensure the atomicity of amount verification and updating; this process is consistent with existing general account processing.

[0038] (2) Register temporary transaction records Temporary transaction records are not recorded for regular account processing; they are only recorded for hot accounts when they are processed asynchronously.

[0039] This new feature is added to ensure that the balance of hot account balance processing is not overdrawn under concurrent conditions; hot account balance processing will perform balance summary analysis on the temporary table.

[0040] (3) Summary and verification of temporary water flow transaction amounts For regular accounts, temporary transaction records are not recorded; only when hot accounts are processed asynchronously, the balance in this table is aggregated for balance verification.

[0041] This feature has been added to ensure that the balance of a regular account is not overdrawn during concurrent transactions. (4) Update the temporary transaction meter processing status to processed. For regular accounts, temporary transaction records are not recorded; for hot account only, the status is updated after the balance is aggregated to ensure that temporary balances are not reused.

[0042] This feature has been added to immediately update temporary balances and reduce the total number of balances for frequently accessed accounts.

[0043] (5) Hotspot Official Marking If the account is in "Upgrading," this step will mark the account as being upgraded to a hotspot. This ensures that subsequent requests go directly into the hotspot processing flow.

[0044] The present invention also provides a parallel processing device for bank account hotspot identification upgrade based on optimistic locking, including a hotspot routing module, a hotspot window checking module, an optimistic locking counting module and a parallel processing module. The device operates in a distributed environment and does not introduce a central node. Hotspot routing module, used for: Receive requests and determine the account's hotspot status; The hotspot window detection module is used for: Manage time windows and concurrent detection; The optimistic locking counting module is used for: Implement concurrent safe counting; Parallel processing module, used for: It supports both asynchronous and synchronous processing flows.

[0045] The device of the present invention also provides real-time hotspot identification and upgrade capabilities, which are triggered immediately when a hotspot occurs without prior prediction or post-analysis; it supports high-concurrency requests and eliminates thread waiting through optimistic locking.

[0046] The main feature of this invention is the parallel hotspot identification of accounts. Under high concurrency, the accounting processing is controlled by version control provided by optimistic locking. The thread that is identifying hotspots performs normal accounting upgrade processing, while the thread that is about to be identified performs hotspot account processing. That is, the identification process supports the parallel processing of normal account processing and hotspot account processing. This ensures high performance while constraining the hotspot upgrade process and reducing the processing complexity of different threads at different stages before, during and after hotspot identification.

[0047] This invention focuses on the goal of dynamic hotspot identification and tagging. It combines hotspot account solutions with ordinary account accounting processing to ensure the availability and reliability of the system during the switch from ordinary accounts to hotspot accounts. It achieves the characteristics of accurate and fast identification, no performance degradation, no overdraft risk, and no system crash risk.

[0048] 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". Example 1:

[0049] Taking a merchant's bank settlement account A (initially a regular account, not marked as a hotspot) during a promotional activity, at time T0, account A simultaneously receives 10 remittance requests from multiple individual customers, causing a sudden hotspot. This invention applies a parallel processing method for real-time upgrades of hotspot account identification, with a preset hotspot threshold of 5, meaning that if more than 5 concurrent requests are received within a time window, a hotspot is triggered. The time window x = 10 seconds, and the maximum number of optimistic retries is 3. Specifically, it includes: Step 1: Concurrent requests 1 to 10 enter the system almost simultaneously. The system starts an independent thread for each request to query the hotspot marking status of account A. The query result is: account A has not yet been marked as a hotspot, so all threads are routed to "hotspot window check". Step 2: For each request, execute the hotspot window check logic in parallel. Request 1 (the first request) falls within an empty window, so the window start time T0 is directly registered, and the window period is set to T0 to T0+10 seconds. Then, request 1 enters the normal account processing flow (no need to participate in the counting, as it is the first request within the window). The timestamps of requests 2 to 10 all fall within the T0 to T0+10 second window, so they are marked as "need to participate in hotspot counting" and enter optimistic locking counting control. If multiple threads attempt to register the window at the same time (such as requests 1 and 2 almost simultaneously), the system uses atomic operations to ensure that only one thread successfully sets the window, and other threads read the already set window value to ensure consistency.

[0050] Step 3: For requests that enter optimistic locking count control (taking request 2 as an example, other requests are similar), query the current count status: The thread of request 2 queries the count data of account A, including: Count value: initially 0 (indicating that there is no count in the current window); Version number: initially v1 (used for optimistic locking control); Use the query result as the update condition to update. The thread attempts an atomic update with the queried value (count value = 0, version number = v1) as the condition: UPDATE count table SET count value = 1, version number = v2 WHERE account ID = A AND version number = v1.

[0051] If the update is successful (number of rows affected = 1): the counter value increases to 1, and the version number is updated to v2. The thread enters the threshold check; If the update fails (affected rows = 0): This means another thread has already updated (e.g., request 3 successfully counted the rows). The thread will retry querying the latest value (e.g., count = 1, version number = v2) and update again, looping a maximum of 3 times. If this limit is exceeded, the request will directly respond with "Recognizing," entering the normal processing flow (to avoid timeout). After request 2 successfully updates, the count value is 1 (not exceeding the threshold of 5), so request 2 enters the normal account processing flow (synchronous parallel processing, proceeding to step 5); when a subsequent request (such as request 6) causes the count value to exceed 5, the threshold is triggered, and the thread of request 6 enters asynchronous parallel processing; Step 4: When request 6 causes the count value to exceed the threshold, the system marks account A as "Upgrading" and starts an asynchronous hotspot upgrade task; the thread of request 6: after being marked as "Upgrading", immediately enters the hotspot account processing flow and uses asynchronous accounting methods (such as shadow accounts) to process the balance without waiting for the upgrade to complete.

[0052] Subsequent requests (such as requests 7-10): During the routing step (first step), these requests may detect that the account is already in the "upgrading" or "upgraded" state and directly jump to the asynchronous parallel processing flow. Asynchronous parallel processing includes balance verification and temporary transaction registration (to prevent overdraft). These operations are executed in parallel in the background and do not block request responses. During asynchronous processing, the system summarizes the data in the temporary transaction table to ensure balance consistency. After the hot account is fully upgraded, all new requests directly enter this process.

[0053] Step 5: Synchronize and process in parallel; Request 2's thread acquires a pessimistic lock on account A's balance table and performs atomic balance verification (consistent with traditional normal processing); to be compatible with hot threads, a temporary transaction record is added to the normal processing flow; Before updating the balance, request thread 2 to insert a record into the temporary transaction table, including the transaction amount and the status "processing"; The system summarizes the amount in the temporary transaction log in real time and compares it with the balance sheet to ensure that there is no overdraft under concurrent conditions (for example, when hot threads update the balance at the same time, the temporary transaction log summary prevents overdraft). After the balance is updated, request thread 2 to change the temporary transaction status to "processed" to reduce the burden of hotspot aggregation; If the account is in the "Upgrade" phase, this step will detect and complete hotspot marking to ensure that subsequent requests go directly into asynchronous processing.

[0054] In this step, request 2 (normal processing) and request 6 (hotspot processing) run simultaneously: request 2 follows a synchronous process with pessimistic locking, while request 6 follows an asynchronous process without locking; a temporary flow table acts as a bridge to ensure that the balance operations of the two do not conflict.

[0055] Advantages of this invention: This invention employs an optimistic locking-based serial processing technology for identifying hotspots in bank accounts, providing real-time dynamic identification and hotspot escalation capabilities. During the hotspot identification process, it enables parallel processing of asynchronous hotspot processing and synchronous normal processing. Furthermore, there is no business response rejection due to hotspot escalation during hotspot identification, achieving real-time dynamic identification of hotspots and stable processing of multiple concurrent accounts, thus improving the user experience.

[0056] 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 parallel processing method for hotspot identification of bank accounts based on optimistic locking, characterized in that, include: Receive account operation requests initiated by external systems; Determine whether the account has been marked as a hot account; If the account is not marked as a hotspot account, a hotspot window check is performed, which includes: determining a preset time window and detecting concurrent operations within the time window; The concurrent operations within the time window are counted based on an optimistic locking mechanism, wherein the optimistic locking mechanism includes version number control and cyclic update operation. When the count exceeds the preset hotspot threshold, the account will be automatically upgraded to a hotspot account and switched to hotspot processing mode; In the process of identifying account hotspots, the account supports the parallel execution of ordinary account processing operations and hotspot account processing operations.

2. The method for parallel processing of bank account hotspot identification upgrade based on optimistic locking according to claim 1, characterized in that, The hotspot window check specifically includes: When the first account operation is triggered, the start time of the time window is recorded, and the window period is the start time plus a preset duration. For subsequent account operations, determine whether they fall within the aforementioned time window: If it falls within the time window, it participates in the concurrent operation count of that time window; If the time window falls outside the specified time window, a new time window will be created. The account operation that triggers the creation of a time window will directly enter the normal account processing flow after the time window is created.

3. The parallel processing method for hotspot identification and upgrade of bank accounts based on optimistic locking according to claim 1, characterized in that, The optimistic locking-based counting mechanism includes: When the concurrent operation count of an account operation is detected within the specified time window, query the current count value and version number. Update the counter value and version number using the query results as the update condition; If the update is successful, a threshold comparison is performed with the preset hotspot threshold. If the update fails, it will be retried repeatedly until the maximum number of attempts is reached, at which point the system will respond directly to the account's operation.

4. The method for parallel processing of bank account hotspot identification upgrade based on optimistic locking according to claim 3, characterized in that: If the update is successful, the account operation will enter a synchronous parallel processing flow.

5. The method for parallel processing of bank account hotspot identification upgrade based on optimistic locking according to claim 3, characterized in that, The threshold determination is performed against the preset hotspot threshold, including: If the updated count value does not exceed the preset hotspot threshold, the account operation will proceed to the normal account processing flow. If the updated count value exceeds the preset hotspot threshold, the account will be automatically upgraded to a hotspot account, and the operation of the account will enter an asynchronous parallel processing flow.

6. The parallel processing method for hotspot identification and upgrade of bank accounts based on optimistic locking according to claim 5, characterized in that: The account is automatically upgraded to a hot account, and operations on this account enter an asynchronous parallel processing flow, including: When the thread that triggers the upgrade of an account to a hot account is in the process of upgrading, the hot account markers of some threads of that account instantly change to upgrading, not upgraded, and upgraded, and at the same time enter the normal account processing flow. Subsequent threads of that account enter the hot account balance processing flow. At this time, the threads that are upgrading, not upgraded, and upgraded are processed synchronously and in parallel in the normal account processing flow. When the thread that triggered the account upgrade to a hot account is upgraded to a hot account thread, that thread also enters the hot account balance processing flow, and the account operation enters the asynchronous parallel processing flow.

7. The parallel processing method for hotspot identification and upgrade of bank accounts based on optimistic locking according to claim 1, characterized in that, The switching of the hotspot processing mode includes asynchronous parallel processing and synchronous parallel processing: During the process of upgrading an account to a hotspot, other operations do not need to wait and can directly enter the hotspot account balance processing flow for asynchronous parallel processing. In the normal account processing flow, threads that are compatible with hotspot upgrades are processed synchronously and in parallel through temporary transaction registration and balance aggregation.

8. The method for parallel processing of bank account hotspot identification upgrade based on optimistic locking according to claim 7, characterized in that, The synchronous parallel processing specifically includes: In the processing of ordinary accounts, pessimistic locking is used for balance inquiries; Register temporary transaction records for balance verification under concurrent conditions; Summarize temporary transaction amounts to prevent overdrafts; Update temporary transaction status and officially mark an account as a hot account when it is upgraded.

9. A parallel processing device for hotspot identification of bank accounts based on optimistic locking, used to implement the method of any one of claims 1-5, characterized in that: The device includes a hotspot routing module, a hotspot window checking module, an optimistic locking counting module, and a parallel processing module. It operates in a distributed environment and does not introduce a central node. The hotspot routing module is used for: Receive requests and determine the account's hotspot status; The hotspot window checking module is used for: Manage time windows and concurrent detection; The optimistic locking counting module is used for: Implement concurrent safe counting; The parallel processing module is used for: It supports both asynchronous and synchronous processing flows.

10. The bank account hotspot identification and upgrade parallel processing device based on optimistic locking according to claim 9, characterized in that, The device also provides real-time hotspot identification and upgrade capabilities, which are triggered immediately when a hotspot occurs, without the need for prior prediction or post-event analysis; it supports high-concurrency requests and eliminates thread waiting through optimistic locking.

Images