Efficient processing system and method for hot account based on redis, flink and timing task, computer and storage medium

Abstract

The application discloses a hot account efficient processing system and method based on Redis, Flink and timing tasks, a computer and a storage medium, hot account early warning information and balance caching are stored based on Redis; account transaction pen numbers are summarized based on Flink, and hot accounts are warned; asynchronous account entry bottom and balance checking are realized based on timing tasks, Flink failure or data loss during publishing is avoided. The application improves system response speed and processing efficiency, enhances data accuracy and consistency, improves system stability and reliability, optimizes resource utilization and cost control, and enhances risk prevention and control capability.

Description

Technical Field

[0001] This invention relates to the fields of financial transactions and internet payments, specifically to a system, method, computer, and storage medium for efficiently processing hot accounts based on Redis, Flink, and scheduled tasks. Background Technology

[0002] In many fields such as financial transactions and internet payments, account management is a key component of core business processes, and the issue of "hot accounts" is becoming increasingly prominent. Hot accounts, due to their frequent transactions, large fund flows, and high user attention, place extremely high demands on the timeliness, accuracy, and system stability of data processing.

[0003] However, existing technologies generally suffer from numerous pain points and limitations when handling hot accounts. First, their real-time processing capabilities for hot account data are insufficient. Traditional batch processing methods typically rely on scheduled tasks for batch aggregation, a model that struggles to meet the high concurrency and real-time requirements of hot account transactions. This results in significant data processing delays, failing to reflect changes in account status promptly and consequently impacting the timeliness of business decisions. For example, in the "Double 11" shopping festival scenario on third-party payment platforms, a large number of users simultaneously make payments. Real-time fund changes in hot accounts are crucial to the transaction experience for both merchants and users, but data delays can lead to transaction failures, order timeouts, and even delayed payment information updates, severely impacting user experience.

[0004] In addition, the sheer volume of data is a major challenge for traditional processing methods. During peak periods, popular accounts generate massive amounts of transaction data, which can easily cause performance bottlenecks in traditional systems, leading to slower data transmission speeds, processing queue backlogs, and frequent errors. For example, during peak offline payment periods, numerous merchant accounts simultaneously receive a large number of payment requests. Traditional systems may be unable to process these requests efficiently, resulting in issues such as incorrect payment information, duplicate charges, or delayed payments, causing considerable inconvenience and disputes for both merchants and consumers.

[0005] Meanwhile, existing technologies also face bottlenecks in resource consumption and system complexity. To cope with high-concurrency access from popular accounts, traditional systems often require the deployment of large amounts of hardware resources and complex software architectures. This not only significantly increases system costs but also greatly increases the difficulty of system operation and maintenance, requiring substantial server investment and support from professional operation and maintenance teams. For example, third-party payment platforms often face excessive system pressure when handling a large number of users' simultaneous transfers and inquiries, requiring continuous expansion of hardware resources to meet the demand. However, such expansion cannot fundamentally solve problems such as insufficient real-time performance and frequent errors.

[0006] In summary, the existing technology has the following problems:

[0007] Problem 1: Insufficient processing latency and real-time performance: Traditional systems rely on scheduled tasks for batch processing. In high-concurrency scenarios (such as the "Double 11" shopping festival), data latency may reach several minutes or even longer, resulting in a large number of failed transactions and a degraded user experience.

[0008] Question 2: Resource Consumption and System Complexity: Traditional systems require the deployment of large amounts of hardware resources and complex software architectures to cope with high-concurrency access from popular accounts. For example, during the "Double 11" shopping festival, a third-party payment platform increased its server resource investment by more than 50%, requiring its operations and maintenance team to monitor and maintain the system 24 / 7, resulting in high costs and difficulty in adapting to rapid business changes.

[0009] Question 3: Data Processing Accuracy and System Stability: Traditional systems exhibit significant performance bottlenecks when handling massive amounts of transaction data from popular accounts during peak periods. For example, during a peak offline payment period, a payment platform received over 1,000 transaction requests per second, with system response delays reaching several minutes. This resulted in issues such as incorrect payment information, duplicate charges, or delayed payments, leading to a high error rate and severely impacting the interests of merchants and consumers.

