A method and system for handling high concurrency issues of frequently accessed accounts based on master and sub-accounts

Abstract

This invention provides a method and system for handling high concurrency issues of hot accounts based on master-sub-accounts, relating to the core accounting system technology field within the FinTech sector. The method includes: based on the existence of transaction details marked as "ready to be recorded" in the pending transaction details table, batch reading these transaction details using a scheduled task, and batch updating the balance of the master account based on the read transaction details to complete the accounting processing. This invention effectively solves the high concurrency problem of hot accounts in financial systems through master-sub-account splitting and batch processing mechanisms, improving processing efficiency and ensuring system stability.

Description

Technical Field

[0001] This invention relates to the field of core accounting system technology in the field of financial technology (FinTech), and in particular to a method and system for handling high concurrency issues of hot accounts based on master and sub-accounts. Background Technology

[0002] In the fintech field, handling high concurrency of frequently accessed accounts in core accounting systems remains a significant technical challenge. Frequently accessed accounts refer to specific accounts that are accessed by a massive number of transactions within a short period, such as payment accounts on large e-commerce platforms or accounts used for promotional activities involving red envelopes. Under traditional accounting architectures, these accounts are highly susceptible to becoming system performance bottlenecks due to resource contention.

[0003] Currently, the financial industry generally uses consolidated accounting solutions to address this challenge. These solutions reduce the frequency of real-time updates to the master account balance by merging multiple transactions within a specific time window. However, this approach has the following drawbacks in terms of data processing:

[0004] First, although consolidated accounting reduces the frequency of balance updates, all concurrent transactions still require locking the same master account resources to ensure data consistency. In high-concurrency scenarios, frequent locking operations can lead to a sharp drop in system throughput and a significant increase in transaction latency. Second, the consolidated accounting model shifts the concurrency pressure from balance updates to transaction table operations. A large number of concurrent insertion, summary calculations, and status update operations create table-level hotspots on the transaction table, causing severe disk I / O contention and index contention. Third, the core processing object of the existing solution is still a single master account entity. This centralized data processing model has inherent scalability defects, making it impossible to linearly improve system performance by adding computing nodes. When facing extremely high-concurrency scenarios such as Double Eleven and flash sales, system throughput quickly approaches its architectural bottleneck, resulting in a severe performance inflection point that may restrict the system's elastic scaling capabilities. Finally, to ensure fund security, the system must maintain strong consistency, which usually requires locking mechanisms in high-concurrency environments, which in turn restricts processing efficiency and real-time response capabilities. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a method and system for handling high concurrency of hot accounts based on master and sub-accounts. By splitting master and sub-accounts and batch processing mechanism, the high concurrency of hot accounts in the financial system is effectively solved, the processing efficiency is improved and the system stability is guaranteed.

[0006] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0007] Firstly, a method for handling high concurrency issues of frequently accessed accounts based on master-sub-accounts, the method comprising:

[0008] Receive accounting transaction requests that include the transaction type and transaction amount;

[0009] In response to the accounting transaction request, the accounting transaction request is routed to the corresponding target sub-account according to the transaction type and transaction amount;

[0010] Based on the target sub-account, the lending and borrowing directions of the accounting transaction requests are identified; for debit transactions, the transaction amount and lending and borrowing directions are inserted into the temporary stop payment table, and the records in the temporary stop payment table are netted to determine the available balance. If the available balance is sufficient, the transaction details are moved to the pending details table; if the available balance is insufficient, a fund transfer request is generated; for credit transactions, the transaction details are recorded in the pending details table.

[0011] The process for processing the fund transfer request involves obtaining multiple performance indicator data by querying the fund transfer history, generating transfer control parameters based on the multiple performance indicator data using a predefined evaluation strategy, determining the priority and amount of the fund transfer according to the transfer control parameters, and transferring funds from the fund pool sub-account, other transaction sub-accounts, or overdraft sub-accounts to the sub-account initiating the transfer based on the determined priority and transfer amount. After completing the fund transfer operation, the transaction details corresponding to the fund transfer request are moved from the temporary stop payment table to the pending details table and marked as available for recording.

[0012] Based on the transaction details in the pending details table that are marked as recordable, the transaction details marked as recordable are read in batches through a scheduled task, and the balance of the main account is updated in batches based on the read transaction details to complete the accounting process.

[0013] Secondly, a system for handling high concurrency issues of frequently accessed accounts based on master-sub-accounts includes:

[0014] The receiving module is used to receive accounting transaction requests that include the transaction type and transaction amount;

[0015] The routing module is used to respond to the accounting transaction request and route the accounting transaction request to the corresponding target sub-account according to the transaction type and transaction amount;

[0016] The processing module is used to process accounting transaction requests on the target sub-account. For debit transactions, the transaction amount and debit / credit direction are inserted into the temporary stop payment table, and the records in the temporary stop payment table are netted to determine the available balance. If the available balance is sufficient, the transaction details are moved to the pending details table. If the available balance is insufficient, a fund transfer request is generated.

[0017] The scheduling module is used to process the fund transfer request. It obtains multiple performance index data by querying the fund transfer history, and generates transfer control parameters based on the multiple performance index data through a predefined evaluation strategy. It determines the priority and amount of fund transfer according to the transfer control parameters, and transfers funds from the fund pool sub-account, other transaction sub-accounts or overdraft sub-accounts to the sub-account that initiated the transfer according to the determined priority and transfer amount. After the fund transfer operation is completed, the transaction details corresponding to the fund transfer request are moved from the temporary stop payment table to the pending details table and marked as registrable.

[0018] The batch synchronization module is used to read transaction details marked as recordable in the pending details table in batches through a scheduled task, and update the balance of the main account in batches based on the read transaction details to complete the accounting process.

[0019] Thirdly, a computing device, comprising:

[0020] One or more processors;

[0021] A storage device for storing one or more programs that, when executed by one or more processors, cause the one or more processors to implement the method.

[0022] Fourthly, a computer-readable storage medium storing a program that, when executed by a processor, implements the method.

[0023] The above-described solution of the present invention has at least the following beneficial effects:

[0024] It receives accounting transaction requests containing transaction type and amount, quickly obtaining the core basic information required for accounting processing. This ensures the integrity and validity of the requested data, providing clear data support for subsequent routing and classification, and preventing process interruptions due to missing key information. It routes requests to corresponding target sub-accounts based on transaction type and amount, achieving precise distribution of transaction requests and avoiding resource competition caused by all transactions converging on the main account. Simultaneously, it ensures precise matching of transactions with sub-account functions, improving the overall targeting and efficiency of transaction processing. It processes transactions differently based on borrowing / debiting direction. Debit transactions are precisely controlled through netting calculations to ensure compliant fund deductions, triggering transfers to ensure transaction continuity when insufficient funds are available. Credit transactions are directly recorded to... The pending processing details table simplifies processes and improves efficiency, enabling standardized management of transaction data. Performance indicators extracted from historical records generate allocation control parameters, providing data support for fund allocation decisions. Prioritization ensures critical needs are processed first, and multiple funding sources guarantee allocation feasibility. After allocation, transaction details are migrated and marked as recordable, achieving seamless integration of allocation and accounting processes and ensuring continuous and traceable data flow. Scheduled tasks process recordable details in batches, reducing the frequency of main account balance updates and lowering resource consumption and lock contention. Batch updates of the main account balance improve accounting processing efficiency while ensuring consistency between the main account balance and transaction details, completing the accounting processing loop and guaranteeing the accuracy and integrity of accounting data. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating a method for handling high concurrency issues of hot accounts based on master and sub-accounts, provided by an embodiment of the present invention.

[0026] Figure 2 This is a schematic diagram of a system for handling high concurrency issues of hot accounts based on master and sub-accounts, provided by an embodiment of the present invention. Detailed Implementation

[0027] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0028] like Figure 1 As shown, an embodiment of the present invention proposes a method for handling high concurrency issues of hot accounts based on master and sub-accounts. The method includes the following steps:

[0029] Step 100: Receive an accounting transaction request containing the transaction type and transaction amount;

[0030] Step 200: In response to the accounting transaction request, the accounting transaction request is routed to the corresponding target sub-account according to the transaction type and transaction amount;

[0031] Step 300: Based on the target sub-account, identify the lending or borrowing direction of the accounting transaction request; for debit transactions, insert the transaction amount and lending or borrowing direction into the temporary stop payment table, and perform netting calculation on the records in the temporary stop payment table to determine the available balance. If the available balance is sufficient, move the transaction details to the pending details table; if the available balance is insufficient, generate a fund transfer request; for credit transactions, record the transaction details in the pending details table.

[0032] Step 400: Process the fund transfer request. Obtain multiple performance indicator data by querying the fund transfer history. Generate transfer control parameters based on the multiple performance indicator data using a predefined evaluation strategy. Determine the priority and amount of fund transfer according to the transfer control parameters. Transfer funds from the fund pool sub-account, other transaction sub-accounts, or overdraft sub-account to the sub-account that initiated the transfer according to the determined priority and transfer amount. After the fund transfer operation is completed, move the transaction details corresponding to the fund transfer request from the temporary stop payment table to the pending details table and mark it as available for accounting.

[0033] Step 500: Based on the transaction details marked as recordable in the pending details table, the transaction details marked as recordable are read in batches through a scheduled task, and the balance of the main account is updated in batches based on the read transaction details to complete the accounting process.

[0034] In this embodiment of the invention, the core key information of accounting transactions is clearly defined, providing a clear data foundation for subsequent transaction routing and processing. This ensures a standardized and efficient starting point for the data processing flow, guaranteeing the targeted and orderly nature of subsequent operations. Processing nodes are precisely allocated according to transaction attributes, distributing the transaction load on the main account. Parallel processing of sub-accounts enhances overall concurrent processing capabilities, reduces transaction queuing, and optimizes the efficiency of data processing diversion. Differentiated processing logic is adopted to distinguish between borrowing and lending directions. Debit transactions are monitored in real time through netting calculations to ensure the accuracy of account data. Credit transactions have simplified processing procedures for rapid accounting, improving the efficiency of single transaction data processing and avoiding data confusion or omissions. The allocation strategy is dynamically optimized based on actual performance indicators, making fund allocation more aligned with the system's operating status and ensuring rapid and accurate replenishment of funds. Funds are allocated in an orderly manner according to priority, making reasonable use of various account resources, maintaining transaction continuity, and improving the efficiency of fund data flow. Batch processing reduces the frequency of main account balance updates, lowers the frequency of resource lock operations, and reduces system resource competition. Regularly summarized updates ensure the consistency of main account data and sub-account data, improving the stability and efficiency of overall accounting data processing.

[0035] In a preferred embodiment of the present invention, step 100, receiving an accounting transaction request including a transaction type and a transaction amount, includes:

[0036] Step 101 involves receiving transaction request data packets sent by external systems. Specifically, this includes: a pre-configured communication interface adapted to the external system, such as an e-commerce platform transaction system or a third-party payment clearing system. This interface supports preset communication protocols such as RESTful API and WebSocket, and the system monitors the external system's request sending channel in real time through the interface. When the external system initiates a transaction request, it sends a structured transaction request data packet conforming to the aforementioned communication protocol to this system. This data packet contains three parts: a header, a body, and a checksum. The header records the data packet length, version number, and sender identifier; the body stores core transaction information; and the checksum is used for preliminary verification of data transmission integrity. After detecting the data packet transmission request, the system receives the data packet according to the following sequence: first, the header; then, the body; and finally, the checksum. During the reception process, metadata information such as the data packet reception time, sender IP address, and unique sequence number is recorded in real time. The fully received data packet is temporarily stored in the system's temporary data buffer, and the data packet in the buffer is initially identified (associated with the aforementioned metadata information) to ensure accurate location of the data packet in subsequent steps.

