A method and system for clearing orders based on direct delivery

Abstract

The present invention provides a direct-through order clearing method and system, which relates to the field of data processing technology. The method includes obtaining pending order files in shared storage, assigning a unique order clearing service group to each file based on the real-time load status of each order clearing service group and the number of orders in the pending file, generating a task record containing a file identifier, an assigned service group identifier, and an initial status, and writing the task record into a pending task table; triggering the corresponding order clearing service group based on the task record in the pending task table, and simultaneously updating the status of the task record to "processing". The present invention solves the problems of massive order processing, multi-account collaboration, and hotspot account conflicts in scenarios where banks and e-commerce platforms are directly connected.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a direct-through order clearing method and system. Background Art

[0002] In clearing scenarios where banks are directly connected to large e-commerce platforms, some traditional systems face the following problems:

[0003] For example, the efficiency of processing massive orders is insufficient. On average, asynchronous clearing files for 50 million to 75 million orders need to be processed every day, and the high concurrency requirement of 2300+TPS for online transactions must be met (such as 500-800TPS for refunds and 800-1500TPS for electronic transfers). The existing serial architecture cannot guarantee a 10-second response time. The multi-level account system is complex to coordinate, and it is necessary to simultaneously manage the flow of funds for the platform's functional accounts (pending accounts / advance funding / withdrawals in progress), the platform's own accounts (commissions / marketing), and merchant dual accounts (pending settlement 01 / cash 02). The transaction-by-transaction processing mode makes it difficult to achieve atomic operations across accounts.

[0004] For example, high-frequency trading triggers conflicts in hot accounts, and scenarios such as refunds and transfers require centralized access to pending accounts. Exceeding 500 TPS will lead to database row lock contention, resulting in a sharp drop in throughput and the risk of financial errors. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a direct-connection-based order clearing method and system to solve the problems of massive order processing, multi-account collaboration and hot account conflicts in the scenario of direct connection between banks and e-commerce platforms.

[0006] In order to solve the above technical problems, the technical solutions of the present invention are as follows:

[0007] In a first aspect, a method for clearing orders based on direct delivery is provided, the method comprising:

[0008] Step 1: Obtain pending order files from shared storage. Based on the real-time load status of each order clearing service group and the number of orders in the pending file, assign a unique order clearing service group to each file. Generate a task record containing the file identifier, assigned service group identifier, and initial status, and write the task record to the pending task table.

[0009] Step 2: trigger the corresponding order clearing service group according to the task record in the pending task table, and update the status of the task record to "in process";

[0010] Step 3: The triggered order clearing service group obtains task records with the status of "in progress" from the pending task table, routes the order file data to the designated order processing library's daily shard table for storage based on the file dimension using a hash algorithm, and creates an order number index record in an independent index library based on the storage result. This record contains the order number, the corresponding order processing library ID, and the shard table ID.

[0011] Step 4: Based on the stored order file data, calculate the total amount that needs to be debited from the platform's pending accounts using the file dimension;

[0012] Step 5: Based on the stored order file data, calculate the amount to be credited to each merchant's pending settlement account in the file dimension;

[0013] Step 6: Access the platform account library, perform the summary debit operation on the pending accounts based on the calculated total debit amount, route to the designated merchant account library according to the merchant account hash value, and perform the summary debit operation on the merchant accounts to be settled based on the calculated debit amount of each merchant.

[0014] Second, a direct-through order clearing system includes:

[0015] The acquisition module is used to obtain pending order files in the shared storage, assign a unique order clearing service group to each file based on the real-time load status of each order clearing service group and the number of orders in the pending file, generate a task record containing the file identifier, the assigned service group identifier, and the initial status, and write the task record to the pending task table; based on the task record in the pending task table, trigger the corresponding order clearing service group and update the status of the task record to processing;

[0016] The calculation module is used for the triggered order clearing service group to obtain task records with a status of "in-process" from the pending task table, route the order file data to the designated order processing library's daily shard table for storage based on the file dimension through a hash algorithm, and, based on the storage result, create an order number index record in an independent index library. This record contains the order number, the corresponding order processing library identifier, and the shard table identifier; based on the stored order file data, the total amount that needs to be debited from the platform's pending accounts is calculated in the file dimension; based on the stored order file data, the amount that needs to be credited to each merchant's pending settlement account is calculated in the file dimension;

[0017] The processing module is used to access the platform account library, perform the summary account release operation of the pending accounts based on the calculated total account release amount, route to the designated merchant account library according to the merchant account hash value, and perform the summary account release operation of the merchant's pending settlement accounts based on the calculated account release amount of each merchant.

[0018] According to a third aspect, a computing device includes:

