Search

CN-121981829-A - Method for realizing system hot spot account processing

CN121981829ACN 121981829 ACN121981829 ACN 121981829ACN-121981829-A

Abstract

The invention discloses a method for realizing system hot account processing, which comprises the following steps of receiving a transaction request aiming at a target account, counting access frequency, dynamically identifying whether the target account is the hot account, executing atomic accumulation operation on balance change increment values corresponding to the target account in a distributed cache when the target account is identified as the hot account, carrying out real-time balance verification on the balance change increment values corresponding to the target account based on accumulation results and pre-stored account reference balances, returning a transaction processing success response after verification, atomising and obtaining the accumulated change increment values of all the hot accounts from the distributed cache through a timing scheduling task, clearing the accumulated change increment values, generating batch update instructions based on the obtained accumulated change increment values, and executing the batch update instructions in database transactions. The calculation load of the high-frequency transaction is transferred from the database to the high-performance memory, so that the transaction processing capacity of the system is improved by orders of magnitude, the response delay is reduced from the second level to the millisecond level, and the high-concurrency real-time scene is satisfied.

Inventors

  • WANG PENGFEI
  • LI QIANG

Assignees

  • 河南中原消费金融股份有限公司

Dates

Publication Date
20260505
Application Date
20260123

Claims (10)

  1. 1. The method for realizing the processing of the hot spot account of the system is characterized by comprising the following steps: receiving a transaction request for a target account; Counting the access frequency of the target account based on a sliding time window algorithm, and dynamically identifying whether the target account is a hot spot account or not according to comparison of a counting result and a preset threshold value; When the target account is identified as a hot account, performing atomic accumulation operation on a balance change increment value corresponding to the target account in a distributed cache, performing real-time balance verification based on an accumulation result and a pre-stored account reference balance, and immediately returning a transaction processing success response after verification is passed; Periodically acquiring the accumulated change increment value of each hot spot account from the distributed cache in an atomization way through a timing scheduling task, clearing the accumulated change increment value, and generating a batch update instruction based on the acquired accumulated change increment value; Executing the batch updating instruction in the database transaction to update the balance of each hot spot account in the database in batches, and synchronously updating the corresponding account reference balance in the distributed cache after successful updating.
  2. 2. The method for implementing system hot-spot account processing as claimed in claim 1, wherein said dynamically identifying whether said target account is a hot-spot account comprises: creating a count key for the target account in the distributed cache; in response to each access request for the target account, atomically performing a self-increment operation on the count key by a preloaded Lua script, and checking the lifetime of the count key to maintain a sliding time window; judging whether the count value of the count key in the sliding time window exceeds the preset threshold value or not; If yes, marking the target account as a hot spot account and adding the hot spot account into a hot spot account pool of a local application cache.
  3. 3. The method for implementing system hot spot account processing according to claim 1, wherein the performing an atomic accumulation operation on the balance change increment value corresponding to the target account in the distributed cache specifically includes: And performing atomic floating point number accumulation on the numerical value of an increment key prefixed by the target account identifier by using INCRBYFLOAT commands of the distributed cache, wherein the increment key is independent of a key for storing the account reference balance.
  4. 4. The method for implementing system hot spot account processing as claimed in claim 3, wherein the real-time balance verification is performed based on the accumulated result and a pre-stored account reference balance, specifically comprising: If the transaction request is a deduction request, reading the current values of the account reference balance and the increment key after the atomic accumulation operation is executed; calculating the sum of the account reference balance and the current value; And if the sum is smaller than zero, judging that the balance is insufficient, and executing reverse accumulation on the numerical value of the increment key to rollback the atomic accumulation operation.
  5. 5. The method for implementing system hot-spot account processing as claimed in claim 1, wherein said periodically obtaining and zeroing the cumulative delta value of each hot-spot account from the distributed cache includes: the timing scheduling task is triggered at a configurable time interval; scanning increment keys corresponding to all hot spot accounts in the distributed cache when triggering each time; For each of the delta keys, the GETSET command or GETDEL command is used to atomically fetch its current value and simultaneously reset the value of that key to zero.
  6. 6. The method for implementing system hot spot account processing according to claim 1, wherein the generating a batch update instruction based on the obtained accumulated delta variation value specifically comprises: filtering out the hot spot account with the accumulated change increment value of zero; Generating a parameterized balance update SQL statement for each other hot spot account, wherein the SQL statement is used for increasing the account balance in the database by the accumulated change increment value; and combining a plurality of SQL sentences into a batch database operation task.
  7. 7. The method for implementing system hot spot account processing according to claim 1, wherein the executing the batch update instruction in a database transaction specifically comprises: Placing a plurality of update sentences contained in the batch update instructions into the same database transaction for submitting execution; After the database transaction is successfully executed, inquiring from a database or acquiring the updated latest balance of each hot spot account through the returned result of the update statement; And using the pipeline technology of the distributed cache to write the latest balance of each hot spot account into the corresponding account reference balance key in batches.
  8. 8. The method for implementing system hot spot account processing according to claim 1, wherein the method further comprises an exception handling mechanism: if the distributed cache fails, the system is degraded to directly and synchronously write the transaction request into a database, and the asynchronous incremental information is recorded, and after the distributed cache is recovered, data retrieval is executed; if the database transaction fails to execute, the corresponding batch update instruction is recorded to a pre-write log, and an independent retry service performs asynchronous retry according to an exponential backoff strategy.
  9. 9. The method for implementing system hot spot account processing according to claim 1, further comprising a final consistency assurance step: starting independent checking and compensating service, periodically scanning account balance in a database and corresponding account reference balance and variation increment value in the distributed cache; Comparing the balance of the formula database with the buffer reference balance and the buffer fluctuation increment value, and if the difference exceeds the allowable error range, generating an alarm and triggering a compensation task; The compensation task calibrates inconsistent data based on a pre-written operation log or database transaction log.
  10. 10. The method for implementing system hot spot account processing according to claim 1, wherein the execution interval of the timing scheduling task and the number of update sentences contained in the batch update instruction are dynamically adjusted according to the system monitoring index; The system monitoring index comprises CPU load of a database host, utilization rate of a database connection pool and the number of variable increment keys in the distributed cache; When the monitor indicator displays that the system pressure increases, the execution interval is automatically lengthened and/or the number of update sentences of single batch processing is reduced.