[0010] Question 4: Lack of efficient monitoring and management mechanisms: Traditional systems lack dynamic monitoring and real-time early warning mechanisms for frequently accessed accounts. For example, during a promotional campaign on a payment platform, the inability to monitor the activity of frequently accessed accounts in real time and the failure to promptly detect issues such as insufficient account balances led to a large number of failed transactions, significantly increasing system risk.

[0011] Therefore, there is an urgent need for an innovative technical solution that can rapidly process massive amounts of transaction data, ensuring data accuracy and consistency, while also possessing good scalability and maintainability. This solution should reduce reliance on traditional scheduled tasks and batch processing, decrease system resource consumption and operational costs, and improve account management efficiency to better adapt to the rapid changes and development needs in fields such as internet finance and payment settlement. Summary of the Invention

[0012] The purpose of this invention is to provide an efficient system, method, computer, and storage medium for handling hot accounts based on Redis, Flink, and scheduled tasks.

[0013] The technical solution to achieve the purpose of this invention is as follows: a high-efficiency hot account processing system based on Redis, Flink, and scheduled tasks. The system uses Redis to store hot account warning information and cached balances; Flink to aggregate account transaction counts and issue warnings for hot accounts; and scheduled tasks to implement asynchronous crediting and balance checks to prevent data loss and inconsistency.

[0014] The hot account management module is used to monitor and set up hot accounts. By reading the hot account cache list of Flink alerts, it provides a list of recent hot accounts and the specific maximum concurrency per unit time. For hot accounts, it reads the account balance from the database and caches it in Redis to complete the hot account settings.

[0015] The deposit request acceptance module receives deposit requests for adding or subtracting account balances. Based on the account information in the request data, it reads the configuration information of hot accounts stored in Redis. For non-hot accounts, it directly performs the addition or subtraction operation on the account balance and sends the deposit request details to the Kafka queue. For hot accounts, it needs to check whether the available balance of the account in the Redis cache is sufficient before the deduction operation, and update the account balance in the Redis cache according to the addition / deduction operation. It records the addition / deduction information in the hot account asynchronous deposit register and sends the registration information to the Kafka queue.

[0016] The Flink real-time stream processing and account-dimensional aggregation module reads account request details from the Kafka queue in real time based on Flink. For account request details of non-hot accounts, it counts the number of requests per second, issues alerts for hot accounts, and synchronizes the alert information to Redis. For account request details of hot accounts, it aggregates the account request details according to a preset frequency and organizes them into messages.

[0017] The Hot Account Inbound Module is used to process inbound requests that have been aggregated by Flink or scheduled tasks, perform batch inbound operations on the actual account balance, update the asynchronous inbound register of the account according to the detailed serial number in the request message, change the pending inbound status to the inbound status, and ensure that the balance update and status change are completed in the same transaction.

[0018] The end-of-day fallback scheduled task module is used to query the database for data on pending account status when hot accounts fail to receive payments, and summarize the data by account dimension. Also, at the end of the day, it checks whether the account balance in the Redis cache is consistent with the database balance.

[0019] Furthermore, the hot account management module provides a one-click setup function for hot accounts.

[0020] Furthermore, in the invoice request acceptance module, for the deduction operation of hot accounts, it checks whether the account balance in the Redis cache is sufficient. If the balance is insufficient, it directly returns a "Balance Insufficient" prompt message; if the balance is sufficient, it deducts the corresponding amount from the cache, records the deduction information in the hot account asynchronous invoice register, and sends the relevant registration information to the Kafka queue.

[0021] Furthermore, the Flink real-time stream processing and account-level aggregation module counts the number of requests per second for non-hot accounts, calculates the number of times the number of requests exceeds the system's maximum single-transaction concurrency within the statistical period, and sorts accounts based on the frequency of high concurrency to issue warnings for hot accounts.

[0022] Furthermore, the Flink real-time stream processing and account-level aggregation module provides a flow control mechanism for occasional hyperconcurrency situations. If hyperconcurrency occurs frequently within a period of time, these accounts should be designated as hot accounts based on the judgment of the operations personnel.