[0019] one or more processors;

[0020] The storage device is used to store one or more programs, and when the one or more programs are executed by the one or more processors, the one or more processors implement the method.

[0021] In a fourth aspect, a computer-readable storage medium stores a program, which implements the method when executed by a processor.

[0022] The above solution of the present invention includes at least the following beneficial effects:

[0023] Dynamic resource scheduling ensures load balancing across service groups, reduces task queue wait times, and improves overall order clearing and processing throughput. Standardized task records and status tags provide traceability throughout the entire order processing process, making it easier to monitor task progress and locate abnormal nodes, preventing task loss or duplication and improving system reliability. Tables are partitioned by date to reduce the amount of data per table. Combined with hash routing, data is evenly distributed, reducing database I / O bottlenecks and improving storage and query efficiency. The independent index library directly associates the order number with the storage location, and can quickly locate data during queries without a full table scan. It is especially suitable for high-frequency order retrieval scenarios, avoiding order-by-order calculations and account operations, and merging multiple small calculations into batch processing, reducing the number of database interactions and CPU and memory resource consumption. Account operations are performed after unified aggregation, improving settlement efficiency and reducing the probability of operational errors (such as duplicate accounting and amount calculation errors). Through hash routing, account operations are distributed to different database instances to avoid high load on a single account library, realize parallel processing of funds settlement, shorten overall settlement time, reduce delays in intermediate links, improve the timeliness of order clearing processing, and reduce manual operation costs and the risk of human error. When business volume grows, the system capacity can be increased by adding order clearing service groups or account library nodes without significantly modifying the underlying architecture, reducing expansion costs and complexity. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 The present invention provides a flowchart of a method for clearing orders based on direct delivery.

[0025] Figure 2 This is a schematic diagram of a direct-through order clearing system provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0026] Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0027] like Figure 1 As shown, an embodiment of the present invention proposes a method for clearing orders based on direct delivery, the method comprising the following steps:

[0028] Step 1: Obtain pending order files from shared storage. Based on the real-time load status of each order clearing service group and the number of orders in the pending file, assign a unique order clearing service group to each file. Generate a task record containing the file identifier, assigned service group identifier, and initial status, and write the task record to the pending task table.

[0029] Step 2: trigger the corresponding order clearing service group according to the task record in the pending task table, and update the status of the task record to "in process";

[0030] Step 3: The triggered order clearing service group obtains task records with the status of "in progress" from the pending task table, routes the order file data to the designated order processing library's daily shard table for storage based on the file dimension using a hash algorithm, and creates an order number index record in an independent index library based on the storage result. This record contains the order number, the corresponding order processing library ID, and the shard table ID.

[0031] Step 4: Based on the stored order file data, calculate the total amount that needs to be debited from the platform's pending accounts using the file dimension;

[0032] Step 5: Based on the stored order file data, calculate the amount to be credited to each merchant's pending settlement account in the file dimension;

[0033] Step 6: Access the platform account library, perform the summary debit operation on the pending accounts based on the calculated total debit amount, route to the designated merchant account library according to the merchant account hash value, and perform the summary debit operation on the merchant accounts to be settled based on the calculated debit amount of each merchant.

[0034] In an embodiment of the present invention, load balancing distribution of pending order files is achieved through file preprocessing services, and routing storage and independent index construction of order data are achieved using a hash algorithm. The total amount of accounts debited from the platform and the amount of accounts credited to merchants' pending settlement accounts are summarized and calculated in file dimensions, and batch operations on accounts are performed based on distributed transactions. This effectively improves the efficiency of processing massive orders, meets high concurrency requirements, solves the complexities of multi-level account collaboration and conflicts in hotspot accounts, and ensures the accuracy and timeliness of fund processing.

[0035] In a preferred embodiment of the present invention, the above step 1 may include:

[0036] Step 1.1: Deployed in the file pre-processing service, it continuously scans the shared storage area, identifies newly added order files to be processed, and obtains the unique file identifier and total number of orders for each file;

[0037] Step 1.2: Calculate the load weight of each service group based on the real-time collected operating status indicators of each order clearing service group;

[0038] Step 1.3: Based on the total number of orders for the pending files and the load weights of each service group, a weighted round-robin algorithm is used to assign each file to the order clearing service group with the most balanced load, generating a task record containing the file identifier, the assigned service group identifier, and an initial status of "pending";

[0039] Step 1.4: Write the generated task records into the pending task table of the distributed database.