Description

Method for realizing system hot spot account processing Technical Field The invention belongs to the field of financial science and technology, and relates to a method for realizing system hot spot account processing. Background In financial transaction systems, there are a small number of accounts that are accessed concurrently at extremely high frequency over a particular period of time, such accounts being referred to as "hot spot accounts. The traditional centralized transaction model based on the relational database faces serious challenges when dealing with such a scenario that all updating operations on the balance of the same account need to obtain and hold the row locks of the database records in a serialization manner, so that a large number of concurrent transactions are queued, the transaction capability (TPS) of the database is caused to be rapidly reduced, the response delay (Latency) is increased, and the throughput and the expansibility of the whole system are finally restricted. There are several typical solutions to this problem, but there are significant limitations to the industry: account barreling (Account Sharding) technology, namely physically splitting a logical hot-spot account into a plurality of sub-accounts, and dispersing transaction traffic in a hash mode and the like. The scheme can reduce the heat of single database records, but the business logic is complicated, and the scheme relates to balance summarization, sub-account selection, dynamic routing and the like, and has high development and maintenance cost. Transaction consistency is difficult to guarantee, atomicity is difficult to guarantee when deducting money or transferring money across multiple sub-accounts, and a complex distributed transaction mechanism needs to be introduced to sacrifice performance or consistency. The flexibility is poor, once the barrel policy is determined, the adjustment is difficult, and new hot spot unevenness can be caused by service change. And (3) caching account balance into a high-performance memory database based on an asynchronous database-falling scheme of Redis and other caches, and finishing balance updating in the cache and asynchronously synchronizing the balance to a back-end database during transaction. Although the scheme can greatly improve the reading and writing speed, the main defects are that a data inconsistent window period exists, and asynchronous synchronization between the cache and the database has delay, so that the application can read out an overdue balance or an error balance under extreme conditions, and the basic requirement of a financial system on the strong data consistency is violated. The insufficient balance of the borrower is complex to process, and under the mode of 'caching deduction firstly and then asynchronously falling down to the warehouse', the deduction in the cache is successful, but under the condition that the balance of the actual database is insufficient, complex fund checking, flushing and rollback mechanisms are required to be designed, so that the complexity and risk of the system are increased. The reliability of the cache is strong, the whole scheme is highly dependent on the availability of the cache service and the data persistence capability, and the service interruption or the data loss can be caused by the cache fault. And the serializing queue processing scheme is used for placing all requests for the same hot spot account into a memory queue and sequentially processing the requests by a single working thread or process. The method avoids lock contention by forcing serialization. However, inherent disadvantages include high processing delays, requests having to be queued, and even a single process is fast, queue latency results in a significant increase in average response time, making it difficult to meet transaction scenarios with high real-time requirements. The single-point processing capability is bottleneck, the queue consumer is a single point, the upper limit of the processing capability determines the overall throughput of the hot spot account, and multi-core or multi-machine resources cannot be fully utilized for horizontal expansion. The system resource utilization rate is low, and under the high concurrency scene, a large number of threads/connections are in a blocking or idle state due to waiting for a queue result. In summary, when dealing with high concurrency scenarios of financial hot-spot accounts, it is often difficult to achieve an ideal balance among data strong consistency, high processing throughput, low latency response, and system level expansion capability. Therefore, a new technical scheme is needed to fundamentally relieve or eliminate the database lock competition, and simultaneously ensure the real-time performance and accuracy of the transaction and the high expandability of the system. Disclosure of Invention The invention aims to solve the problem that ideal balance among data strong consistency,