[0023] Furthermore, the Flink real-time stream processing and account-level aggregation module aggregates the account request details of hot accounts according to a preset frequency and organizes them into messages. The message content includes the account number, the aggregated detail serial number, and the difference between the balance of the batch and the amount of the difference.

[0024] Furthermore, the hot account entry module also checks whether the number of updated details matches the request. If they match, the transaction is committed and a success is returned; otherwise, the transaction is rolled back and an exception is returned.

[0025] A method for efficiently handling hot accounts based on Redis, Flink, and scheduled tasks is proposed. This method utilizes the aforementioned system for efficiently handling hot accounts based on Redis, Flink, and scheduled tasks to implement efficient hot account processing, including:

[0026] Hotspot Management and Alerts: Displays a list of hot accounts and their maximum concurrency per unit time, and supports one-click setting of hot accounts; at the same time, Flink counts the number of requests per second in real time, and combines the alert configuration to sort by the frequency of high concurrency and synchronize it to the Redis cache to achieve real-time alerts for hot accounts;

[0027] Flexible deposit: Different processing strategies are adopted according to different account types. Non-frequent accounts will directly complete the balance addition and subtraction operations; for frequent accounts, the addition operation will be directly recorded and the cache balance will be increased, while the subtraction operation will check the balance first before processing.

[0028] Real-time stream processing and aggregated accounting: Flink aggregates accounting request details by account, organizes the aggregated messages according to a preset frequency, and calls the hot account accounting module to achieve batch accounting;

[0029] Data integrity assurance: Handle accounting failures caused by Flink exceptions, query the database for data in the pending accounting status and summarize it by account, and call the hot account accounting module for processing.

[0030] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the aforementioned method for efficient handling of hot accounts based on Redis, Flink, and scheduled tasks.

[0031] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the aforementioned method for efficient handling of hot accounts based on Redis, Flink, and scheduled tasks.

[0032] Compared with the prior art, the significant advantages of this invention are:

[0033] 1. Improve system response speed and processing efficiency: Leveraging Redis's efficient caching capabilities, quickly query hot account alert information and perform balance checks to ensure rapid judgment before transaction processing, thereby improving system response speed. Flink's real-time stream processing capabilities can quickly aggregate account transaction counts, promptly alert users to hot accounts, avoid system overload, and aggregate pending transaction details in near real-time, enabling rapid batch processing and significantly improving the processing efficiency of hot accounts.

[0034] 2. Enhance data accuracy and consistency: During the process of crediting frequently accessed accounts, a transaction mechanism ensures the atomicity of balance updates and status changes, avoiding data inconsistencies. Simultaneously, a scheduled task mechanism for verifying database and cached balances can promptly detect and warn of data inconsistencies, facilitating timely intervention by operations and maintenance personnel, thereby enhancing the system's data accuracy and consistency.

[0035] 3. Improved System Stability and Reliability: The fallback mechanism of scheduled tasks effectively prevents posting failures due to Flink malfunctions or deployment issues, ensuring that all transactions are ultimately posted. End-of-day balance reconciliation and processing further guarantee system stability and reliability, reducing potential risks caused by data inconsistencies.

[0036] 4. Optimize resource utilization and cost control: By leveraging Flink's real-time stream processing and Redis's efficient caching, reliance on hardware resources is reduced, lowering system complexity and operating costs. Simultaneously, flexible accounting strategies and batch accounting operations reduce system call counts and resource consumption, improving resource utilization efficiency.

[0037] 5. Enhanced Risk Control Capabilities: Through a hot account early warning mechanism, the system can identify potential hot accounts in advance, allowing for timely intervention and handling, thus reducing system risks caused by high-concurrency transactions. Simultaneously, end-of-day balance verification effectively prevents overdraft risks and enhances the system's overall risk control capabilities. Attached Figure Description

[0038] Figure 1 Architecture diagram for efficient handling of hot accounts based on Redis, Flink, and scheduled tasks. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0040] like Figure 1 As shown, this invention integrates Redis, Flink, and scheduled tasks to achieve efficient handling of hot accounts. Redis stores hot account alert information and cached balances for alert queries and pre-transaction balance checks. Flink aggregates the number of account transactions for hot account alerts and summarizes pending invoice details in near real-time, calling the invoice interface to update the balance by account. Scheduled tasks handle asynchronous invoice backup and balance checks to prevent data loss and inconsistency, providing timely alerts for operations personnel to handle. Specifically:

[0041] Redis is used to store hot account alert information and hot account cached balances. During the hot account alert phase, it provides a query for the current hot account alert list; during the hot account balance crediting process, it determines whether the account has sufficient available balance before transaction acceptance.

[0042] Flink is used to aggregate the number of transactions per unit time for an account, provide alerts for hot accounts, and, if a hot account is configured, aggregate pending invoice details in near real-time, aggregate detail requests by account, and aggregate calls to the invoice interface to update the balance.

[0043] This scheduled task is used for asynchronous billing backup and balance checks to prevent the loss of asynchronous billing data during Flink failures or deployments. The task checks the pending billing details (details that have not been billed for a long time) in the database and compares the cached balance with the database balance. If they are inconsistent, an anomaly warning is issued to facilitate timely intervention by operations and maintenance personnel.

[0044] A high-efficiency hot account processing system based on Redis, Flink, and scheduled tasks, the core processing module includes:

[0045] (1) Hotspot Account Management Module

[0046] This module primarily serves system operators, enabling them to monitor and configure hotspot accounts. By reading the cached list of hotspot accounts from Flink alerts, it provides users with a list of recently active accounts and their maximum concurrency per unit time. It also offers a one-click hotspot account configuration function for accounts that frequently trigger alerts. During hotspot account configuration, the module reads the account balance from the database and caches it in Redis. This cached balance is used to check for sufficiency when processing incoming payments for hotspot accounts.

[0047] (2) Accounting Request Acceptance Module

[0048] This module handles account balance addition / subtraction requests initiated by external systems (such as payment systems, where users add or subtract account balances when making deposits or payments). Upon receiving a request, it reads the hot account configuration information stored in Redis based on the account information in the request data. Depending on the query results, the processing method falls into two categories:

[0049] A. Non-hotspot accounts:

[0050] The system directly calls the single balance change service to perform addition and subtraction operations on the account balance. Simultaneously, it sends the account request details to a Kafka queue so that Flink can perform concurrent period statistics for account transactions.

[0051] B. Popular Accounts:

[0052] Adding funds: The addition information (including account, currency, operation type (add / decrease), transaction amount, transaction number, and counterparty account) is directly recorded in the asynchronous deposit register of the hot account, and the account balance in the Redis cache is increased accordingly. Then, the registered information is sent to the Kafka queue.

[0053] Reduction operation: First, check if the account balance in the Redis cache is sufficient. If the balance is insufficient, return an "Insufficient balance" message directly. If the balance is sufficient, deduct the corresponding amount from the Redis cache and record the reduction information (including account, currency, operation type (add / deduct), transaction amount, transaction number, and counterparty account) in the hot account asynchronous deposit register. Finally, send the registration information to the Kafka queue.

[0054] (3) Flink Real-time Stream Processing and Account Dimension Summary Module

[0055] This module primarily leverages Flink's streaming computing capabilities to provide alerts for frequently accessed accounts and aggregate data for accounting purposes based on account type.

[0056] Based on the account request details sent by the inbound request acceptance module when processing non-hotspot accounts, Flink reads this detailed data from Kafka in real time and counts the number of requests per second. Combined with alert configuration, it calculates the number of times the number of requests exceeds the system's maximum concurrency limit within a statistical period and sorts accounts according to the frequency of high concurrency. These alerts are periodically synchronized to the Redis cache for quick querying and analysis. The key parameter of the alert configuration is the system's maximum concurrency limit. When the number of requests exceeds this value, due to database processing limitations, the system may not be able to effectively handle concurrent requests, and the relevant accounts need to be designated as hotspot accounts. For occasional hyperconcurrency, the system has a flow control mechanism to handle it. However, if hyperconcurrency occurs frequently over a period of time, based on the judgment of operations personnel, these accounts can be designated as hotspot accounts for more granular management and control.