[0040] In an embodiment of the present invention, newly added order files are identified and their key information is obtained by continuously scanning the shared storage area, and the load weight is calculated in combination with the real-time collected operating status indicators of each order clearing service group. Then, a weighted polling algorithm is used to assign the service group with the most balanced load to each file, and finally, the task record is written into the distributed database pending task table, thereby realizing dynamic load balancing distribution of order file processing tasks, effectively avoiding the problem of low processing efficiency caused by unbalanced load of service groups, and improving the overall processing performance and resource utilization of the system.

[0041] In an embodiment of the present invention, the specific steps include:

[0042] In step 1.1, deploy a scanner in the file preprocessing service and set a scheduled scanning mechanism (e.g., every second / minute) to traverse the shared storage area. Identify newly added order files to be processed based on features such as file creation time and file name rules. For each identified file, extract its unique file identifier and parse the file content to count the total number of orders.

[0043] In step 1.2, monitor the operating status of each order clearing service group in real time. Collect metrics such as CPU usage, memory usage, thread pool task queue length, and current order processing rate. Based on a preset weight formula (e.g., 40% CPU usage, 30% memory usage, and 30% task queue length), standardize each metric and calculate the load weight of each service group. A lower weight indicates a lighter load.

[0044] In step 1.3, establish a mapping rule between pending files and service groups. Take the total number of file orders and the service group load weight as input parameters, and use a weighted round-robin algorithm (such as assigning scheduling priority according to the weight ratio) to match each file with the service group with the most balanced load. When generating a task record, it includes the file identifier, the assigned service group ID, the initial status of the task (pending), and metadata such as the timestamp.

[0045] In step 1.4, write the generated task record to the pending tasks table using a distributed database client (such as MySQL Cluster or MongoDB). Ensure that the record contains necessary fields, such as the primary key (task ID), file identifier, service group ID, status field, and creation time.

[0046] In a preferred embodiment of the present invention, the above step 2 may include:

[0047] Step 2.1: The deployed file pre-processing service monitors the pending task table write completion event of the distributed database, and when a new task record is detected, extracts the assigned service group identifier and initial status of the record;

[0048] Step 2.2: Verify that the initial status of the task record is pending, and confirm the current health status of the corresponding order clearing service group;

[0049] In step 2.3, based on the current health status, an atomic operation is performed through a distributed transaction to update the status of the task record from pending to processing.

[0050] In an embodiment of the present invention, a file preprocessing service is deployed to monitor the write completion event of the distributed database pending task table. When a new task record is detected, the assigned service group identifier and initial status are extracted. After verifying that the status is pending and confirming the health status of the corresponding service group, the task record status is atomically updated to processing with the help of distributed transactions, ensuring the real-time, accuracy and reliability of the task triggering process, effectively avoiding the problem of repeated task processing or inconsistent status, and ensuring the orderliness and data consistency of task processing in the system under high concurrency scenarios.

[0051] In an embodiment of the present invention, the specific steps include:

[0052] In step 2.1, integrate a database monitoring component into the file preprocessing service and set a write completion event trigger for the pending task table in the distributed database. When a new task record is written to the database, the monitoring service captures the event in real time, parses the event data, and extracts the assigned service group identifier and initial status (Status = Pending) from the task record.

[0053] Step 2.2, status verification, verifies whether the initial status of the task record is "pending" through the database query interface to avoid repeated triggering of tasks that have been processed or are in abnormal status.

[0054] Health check: Send a health check request to the service registry (such as Eureka or Nacos) corresponding to the assigned service group to obtain the real-time status of the service group (such as the number of online nodes, response time, and error rate) and confirm that the service group is in a healthy state capable of processing tasks (such as Healthy = true).

[0055] In step 2.3, a distributed transaction framework (such as Seata or the XA protocol) is used to encapsulate the status update operation. If the service group is healthy, the SQL statement is executed: UPDATE pending task table SET status = processing WHERE task ID = ?, and the operation process is recorded in the transaction log. When the transaction is committed, the atomicity of the status update and event notification is ensured. If the update fails, it is rolled back to avoid inconsistent task status. After the update is completed, a triggering message is sent to the corresponding service group.

[0056] In a preferred embodiment of the present invention, the above step 3 may include:

[0057] Step 3.1: The order clearing service group extracts the processing instruction event from the local pending task queue, parses it to obtain the file identifier and task record ID, and obtains the task record with the status of "in progress" from the pending task table of the distributed database based on the task record ID;

[0058] Step 3.2: Based on the file identifier in the task record, access the shared storage area to read the original data of the corresponding order file and verify the file integrity;

[0059] Step 3.3: Generate a sub-table identifier for the current day based on the preset date hash rule, determine the target order processing database identifier using a consistent hashing algorithm based on the file identifier, and write the order file data into the sub-table for the current day of the target order processing database in batches according to the file dimension;