[0037] Step 102 involves parsing and verifying the received transaction request data packet to extract the transaction account identifier, transaction type, and transaction amount. Specifically, this includes: first, calling the system's preset data packet structure definition, such as XMLSchema or JSONSchema, to parse the header of the data packet in the temporary data buffer, extracting the data packet version number and data format identifier to determine the parsing rules for the message body; then, performing structured parsing of the message body according to these rules, based on the system's preset field mapping relationships, such as mapping the accId field to the transaction account identifier, the transType field to the transaction type, and the transAmt field to the transaction amount, to locate and extract the three core transaction data fields: transaction account identifier, transaction type, and transaction amount; after completing the parsing operation, further processing the extracted core transaction data... Multi-dimensional verification is performed: For the transaction account identifier, the system's built-in database of legitimate accounts is queried to determine whether the identifier belongs to a valid account that has completed account opening and filing. If it does not exist, it is considered invalid data. For the transaction type, it is verified whether it belongs to the system's predefined set of legitimate transaction types, such as frozen transactions and ordinary accounting transactions. If it is not in the set, it is considered invalid data. For the transaction amount, it is checked whether its data format conforms to currency data specifications (such as retaining two decimal places) and whether it exceeds the system's preset upper and lower limits for single transaction amounts. At the same time, the integrity of the core data extracted by parsing is verified by combining the CRC32 check value in the data packet verification segment to ensure that the data has not been lost or tampered with. Finally, all core transaction data that has passed verification is temporarily stored in the parsing result cache area. For data packets that have not passed verification, an invalid data log (recording the reason for invalidity and data packet metadata) is generated and fed back to the external system.

[0038] Step 103: Using the transaction account identifier, transaction type, and transaction amount, construct an accounting transaction request that can be used in the routing step. Specifically, this includes: First, obtaining a preset standard structure for the accounting transaction request. This structure contains four core parts: a request identifier field, an account information field, a transaction attribute field, and a routing adaptation field. The request identifier field is used to generate a unique request identifier; the account information field carries the transaction account identifier; the transaction attribute field carries the transaction type and transaction amount; and the routing adaptation field reserves adaptation information required for routing. Next, according to preset field filling rules, fill the account information field with the transaction account identifier temporarily stored in the parsing result cache in step 102, and fill the corresponding subfields of the transaction attribute field with the transaction type and transaction amount, respectively. Simultaneously, perform a range judgment based on the transaction amount, according to the system's preset amount range division rules, such as 0 to 100 yuan, 100 to 1000 yuan, and above 1000 yuan. The process involves determining the range to which the transaction amount belongs and generating a corresponding range code, which is then populated into the amount range identifier subfield of the routing adaptation field. Sub-account type matching is performed based on the transaction type; for example, a frozen sub-account identifier is generated if the transaction type is frozen, and a normal transaction sub-account identifier is generated if it is a normal accounting transaction, both populated into the sub-account type identifier subfield of the routing adaptation field. Subsequently, an integrity check is performed on the completed accounting transaction request structure to confirm that all required fields, including request identifier, account information, transaction attributes, and routing adaptation, are correctly filled and that the field content conforms to the preset format requirements. Finally, accounting transaction requests that pass the integrity check are marked as pending routing and transmitted to the system's routing request queue. This provides subsequent accounting transaction request routing operations with uniformly formatted, complete, and routing-adapted request data, ensuring that subsequent routing steps can directly perform sub-account matching and allocation based on this constructed request, thereby improving overall routing processing efficiency.

[0039] In this embodiment of the invention, the complete access of transaction request data sent by external systems is ensured, providing an original and complete data source for subsequent data parsing, verification, and processing. This avoids interruptions in subsequent processes due to incomplete data reception and ensures the stability and reliability of the starting point of the entire accounting transaction data processing chain. By parsing the transaction request data packets, core processing information such as transaction account identifier, transaction type, and transaction amount can be extracted. At the same time, the verification process filters out invalid data packets with incorrect formats or missing key information, reducing the consumption of invalid data on subsequent processing resources and ensuring the validity and accuracy of data entering subsequent processes. Constructing the extracted key information into accounting transaction requests that can be used by routing steps transforms the scattered core data into a standardized and normalized data format, making the data compatible with the processing requirements of subsequent routing steps. This avoids routing compatibility problems caused by inconsistent data formats, improves the processing efficiency of subsequent routing steps for accounting transaction requests, and ensures that data can quickly and smoothly enter the next round of processing.

[0040] In a preferred embodiment of the present invention, step 200, in response to the accounting transaction request, routes the accounting transaction request to the corresponding target sub-account according to the transaction type and transaction amount, including:

[0041] Step 201: Parse the accounting transaction request and identify its transaction type. Specifically, this includes: First, reading the accounting transaction request constructed in step 103 and transmitted to the routing request queue. This request already contains standardized fields such as request identifier, account information, transaction attributes, and routing adaptation. The transaction attribute field explicitly stores the original data related to the transaction type. Next, based on the system's built-in transaction type field mapping rules, locate and extract the transaction type identifier data from the transaction attribute field. This identifier is a preset encoding format, such as 01 representing a frozen transaction and 02 representing a normal accounting transaction. Then, match the extracted transaction type identifier with... The system compares and verifies the extracted identifier against a pre-stored database of valid transaction type codes. This database contains all supported transaction types and their corresponding codes. If a match is found in the database, the transaction type is confirmed as valid, and the specific name of the transaction type is recorded. For example, a match of 01 is recorded as a frozen transaction, and a match of 02 is recorded as a normal accounting transaction. If no match is found in the database, the transaction type of the accounting transaction request is determined to be invalid, an invalid request log is generated and sent back to the request initiator, and the subsequent routing process is terminated. Finally, for accounting transaction requests with valid transaction types, the transaction type information is associated with and stored with the unique identifier of the request.

[0042] Step 202: Based on the transaction type, if it is a frozen transaction, the target sub-account is determined to be a frozen sub-account; if it is a normal accounting transaction, an available sub-account is selected from multiple corresponding transaction sub-accounts as the target sub-account according to the preset range to which the transaction amount belongs. Specifically, this includes: First, receiving the accounting transaction request with associated transaction type transmitted in step 201, reading the transaction type information of the request, and determining whether it belongs to a frozen transaction; if it is determined to be a frozen transaction, calling the sub-account configuration information query interface, accessing the system's sub-account configuration table, which records the identifiers, function types, and current status of various sub-accounts associated with the main account, obtaining the corresponding frozen sub-account identifier by filtering records with the function type of frozen sub-account, and checking the status field of the frozen sub-account, such as normal availability or service suspension; if the status is normal availability, the frozen sub-account is directly determined as the target sub-account; if the status is service suspension, a sub-account unavailability log is generated and fed back to the request initiator.

[0043] If the transaction type is determined to be a regular accounting transaction, the system first reads the transaction amount data from the transaction request. Then, it calls the system's preset amount range matching rules. For example, if the rules are set to three ranges: 0 to 100 yuan, 100 to 1000 yuan, and above 1000 yuan, the transaction amount is compared with the upper and lower limits of each range to determine the specific range to which the transaction amount belongs. For example, a transaction amount of 50 yuan is matched with the 0 to 100 yuan range, and an amount of 150 yuan is matched with the 100 to 1000 yuan range. Subsequently, the sub-account configuration table is accessed again to filter sub-accounts whose function type is "regular transaction". The system first identifies all sub-account records with the amount range marked as the current matching range, forming a list of transaction sub-accounts corresponding to that range. Next, the availability status of the sub-accounts in this list is filtered, checking the status field and real-time load data of each sub-account. For example, if the current number of transactions processed is lower than a preset threshold, sub-accounts with suspended services or exceeding the load threshold are removed, while those with a normal availability status and a load within a reasonable range are retained, forming a list of available sub-accounts. If the list of available sub-accounts is empty, a fallback mechanism is invoked to include transaction sub-accounts in the preset range of 1000 yuan or more into the available list.

[0044] Finally, when selecting a target sub-account from the list of available sub-accounts, an algorithm based on the distance from image pixels to a straight line is introduced to improve the accuracy of load balancing. The specific calculation process is as follows: First, each sub-account in the list of available sub-accounts is mapped to a pixel in a two-dimensional image coordinate system. The horizontal axis of the coordinate system is set as the unique index of the sub-account in the list, such as the first sub-account being indexed as 1, the second as 2, and so on. The vertical axis is set as the real-time load data of the sub-account, i.e., the number of transactions currently being processed. This forms the pixel coordinates corresponding to each sub-account. For example, the sub-account with index 3 is currently processing... 48 transactions are processed, corresponding to pixel coordinates (3, 48); sub-account number 5 is currently processing 53 transactions, corresponding to pixel coordinates (5, 53); next, a baseline line corresponding to this amount range is determined. This baseline line is set based on the performance parameters of the sub-accounts in this range, combined with the single-account performance TPS of the sub-accounts in this amount range and the system's preset load safety redundancy ratio, to calculate the optimal load threshold for this type of sub-account. For example, if the single-account performance TPS is 100 transactions per minute and the safety redundancy ratio is 50%, then the optimal load threshold is set to 50 transactions per minute, in two-dimensional coordinates. In this system, the optimal load threshold corresponds to a reference straight line parallel to the horizontal axis, i.e., a horizontal straight line with a constant vertical axis coordinate of 50. Then, the distance from each pixel (sub-account load) to this reference straight line is calculated: since the reference straight line is horizontal, the calculation first extracts the vertical axis coordinate value of each pixel and the vertical axis coordinate value of the reference straight line, then calculates the absolute value of the difference between the two. This absolute value is the distance from the pixel to the reference straight line. For example, the absolute value of the difference between the vertical axis coordinate 48 of pixel (3, 48) and the vertical axis coordinate 50 of the reference straight line is 2, corresponding to a distance of 2; the distance from pixel (5, 53) is... The absolute value of the difference is 3, corresponding to a distance value of 3. Then, all available sub-accounts are sorted in ascending order of their corresponding distance values. The smaller the distance value, the closer the real-time load of the sub-account is to the optimal load threshold, and the more stable the load status. If multiple sub-accounts have the same distance value, they are sorted in ascending order of their sequence number in the list to ensure the uniqueness of the selection logic. Finally, the sub-account at the top of the sorted list is selected as the target sub-account, and its identifier and corresponding processing node information are recorded to ensure that subsequent transaction requests can be accurately routed to the sub-account with the optimal load for processing.

[0045] Step 203 involves routing the accounting transaction request to the determined target sub-account. Specifically, this includes: First, receiving the target sub-account identifier, processing node information, and associated accounting transaction request transmitted in step 202. The node address resolution interface is then called to extract the corresponding processing node IP address, port number, and communication protocol (e.g., TCP / IP) from the system's sub-account processing node configuration table, ensuring that the obtained node information supports data transmission. Next, the accounting transaction request is routed and encapsulated. The target sub-account identifier, processing node information, and the core data of the original accounting transaction request (transaction account identifier, transaction type, transaction amount) are associated and integrated to generate a standardized routing request packet containing the routing identifier. This request packet also includes a data integrity verification field, such as a verification code generated based on the request content, used by the target sub-account to verify data integrity upon receipt. Subsequently... According to the extracted communication protocol, a communication connection is established with the target sub-account processing node. After the connection is successfully established, the encapsulated routing request packet is sent to the processing node. After receiving the request packet, the target sub-account processing node first verifies the checksum to confirm the data integrity. If the verification passes, it returns a successful receipt; if the verification fails, it returns a data error receipt. After receiving the successful receipt, the completion time, target node, and request identifier of the routing operation are recorded, forming a routing log and storing it in the system log database. At the same time, it is determined that the accounting transaction request has been successfully routed to the target sub-account, and the process enters the subsequent transaction processing stage. If a data error receipt is received or no receipt is received after a timeout, the connection and request transmission are re-initiated. The number of retries does not exceed the system's preset threshold, such as 3 times. If the retries are still unsuccessful, a routing failure log is generated and fed back to the request initiator to ensure the reliability and traceability of the routing process.