[0057] Based on the account request details sent by the deposit request acceptance module when processing hot accounts, the system summarizes the deposit request details according to a preset frequency (configurable, the specific setting depends on the system's processing capacity, such as every 1 second, every 5 seconds, 10 seconds, etc.). The system organizes this summarized information into a message and calls the hot account deposit module. The message content includes key information such as the account number, the summarized transaction number (multiple entries), and the difference between the added and subtracted balances for this batch. Subsequently, the hot account deposit service is called to realize the batch deposit operation.

[0058] (4) Hotspot Account Inbound Module

[0059] This module is primarily responsible for processing posting requests aggregated by Flink or scheduled tasks, and performing posting operations such as adding or subtracting the actual account balance. During execution, it updates the account's asynchronous posting register based on the detailed transaction number in the request message, changing the pending posting status to the posted status, ensuring that the balance update and status change are completed within the same transaction. After the update, it checks whether the number of updated detailed entries matches the request. If they match, the transaction is committed and a success return is returned; otherwise, the transaction is rolled back and an exception is returned.

[0060] (5) End-of-day backup scheduled task module

[0061] This module is designed to prevent posting failures due to Flink concurrency issues, exceptions, or deployment problems. When a posting fails, the account's asynchronous posting register remains in the "pending posting" state. A scheduled task queries the database for data in the pending posting status, summarizes it by account, and then calls the hot account posting service for processing, ensuring that there are no unposted accounts for the day.

[0062] At the end of the day, this module also checks whether the account balance in the Redis cache matches the database balance to prevent data inconsistencies throughout the processing chain. If an inconsistency is found, it indicates that the balance is inaccurate and may pose an overdraft risk, requiring timely manual intervention.

[0063] This paper presents an efficient method for handling hot accounts based on Redis, Flink, and scheduled tasks. It utilizes Redis, Flink, and scheduled tasks for processing incoming transactions for these accounts. When handling balance addition / subtraction requests, Redis is used for rapid balance control without immediately updating the database, thus accelerating transaction processing. Balance updates in the database are performed in batches to ensure data consistency. Flink aggregates transactions over a certain period in near real-time, reducing database access frequency and significantly improving the concurrent processing capability for hot accounts. Scheduled tasks provide asynchronous incoming transaction fallback and balance checks to prevent data loss and inconsistency, and provide timely alerts for maintenance personnel to handle issues. Specifically, this includes:

[0064] (1) Hotspot Management and Early Warning

[0065] The system provides a hotspot account management tool, making it easy for operations personnel to monitor and configure hotspot accounts. It displays a list of hotspot accounts and their maximum concurrency per unit time, and supports one-click hotspot account configuration. Simultaneously, Flink provides real-time statistics on requests per second, and, combined with alert configurations, sorts these requests by frequency of high concurrency and synchronizes them to the Redis cache, enabling real-time alerts for hotspot accounts.

[0066] (2) Flexible accounting

[0067] The incoming payment request processing module adopts differentiated processing strategies based on different account types: non-hot accounts directly call the single balance change service to complete the balance addition or subtraction operation; hot accounts add funds directly register and increase the cached balance, while subtraction operations check the balance first before processing, thus improving system processing efficiency.

[0068] (3) Real-time stream processing and summary accounting

[0069] Flink summarizes the account request details sent by the invoice request processing module by account dimension, organizes the summarized messages according to the preset frequency, and calls the hot account invoice module to realize batch invoices and improve invoice processing efficiency.

[0070] (4) Data integrity assurance

[0071] The end-of-day fallback task is used to handle payment failures caused by Flink exceptions. It queries the database for data in the pending payment status and summarizes it by account. It then calls the payment service for hot accounts to process the data, ensuring data integrity and accuracy and preventing overdraft risks.

[0072] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the aforementioned method for efficient handling of hot accounts based on Redis, Flink, and scheduled tasks.

[0073] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the aforementioned method for efficient handling of hot accounts based on Redis, Flink, and scheduled tasks.

[0074] In addition, based on the above solution, a high-efficiency hot account processing system based on Redis, Flink and scheduled tasks was built, and the following functional tests were performed.

[0075] (1) Hotspot Account Management Module:

[0076] Warning information detection: The monitoring system allows real-time viewing of the list of hot accounts and the maximum concurrency per unit time in Flink warnings, verifying the accuracy of the warning function.

[0077] One-click setup detection: For accounts that frequently trigger alerts, a one-click hotspot account setup is performed to check whether the system correctly reads the balance from the database and caches it in Redis, ensuring the completeness and speed of the setup function.

[0078] (2) Invoice Request Processing Module:

[0079] Non-hotspot account detection: Send balance increase / decrease requests for non-hotspot accounts to check whether the system directly calls the single balance change service, and verify the correctness of the balance update and whether the details are correctly sent to the Kafka queue.

[0080] Hotspot account detection: Perform add and subtract funds for hotspot accounts, check whether the system correctly updates the Redis cache balance and records the operation in the asynchronous credit register, and verify whether the relevant details are accurately sent to the Kafka queue.

[0081] (3) Flink Real-time Stream Processing and Account Dimension Aggregation Module:

[0082] Early warning statistics and detection: By simulating high-concurrency requests, observe whether Flink accurately counts the number of requests per second and combine the early warning configuration to count the number of high-concurrency requests, thus verifying the reliability of its early warning function.

[0083] Summary posting check: Checks whether Flink summarizes posting request details according to the preset frequency, and verifies whether the summarized message content is correct, ensuring the accuracy and efficiency of batch posting operations.

[0084] (4) Hotspot Account Inbound Module:

[0085] Transaction consistency check: By submitting an accounting request containing multiple details, check whether the system correctly updates the account balance and the status of the asynchronous accounting register, and verify the correctness of transaction commit or rollback to ensure data consistency.

[0086] Anomaly handling detection: Simulate a situation where the number of updated detail records is inconsistent with the request to verify whether the system correctly rolls back the transaction and returns an exception, ensuring the stability and reliability of the system.

[0087] (5) End-of-day fallback scheduled task module:

[0088] Back-up payment detection: Simulate a back-up payment failure scenario caused by Flink failure or release, check whether the scheduled task can correctly query and summarize the data in the database that is pending payment, and verify the effectiveness of its back-up function.

[0089] Balance consistency check: At the end of the day, check whether the scheduled task accurately compares the Redis cache balance with the database balance, and verify whether the system issues an early warning in case of inconsistency, to ensure the accuracy and integrity of the data.

[0090] In summary, this invention provides an efficient, stable, and low-cost solution that effectively addresses the technical problems in existing hot account processing systems and can adapt to the needs of rapid modern business development.

[0091] Real-time monitoring and rapid processing: Leveraging Redis's high-performance caching and Flink's real-time streaming capabilities, we can monitor hot account activity in real time, rapidly process massive amounts of transaction data, and ensure the real-time nature and accuracy of data, thereby improving user experience and the timeliness of business decisions.

[0092] Optimize resource utilization: Leverage the distributed nature of Redis and Flink to optimize resource utilization, reduce dependence on hardware resources, reduce system complexity, and thus reduce hardware costs and maintenance difficulty.

[0093] Improve data processing accuracy and system stability: By using real-time stream processing and efficient data management mechanisms, avoid performance bottlenecks and data backlog issues in traditional batch processing methods, thereby improving system stability and data processing accuracy.

[0094] Provides an efficient management mechanism: introduces scheduled tasks for periodic data aggregation and status updates, combined with a real-time monitoring mechanism to ensure data consistency and integrity, while simplifying the management of hot accounts and improving the system's flexibility and adaptability to meet the rapidly developing needs of hot account processing in fields such as internet finance and payment settlement.

[0095] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0096] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these modifications and improvements all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A high-efficiency hot account processing system based on Redis, Flink, and scheduled tasks, characterized in that, Hot account alerts and cached balances are stored using Redis; hot account alerts are generated by aggregating account transaction counts using Flink. Implement asynchronous deposit backup and balance checks based on scheduled tasks to prevent data loss and inconsistency, including: The hot account management module is used to monitor and set up hot accounts. By reading the hot account cache list of Flink alerts, it provides a list of recent hot accounts and the specific maximum concurrency per unit time. For hot accounts, it reads the account balance from the database and caches it in Redis to complete the hot account settings. The deposit request acceptance module receives deposit requests for adding or subtracting account balances. Based on the account information in the request data, it reads the configuration information of hot accounts stored in Redis. For non-hot accounts, it directly performs the addition or subtraction operation on the account balance and sends the deposit request details to the Kafka queue. For hot accounts, it needs to check whether the available balance of the account in the Redis cache is sufficient before the deduction operation, and update the account balance in the Redis cache according to the addition / deduction operation. It records the addition / deduction information in the hot account asynchronous deposit register and sends the registration information to the Kafka queue. The Flink real-time stream processing and account-dimensional aggregation module reads account request details from the Kafka queue in real time based on Flink. For account request details of non-hot accounts, it counts the number of requests per second, issues alerts for hot accounts, and synchronizes the alert information to Redis. For account request details of hot accounts, it aggregates the account request details according to a preset frequency and organizes them into messages. The Hot Account Inbound Module is used to process inbound requests that have been aggregated by Flink or scheduled tasks, perform batch inbound operations on the actual account balance, update the asynchronous inbound register of the account according to the detailed serial number in the request message, change the pending inbound status to the inbound status, and ensure that the balance update and status change are completed in the same transaction. The end-of-day fallback scheduled task module is used to query the data on the pending account status in the database when the hot account fails to receive funds, and summarize it by account dimension. Also, at the end of the day, it checks whether the account balance in the Redis cache is consistent with the database balance. in: The hotspot account management module provides a one-click setup function for hotspot accounts; The invoice request acceptance module checks whether the account balance in the Redis cache is sufficient for the deduction operation of hot accounts. If the balance is insufficient, it directly returns the "insufficient balance" prompt message; if the balance is sufficient, it deducts the corresponding amount from the cache, records the deduction information in the hot account asynchronous invoice register, and sends the relevant registration information to the Kafka queue. The Flink real-time stream processing and account-level aggregation module counts the number of requests per second for non-hot accounts, calculates the number of times the number of requests exceeds the system's maximum single-transaction concurrency within the statistical period, and sorts accounts based on the frequency of high concurrency to provide early warnings for hot accounts. The Flink real-time stream processing and account-level aggregation module provides a flow control mechanism for occasional hyperconcurrency situations. If hyperconcurrency occurs frequently within a period of time, these accounts should be designated as hot accounts based on the judgment of the operations personnel. The Flink real-time stream processing and account-dimensional aggregation module aggregates account request details for hot accounts at a preset frequency and organizes them into messages. The message content includes the account, the aggregated detail serial number, and the difference between the balance of the batch and the amount of the subtracted balance. The hot account entry module also checks whether the number of updated details matches the request. If they match, the transaction is committed and a success is returned; otherwise, the transaction is rolled back and an exception is returned.