[0060] In step 3.4, after the order data is successfully stored, based on the transaction ID returned by the storage operation, the order number index record is synchronously written to the independent index library. Each record contains: order number, target order processing library identifier, current day table identifier, and file identifier.

[0061] In an embodiment of the present invention, the order clearing service group efficiently extracts processing instructions from the local queue, parses and obtains task records, and ensures the orderliness and real-time nature of task processing; accesses the shared storage area to read order files and verifies their integrity to ensure data accuracy; uses date hashing and consistent hashing algorithms to implement intelligent sub-library and table storage of order data, improves storage efficiency and data distribution balance, and avoids database hotspot issues; and synchronously establishes an independent index library after successful order data storage, constructs a fast retrieval path for the order number, and facilitates subsequent efficient query and positioning based on the order number, thereby achieving overall efficiency, accuracy, and traceability of order data storage and index construction.

[0062] In an embodiment of the present invention, the specific steps include:

[0063] Step 3.1, event extraction, the order clearing service group regularly polls the local pending task queue (based on memory queue or Redis cache) through the local task scheduler (such as Quartz, TaskScheduler) to extract the processing instruction event (including metadata such as task ID and file identifier).

[0064] Data parsing: parse the event content through the JSON / XML parser to obtain the file unique identifier (FileID) and task record ID (TaskID).

[0065] Database query: construct an SQL query statement based on TaskID, query the task record through a distributed database client (such as MyBatis, Hibernate), and verify whether the task status is "processing".

[0066] Step 3.2, file access, based on the FileID in the task record, access the shared storage area (such as HDFS, Ceph) through the file system interface (such as NFS, S3 client) and read the corresponding order file (such as CSV, JSON format).

[0067] integrity check, Generates a 256-bit (32-byte) hash value, presented as a 64-bit hexadecimal string. The calculation steps are:

[0068] Data preprocessing: pad the data to a length modulo 512 equal to 448, and add 64 bits of the original length;

[0069] Message extension, which expands a 512-bit block into 64 32-bit words;

[0070] Iterative calculation, through 64 rounds of operations (each round uses a different compression function), finally outputs a 256-bit hash value, the formula is: ,in For file binary data, The calculated hash value is compared with the preset file hash value in the task record; or the file integrity is verified through the checksum at the end of the file, the consistency of the number of file lines and the total number of orders. If the verification fails, the exception is recorded and the file retransmission mechanism is triggered.

[0071] Step 3.3, table shard identifier generation: Generate the table shard name for that day based on the current date (e.g., 20250615) according to the preset rules (e.g., order_data_yyyyMMdd). If a table suffix rule exists (e.g., modulo the file ID), append a suffix (e.g., _01).

[0072] Target library routing, input the file identifier into the consistent hash algorithm, combined with the database node virtual ring mapping, to determine the target order processing library (such as mapping FileID to node A through the consistent hash ring).

[0073] Batch writing: parse the order file data into an object collection by row. Use the database batch insert interface (such as JDBC Batch or MyBatis batch insert) to write the data into the target database's daily table at one time based on the file dimension. Set the batch size to 500-1000 records per batch to balance performance and memory usage.

[0074] Step 3.4, transaction association, captures the transaction ID (TransactionID) returned by the database storage operation as the association identifier between the index record and the data storage.

[0075] Index construction: traverse each record in the order data, extract the order number (OrderNo), combine the target database identifier (DBID), the day's table identifier (TableID) and FileID to construct the index record.

[0076] Write to the index library: write index records to the index library through an independent index library client (such as Elasticsearch, Redis), and create a unique index with OrderNo as the key.

[0077] In a preferred embodiment of the present invention, the above step 4 may include:

[0078] Step 4.1: The order clearing service group monitors the storage completion event of the distributed database. When it detects that the task record status is stored, it extracts the file ID, target order processing database ID, and daily table ID of the record;

[0079] Step 4.2: Based on the target order processing database ID and the current day's table ID, construct a cross-database query statement to batch retrieve all order records corresponding to the file ID from the specified table;

[0080] In step 4.3, parse the Amount Receivable field in the order record, aggregate the Amount Receivable of all orders in the file using the file dimension, and generate the total amount that needs to be debited to the platform's pending account.

[0081] In an embodiment of the present invention, the order clearing service group monitors the storage completion event of the distributed database to ensure that the file identifier, target order processing library identifier and the day's sub-table identifier are extracted after the order data is completely stored, thereby ensuring the accuracy of data processing; based on the obtained identifier, a cross-library query statement is constructed and order records are obtained in batches, making full use of the advantages of the sub-library and sub-table architecture to improve data query efficiency; the receivable amount is parsed and aggregated according to the file dimension to generate the total amount of the platform's pending account, and the traditional transaction-by-transaction processing mode is transformed into batch aggregation processing, which greatly reduces the calculation time and effectively improves the amount calculation efficiency in massive order scenarios, laying an efficient and accurate data foundation for subsequent account batch operations, while avoiding the hot account conflict problem caused by transaction-by-transaction processing.