[0046] In this embodiment of the invention, parsing transaction requests to identify transaction types enables the identification of the core business attributes of each request, clarifying whether it is a frozen transaction or a regular transaction, providing a clear and accurate basis for determining the target sub-account. Based on the identified transaction types, a differentiated target sub-account determination strategy is adopted, enabling the adaptation of transaction requests to sub-account functions: for frozen transactions, the frozen sub-account is directly identified as the target sub-account, and the dedicated functions of the frozen sub-account can be used to complete the processing of frozen funds, ensuring the professionalism of such transaction data processing; for regular transactions, the transaction amount is first divided into preset areas. In addition, available sub-accounts are selected from multiple transaction sub-accounts within the corresponding range. This not only enables the classification and distribution of transaction data based on amount ranges, avoiding the concentration of transactions of different amounts in a single sub-account, but also ensures that transaction requests can directly enter the effective processing stage by selecting available sub-accounts, reducing processing interruptions caused by the unavailability of factor accounts, and further optimizing the efficiency and reliability of data processing. Routing accounting transaction requests to specific target sub-accounts enables the connection between transaction data and processing nodes, allowing each request to directly enter the appropriate sub-account for subsequent processing, reducing invalid data flow between different nodes and improving data flow efficiency.

[0047] In a preferred embodiment of the present invention, step 300 above involves identifying the lending or borrowing direction of the accounting transaction request based on the target sub-account; for debit transactions, the transaction amount and lending or borrowing direction are inserted into a temporary stop payment table, and netting is performed on the records in the temporary stop payment table to determine the available balance; if the available balance is sufficient, the transaction details are moved to a pending details table; if the available balance is insufficient, a fund transfer request is generated; for credit transactions, the transaction details are recorded in the pending details table, including:

[0048] Step 301: Receive an accounting transaction request on the target sub-account; parse the accounting transaction request, identify its lending direction, and obtain the lending direction identification result. Specifically, this includes: First, following the routing completion result of step 203, the processing node corresponding to the target sub-account will listen for and receive the routed accounting transaction request. This request carries standardized data such as routing identifier, transaction account identifier, transaction type, and transaction amount. Next, based on the system's built-in request structure mapping rules, locate the field recording the lending direction in the request data, such as the debitCreditFlag field, and extract the original data corresponding to this field. This data is in a system-preset encoding format, for example, 1 represents the debit party. 2 represents the credit side; subsequently, the extracted lending direction code is compared and verified with the pre-stored lending direction code and name correspondence table in the system. If a code has a matching item in the correspondence table, such as 1 matching the debit side and 2 matching the credit side, the lending direction is confirmed to be valid, and an associated record containing the unique identifier of the transaction request and the lending direction name is generated; if the code has no matching item or the field data is missing, the lending direction identification is determined to have failed, an identification failure log (recording the request identifier and the reason for failure) is generated and fed back to the request initiator, and subsequent processing is terminated; finally, the valid lending direction identification results are integrated with the original accounting transaction request data and synchronously transmitted to the subsequent steps, providing a clear basis for differentiated processing of debit and credit transactions.

[0049] Step 302: When the loan direction identification result is a debit, insert the current transaction amount and loan direction as a new record into the temporary stop payment table corresponding to the sub-account. Specifically, this includes: First, when the loan direction identification result is a debit, access the temporary stop payment table specifically configured for the target sub-account. Each sub-account corresponds to an independent temporary stop payment table to avoid cross-account data interference. The table's preset fields include sub-account identifier, transaction request unique identifier, transaction amount, loan direction, record insertion time, and record status. Next, extract the sub-account identifier, transaction request unique identifier, and transaction amount from the integrated request data, and combine them with the confirmed debit direction to apply temporary stop payment. The table's fields are formatted and populated with data. Simultaneously, the current time is automatically generated as the record insertion time, and the record status is initialized to pending netting. Subsequently, a data insertion operation is performed, writing a fully populated new record to the temporary stop-payment table. The insertion result is confirmed through a system-preset insertion verification mechanism, which verifies whether the record was successfully stored and whether the field data is complete. If the insertion is successful, the total number of records in the temporary stop-payment table is updated to provide a data volume reference for subsequent record readings. If the insertion fails, an insertion exception message is returned, and the insertion operation is re-initiated, with the number of retries not exceeding a system-preset threshold of 3, ensuring that debit transaction data is effectively retained in the temporary stop-payment table.

[0050] Step 303: Read all records in the temporary stop payment table after the new record is inserted, and perform netting calculation based on the lending direction and amount in the records to obtain the current temporary stop payment net amount. Specifically, this includes: First, after confirming the successful insertion of the new record, the temporary stop payment table reads all records in the temporary stop payment table corresponding to the target sub-account whose record status is pending netting or netted but not migrated, excludes invalid records in the migrated status, and sorts and organizes them according to the record insertion time to form an ordered list of records pending netting; then, according to the netting rules built into the system, the vector conversion standard is determined, and each transaction is mapped to a one-dimensional vector, with the transaction amount as the vector's magnitude and the lending direction as the vector's direction, where debit transactions correspond to positive direction vectors and credit transactions correspond to negative direction vectors. If there are reversal transactions with the same request, the vector direction corresponding to the reversal transaction is opposite to the original transaction vector direction, while the magnitude remains the same.

[0051] Subsequently, the transaction amount and debit / credit direction are extracted from the list of records to be netted one by one. Each transaction is converted into a corresponding one-dimensional vector according to the aforementioned vector conversion standard. During the conversion process, the numerical format of each amount is simultaneously verified to confirm whether it is a valid currency value and whether it exceeds the preset precision range. If there is any abnormally formatted amount data, the vector corresponding to that transaction is removed, the abnormality log is recorded, and the remaining valid records are processed. After all valid transactions have completed vector conversion, vector addition calculation is started. All valid vectors are accumulated sequentially according to the rules of vector addition, that is, the end point of the previous vector is used as the starting point of the next vector. The value of the sum of the vectors formed after sequential concatenation is the result of the sum of all transaction vectors. The value of this sum of vectors directly corresponds to the current temporary stop payment net amount. If the sum of vectors is positive, it means that the temporary stop payment net amount is a debit net amount. If it is negative, it means that it is a credit net amount. A value of zero means that the income and expenditure are balanced.

[0052] Finally, the calculated net amount of temporary stop payment, calculation time, number of records involved in the calculation, and process logs of vector transformation and addition calculation are associated and stored, and the status of the records involved in the calculation is marked as netted but not migrated, to ensure that they can be traced and checked later.

[0053] Step 304: Add the current balance of the sub-account to the current net amount of the temporary stop payment to obtain the real-time available balance of the sub-account. Specifically, this includes: First, ensuring the up-to-dateness of the balance data by accessing the system's sub-account balance database or real-time balance cache; based on the target sub-account's identifier, extracting the current book balance of the sub-account, i.e., the balance after deducting confirmed accounting transactions, excluding the temporary stop payment portion; during the extraction process, a row-level lock is applied to the balance data to prevent the balance from being modified by other transactions in concurrent scenarios, ensuring data consistency; the lock is released after the extraction is complete; then, obtain the current net amount of the temporary stop payment from the calculation result of step 303, and calculate the real-time available balance according to the system's preset available balance calculation logic. The available balance reflects the funds that the sub-account can currently actually control. It needs to be combined with the funds that have been temporarily stopped from payment. Therefore, the current book balance is added to the net amount of the temporary stop payment. The extracted current book balance is added to the current net amount of the temporary stop payment. During the addition process, the consistency of the units of the two values ​​is checked. If they are both in the same currency unit, the currency unit conversion is triggered (converted to a unified unit according to the system's preset exchange rate) before the calculation is performed. Finally, the result of the calculation is the real-time available balance of the sub-account. The real-time available balance, calculation time, current book balance, and net amount of temporary stop payment are linked and recorded in the sub-account balance log table, and the available balance field in the sub-account real-time balance cache is updated at the same time.

[0054] Step 305 compares the real-time available balance with the current transaction amount to generate a balance adequacy determination result. Specifically, this includes: first, extracting the real-time available balance, and then extracting the current transaction amount from the integrated accounting transaction request data, which is the amount of funds to be deducted in this debit transaction; next, preprocessing the two values, including verifying whether the values ​​are non-negative (the real-time available balance is allowed to be negative, representing overdraft, while the current transaction amount must be positive; if the transaction amount is negative, it is determined to be an abnormal transaction), ensuring that the numerical precision is consistent, such as retaining two decimal places if both are not consistent, and adjusting to two decimal places according to the rounding rules if they are inconsistent.

[0055] After numerical preprocessing, to further aid in the determination by incorporating the dynamic trend of sub-account balance changes, a curve and polygon intersection algorithm is introduced. The specific calculation process is as follows: First, the historical real-time available balance data of the target sub-account within a preset time period is obtained. This preset time period, such as the most recent 5 minutes, is configured by the system based on transaction frequency. The balance data is fitted to generate a balance change curve in chronological order (e.g., one record every 10 seconds). The horizontal axis of the two-dimensional coordinate system is set to the timestamp in seconds, and the vertical axis is set to the balance value in the same unit as the transaction amount. Then, a closed polygon region is constructed for determination. The boundary of this polygon is set based on key thresholds for balance determination: the horizontal axis ranges from the current timestamp to the preset time period, covering the historical balance data; the vertical axis includes three key values. The overdraft limit is 0, and the current transaction amount is 0. The overdraft limit is the maximum allowed overdraft amount configured in the sub-account if the sub-account supports overdraft; it is a negative value, and 0 is the baseline for a zero balance. The current transaction amount is the amount of funds to be deducted this time. Connect the coordinates corresponding to the current timestamp minus the preset time period with the coordinates corresponding to the overdraft limit, then connect the coordinates corresponding to the current timestamp with the coordinates corresponding to the overdraft limit, then connect the coordinates corresponding to the current timestamp with the coordinates corresponding to the current transaction amount, then connect the coordinates corresponding to the current timestamp minus the preset time period with the coordinates corresponding to the current transaction amount, and finally connect them back to the coordinates corresponding to the current timestamp minus the preset time period with the coordinates corresponding to the overdraft limit, thus forming a closed polygon. The interior of this polygon defines the potential range where the balance can cover the transaction amount or is within the allowed overdraft range.

[0056] Next, the intersection points of the curve and the polygon are calculated: each continuous segment of the balance change curve is traversed, which is composed of the balance data of two adjacent timestamps, and the intersection points are checked with the four boundary lines (top, bottom, left, and right sides) of the polygon one by one; for each curve segment, it is first determined whether it overlaps or intersects with the boundary line. If there is an intersection, the coordinates of the intersection point are calculated, that is, the timestamp and the balance value, and the boundary line type to which the intersection point belongs is recorded, such as the current transaction amount line overdraft limit line or time boundary line; for example, if a curve segment extends from (t1, 150 yuan) to (t2, 80 yuan), and the current transaction amount is 100 yuan, that is, the vertical axis value of the upper boundary line of the corresponding polygon is 100 yuan, then the segment intersects with the upper boundary line, and the timestamp t and the balance value of 100 yuan of the intersection point are calculated and recorded.