2. A method for efficiently handling hot accounts based on Redis, Flink, and scheduled tasks, characterized in that, The system for efficient handling of hot accounts based on Redis, Flink, and scheduled tasks as described in claim 1 is used to implement efficient handling of hot accounts, including: Hotspot Management and Alerts: Displays a list of hot accounts and their maximum concurrency per unit time, and supports one-click setting of hot accounts; at the same time, Flink counts the number of requests per second in real time, and combines the alert configuration to sort by the frequency of high concurrency and synchronize it to the Redis cache to achieve real-time alerts for hot accounts; Flexible deposit: Different processing strategies are adopted according to different account types. Non-frequent accounts will directly complete the balance addition and subtraction operations; for frequent accounts, the addition operation will be directly recorded and the cache balance will be increased, while the subtraction operation will check the balance first before processing. Real-time stream processing and aggregated accounting: Flink aggregates accounting request details by account, organizes the aggregated messages according to a preset frequency, and calls the hot account accounting module to achieve batch accounting; Data integrity assurance: Handle accounting failures caused by Flink exceptions, query the database for data in the pending accounting status and summarize it by account, and call the hot account accounting module for processing.

3. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, it implements the efficient hot account processing method based on Redis, Flink, and scheduled tasks as described in claim 2.

4. A computer-readable storage medium having a computer program stored thereon, wherein when executed by a processor, the computer program implements the efficient hot account processing method based on Redis, Flink, and scheduled tasks as described in claim 2.

Images