[0082] In an embodiment of the present invention, the specific steps include:

[0083] Step 4.1, deploy the database monitoring service: Configure the database monitoring component (such as MySQL-based Binlog monitoring or message queue trigger) in the order clearing service group to continuously monitor the status change events of the task record table in the distributed database.

[0084] Event filtering and extraction: When the status field of a task record is detected to be updated from "Processing" to "Stored", the event handler is triggered to extract the following fields:

[0085] File ID (FileID), a string that uniquely identifies an order file.

[0086] Target order processing database ID (DBID), indicating the database instance where the order data is stored.

[0087] The table ID of the day (TableID) indicates the specific table where the order data is stored (such as order_20250615).

[0088] Parameter validation checks the integrity of the extracted fields to ensure there are no empty or invalid values.

[0089] Step 4.2: Dynamically generate SQL queries and construct cross-database query statements based on the extracted DBID and TableID.

[0090] Configure the database connection pool. For distributed database clusters, configure the connection pool parameters (such as the maximum number of connections and timeout) to ensure efficient data acquisition.

[0091] Execute batch queries, execute SQL queries through the database connection pool, and use paging or streaming processing to obtain all order records to avoid memory overflow.

[0092] In step 4.3, field parsing and verification, traverse the query result set, parse the amount_receivable field in each order record, and perform data format verification (for example, whether it is a numeric type and whether it is greater than 0).

[0093] Initialize the aggregation variable and define an accumulator variable (such as total_amount=0) to store the total amount of the document dimension.

[0094] Perform amount aggregation to add up the receivable amounts of all order records under the same file ID. The formula is: in, The total number of orders placed for that document, For the The value of the Amount Receivable field of the order record.

[0095] In a preferred embodiment of the present invention, the above step 5 may include:

[0096] Step 5.1: The order clearing service group reuses the storage completion event monitored in step 4.1 and synchronously extracts the file identifier, target order processing library identifier, and daily table identifier from the task record.

[0097] Step 5.2: Based on the target order processing database ID and the daily table ID, a cross-database aggregation query statement is constructed to batch retrieve order records corresponding to the file ID from the designated table, grouped by merchant ID.

[0098] Step 5.3: Parse the merchant ID field and the payable amount field in the order record, group and aggregate the payable amounts of all orders in the file by merchant ID, and generate a mapping table of the amounts to be posted to each merchant's pending settlement account.

[0099] In an embodiment of the present invention, key identifiers are extracted from completed events through reused storage to avoid repeated monitoring and improve resource utilization; a cross-database aggregation query is constructed to obtain order records in batches by grouping by merchant identifiers, and a sharded database and table architecture is used to achieve efficient data retrieval and reduce cross-database query overhead; the payable amount is parsed and aggregated by merchant group to generate an amount mapping table, and the transaction-by-transaction processing is converted into batch aggregation, which greatly reduces the frequency of database operations, effectively avoids conflicts in hot account accounts, and ensures the accuracy and consistency of the merchant's account amounts.

[0100] In an embodiment of the present invention, the specific steps include:

[0101] In step 5.1, configure an event listener module in the order clearing service group and reuse the distributed database storage completion event (status changes to "Stored") monitored in step 4.1. Subscribe to this event through an event bus (such as Kafka or RabbitMQ) to ensure data consistency and processing order.

[0102] Parse and extract the following fields from the event message body:

[0103] File ID (FileID), such as FILE_20250615_001.

[0104] Target order processing database ID (DBID), such as db_order_01.

[0105] Table ID for the day (TableID), such as order_20250615.

[0106] Check field integrity (not empty, format compliance). If not met, log an exception and terminate processing.

[0107] In step 5.2, based on the extracted database table identifiers, construct an aggregate query SQL grouped by merchant, ensure that the merchant_id and file_id fields have a composite index to accelerate group aggregation, execute cross-database queries through distributed database middleware (such as ShardingSphere), and configure a reasonable timeout (such as 30 seconds).

[0108] Step 5.3, traverse the query results, for each record:

[0109] Extract merchant_id (merchant ID) and total_payable (aggregated total payable).

[0110] Checks whether total_payable is a valid value (non-negative, non-NaN). If invalid, sets it to 0 and logs an exception.

[0111] Memory map construction:

[0112] Initialize a data structure (such as a key-value map), store the total amount payable by merchant ID, store the mapping table in a temporary result table (such as merchant_settlement_temp), associate the task ID and processing time, and send a "merchant amount calculation completed" event through a message queue (such as Kafka) with the file identifier to trigger the subsequent account posting process.

[0113] In a preferred embodiment of the present invention, the above step 6 may include:

[0114] Step 6.1: The order clearing service group monitors the pending account amount ready event and the merchant amount ready event in the distributed database. When both events are detected for the same task record, the dual account clearing operation is performed.

[0115] Step 6.2: Extract the temporarily stored total amount from the distributed cache, access the platform account database, and perform a single summary payment operation on the pending account;

[0116] Step 6.3: Extract the temporarily stored merchant amount mapping table from the distributed cache, and determine the target merchant account database ID using the consistent hashing algorithm based on the merchant IDs in the mapping table;

[0117] Step 6.4: Group and aggregate the deposit amounts of each merchant by target merchant account database; and send batch deposit instructions to each target merchant account database;

[0118] In step 6.5, when all account operations are successful, the status of the pending task table is updated to completed, and the temporary data in the distributed cache is deleted.

[0119] In an embodiment of the present invention, by monitoring the pending account amount ready event and the merchant amount ready event of the distributed database, it is ensured that the dual account clearing operation is performed only when both key data are complete, thereby avoiding the risk of data inconsistency; the temporary data is extracted from the distributed cache and the pending account single summary is executed to reduce the frequency of database operations and improve the efficiency of account settlement; the target merchant account library is determined based on the consistent hashing algorithm to achieve load balancing of account operations; the account settlement instructions are sent in batches according to the library group, and the traditional transaction-by-transaction operations are converted into batch processing, which greatly improves the merchant account settlement efficiency; the task status is updated and the cache is cleared after all operations are successful to ensure the final consistency of the data and efficient use of resources, thereby achieving efficient and safe clearing of funds between the platform and merchant accounts and reducing account operation delays and system resource consumption.

[0120] In an embodiment of the present invention, the specific steps include:

[0121] Step 6.1, dual event monitoring configuration:

[0122] Deploy the event monitoring module in the order clearing service group and subscribe to the following events of the distributed database:

[0123] The pending amount ready event is triggered after step 4 is completed, and carries the task ID, file ID, and total amount to be paid.

[0124] The merchant amount ready event is triggered after step 5 is completed, and carries the task ID, file identifier, and merchant amount mapping table.

[0125] Event association and triggering conditions:

[0126] Maintain an in-memory event association table (e.g., a mapping based on task ID). When two events with the same task ID arrive:

[0127] Verify the consistency of the file identifiers in the event and check the event timestamp to ensure that the merchant amount event is later than the pending account amount event (to avoid data staleness). If the conditions are met, trigger the dual account clearing process; otherwise, temporarily store the event and wait for timeout processing (for example, 30 minutes).

[0128] Step 6.2, cache data extraction:

[0129] Get the total amount of the transaction from the distributed cache (such as Redis) with the task ID as the key, and verify the validity of the amount (for example, it is greater than 0 and the accuracy meets the requirements).

[0130] Account operation execution, constructing an account request:

[0131] Account ID, platform hanging account (such as PLATFORM_HANGING_ACCOUNT).

[0132] Amount, the total amount of the payment extracted from the cache.

[0133] Transaction type, whether it is a hanging account or a debit account (such as TYPE_HANGING_DEBIT).

[0134] Execute a single summary payment through the account service interface and obtain the operation result (success / failure).

[0135] Step 6.3, mapping table extraction and parsing:

[0136] Get the merchant amount mapping table with the task ID as the key from the distributed cache.

[0137] Consistent hash routing:

[0138] Take the merchant ID (such as MER001) as input and calculate the hash value using the consistent hashing algorithm.

[0139] Map the hash value to the corresponding merchant account database (such as merchant_db_01, merchant_db_02) to ensure that the same merchant is always routed to the same database.

[0140] Step 6.4, batch payment instruction processing:

[0141] Traverse the merchant amount mapping table, group and aggregate the amount by target account library, generate an intermediate structure, and for each target account library:

[0142] Construct a batch posting request (e.g., including 1,000 merchants / batch), send the posting instruction through the account service interface, obtain the batch operation results, and record the processing status of each database (a list of successful / failed merchants).

[0143] Step 6.5, check the results of the pending account debit and all merchant account credit operations:

[0144] If all are successful, proceed to the next step. If some fail, the compensation mechanism will be triggered (such as performing reverse operations on merchants that have already received accounts).

[0145] Task status updates are performed in distributed transactions:

[0146] Update the pending task table status to "Completed", record the completion time and operation results, clean up the cache, and delete all temporary data related to the task in the distributed cache (such as the total amount of the account and the merchant amount mapping table).

[0147] like Figure 2 As shown, an embodiment of the present invention further provides an order clearing system based on direct delivery, comprising:

[0148] The acquisition module is used to obtain pending order files in the shared storage, assign a unique order clearing service group to each file based on the real-time load status of each order clearing service group and the number of orders in the pending file, generate a task record containing the file identifier, the assigned service group identifier, and the initial status, and write the task record to the pending task table; based on the task record in the pending task table, trigger the corresponding order clearing service group and update the status of the task record to processing;

[0149] The calculation module is used for the triggered order clearing service group to obtain task records with a status of "in-process" from the pending task table, route the order file data to the designated order processing library's daily shard table for storage based on the file dimension through a hash algorithm, and, based on the storage result, create an order number index record in an independent index library. This record contains the order number, the corresponding order processing library identifier, and the shard table identifier; based on the stored order file data, the total amount that needs to be debited from the platform's pending accounts is calculated in the file dimension; based on the stored order file data, the amount that needs to be credited to each merchant's pending settlement account is calculated in the file dimension;

[0150] The processing module is used to access the platform account library, perform the summary account release operation of the pending accounts based on the calculated total account release amount, route to the designated merchant account library according to the merchant account hash value, and perform the summary account release operation of the merchant's pending settlement accounts based on the calculated account release amount of each merchant.

[0151] The above is a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as within the scope of protection of the present invention.

Claims

1. A method for clearing orders based on direct delivery, characterized in that: The method comprises: Step 1: Obtain pending order files from shared storage. Based on the real-time load status of each order clearing service group and the number of orders in the pending file, assign a unique order clearing service group to each file. Generate a task record containing the file identifier, assigned service group identifier, and initial status, and write the task record to the pending task table. Step 2: trigger the corresponding order clearing service group according to the task record in the pending task table, and update the status of the task record to "in process"; Step 3: The triggered order clearing service group obtains task records with the status of "in progress" from the pending task table, routes the order file data to the designated order processing library's daily shard table for storage based on the file dimension using a hash algorithm, and creates an order number index record in an independent index library based on the storage result. This record contains the order number, the corresponding order processing library ID, and the shard table ID. Step 4: Based on the stored order file data, calculate the total amount that needs to be debited from the platform's pending accounts using the file dimension; Step 5: Based on the stored order file data, calculate the amount to be credited to each merchant's pending settlement account in the file dimension; Step 6: Access the platform account library, perform the summary debit operation on the pending accounts based on the calculated total debit amount, route to the designated merchant account library according to the merchant account hash value, and perform the summary debit operation on the merchant accounts to be settled based on the calculated debit amount of each merchant.

2. A direct order clearing method according to claim 1, characterized in that: Obtain pending order files from shared storage, assign a unique order clearing service group to each file based on the real-time load status of each order clearing service group and the number of orders for the pending file, generate a task record containing the file identifier, assigned service group identifier, and initial status, and write the task record to the pending task table, including: Step 1.1: Scan the shared storage area to identify newly added order files to be processed, and obtain the unique file identifier and total number of orders for each file; Step 1.2: Calculate the load weight of each service group based on the real-time collected operating status indicators of each order clearing service group; Step 1.3: Based on the total number of orders for the pending files and the load weights of each service group, a weighted round-robin algorithm is used to assign each file to the order clearing service group with the most balanced load, generating a task record containing the file identifier, the assigned service group identifier, and an initial status of "pending"; Step 1.4: Write the generated task records into the pending task table of the distributed database.

3. A direct order clearing method according to claim 2, characterized in that: According to the task record in the pending task table, the corresponding order clearing service group is triggered, and the status of the task record is updated to being processed, including: Step 2.1, obtaining a pending task table write completion event of the distributed database, and when a new task record is detected to be written, extracting the assigned service group identifier and initial status of the record; Step 2.2: Verify that the initial status of the task record is pending, and confirm the current health status of the corresponding order clearing service group; In step 2.3, based on the current health status, an atomic operation is performed through a distributed transaction to update the status of the task record from pending to processing.