[0057] After completing the intersection calculation, a comprehensive judgment is made by combining intersection analysis and real-time value comparison: First, a basic comparison operation is performed to determine whether the real-time available balance is greater than or equal to the current transaction amount; then, the intersection data is used for auxiliary verification. If the basic comparison result shows that the real-time available balance is greater than or equal to the current transaction amount, and the balance change curve has not intersected with the current transaction amount line in the most recent preset time period, or the intersection timestamp is before the current timestamp and the curve subsequently shows an upward trend, then the judgment is strengthened to indicate that the available balance is sufficient; if the basic comparison result shows that the real-time available balance is greater than or equal to the current transaction amount, but the curve has recently intersected with the current transaction amount line and subsequently shows a downward trend, then while determining that the available balance is sufficient, a supplementary prompt indicating that the balance is at risk of decreasing is recorded; if the basic comparison result shows that the real-time available balance is less than the current transaction amount, and the curve has not intersected with the overdraft limit line, that is, the balance has not exceeded the overdraft limit, then the judgment is that the available balance is insufficient but overdraft transfer can be triggered; if the curve has intersected with the overdraft limit line, that is, the balance has exceeded the overdraft limit, then the judgment is that the available balance is insufficient and there is no overdraft space.

[0058] Subsequently, a balance adequacy assessment report is generated, which includes the real-time available balance value, the current transaction amount value, the basic comparison results, the intersection analysis conclusion, the comparison time, and the target sub-account identifier. Finally, the assessment report is transmitted to the subsequent steps, and the report and the corresponding curve and polygon data are stored in the transaction assessment log library to ensure the traceability and reproducibility of the assessment process.

[0059] Step 306: When the balance adequacy determination result indicates that the available balance is sufficient, the current transaction details are moved from the temporary stop payment table to the pending details table. Specifically, this includes: First, when the balance adequacy determination result indicates that the available balance is sufficient, based on the target sub-account identifier and the unique identifier of the current transaction request, locating the corresponding netted but not migrated record in the temporary stop payment table, and extracting core field data such as sub-account identifier, unique transaction request identifier, transaction amount, loan / borrowing direction, and record insertion time from this record; Next, accessing the pending details table configured by the system for the target sub-account. This table corresponds one-to-one with the temporary stop payment table, and its field structure includes sub-account identifier, unique transaction request identifier, transaction amount, loan / borrowing direction, migration time, and posting status, according to the field structure of the pending details table. The process involves extracting core data from the temporary stop-payment table and filling it into the corresponding fields. Simultaneously, the current time is automatically generated as the migration time, and the accounting status is initialized to "pending accounting." Subsequently, a data insertion operation is performed, writing the fully populated record into the pending details table. An insertion validation mechanism confirms the insertion result, verifying whether the record has been successfully stored and whether it matches the data in the temporary stop-payment table. If the insertion is successful, the process returns to the temporary stop-payment table, updating the record status to "migrated" to avoid subsequent duplicate processing. If the insertion fails, the migration operation is re-initiated, with a maximum of three retries. If a retrieval fails, a migration exception log is generated, triggering manual investigation. Finally, the process ensures that debit transaction details are successfully migrated to the pending details table, preparing the data for subsequent batch accounting.

[0060] Step 307: When the balance adequacy determination result indicates insufficient available balance, a fund transfer request for the sub-account is generated. This includes: First, when the balance adequacy determination result indicates insufficient available balance, the target sub-account identifier, real-time available balance, and current transaction amount are extracted from the results of steps 304 and 305. Based on the system's preset transfer amount calculation logic (i.e., the amount to be transferred is the difference between the current transaction amount and the real-time available balance), ensuring that the sub-account's available balance can cover the transaction amount after the transfer, the required transfer amount is calculated, i.e., the required transfer amount equals the current transaction amount minus the real-time available balance); Next, according to the system's preset transfer request structure, including a unique transfer request identifier, target sub-account identifier, required transfer amount, request generation time, request status, and priority, relevant data is filled in. The unique transfer request identifier is automatically generated by the system. The system includes a sub-account identifier prefix and timestamp. The request status is initialized to pending, and the priority is set according to the current transaction's business type. For example, real-time consumption transactions are given high priority, and ordinary transfer transactions are given medium priority. The priority rules are pre-configured in the system. Subsequently, the completed transfer request data is checked for integrity, such as whether key fields are missing and whether the amount to be transferred is positive. After the check passes, the transfer request is written to the system's fund transfer request queue. The queue is sorted according to request priority, with higher priority requests being processed first. At the same time, the transfer request data is stored in the transfer request log database, and a new transfer request notification containing a unique identifier for the transfer request is sent to the account control service, triggering the account control service's subsequent transfer processing flow. Finally, the system ensures that fund transfer requests are generated in a standardized manner and can be processed in a timely manner, providing support for replenishing funds to the target sub-account to complete subsequent transactions.

[0061] Step 308: When the lending direction identification result is a credit, the current transaction details are directly recorded to the pending details table. Specifically, this includes: First, when the lending direction identification result is a credit, extracting core field data such as the target sub-account identifier, unique transaction request identifier, transaction amount, lending direction, and transaction occurrence time from the integrated accounting transaction request data; then, accessing the pending details table corresponding to the target sub-account, and filling the corresponding fields with the extracted core data according to the table's field structure, which is consistent with the pending details table structure in step 306: The lending direction is explicitly marked as a credit, the migration time (here it is directly recorded, so the field name can be reused) is automatically generated to the current time, and the accounting status is initialized to pending accounting; subsequently, execution... The data insertion operation writes the completed records to the pending details table and confirms the insertion result through an insertion validation mechanism. This validation mechanism includes checking whether the transaction amount is positive and whether the field data meets the format requirements. If the insertion is successful, a record insertion log (including sub-account identifier, request unique identifier, and insertion time) is generated and stored in the transaction log database. If the insertion fails, the insertion operation is re-initiated, with a maximum of three retries. If the retries fail, an insertion exception log is generated and fed back to the requesting end. Ultimately, this ensures that credit transaction details can be quickly and accurately entered into the pending details table, eliminating the need for netting and balance determination for debit transactions, improving the data processing efficiency of credit transactions, and providing complete credit transaction data for subsequent batch accounting.

[0062] In this embodiment of the invention, receiving transaction requests on the target sub-account ensures that the requests reach the corresponding processing node, avoiding data flow deviations. Simultaneously, by parsing the requests to identify the lending direction, the fund flow attributes of each transaction can be clearly defined, providing a clear basis for differentiated processing of subsequent debit and credit transactions, ensuring that data processing has a clear business orientation from the source. Inserting the amount and lending direction of debit transactions as new records into the temporary stop-payment table corresponding to the sub-account allows for real-time retention of core debit transaction data, forming complete and traceable temporary transaction details. Reading all records after inserting the new record into the temporary stop-payment table and performing netting calculations based on the lending direction and amount yields the temporary stop-payment net amount, which can aggregate and integrate scattered individual temporary transaction records into intuitive net amount data. The sub-account... The current balance is added to the net amount of temporary stop payment to obtain the real-time available balance. The available funds data can be dynamically updated based on the actual funds in the sub-account and the temporary stop payment situation. The real-time available balance is compared with the current transaction amount to generate a judgment result, which can quickly determine whether the sub-account funds can support the current transaction. When the balance is sufficient, the transaction details are moved from the temporary stop payment table to the pending details table, which can complete the initial compliance screening of debit transactions and ensure that all transactions entering the pending details table are valid transactions that meet the funding conditions. When the balance is insufficient, a fund transfer request is generated for the sub-account, which can respond to the funding gap problem in a timely manner and avoid directly interrupting the transaction due to insufficient balance. Credit transactions are directly recorded in the pending details table, which can simplify the processing process based on the business characteristics of credit transactions that do not require fund deduction.

[0063] In a preferred embodiment of the present invention, step 400 above involves processing the fund transfer request by obtaining multiple performance indicator data through querying fund transfer history records, generating transfer control parameters based on the multiple performance indicator data using a predefined evaluation strategy, determining the priority and amount of fund transfer according to the transfer control parameters, and transferring funds from the fund pool sub-account, other transaction sub-accounts, or overdraft sub-accounts to the sub-account initiating the transfer based on the determined priority and transfer amount. After completing the fund transfer operation, the transaction details corresponding to the fund transfer request are moved from the temporary stop payment table to the pending details table and marked as available for recording, including:

[0064] Step 401: In response to the fund transfer request, query the fund transfer history within a preset time period. Specifically, this includes: First, accepting the fund transfer request generated in step 307 above, which already contains core information such as the target sub-account identifier, the amount to be transferred, and the unique identifier of the request; The system's transfer history query function responds to this request by first reading the target sub-account identifier and business type in the request, such as ordinary accounting transaction transfer or frozen transaction transfer, and using these as query filtering conditions.

[0065] Next, determine the preset time period. This period is initially configured based on the business scenario and can be set to the most recent 1 hour, 6 hours, or 24 hours. Subsequently, the operation and maintenance personnel can dynamically adjust it according to the characteristics of peak transaction periods. During peak transaction periods such as e-commerce promotions, the period will be shortened to 1 hour to ensure that the acquired historical data matches the allocation needs under high concurrency scenarios. During off-peak periods, the period will be extended to 24 hours to balance data timeliness and query efficiency.

[0066] Subsequently, the system accesses its historical fund transfer database, which stores complete records of all historical transfer requests, including fields such as transfer request identifier, sub-account identifier, business type, transfer time, delay time, result status, and number of concurrent requests. A query is then performed based on a combination of conditions: the sub-account identifier equals the current target sub-account identifier, the business type equals the current requested business type, and the transfer time is greater than or equal to the current time minus a preset time period. After the query is completed, the returned historical records are initially filtered, removing invalid records with abnormal transfer times (such as exceeding the preset period) or mismatched sub-account identifiers. The remaining valid records are temporarily stored in the historical record cache.

[0067] Step 402: Extract the delay time, transfer result status, and number of concurrent requests for each transfer from the historical fund transfer history to obtain a historical transfer record set. Specifically, this includes: First, calling the valid historical records temporarily stored in the historical record cache in step 401 and parsing each record one by one; For each historical record, first locate the delay time field, which records the time difference from the initiation of the historical transfer request to its completion (or failure), in milliseconds. If the data in this field is missing or negative, the record is marked as a field abnormal and temporarily stored in the abnormal log; Next, locate the transfer result status field, which has four preset values: success, failure (insufficient funds), failure (account unavailable), and timeout. If the field value does not belong to the preset category, it is also marked as a field abnormal; Subsequently, locate the number of concurrent requests field, which records the total number of transfer requests in the pending state under the same sub-account at the time the historical transfer request was initiated. If the data in this field is 0 or negative, it is also marked as a field abnormal.

[0068] After parsing a single record, records marked as having abnormal fields are verified a second time. If only a single field is abnormal and can be supplemented by other related records (e.g., if the delay time is missing, the average delay of the same type of transfer within the same time period can be referenced), then the data is supplemented. If multiple fields are abnormal or cannot be supplemented, then the record is removed. Finally, all historical records that have passed parsing and have complete fields are organized in the field order of delay time, transfer result status, and number of concurrent requests to form a structured historical transfer record set. A unique identifier is assigned to this record set and associated with the unique identifier of the current transfer request, and then stored in the performance analysis database.

[0069] Step 403: Based on the historical allocation record set, calculate the average historical allocation delay, the average historical allocation success rate, and the peak concurrent processing volume. Specifically, this includes: First, reading the historical allocation record set and counting the total number of records in the set, denoted as N. If N is less than a preset threshold (e.g., N is less than 5 records, the threshold is configured by the system according to data validity requirements), then it is determined that the historical data volume is insufficient, and the system's preset default indicator values ​​are used, such as an average delay of 500 milliseconds, an average success rate of 90%, and a peak concurrent processing volume of 10, and a note indicating insufficient data volume is recorded. If N is greater than or equal to the preset threshold, then the normal calculation process is started.

[0070] For the average historical allocation delay, first extract all delay time data from the record set, and remove outliers that exceed a preset reasonable range, such as delay times greater than 10,000 milliseconds. This range is determined by the system based on historical best performance configurations, resulting in a list of effective delay times, denoted as T1, T2, ... T. m m is less than or equal to N; sum all the delay times in the list to get the total delay duration, denoted as T. 总 Then use T 总 Divide by the number of effective delay times m to obtain the average historical allocation delay.

[0071] To calculate the average historical allocation success rate, the number of records in the statistical record set with a successful allocation result status is denoted as S. S is divided by the total number of records in the record set, N, to obtain the success rate, which is rounded to two decimal places. If there are multiple allocation requests in the same batch, such as multiple allocations initiated at the same time, the success rate is calculated for each batch before taking the average to ensure that the result is more in line with the actual business scenario. For the peak concurrent processing volume, all concurrent request quantity data in the record set are extracted, sorted in descending order, and the first value after sorting (i.e., the maximum value) is taken as the peak concurrent processing volume. If there are multiple identical maximum values, the maximum value and the corresponding number of occurrences are recorded. After the calculation is completed, the three statistical values ​​(average latency, average success rate, and peak concurrency) are associated with the unique identifier of the record set and stored. At the same time, metadata such as the number of outliers removed during the calculation process and the number of records from which the data originated are also recorded.

[0072] Step 404 involves using the historical average allocation delay, historical average allocation success rate, and peak concurrent processing volume as multiple performance metrics. Specifically, this includes: First, receiving the three statistical values ​​(average delay, average success rate, and peak concurrent processing volume) and corresponding metadata transmitted in step 403. The metadata is then checked for insufficient data volume. If this note exists, it is confirmed whether the default metric values ​​are within a reasonable range allowed by the system. For example, the default value for the average delay is 500 milliseconds less than or equal to 1000 milliseconds, and the default value for the average success rate is 90% greater than or equal to 80%. If within the range, the default value is accepted; if outside the range, an alarm is triggered and manual confirmation by operations personnel is required. If the note does not exist, the calculation logic of the three statistical values ​​is verified for compliance. For example, whether the average delay is calculated based on the effective delay time and whether the average success rate is based on the total number of records. If the calculation logic is compliant, the process proceeds to the metric determination stage.

[0073] Subsequently, the definitions of three statistical values ​​were determined: the average historical allocation delay reflects allocation efficiency, the average historical allocation success rate reflects allocation reliability, and the peak concurrent processing volume reflects allocation capacity. These three together constitute the core dimensions of performance evaluation. These three statistical values ​​were formally defined as multiple performance indicator data, and indicator reports were generated in the format of indicator name, statistical value, calculation time, and data source. Finally, the indicator reports were stored in the system's performance indicator library, and a unique index was assigned to the report, associating it with the unique identifier of the current allocation request.

[0074] Step 405: Normalize the multiple performance index data to form a normalized index vector; weight the normalized index vector with a predefined weight coefficient vector to obtain a comprehensive performance index. Specifically, this includes: First, after receiving the index ready notification, the system's normalization function reads the three performance index data determined in step 404 from the performance index library, denoted as A: average latency, B: average success rate, and C: peak concurrency. It first calls the system's preset normalization rule, which sets differentiated processing logic for different index characteristics: for the average latency A, the smaller the better. Normalization is performed by subtracting the current value from the maximum value of the indicator and dividing by the minimum value of the indicator. The maximum and minimum values ​​are configured by the system based on historical full data, such as a maximum latency of 10,000 milliseconds and a minimum latency of 100 milliseconds. For the average success rate B, the larger the better, it is performed by subtracting the minimum value of the indicator from the current value and dividing by the minimum value of the indicator, such as a maximum success rate of 100% and a minimum success rate of 60%. For the peak concurrency C, the larger the value, the stronger the carrying capacity, and it is treated as better to be larger. The same normalization method as B is used, such as a maximum concurrency of 100 and a minimum concurrency of 10.

[0075] After normalization calculation, three normalized indicator values ​​are obtained, denoted as A', B', and C', each ranging from 0 to 1. These three values ​​are combined in the order of delay normalization, success rate normalization, and concurrency normalization to form a normalized indicator vector [A', B', C']. Next, the system's predefined weight coefficient vector is read. This vector is determined by business experts who first analyze the impact of the three indicators—average delay, average success rate, and peak concurrency—on fund allocation decisions, ranking the importance of each indicator. Then, corresponding weight coefficients are assigned according to the ranking, ensuring that the sum of all coefficients is 1. For example, the success rate has the greatest impact on allocation reliability and is set to 0.5. The impact of the late average value is set to 0.3, and the impact of the concurrent peak value is relatively small, set to 0.2, forming the corresponding weight coefficient vector. Each element in the normalized index vector is multiplied by the corresponding element in the weight coefficient vector, i.e., A' multiplied by 0.3, B' multiplied by 0.5, and C' multiplied by 0.2. The three products are then added together, and the sum is the comprehensive performance index, with a value range of 0 to 1. Finally, the comprehensive performance index is checked for accuracy, retaining three decimal places. If the index is less than 0, it is taken as 0, and if it is greater than 1, it is taken as 1, ensuring that the result is within a reasonable range. After the check passes, the comprehensive performance index is associated with the normalization process record (including the normalization method and weight coefficients) and stored.

[0076] Step 406: Based on the comprehensive performance index, determine the corresponding allocation priority weight by querying a predefined mapping table. Specifically, this includes: First, receiving the comprehensive performance index and simultaneously calling the system's predefined mapping table. The predefined mapping table is defined by first clarifying the division range of the comprehensive performance index based on the urgency of the business, and then allocating allocation priority weights and priority levels according to the performance level corresponding to the range, ensuring that the higher the index, the greater the corresponding priority weight and the higher the priority level. For example, the index is divided into four ranges: 0 to 0.2, 0.2 to 0.5, 0.5 to 0.8, and 0.8 to 1.0, corresponding to weights of 0.1, 0.4, 0.7, and 1.0, respectively, as well as lowest priority, low priority, medium priority, and high priority. This table can be dynamically adjusted by operations and maintenance personnel according to business needs. Its structured data includes three columns: comprehensive performance index range, corresponding allocation priority weight, and priority level.

[0077] Next, the received comprehensive performance index is matched with the comprehensive performance index range in the table. For example, if the comprehensive performance index is 0.85, the range of 0.8 to 1.0 is matched. If the index is exactly equal to the critical value of the range, such as 0.8, the next higher range, i.e., the range of 0.8 to 1.0, is matched according to the principle of choosing the higher value. If the index exceeds the maximum range in the table, such as 1.05, the maximum range is matched. If it is lower than the minimum range, such as -0.05, the minimum range is matched. After the matching is completed, the allocation priority weight of the corresponding range is extracted. For example, 0.85 matches to 1.0. At the same time, the matching process is recorded, including the index value, the matching range, and the weight value. Finally, the allocation priority weight is associated with the unique identifier of the current allocation request.

[0078] Step 407: Based on multiple performance index data, extract the average historical allocation success rate, calculate the ratio of the average historical allocation success rate to the preset success rate threshold, and obtain the real-time allocation coefficient. Specifically, this includes: First, after receiving the priority weight ready notification, extract the average historical allocation success rate from the performance index data determined in step 404, denoted as D, such as 92%; then, read the system's preset success rate threshold. This threshold is first determined based on the system's historical best allocation performance to determine the basic target value, and then dynamically adjusted according to business stability requirements. During non-promotional periods, it is set to 95% based on the historical best performance, and during promotional periods, it can be lowered to 90% to ensure allocation flexibility, forming a preset success rate threshold adapted to different business scenarios.

[0079] Subsequently, the average historical allocation success rate D is compared with a preset success rate threshold. For example, when D is 92% and the threshold is 95%, the ratio is calculated and the result is rounded to three decimal places. During the calculation, the result is limited to a certain range. If the ratio is greater than 1.2, it is set to 1.2 to avoid excessive redundancy in allocation amount due to an excessively high coefficient. If the ratio is less than 0.5, it is set to 0.5 to avoid insufficient allocation amount due to an excessively low coefficient. If the ratio is between 0.5 and 1.2, the original calculation result is retained. The obtained ratio is the real-time allocation coefficient. In the example above, the coefficient is 0.968. This coefficient is associated with and stored with the average success rate D, the preset threshold, and the calculation process record.

[0080] Step 408: Combine the allocation priority weight with the real-time allocation coefficient to form the allocation control parameters for fund allocation decisions. Specifically, this includes: First, receiving the allocation priority weight (e.g., 1.0) and the real-time allocation coefficient (e.g., 0.968), and simultaneously reading the unique identifier of the current allocation request; first, validating the two parameters: checking whether the priority weight is within the preset range of 0.1 to 1.0, and whether the real-time allocation coefficient is within the range of 0.5 to 1.2. If either parameter exceeds the range, return to the corresponding step for recalculation; if both are within the range, proceed to the combination step. The process involves combining two parameters based on their allocation priority weight, real-time allocation coefficient, and unique request identifier to form a structured allocation control parameter. This parameter also includes metadata such as parameter generation time and generation identifier to ensure subsequent traceability. For example, the parameter structure is: request identifier is REQ20240501001, priority weight is 1.0, real-time allocation coefficient is 0.968, and generation time is 2024-05-01 10:00:00. After combination, the allocation control parameter is stored in the system's allocation control parameter library and set to a ready-to-use status.

[0081] Step 409: Using the allocation priority weight in the allocation control parameters as the sorting key, sort all pending fund allocation requests to obtain an allocation queue. Specifically, this includes: First, accessing the allocation control parameter library to read all pending fund allocation requests and their corresponding allocation priority weights; first, sorting these requests in descending order of allocation priority weight: requests with larger weights are placed first and processed with priority; if multiple requests have the same priority weight, such as multiple requests with a weight of 1.0, then sorting them in ascending order of request initiation time: requests with earlier initiation times are placed first to avoid delaying earlier requests; during the sorting process, a stable sorting algorithm built into the system, such as merge sort, is used to ensure the consistency of the sorting results and avoid request order disorder caused by the sorting algorithm.

[0082] After sorting, the sorted requests are arranged in order to form a structured allocation queue. Each element in the queue contains information such as a unique request identifier, a target sub-account identifier, a priority weight, and an initiation time. A unique queue identifier is assigned to the allocation queue, stored in the system's allocation queue cache, and metadata such as queue generation time and queue length are recorded.

[0083] Step 410: For the current transfer request, determine the basic transfer amount based on the preset water level configuration of the target sub-account. Specifically, this includes: First, reading the water level configuration information corresponding to the target sub-account initiating the transfer from the system's sub-account configuration library. The sub-account lower limit in this configuration information is initially set by the system based on the sub-account's historical transaction volume and the importance of the business scenario. For example, the lower limit for high-frequency trading sub-accounts is set to 2,000 yuan, and for low-frequency trading sub-accounts, it is set to 1,000 yuan. It can be dynamically adjusted by the operations and maintenance personnel according to the business funding needs. The water level ratio is preset to 50% of the sub-account lower limit, and can also be adapted to the sub-account's transaction fluctuations (e.g., if transactions are frequent during promotional periods, it is increased to 60%, and if transactions are not during off-peak periods, it is decreased to 40%). The sub-account lower limit serves as the minimum amount of funds held by the sub-account to ensure that the sub-account has basic transaction processing capabilities.