4. A direct order clearing method according to claim 3, characterized in that: The triggered order clearing service group obtains task records with the status of "in-process" from the pending task table, routes the order file data to the designated order processing library's daily shard table for storage based on the file dimension using a hash algorithm, and creates an order number index record in an independent index library based on the storage result. This record contains the order number, the corresponding order processing library identifier, and the shard table identifier, including: Step 3.1: The order clearing service group extracts the processing instruction event from the local pending task queue, parses it to obtain the file identifier and task record ID, and then obtains the task record with the status of "in progress" from the pending task table in the distributed database based on the task record ID. Step 3.2: Based on the file identifier in the task record, access the shared storage area to read the original data of the corresponding order file and verify the file integrity; Step 3.3: Generate a sub-table identifier for the current day based on the preset date hash rule, determine the target order processing database identifier using a consistent hashing algorithm based on the file identifier, and write the order file data into the sub-table for the current day of the target order processing database in batches according to the file dimension; In step 3.4, after the order data is successfully stored, based on the transaction ID returned by the storage operation, the order number index record is synchronously written to the independent index library. Each record contains the order number, the target order processing library identifier, the day's table identifier, and the file identifier.

5. A direct order clearing method according to claim 4, characterized in that: Based on the stored order file data, the total amount that needs to be debited from the platform's pending accounts is calculated in file dimensions, including: Step 4.1: The order clearing service group monitors the storage completion event of the distributed database. When it detects that the task record status is stored, it extracts the file ID, target order processing database ID, and daily table ID of the record; Step 4.2: Based on the target order processing database ID and the current day's table ID, construct a cross-database query statement to batch retrieve all order records corresponding to the file ID from the specified table; In step 4.3, parse the Amount Receivable field in the order record, aggregate the Amount Receivable of all orders in the file using the file dimension, and generate the total amount that needs to be debited to the platform's pending account.

6. A direct order clearing method according to claim 5, characterized in that: Based on the stored order file data, the amount to be posted to each merchant's pending settlement account is calculated using the file dimension, including: Step 5.1: The order clearing service group reuses the storage completion event monitored in step 4.1 and synchronously extracts the file identifier, target order processing library identifier, and daily table identifier from the task record. Step 5.2: Based on the target order processing database ID and the daily table ID, a cross-database aggregation query statement is constructed to batch retrieve order records corresponding to the file ID from the designated table, grouped by merchant ID. Step 5.3: Parse the merchant ID field and the payable amount field in the order record, group and aggregate the payable amounts of all orders in the file by merchant ID, and generate a mapping table of the amounts to be posted to each merchant's pending settlement account.

7. A direct order clearing method according to claim 6, characterized in that: Access the platform account database, perform the summary debit operation on the pending accounts based on the calculated total debit amount, route to the designated merchant account database based on the merchant account hash value, and perform the summary debit operation on the merchant pending settlement accounts based on the calculated debit amount of each merchant, including: Step 6.1: The order clearing service group monitors the pending account amount ready event and the merchant amount ready event in the distributed database. When both events are detected for the same task record, the dual account clearing operation is performed. Step 6.2: Extract the temporarily stored total amount from the distributed cache, access the platform account database, and perform a single summary payment operation on the pending account; Step 6.3: Extract the temporarily stored merchant amount mapping table from the distributed cache, and determine the target merchant account database ID using the consistent hashing algorithm based on the merchant IDs in the mapping table; Step 6.4: Group and aggregate the deposit amounts of each merchant by target merchant account database; and send batch deposit instructions to each target merchant account database; In step 6.5, when all account operations are successful, the status of the pending task table is updated to completed, and the temporary data in the distributed cache is deleted.

8. A direct-through order clearing system, which implements the method according to any one of claims 1 to 7, characterized in that: include: The acquisition module is used to obtain pending order files in the shared storage, assign a unique order clearing service group to each file based on the real-time load status of each order clearing service group and the number of orders for the pending files, generate a task record containing the file identifier, the assigned service group identifier, and the initial status, and write the task record into the pending task table; According to the task record in the pending task table, the corresponding order clearing service group is triggered, and the status of the task record is updated to being processed; The calculation module is used by the triggered order clearing service group to obtain task records with a status of "in-process" from the pending task table, route the order file data to the designated order processing library's daily shard table for storage based on the file dimension using a hash algorithm, and create an order number index record in an independent index library based on the storage result. This record contains the order number, the corresponding order processing library identifier, and the shard table identifier; Based on the stored order file data, the total amount that needs to be debited from the platform's pending accounts is calculated in file dimensions; Based on the stored order file data, calculate the amount that needs to be posted to each merchant's pending settlement account using the file dimension; The processing module is used to access the platform account library, perform the summary account release operation of the pending accounts based on the calculated total account release amount, route to the designated merchant account library according to the merchant account hash value, and perform the summary account release operation of the merchant's pending settlement accounts based on the calculated account release amount of each merchant.

9. A computing device, characterized in that include: one or more processors; A storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a program, which, when executed by a processor, implements the method according to any one of claims 1 to 7.

Images