[0084] Next, the sub-account lower limit and water level ratio are extracted from the configuration information to calculate the target sub-account's water level amount: multiplying the sub-account lower limit by the water level ratio yields the basic allocation amount to be transferred in one go; during the calculation, two decimal places are retained according to currency data specifications. For example, if the sub-account lower limit is 2000 yuan and the water level ratio is 50%, then the basic allocation amount is 1000.00 yuan; subsequently, the basic allocation amount is validated: confirming that the amount is positive and does not exceed the system's preset single allocation limit, which is configured by the system based on the overall capacity of the fund pool and risk control rules; if the amount is negative, zero, or exceeds the single allocation limit, it is determined to be a configuration anomaly, an anomaly log is recorded, and maintenance personnel are triggered to check the sub-account water level configuration; if the validation passes, the basic allocation amount is confirmed to be valid; finally, the basic allocation amount is associated with the target sub-account identifier, water level configuration parameters (lower limit, ratio), and calculation time and stored in the allocation amount database.

[0085] Step 411: Based on the basic transfer amount, and combined with the current available balance of the fund pool sub-account, perform a fund adequacy verification to determine the actual transfer amount. Specifically, this includes: First, after receiving the basic amount ready notification, read the basic transfer amount from the transfer amount database, such as 968.00 yuan; then, call the fund pool sub-account balance query interface to access the real-time balance database of the fund pool sub-account. Based on the unique identifier of the fund pool sub-account, each main account corresponds to a unique fund pool sub-account, and extract the current available balance of that account, denoted as F, such as 1000.00 yuan; during the query process, add row-level locks to the balance data to prevent the balance from being modified by other transfer requests in concurrent scenarios, ensuring the accuracy of the balance data.

[0086] The basic allocation amount is compared with the current available balance F: if the basic allocation amount is less than or equal to F, such as 968.00 yuan less than or equal to 1000.00 yuan, the balance of the fund pool sub-account is determined to be sufficient, and the basic allocation amount is directly determined as the actual allocation amount, i.e., 968.00 yuan; if the basic allocation amount is greater than F, such as the basic amount of 1200.00 yuan greater than F, i.e., 1000.00 yuan, the balance of the fund pool sub-account is determined to be insufficient, and the current available balance F is determined as the actual allocation amount, i.e., 1000.00 yuan, while the funding gap is recorded as 1200.00 - 1000.00 = 200.00 yuan; after determining the actual allocation amount, the row-level lock of the fund pool sub-account balance is released, and the information such as the actual allocation amount, the fund pool account balance, and whether there is a gap is stored together.

[0087] Step 412: Based on the allocation queue and the actual allocation amount, and according to the priority order of the fund pool sub-account, other transaction sub-accounts, and overdraft sub-accounts, transfer funds from the available sub-accounts to the sub-account that initiated the allocation, and generate a fund allocation execution result containing the execution status and transfer details. Specifically, this includes: First, after receiving the queue ready and actual amount ready notifications, reading the currently pending allocation request from the allocation queue buffer, taking the first one according to the queue order, and reading the actual allocation amount (e.g., 968.00 yuan) and a flag indicating whether there is a funding gap from the allocation amount database.

[0088] First, process the transfers from the fund pool sub-accounts: If there is no shortfall, such as when the actual amount of 968.00 yuan is less than or equal to the fund pool balance of 1000.00 yuan, then call the fund transfer interface to transfer 968.00 yuan from the fund pool sub-account to the sub-account initiating the transfer. Simultaneously, update the fund pool sub-account balance (1000.00 - 968.00 = 32.00 yuan) and the balance of the sub-account initiating the transfer (original balance + 968.00 yuan). If there is a shortfall, such as when the actual amount of 1000.00 yuan is the entire fund pool balance, and the shortfall is 200.00 yuan, then first transfer 1000.00 yuan, and then query other transaction sub-accounts according to priority: from available... From other transaction sub-accounts with a status and balance greater than 0, select an account with sufficient balance. For example, if a transaction sub-account has a balance of 300.00 yuan, transfer 200.00 yuan to fill the gap. If the balance of other transaction sub-accounts is still insufficient, transfer the remaining amount from the overdraft sub-account (it is necessary to verify whether the overdraft limit is sufficient). After the transfer is completed, a fund transfer execution result is generated. This result includes the execution status, transfer details, and balance change record. The execution status is such as successful, partially successful, or failed. The transfer details include: transferring account, receiving account, transfer amount, and transfer time. The balance change record shows the balance of each account before and after the transfer. The execution result is stored in the fund transfer execution result database.

[0089] Step 413: Verify the fund transfer execution result to obtain a successfully verified fund transfer execution result. Specifically, this includes: First, after receiving the execution result ready notification, read the execution result from the transfer execution result database; First, verify the rationality of the execution status: If the execution status is successful, verify whether the sum of the amounts of all transfer details equals the actual transfer amount, and whether the changes in the balances of each account are correct, such as the decrease in the balance of the fund pool sub-account equals the transfer amount, and the increase in the balance of the initiating transfer sub-account equals the transfer amount; If the execution status is partially successful, verify whether the transferred amount is accurate, and whether the shortfall amount not transferred is reasonably recorded, such as the account being unavailable or the balance being insufficient; If the execution status is failed, verify whether the reason for the failure is consistent with the actual situation, such as all accounts having no available funds.

[0090] During the verification process, the consistency of fund transfers is confirmed by comparing the account balance change log with the transfer details. If all verification items pass, the verification is considered successful, and the execution result is marked as successfully verified. If there are any verification failures, such as a mismatch between the transfer amount and the balance reduction amount, the verification is considered to have failed, marked as failed, and a retry mechanism is triggered to re-execute the transfer operation in step 412. After the verification is completed, the verification result is associated with the execution result and stored together.

[0091] Step 414: Based on the successfully verified fund transfer execution result, remove the transaction details corresponding to the fund transfer request from the temporary stop payment table to obtain the removed transaction details. Specifically, this includes: First, after receiving the successful verification notification, obtaining the unique identifier of the current transfer request from the verification result; accessing the temporary stop payment table corresponding to the target sub-account in step 302, which records the transaction details associated with the transfer request, linked by the unique identifier of the transaction request; querying the temporary stop payment table based on the condition that the unique identifier of the transaction request equals the unique identifier of the current transfer request, and locating the corresponding transaction detail record. The query includes fields such as sub-account identifier, transaction amount, lending direction, and insertion time. After the query is completed, the status of the record is first confirmed to be "netted but not migrated", i.e., the status marked in step 303. If the status does not match, it is determined that the detail is located incorrectly, and the process returns to step 303 to re-mark the status. If the status matches, the deletion operation is performed to remove the record from the temporary stop payment table. After the deletion operation is completed, the deletion time, operation identifier, and key information of the deleted detail, such as transaction amount and lending direction, are recorded, and the deleted detail data is temporarily stored in the temporary cache area (to avoid data loss).

[0092] Step 415 involves persistently storing the removed transaction details in the pending details table and setting the transaction details to an accountable status based on the fund transfer execution result. Specifically, this includes: First, upon receiving a notification that a detail has been removed, reading the removed transaction detail data from the temporary cache; accessing the pending details table corresponding to the target sub-account, which corresponds one-to-one with the temporary stop-payment table. This table has preset fields including sub-account identifier, unique transaction request identifier, transaction amount, loan direction, migration time, and accounting status; filling the removed detail's sub-account identifier, unique transaction request identifier, transaction amount, and loan direction into the corresponding fields according to the field format of the pending details table, and automatically generating the current time as the migration time; simultaneously, based on the successful transfer execution result verified in step 413, setting the accounting status to accountable, indicating that the detail has met the accounting conditions and can participate in subsequent batch accounting.

[0093] After the data is populated, a data insertion operation is performed to persist the detailed data to the pending details table. After insertion, the pending details table is queried to confirm whether the data has been successfully stored in the database. If the storage is successful, a details storage log is generated, and the status of the details in the temporary cache is updated to stored. If the storage fails, the insertion operation is re-initiated, with no more than 3 retries to ensure reliable storage of the detailed data.

[0094] In this embodiment of the invention, responding to a fund transfer request by querying historical fund transfer records within a preset time period can obtain historical data support relevant to the current transfer scenario, avoiding decisions based on unfounded blank data. By limiting the preset time period, it can ensure that the extracted historical records are timely and relevant to the scenario, eliminating the interference of outdated data on the current transfer decision. Extracting the delay time, transfer result status, and number of concurrent requests for each transfer from the historical fund transfer records to form a historical transfer record set can filter out core data dimensions directly related to transfer performance evaluation and eliminate irrelevant and redundant information. Calculating the historical transfer delay average, historical transfer success rate average, and concurrent processing volume peak based on the historical transfer record set can transform scattered individual historical records into aggregated indicators reflecting overall transfer performance. Through the calculation of averages and peaks, the efficiency level, success probability, and maximum processing load in the historical transfer process can be intuitively presented, making the quantitative evaluation of transfer performance more objective and valuable. Determining the historical transfer delay average, historical transfer success rate average, and concurrent processing volume peak as multiple performance indicator data can clarify subsequent evaluation and... The core dimensions of decision-making allow for a more focused performance analysis. Normalizing multiple performance indicators to form a normalized indicator vector eliminates evaluation biases caused by differences in units and magnitudes between indicators, ensuring comparability and superposition. The normalized indicator vector is then weighted with a predefined weight coefficient vector to obtain a comprehensive performance index. This index assigns weights based on the importance of each indicator to the allocation decision, ensuring it objectively reflects overall allocation performance. The comprehensive performance index is used to query a predefined mapping table to determine the corresponding allocation priority weights, transforming the abstract index into concrete parameters directly usable for allocation ranking, thus standardizing and making the priority determination process traceable. The average historical allocation success rate is extracted from multiple performance indicator data, and its ratio to a preset success rate threshold is calculated to obtain a real-time allocation coefficient. This transforms the reliability level of historical allocations into a quantitative parameter that can be used to adjust allocation amounts. Combining allocation priority weights with the real-time allocation coefficient constitutes allocation control parameters, integrating the two core elements influencing allocation decisions, processing the order and basis for amount adjustments, and forming a complete decision parameter system.

[0095] The system sorts all pending fund transfer requests using the transfer priority weight in the transfer control parameters as the sorting key to obtain the transfer queue. This allows for determining the processing order based on the urgency and importance of the transfers, avoiding resource waste caused by disordered processing. For each current transfer request, the current transaction amount is multiplied by the real-time transfer coefficient to obtain the base transfer amount. This allows for dynamic adjustment of the transfer amount based on historical transfer success rates, avoiding insufficient or excessive transfers due to fixed amounts. Based on the base transfer amount and the current available balance of the fund pool sub-account, the system performs a fund adequacy check to determine the actual transfer amount. This ensures that the determined transfer amount is within the capacity of the fund pool sub-account, avoiding the generation of invalid transfer amounts exceeding the actual fund capacity. The system then prioritizes the fund pool sub-account, other transaction sub-accounts, and overdraft sub-accounts according to the priority order of available funds based on the transfer queue and the actual transfer amount. Sub-account fund transfers to the initiating sub-account can rationally plan the order of fund sources, prioritize the use of idle or dedicated fund pool resources, and reduce reliance on other transaction sub-accounts and overdraft resources. Verification of successful fund transfer execution results allows for timely detection of data errors or operational anomalies during the transfer process, preventing erroneous transfer results from entering subsequent processes. Removing the transaction details corresponding to the fund transfer request from the temporary stop-payment table based on the verified successful transfer execution results promptly clears the detailed data associated with completed transfers in the temporary stop-payment table, avoiding redundant data accumulation. Persistently storing the removed transaction details in the pending details table and setting their accounting status based on the transfer execution results ensures an orderly transition of transaction details from the temporary processing stage to the pending accounting stage, guaranteeing the continuity of data flow.

[0096] In a preferred embodiment of the present invention, step 500, which involves reading transaction details marked as "accountable" in the pending details table in batches via a scheduled task, and updating the balance of the main account in batches based on the read transaction details to complete the accounting process, includes:

[0097] Step 501: When the preset scheduled task execution time is reached, a batch accounting processing transaction is triggered. In the batch accounting processing transaction, the transaction records marked as "accountable" in the pending details table are queried. Transaction consistency verification is performed on the transaction records in the "accountable" state to form a set of transactions to be processed in batches. Specifically, this includes: First, taking the "accountable" transaction details stored in the pending details table in step 415, the system pre-configures a batch accounting scheduled task. The execution time of this task is set by the operations and maintenance personnel based on the business scenario, such as configuring it to execute every 5 minutes or 15 minutes, or during non-peak transaction periods (such as 2 AM). After the time is set, it is stored in the system's scheduled task configuration library. When the system time reaches the preset time, the batch accounting processing transaction is automatically triggered. This transaction adopts a preset transaction isolation level, such as READCOMMITTED, to ensure the visibility and consistency of data during transaction execution and avoid problems such as dirty reads and non-repeatable reads.

[0098] Next, within the batch accounting processing transaction, the pending details table is accessed. This table contains transaction details marked as eligible for accounting, including fields such as main account identifier, sub-account identifier, transaction amount, debit / credit direction, status identifier, and unique identifier of transaction request. A query operation is performed based on the filtering condition that the status identifier equals the eligible accounting condition. Simultaneously, the transaction request log database is queried to verify whether the transaction request corresponding to each eligible accounting record has completed the fund transfer, i.e., the successful verification result of step 413. If the transfer has not been completed, it is not included in the query results. Subsequently, the queried eligible accounting transaction records are verified in multiple dimensions: First, the transaction amount format is verified to confirm whether the amount conforms to the currency data specifications, such as retaining two decimal places and non-negative values. Second, the relationship between the main account and the sub-account is verified by querying the main-sub-account configuration table to confirm whether the sub-account identifier of the transaction record belongs to the corresponding main account identifier, avoiding cross-main account association errors. Third, the uniqueness of the transaction status is verified to confirm that there is only one eligible accounting record corresponding to the unique identifier of the same transaction request, avoiding duplicate records.

[0099] For transaction records that pass verification, they are included in a temporary set; for records that fail verification, such as incorrect amount format or abnormal relationship, they are marked as verification failures and the reasons for failure are recorded, such as abnormal number of digits in the amount or mismatch between master and sub-accounts, and are temporarily stored in the abnormal transaction log database for subsequent manual investigation; finally, all the verification-passing records in the temporary set constitute the transaction set to be processed in batches, and a unique batch identifier is assigned to this set and stored in the batch processing data cache area.

[0100] Step 502: Based on the set of transactions to be processed in batches, all transaction details are grouped and aggregated according to their respective master accounts. For each master account group, the summarization calculation of the lending and borrowing amounts is performed to obtain the net change value of each master account. Specifically, this includes: First, after receiving the notification that the set of transactions to be processed in batches is ready, the set of transactions to be processed in batches and the corresponding batch identifier are read from the batch processing data cache. Each record in the set contains a master account identifier field. Using the master account identifier as the grouping key, all transaction details in the set are grouped, that is, transaction details with the same master account identifier are grouped into the same group, forming a key-value pair structure with the master account identifier as the key and the transaction detail list as the value. For example, the group with the master account identifier MA001 contains all the recordable transaction details under that master account.

[0101] After grouping, the transaction details within each main account group are aggregated in both debit and credit directions: First, the debit / credit direction and transaction amount fields of each transaction detail within the group are read. According to the system's preset aggregation rules, debit transaction amounts are calculated as positive values, and credit transaction amounts are calculated as negative values. The direction of each amount is converted; for example, a debit amount of 100 yuan is retained as 100, and a credit amount of 50 yuan is converted to negative 50. Next, all converted amounts are accumulated. During the accumulation process, the intermediate accumulation result is recorded in real time. After each record is accumulated, it is checked whether the amount of that record has been included in the accumulation to avoid double counting. If there is a reversal transaction within the group, such as a reversal transaction of the original debit transaction being marked as a credit transaction, the reversal transaction is accumulated in reverse according to the debit / credit direction and amount to ensure that the aggregation result accurately reflects the actual fund changes of the main account.

[0102] After the summation is completed, the final result is the net change value of the main account. For example, if the total debit amount in a group of a main account is 500 yuan and the total credit amount is 300 yuan, the net change value is 200 yuan. Each main account identifier is associated with the corresponding net change value and stored to form a mapping table between the main account identifier and the net change value. At the same time, the number of transaction details and the summary time of each group are recorded and stored in the net summation result database.

[0103] Step 503: Based on the net change values ​​of each master account, perform an atomic update on the current balance of the corresponding master account using a batch update operation to obtain the master account balance update transaction result, specifically including:

[0104] First, upon receiving the net summation ready notification, the system reads the mapping table between the main account identifier and the net summation result database. Simultaneously, it calls the main account balance query interface to access the main account balance database. This database stores fields such as the current balance, balance update time, and most recent transaction batch identifier for each main account. The query interface extracts the corresponding current balance one by one according to the main account identifier in the mapping table. During the extraction process, row-level locks are applied to the balance record of each main account to prevent other transactions from modifying the balance in concurrent scenarios, thus ensuring the accuracy of the balance data.

[0105] Next, the extracted current balance is added to the corresponding net change value to obtain the new balance of the main account. For example, if the current balance is 1,000 yuan and the net change value is 200 yuan, the new balance is 1,200 yuan. During the calculation process, it is verified whether the new balance meets the business rules. For example, if the main account is a non-overdraft account, the new balance must be greater than or equal to 0. If the new balance is less than 0, it is determined to be an abnormal balance, the update operation of the main account is suspended and marked as an abnormal balance, and recorded in the balance update log.

[0106] Subsequently, using a pre-defined batch update statement from the database, such as the UPDATE...IN statement in SQL, the current balance field of all master accounts with correctly calculated balances is updated to the new balance. Simultaneously, the balance update time is updated to the current system time, and the most recent transaction batch identifier is updated to the batch identifier from step 501. The batch update operation ensures that the balance updates of all master accounts are executed within the same transaction. If the update operation of any master account fails, such as due to a database connection interruption, the entire batch update transaction is rolled back, and the balances of all master accounts are restored to their pre-update state, avoiding inconsistencies in balance data caused by some master accounts succeeding while others fail. After the update is complete, the row-level locks on all master account balance records are released, and a master account balance update transaction result is generated. This result includes information such as the number of master accounts that were successfully updated, the identifiers and reasons for failed updates, and the update batch identifier. The transaction result is then stored in the balance update result database.

[0107] Step 504: Based on the main account balance update transaction result, mark the update status of the corresponding transaction detail record in the batch processing transaction set as "posted," completing this batch posting process. Specifically, this includes: First, after receiving the balance update ready notification, reading the main account balance update transaction result from the balance update result database, and simultaneously reading the batch processing transaction set and batch identifier from the batch processing data cache; first, filtering the successfully updated main account identifiers in the transaction results, and associating the corresponding transaction details in the batch processing transaction set according to the main account identifier, forming an association list of successfully updated main accounts and transaction details; then, accessing the pending details table, and performing a status update operation on each transaction detail in the association list: changing the status identifier field from "ready to post" to "posted," and simultaneously updating the posting time to the current system time and the posting batch identifier to the batch identifier in step 501; to improve update efficiency, a batch update method is adopted, performing status updates in batches according to the main account identifier to avoid frequent database operations caused by single updates.

[0108] For transaction details corresponding to the primary account that failed to update in the transaction results, their bookkeeping status is not modified. Instead, the failure of this batch bookkeeping is recorded in the remarks field. The reason is: such as the database update failure due to an abnormal balance. It will be re-verified and processed when the next batch bookkeeping task is executed. After the status update is completed, the transaction details corresponding to this batch identifier in the pending details table are queried to confirm that the details associated with the primary account that were successfully updated have been marked as bookkeeping, and the details associated with the primary account that failed to update are still bookkeeping and the remarks are complete. After the verification is passed, a statistical report of this batch bookkeeping process is generated. The report includes information such as the processing batch identifier, processing time, total number of records to be processed in batch, number of successfully bookkeeping records, number of failed records to be retried, and distribution of failure reasons. Finally, the statistical report is stored in the batch bookkeeping log database, and a notification of completion of this batch bookkeeping is sent.

[0109] In this embodiment of the invention, triggering batch accounting transactions at preset time points ensures the regularity and timeliness of accounting processing, avoiding processing chaos caused by random triggering; querying transaction records in the pending details table that are eligible for accounting can filter out data that meets the accounting conditions; through transaction consistency verification, invalid records with abnormal data formats or missing related information can be excluded, forming a reliable set of transactions to be processed in batches, laying a high-quality data foundation for subsequent batch operations; grouping and aggregating transaction details by their respective main accounts can classify scattered single transaction data under the corresponding main account, avoiding data interference across main accounts; summarizing the loan and borrow amounts for each main account to obtain the net change value can merge the amounts of multiple scattered transactions into a single net change, reducing the number of subsequent main account balance updates and improving efficiency. In terms of processing efficiency, batch update operations based on net change values ​​perform atomic updates to the main account balance, ensuring that balance update operations for the same main account are either fully executed or completely rolled back, avoiding inconsistencies in balance data caused by partial updates. Batch updates reduce frequent access to and locking of main account resources, reducing resource contention pressure and improving the overall efficiency of main account balance updates. Marking transaction details as posted based on the balance update transaction results clearly distinguishes between completed and incomplete posting transactions, avoiding duplicate or missed postings and ensuring that each transaction participates in accounting processing only once. The completion status update marks the closed loop of the batch posting process, making the processing progress of transaction data traceable, while maintaining the clear and orderly status of data in the pending details table, reducing the cost of filtering invalid data for the next batch processing.

[0110] like Figure 2 As shown, embodiments of the present invention also provide a system for handling high concurrency issues of hot accounts based on master and sub-accounts, including:

[0111] The receiving module is used to receive accounting transaction requests that include the transaction type and transaction amount;

[0112] The routing module is used to respond to the accounting transaction request and route the accounting transaction request to the corresponding target sub-account according to the transaction type and transaction amount;

[0113] The processing module is used to process accounting transaction requests on the target sub-account. For debit transactions, the transaction amount and debit / credit direction are inserted into the temporary stop payment table, and the records in the temporary stop payment table are netted to determine the available balance. If the available balance is sufficient, the transaction details are moved to the pending details table. If the available balance is insufficient, a fund transfer request is generated.

[0114] The scheduling module is used to process the fund transfer request. It obtains multiple performance index data by querying the fund transfer history, and generates transfer control parameters based on the multiple performance index data through a predefined evaluation strategy. It determines the priority and amount of fund transfer according to the transfer control parameters, and transfers funds from the fund pool sub-account, other transaction sub-accounts or overdraft sub-accounts to the sub-account that initiated the transfer according to the determined priority and transfer amount. After the fund transfer operation is completed, the transaction details corresponding to the fund transfer request are moved from the temporary stop payment table to the pending details table and marked as registrable.

[0115] The batch synchronization module is used to read transaction details marked as recordable in the pending details table in batches through a scheduled task, and update the balance of the main account in batches based on the read transaction details to complete the accounting process.

[0116] It should be noted that this system is a system corresponding to the above method. All implementation methods in the above method embodiments are applicable to this embodiment and can achieve the same technical effect.

[0117] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for handling high concurrency issues of frequently accessed accounts based on master and sub-accounts, characterized in that, The method includes: Step 100: Receive an accounting transaction request containing the transaction type and transaction amount; Step 200: In response to the accounting transaction request, the accounting transaction request is routed to the corresponding target sub-account according to the transaction type and transaction amount; Step 300: Based on the target sub-account, identify the debit / credit direction of the accounting transaction request; for debit transactions, insert the transaction amount and debit / credit direction into the temporary stop payment table, and perform netting calculation on the records in the temporary stop payment table to determine the available balance. If the available balance is sufficient, move the transaction details to the pending details table; if the available balance is insufficient, generate a fund transfer request; for credit transactions, record the transaction details in the pending details table, including: Receive an accounting transaction request on the target sub-account; parse the accounting transaction request, identify its lending / borrowing direction, and obtain the lending / borrowing direction identification result; when the lending / borrowing direction identification result is a debit, insert the current transaction amount and lending / borrowing direction as a new record into the temporary stop payment table corresponding to the sub-account; read all records in the temporary stop payment table after the new record is inserted, perform netting calculation based on the lending / borrowing direction and amount in the records, and obtain the current temporary stop payment net amount; add the current balance of the sub-account to the current temporary stop payment net amount to obtain the real-time available balance of the sub-account; The real-time available balance is compared with the current transaction amount to generate a balance adequacy determination result. This includes: extracting the real-time available balance; extracting the current transaction amount from the integrated accounting transaction request data, i.e., the amount of funds to be deducted in this debit transaction; preprocessing the two values, including verifying whether the values ​​are non-negative and ensuring consistent numerical precision; after completing the numerical preprocessing, obtaining the historical real-time available balance data of the target sub-account within a preset time period. The preset time period is configured by the system based on transaction frequency. The balance data is fitted in chronological order to generate a balance change curve, where the horizontal axis of the two-dimensional coordinate system is set to the timestamp in seconds, and the vertical axis is set to the balance value in the same unit as the transaction amount; constructing a system for determining... The closed polygon region is defined, with its boundaries set based on key thresholds for balance determination. The horizontal axis ranges from the current timestamp to a preset time period covering historical balance data. The vertical axis contains three key values: the overdraft limit, 0, and the current transaction amount. The overdraft limit is the maximum allowed overdraft amount configured for the sub-account if it supports overdraft; it is negative. 0 represents the baseline for a zero balance. The current transaction amount is the amount of funds to be deducted this time. The coordinates corresponding to the current timestamp minus the preset time period are connected to the coordinates corresponding to the overdraft limit. Then, the coordinates corresponding to the current timestamp are connected to the coordinates corresponding to the overdraft limit. Finally, the coordinates corresponding to the current timestamp are connected to the coordinates corresponding to the current transaction amount. The coordinates are then connected to the coordinates corresponding to the current timestamp minus the preset time period and the coordinates corresponding to the current transaction amount. Finally, the coordinates are connected back to the coordinates corresponding to the current timestamp minus the preset time period and the coordinates corresponding to the overdraft limit, thus forming a closed polygon. The interior of the closed polygon defines the potential range where the balance can cover the transaction amount or is within the allowed overdraft range. Each continuous segment of the balance change curve, consisting of the balance data of two adjacent timestamps, is traversed, and its intersection with the four boundary lines of the polygon is checked one by one. For each curve segment, it is first determined whether it overlaps or intersects with the boundary lines. If an intersection exists, the coordinates of the intersection point are calculated, i.e., the timestamp and the balance value, and the type of boundary line to which the intersection point belongs is recorded. After completing the intersection calculation... The system combines intersection analysis and real-time value comparison for comprehensive judgment: First, a basic comparison operation is performed to determine whether the real-time available balance is greater than or equal to the current transaction amount; then, intersection data is used for auxiliary verification. If the basic comparison result shows that the real-time available balance is greater than or equal to the current transaction amount, and the balance change curve has not intersected with the current transaction amount line in the most recent preset time period, or the intersection timestamp is before the current timestamp and the curve subsequently shows an upward trend, then the judgment is strengthened to indicate that the available balance is sufficient; if the basic comparison result shows that the real-time available balance is greater than or equal to the current transaction amount, and the curve has recently intersected with the current transaction amount line and subsequently shows a downward trend, then while determining that the available balance is sufficient, a supplementary prompt indicating that the balance is at risk of decreasing is recorded.If the basic comparison result shows that the real-time available balance is less than the current transaction amount, and the curve does not intersect with the overdraft limit line (i.e., the balance has not exceeded the overdraft limit), it is determined that the available balance is insufficient but an overdraft transfer can be triggered. If the curve has intersected with the overdraft limit line (i.e., the balance has exceeded the overdraft limit), it is determined that the available balance is insufficient and there is no overdraft space. When the balance adequacy determination result is that the available balance is sufficient, the current transaction details are moved from the temporary stop payment table to the pending details table. When the balance adequacy determination result is that the available balance is insufficient, a fund transfer request for the sub-account is generated. When the lending direction identification result is a credit, the current transaction details are directly recorded to the pending details table. Step 400: Process the fund transfer request. Obtain multiple performance indicator data by querying the fund transfer history. Generate transfer control parameters based on the multiple performance indicator data using a predefined evaluation strategy. Determine the priority and amount of fund transfer according to the transfer control parameters. Transfer funds from the fund pool sub-account, other transaction sub-accounts, or overdraft sub-account to the sub-account that initiated the transfer according to the determined priority and transfer amount. After the fund transfer operation is completed, move the transaction details corresponding to the fund transfer request from the temporary stop payment table to the pending details table and mark it as available for accounting. Step 500: Based on the transaction details marked as recordable in the pending details table, the transaction details marked as recordable are read in batches through a scheduled task, and the balance of the main account is updated in batches based on the read transaction details to complete the accounting process.

2. The method for handling high concurrency issues of hot accounts based on master and sub-accounts according to claim 1, characterized in that, Step 200 includes: Parse the accounting transaction request and identify the transaction type of the accounting transaction request; Based on the transaction type, if it is a frozen transaction, the target sub-account is determined to be a frozen sub-account; if it is a normal accounting transaction, an available sub-account is selected as the target sub-account from multiple corresponding transaction sub-accounts according to the preset range to which the transaction amount belongs. The transaction request is routed to the identified target sub-account.

3. The method for handling high concurrency issues of hot accounts based on master and sub-accounts according to claim 2, characterized in that, Step 400 includes: In response to the fund transfer request, query the fund transfer history within a preset time period; Extract the delay time, transfer result status, and number of concurrent requests for each transfer from the historical fund transfer history to obtain a historical transfer record set; Based on the historical allocation record set, calculate the average historical allocation delay, the average historical allocation success rate, and the peak concurrent processing volume. The average historical allocation delay, the average historical allocation success rate, and the peak concurrent processing volume are used as multiple performance indicators. The multiple performance index data are normalized to form a normalized index vector; the normalized index vector is weighted and calculated with a predefined weight coefficient vector to obtain a comprehensive performance index. Based on the comprehensive performance index, the corresponding allocation priority weight is determined by querying a predefined mapping relationship table; Based on multiple performance index data, the average historical allocation success rate is extracted, and the ratio of the average historical allocation success rate to the preset success rate threshold is calculated to obtain the real-time allocation coefficient. The allocation priority weights and real-time allocation coefficients are combined to form the allocation control parameters used for fund allocation decisions.

4. The method for handling high concurrency issues of hot accounts based on master and sub-accounts according to claim 3, characterized in that, Step 400 also includes: Using the allocation priority weight in the allocation control parameters as the sorting key, all pending fund allocation requests are sorted to obtain an allocation queue. For the current allocation request, the basic allocation amount is determined based on the preset water level configuration of the target sub-account; Based on the aforementioned basic transfer amount, and combined with the current available balance of the fund pool sub-account, a fund adequacy verification is performed to determine the actual transfer amount; Based on the allocation queue and the actual allocation amount, funds are allocated from the available sub-accounts to the sub-account initiating the allocation, according to the priority order of the fund pool sub-account, other transaction sub-accounts, and overdraft sub-accounts, generating a fund allocation execution result that includes the execution status and transfer details. Based on the execution result of the fund transfer, a successfully verified fund transfer execution result is obtained. Based on the verified successful fund transfer execution result, the transaction details corresponding to the fund transfer request are removed from the temporary stop payment list, and the removed transaction details are obtained. The removed transaction details are persistently stored in the pending details table, and the transaction details are set to an accountable status based on the fund transfer execution result.

5. The method for handling high concurrency issues of hot accounts based on master and sub-accounts according to claim 4, characterized in that, Step 500 includes: When the preset scheduled task execution time is reached, a batch accounting processing transaction is triggered; in the batch accounting processing transaction, the transaction records with the status marked as "accountable" in the pending details table are queried; the transaction records in the "accountable" status are checked for transaction consistency to form a set of transactions to be processed in batches. Based on the set of transactions to be processed in batches, all transaction details are grouped and aggregated according to their respective main accounts. For each main account group, the summation calculation of the lending and borrowing amounts is performed to obtain the net change value of each main account. Based on the net change value of each master account, the current balance of the corresponding master account is atomically updated using a batch update operation to obtain the master account balance update transaction result. Based on the transaction result of updating the main account balance, the update status of the corresponding transaction details record in the transaction set to be processed in batches is marked as recorded, thus completing the batch recording process.

6. A system for handling high concurrency issues of hot accounts based on master and sub-accounts, the system implementing the method as described in any one of claims 1 to 5, characterized in that, include: The receiving module is used to receive accounting transaction requests that include the transaction type and transaction amount; The routing module is used to respond to the accounting transaction request and route the accounting transaction request to the corresponding target sub-account according to the transaction type and transaction amount; The processing module is used to process accounting transaction requests on the target sub-account. For debit transactions, the transaction amount and debit / credit direction are inserted into the temporary stop payment table, and the records in the temporary stop payment table are netted to determine the available balance. If the available balance is sufficient, the transaction details are moved to the pending details table. If the available balance is insufficient, a fund transfer request is generated. The scheduling module is used to process the fund transfer request. It obtains multiple performance index data by querying the fund transfer history, and generates transfer control parameters based on the multiple performance index data through a predefined evaluation strategy. It determines the priority and amount of fund transfer according to the transfer control parameters, and transfers funds from the fund pool sub-account, other transaction sub-accounts or overdraft sub-accounts to the sub-account that initiated the transfer according to the determined priority and transfer amount. After the fund transfer operation is completed, the transaction details corresponding to the fund transfer request are moved from the temporary stop payment table to the pending details table and marked as registrable. The batch synchronization module is used to read transaction details marked as recordable in the pending details table in batches through a scheduled task, and update the balance of the main account in batches based on the read transaction details to complete the accounting process.

7. A computing device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program that, when executed by a processor, implements the method as described in any one of claims 1 to 5.

Images