Cloud-based purchase and sale collaborative settlement system

Abstract

The present application relates to the technical field of financial settlement, in particular to a purchase and sale collaborative settlement system based on cloud, which comprises a task chain initialization module, a sequence dynamic rearrangement module, a task execution feedback module and a scheduling strategy correction module.In the present application, when a settlement task is created, a data node containing initial priority identification and resource estimation is generated and linked into an ordered task chain, and before execution, a scheduling adjustment driving value is formed by calculating the execution time difference and resource request quantity difference between nodes, according to which an optimized task execution sequence is dynamically rearranged from the task chain, the task execution engine executes according to the sequence and accurately monitors and records the actual consumption time and resource occupation data to form a task execution feedback table, the system traverses the feedback table to calculate the execution time deviation, and when the deviation exceeds the threshold, a self-correction mechanism is started to automatically update the initial priority identification and resource quota of subsequent tasks, thereby realizing dynamic optimization of settlement processing and efficient use of resources.

Description

Technical Field

[0001] This invention relates to the field of financial settlement technology, and in particular to a cloud-based collaborative settlement system for purchasing and selling. Background Technology

[0002] The field of financial settlement technology is an interdisciplinary application of computer information processing and business data management. Its core functions include transaction data matching, fund allocation, account clearing, and settlement voucher generation. This technology utilizes computer networks, database technology, and encrypted communication to process payment instructions and order information, manage fund transfers between different economic entities, and is applied to interbank clearing, securities transaction settlement, and enterprise supply chain financial services. Traditional collaborative settlement systems refer to data processing systems used in commodity purchase and sale activities to verify purchase orders, warehouse receipts, sales invoices, and payment information. The technical challenge they address is resolving reconciliation difficulties and settlement delays caused by inconsistencies or missing document information between suppliers and buyers. These systems are typically deployed on individual enterprise servers, using structured query language to extract order tables, invoice tables, and payment record tables from their respective independent databases. Financial personnel then manually export the data and use spreadsheet software's VLOOKUP function or sorting comparison function to match and mark discrepancies row by row. Settlement information relies on reconciliation files sent via email or file transfer protocols.

[0003] Existing collaborative settlement systems for purchasing and sales heavily rely on manual operations by finance personnel. Data must be exported from an independent database and then matched line by line using spreadsheet software. This processing mode results in low reconciliation efficiency and is prone to errors. When faced with peak settlement periods at the end of the month or a large number of complex orders being processed at once, the system lacks an effective task scheduling and resource allocation mechanism. All settlement tasks must be queued for manual processing, and the execution priority cannot be dynamically adjusted. Reconciliation information relies on email or file transmission, resulting in delayed feedback and the inability to form a closed-loop optimization. This severely restricts the speed and accuracy of fund settlement and can easily lead to difficulties in the company's cash flow. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies by proposing a cloud-based collaborative settlement system for purchasing and selling.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a cloud-based collaborative settlement system for purchasing and selling, comprising:

[0006] The task chain initialization module obtains the settlement task creation data node, retrieves parameters to generate an initial priority identifier value, an estimated execution time value, and a resource request quantity value, stores them in the settlement task creation data node, sets initial weights, and links them into an ordered task chain.

[0007] The sequence dynamic reordering module starts a loop processing flow based on the ordered task chain, selects the preceding node and the following node, calculates the scheduling adjustment driving value of the execution time difference and the resource request amount difference, determines whether the scheduling adjustment driving value is greater than the initial weight, and if it is greater, swaps and updates the initial weight, and generates a task execution sequence in a loop.

[0008] The task execution feedback module schedules the task execution engine to execute settlement tasks according to the task execution sequence, monitors and records unique identifiers, actual execution time values, peak resource usage, average resource usage, completion status parameters, resource recovery time values, and resource quota values, and compiles them into a task execution feedback table.

[0009] The scheduling strategy correction module iterates through the task execution feedback table, obtains the actual execution time value and the unique identifier, finds the estimated execution time value, calculates the execution time deviation and deviation ratio, compares the absolute value of the deviation ratio with the adjustment threshold value, and if it is greater, reads the self-correction coefficient value, multiplies them, and updates the initial priority identifier value and resource quota value based on the product result.

[0010] As a further aspect of the present invention, the ordered task chain includes node link pointers and node data structures, the task execution sequence includes the final node execution order and sequence stability identifier, the task execution feedback table specifically refers to task performance logs and resource consumption records, and the resource quota value specifically refers to the adjusted resource allocation upper limit.

[0011] As a further aspect of the present invention, the specific function of the task chain initialization module is as follows:

[0012] The node data acquisition submodule acquires the data node created by the settlement task and retrieves the historical settlement parameters, system load parameters and business rule parameters corresponding to the data node created by the settlement task.

[0013] The node parameter calculation submodule calculates and generates the initial priority identifier value, the estimated execution time value, and the resource request quantity value based on the historical settlement parameters, the system load parameters, and the business rule parameters.

[0014] The task chain linking submodule stores the initial priority identifier value, the estimated execution time value, and the resource request amount value into the settlement task creation data node, sets the initial weight, and links multiple settlement task creation data nodes to generate the ordered task chain.

[0015] As a further aspect of the present invention, the specific function of the sequence dynamic rearrangement module is as follows:

[0016] The node selection submodule starts the loop processing flow based on the ordered task chain, and selects the preceding node and the following node sequentially from the ordered task chain;

[0017] The driving value calculation submodule obtains the estimated execution time value and the resource request amount value of the preceding node and the following node, calculates the difference between the execution time and the difference between the resource request amount, and performs a weighted summation of the difference between the execution time and the difference between the resource request amount to obtain the scheduling adjustment driving value.

[0018] The sequence update submodule compares the scheduling adjustment driving value with the initial weight. If the scheduling adjustment driving value is greater than the initial weight, the positions of the preceding node and the following node in the ordered task chain are swapped, and the initial weight is updated to the scheduling adjustment driving value.

[0019] The sequence output submodule executes in a loop until the loop processing flow ends, outputs the final node execution order, and sets the sequence stability flag, together generating the task execution sequence.

[0020] As a further aspect of the present invention, the specific function of the task execution feedback module is as follows:

[0021] The task execution submodule schedules the task execution engine to execute the settlement task according to the order of the task execution sequence;

[0022] The process monitoring submodule monitors and records in real time the unique identifier of the settlement task, the actual execution time consumed, the peak resource consumption, and the average resource consumption during the execution of the settlement task.

[0023] The result recording submodule records the corresponding completion status parameters and resource recovery time values ​​after the settlement task is completed.

[0024] The log assembly submodule performs structured assembly of the monitored and recorded unique identifier, actual execution time, peak resource usage, average resource usage, completion status parameters, and resource recovery time to generate the task execution feedback table.

[0025] As a further aspect of the present invention, the specific function of the scheduling strategy correction module is as follows:

[0026] The data extraction submodule iterates through the task execution feedback table to obtain the actual execution time value and the unique identifier;

[0027] The deviation calculation submodule finds the corresponding estimated execution time value based on the unique identifier, calculates the execution time deviation between the actual execution time value and the estimated execution time value, and calculates the deviation ratio of the execution time deviation to the estimated execution time value.

[0028] The correction judgment submodule obtains the preset adjustment threshold value and compares the absolute value of the deviation ratio with the adjustment threshold value.

[0029] The parameter correction submodule reads the self-correction coefficient value associated with the unique identifier if the absolute value of the deviation ratio is greater than the adjustment threshold value, multiplies the self-correction coefficient value by the execution time deviation to obtain the correction amount, and updates the initial priority identifier value and the resource quota value based on the correction amount.

[0030] As a further aspect of the present invention, the node parameter calculation submodule is specifically implemented as follows when calculating the initial priority identifier value:

[0031] Obtain the average task execution time from the historical settlement parameters, the current CPU utilization and memory usage from the system load parameters, and the business urgency level from the business rule parameters;

[0032] A basic priority weight is set based on the aforementioned business urgency level;

[0033] Calculate the resource sensitivity factor by combining the average execution time of the task, the current CPU utilization, and the memory usage.

[0034] The initial priority identifier value is generated by weighting and summing the basic priority weight and the resource sensitivity factor.

[0035] As a further aspect of the present invention, the driving value calculation submodule, when calculating the scheduling adjustment driving value, is specifically implemented as follows:

[0036] Obtain the estimated execution time value of the preceding node. The resource request amount of the preceding node Obtain the estimated execution time value of the subsequent node. The resource request amount of the rear node ;

[0037] Calculate the execution time difference ;

[0038] Calculate the difference in resource request volume. ;

[0039] Calculate the time deviation rate separately Resource Deviation Rate ;

[0040] Retrieve time influence factor Resource Influence Factors ;

[0041] Through formula The scheduling adjustment driving value is calculated. ;

[0042] in, This represents the scheduling adjustment driving value. The estimated execution time value represents the preceding node. The numerical value representing the resource request amount of the aforementioned preceding node. The estimated execution time value represents the value of the subsequent node. The value representing the amount of resources requested by the downstream node. This represents the execution time difference. This represents the difference in the amount of resources requested. This represents the time deviation rate. This represents the resource deviation rate. The time-related factor represents the preset time influence factor. This represents the preset resource impact factor.

[0043] As a further aspect of the present invention, the parameter correction submodule, when updating the resource quota value, is specifically implemented as follows:

[0044] Obtain the deviation ratio The self-correction coefficient value and current resource quota values ;

[0045] Through formula The updated resource quota values ​​are calculated. ;

[0046] in, This represents the updated resource quota value. This represents the current resource quota value recorded in the data node where the settlement task is created. This represents the self-correction coefficient value. This represents the deviation ratio.

[0047] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0048] In this invention, data nodes containing initial priority identifiers and resource estimates are generated when a settlement task is created and linked into an ordered task chain. Before execution, the execution time difference and resource request difference between the nodes are calculated to form a scheduling adjustment driving value. Based on this, the task chain is dynamically rearranged to generate an optimized task execution sequence. The task execution engine executes the sequence and accurately monitors and records the actual time consumed and resource usage data to form a task execution feedback table. The system traverses the feedback table to calculate the execution time deviation. When the deviation exceeds the threshold, a self-correction mechanism is activated to automatically update the initial priority identifiers and resource quotas of subsequent tasks, thereby achieving dynamic optimization of settlement processing and efficient resource utilization. Attached Figure Description

[0049] Figure 1 This is a flowchart illustrating the overall system architecture of the present invention;

[0050] Figure 2 This is a flowchart of the task chain initialization process of the present invention;

[0051] Figure 3 This is a flowchart of the dynamic sequence rearrangement process of the present invention;

[0052] Figure 4 This is a flowchart illustrating the task execution and feedback process of this invention.

[0053] Figure 5 This is a flowchart illustrating the dynamic correction process of the scheduling strategy in this invention. Detailed Implementation

[0054] To make the objectives, technical solutions, and advantages of this invention clearer, the software-based technical solution is described in detail below with reference to system architecture diagrams and embodiments. It should be understood that the specific embodiments described herein are only for explaining the technical solutions of this invention and do not constitute a limitation on the scope of protection.

[0055] In the description of this invention, the system architecture relationships or data processing flows indicated by terms such as "layer," "module," "interface," "data flow," "client," and "server" are all defined based on the architecture diagram or flowchart corresponding to the embodiments. This way of describing is only used to clearly illustrate the logical relationships between the elements in the technical solution, and not to limit the physical deployment form. The term "multiple" includes two or more technical units, including but not limited to multiple data nodes, processing threads, service instances, or functional components and other scalable elements. The specific number is determined according to the actual business scenario and needs to be specifically specified.

[0056] Please see Figure 1 and Figure 2 This invention provides a technical solution: a cloud-based collaborative settlement system for purchasing and selling, comprising:

[0057] The task chain initialization module obtains the settlement task creation data node, retrieves parameters to generate an initial priority identifier value, an estimated execution time value, and a resource request quantity value, stores them in the settlement task creation data node, sets initial weights, and links them into an ordered task chain.

[0058] An ordered task chain includes node link pointers and node data structures;

[0059] The specific functional implementation of the task chain initialization module is as follows:

[0060] The node data acquisition submodule acquires the data node created by the settlement task and retrieves the historical settlement parameters, system load parameters, and business rule parameters corresponding to the data node created by the settlement task.

[0061] The node parameter calculation submodule calculates and generates the initial priority identifier value, the estimated execution time value, and the resource request amount value based on historical settlement parameters, system load parameters, and business rule parameters.

[0062] The node parameter calculation submodule is implemented as follows when calculating the initial priority identifier value:

[0063] Obtain the average task execution time from historical settlement parameters, the current CPU utilization and memory usage from system load parameters, and the business urgency level from business rule parameters;

[0064] Set basic priority weights based on the urgency level of the business;

[0065] Calculate the resource sensitivity factor by combining the average task execution time, current CPU utilization, and memory usage.

[0066] The initial priority label value is generated by weighting and summing the basic priority weight and the resource sensitivity factor.

[0067] The task chain linking submodule stores the initial priority identifier value, the estimated execution time value, and the resource request amount value into the settlement task creation data node, sets the initial weight, and links multiple settlement task creation data nodes to generate an ordered task chain.

[0068] In the specific implementation of the task chain initialization module, the node data acquisition submodule is executed first. This submodule accesses the task queue of the cloud-based collaborative settlement system and monitors the generation of settlement task creation data nodes with the number "Z20251027-001" (hereinafter referred to as Node A) and "Z20251027-002" (hereinafter referred to as Node B). For Node A, the node data acquisition submodule retrieves its corresponding historical settlement parameters, system load parameters, and business rule parameters. The historical settlement parameters are extracted from the historical database, revealing that the average execution time for similar tasks of Node A (e.g., "monthly settlement for large suppliers") is 150 seconds, and the historical average resource consumption is 8 standard computing cores. The system load parameters are obtained from the system monitoring interface, showing that the current CPU utilization is 75% and the current memory utilization is 65%. The business rule parameters are retrieved from the business rule library, revealing that the business urgency level of Node A is "Level Two". Similarly, for node B (e.g., "daily settlement for small retailers"), its average task execution time is 100 seconds, its historical average resource consumption is 2 standard computing cores, its system load parameters are 75% CPU and 65% memory, and its business urgency level is "Level 1".

[0069] Next, the node parameter calculation submodule is executed. Based on the data obtained from node A, its initial priority identifier value is calculated. This calculation first requires setting the basic priority weight. The basic priority weight is set according to the business urgency level, which is divided into three levels: Level 1 (high), Level 2 (medium), and Level 3 (low). The setting of the basic priority weight is based on a regression analysis of the business impact and completion time of 10,000 historical settlement tasks. The specific settings are as follows: Level 1 corresponding weight Level 2 corresponds to weight Level 3 corresponds to weight The experimental verification process for this setting value was as follows: 500 historical tasks with different urgency levels were selected, and the settings were applied to each task. for , , Three weighting sets were used for priority ranking and scheduling simulation. Under this combination, the average waiting time for high-urgency tasks was 55 seconds, and the starvation rate for low-urgency tasks was 1.8%. This set of data performed optimally within the preset performance indicators (e.g., waiting time less than 60 seconds and starvation rate less than 2%). Node A's business urgency level is "Level Two", therefore its basic priority weight is set to 0.6. Node B's business urgency level is "Level One", therefore its basic priority weight is set to 0.9.

[0070] Subsequently, the resource sensitivity factor is calculated by combining the average task execution time (150 seconds for node A), current CPU utilization (75%), and memory usage (65%). Resource Sensitivity Factor The calculation process is as follows: First, the average load rate is obtained by averaging the CPU utilization and memory usage. Then, set a baseline execution time. Seconds (obtained by calculating the median execution time of all task types). Calculate task duration deviation. Duration deviation of node A Duration deviation of node B Resource sensitivity factor Based on this, the resource sensitivity factor of node A... Resource sensitivity factor of node B .

[0071] Finally, the basic priority weights and resource sensitivity factors are weighted and summed to generate the initial priority label value. The weighting factors used in the weighted summation (Basic priority) and (Resource sensitivity) set to , The standard for setting these weighting factors is: ensuring the urgency of business operations while also considering the stability of system load. The verification experiment process involves constructing a simulation queue containing 1000 mixed tasks and testing under different system loads (50%, 70%, 90%). The scheduling results ranged from 0.5 to 0.9. The system throughput at 70% load was 360 tasks / hour, and the response latency for high-priority tasks was 122 seconds. This data set represents the best performance within the preset performance parameters (e.g., throughput greater than 350 tasks / hour, latency less than 130 seconds).

[0072] Initial priority flag value for node A:

[0073] ;

[0074] Initial priority flag value for node B:

[0075] ;

[0076] in, and These represent the level weights corresponding to nodes A and B, respectively.

[0077] The node parameter calculation submodule also needs to calculate the estimated execution time and resource request volume. Estimated execution time Calculated using historical average execution time and current load rate: Estimated execution time for node A Seconds. Estimated execution time for node B. Seconds. Resource request count. Based on historical average resource consumption settings: Resource request volume of node A One core. The resource request volume of node B. One core.

[0078] Finally, the task chain linking submodule is executed. The initial priority value of node A (0.945), the estimated execution time (255 seconds), and the resource request quantity (8 cores) are stored in node A's data structure. The initial priority value of node B (0.98007), the estimated execution time (170 seconds), and the resource request quantity (2 cores) are stored in node B's data structure. Simultaneously, an initial weight is set. This initial weight is used for subsequent sequence rearrangement comparisons. The value is set to 0.05. The benchmark for this value is the minimum fluctuation below the expected scheduling adjustment driver value. This threshold is used to determine whether the scheduling adjustment driver value is significant. The verification process involves analyzing 5000 historical scheduling adjustment driver values ​​(…). The distribution of values. The 5th percentile of the value is 0.052, so 0.05 is chosen as the initial threshold. Since the initial priority identifier value of node B (0.98007) is greater than that of node A (0.945), node B comes first and node A comes last in the initial sorting. The task chain linking submodule links node B and node A through node link pointers to generate an ordered task chain: [node B -> node A].

[0079] Please see Figure 1 and Figure 3 The sequence dynamic reordering module starts a loop processing flow based on an ordered task chain, selects the predecessor and successor nodes, calculates the difference between execution time and the difference between resource request amount to obtain the scheduling adjustment driving value, and determines whether the scheduling adjustment driving value is greater than the initial weight. If it is greater, the task execution sequence is swapped and updated, and the task execution sequence is generated in a loop.

[0080] The task execution sequence includes the final node execution order and a sequence stability indicator;

[0081] The specific functionality of the sequence dynamic rearrangement module is as follows:

[0082] The node selection submodule starts a loop processing flow based on an ordered task chain, selecting the previous and next nodes sequentially from the ordered task chain;

[0083] The driving value calculation submodule obtains the estimated execution time and resource request amount values ​​of the preceding and following nodes, calculates the difference between execution time and resource request amount, and performs a weighted summation of the difference between execution time and resource request amount to obtain the scheduling adjustment driving value.

[0084] The specific implementation of the driving value calculation submodule when calculating the scheduling adjustment driving value is as follows:

[0085] Get the estimated execution time of the predecessor node. The value of resource requests from the preceding node Get the estimated execution time of the subsequent node. The value of resource requests from subsequent nodes ;

[0086] Calculate the execution time difference ;

[0087] Computational resource request difference ;

[0088] Calculate the time deviation rate separately Resource Deviation Rate ;

[0089] Retrieve time influence factor Resource Influence Factors ;

[0090] Through formula Calculate the scheduling adjustment driving value ;

[0091] in, This represents the scheduling adjustment of the driving value. This represents the estimated execution time of the preceding node. This represents the amount of resources requested by the preceding node. This represents the estimated execution time of the subsequent node. This represents the amount of resources requested by the subsequent nodes. Represents the difference in execution time. This represents the difference in the number of resource requests. This represents the time deviation rate. Represents the resource deviation rate. This represents the preset time-related factor. Represents the preset resource impact factor;

[0092] The sequence update submodule compares the scheduling adjustment driving value with the initial weight. If the scheduling adjustment driving value is greater than the initial weight, it swaps the positions of the predecessor and successor nodes in the ordered task chain and updates the initial weight to the scheduling adjustment driving value.

[0093] The sequence output submodule executes in a loop until the loop processing flow ends, outputs the final node execution order, and sets the sequence stability flag, together generating the task execution sequence.

[0094] In the specific implementation of the sequence dynamic rearrangement module, the node selection submodule is executed first. This submodule starts a loop processing flow based on the ordered task chain [node B->node A] generated by the task chain initialization module. In the first loop, the preceding node (node ​​B) and the following node (node ​​A) are selected sequentially from the ordered task chain.

[0095] Next, the driver value calculation submodule is executed. This submodule obtains the estimated execution time value of the preceding node (Node B). and resource request quantity And obtain the estimated execution time value of the subsequent node (node ​​A). and resource request quantity Based on the aforementioned calculations, obtain Second, Core. Acquisition Second, Core. The driver value calculation submodule calculates the execution time difference. Seconds. Difference in computational resource requests. Core. Then, the time deviation rate is calculated separately. Calculate the resource deviation rate. (Note: Here) and The calculation is based on the preceding node. and As the denominator, it is used to measure the relative change of the subsequent node relative to the preceding node. Then, the preset time influence factor is retrieved. Resource Influence Factors . Set to 0.6. The value was set to 0.4. The reference standard for setting these two influencing factors is: in scheduling decisions, execution time has a slightly higher priority than resource consumption. The verification experiment involved running a scheduling simulation using a standardized workload dataset containing 5000 tasks. The value changed from 0.1 to 0.9 ( ), with a step size of 0.1.

[0096] Table 1: and Summary table of factor validation experiment data:

[0097] ;

[0098] As shown in Table 1, the experimental data indicate that when , At that time, the system's average task throughput was 360 tasks / hour, and the waiting time for 95% of tasks was 122 seconds. This data set showed optimal performance within the preset performance indicators (such as throughput greater than 350 tasks / hour and waiting time less than 130 seconds). Finally, through the formula... Calculate the scheduling adjustment driving value .Will , , , Substitute into the formula:

[0099] ;

[0100] The formula here middle, This represents the driving value for scheduling adjustments; This represents the estimated execution time of the preceding node. This represents the amount of resources requested by the preceding node. This represents the estimated execution time of the subsequent node. The numerical value representing the amount of resources requested by the subsequent nodes; represent and The difference, represent and The difference; represent and The ratio, represent and The ratio; Represents the time-related factor. This represents the resource impact factor. The calculation logic of this formula lies in: calculating the "relative difference" between the preceding and following nodes in terms of time and resources (in terms of...). and (embodied), and combined with and The weighted sum of the two factors yields a comprehensive "exchange driving force". .like A positive value indicates that the preceding node consumes significantly more time and / or resources than the following node (relatively speaking), suggesting potential value in the exchange; a negative value indicates that the following node consumes more resources.

[0101] Next, the sequence update submodule is executed. The scheduling drive value is compared and adjusted. (-1.5) and the initial weights set by the task chain initialization module (0.05). Judgment process: Whether this holds true, let's compare the actual results: This is not true. Since the scheduling adjustment driving value -1.5 is not greater than the initial weight of 0.05, the sequence update submodule does not perform node swapping operations, and the initial weight remains unchanged at 0.05.

[0102] Finally, the sequence output submodule is executed. Since there are only two nodes in the task chain [node B -> node A], the loop processing ends after the first comparison (B and A). The sequence output submodule outputs the final node execution order as [node B, node A]. Simultaneously, a sequence stability flag is set. The rule for setting the sequence stability flag is: if no node swap occurs during the complete loop processing, the flag is 1 (stable); if at least one swap occurs, the flag is 0 (dynamically adjusted). In this embodiment, since no swap occurred, the sequence stability flag is set to 1. The final generated task execution sequence is ([node B, node A], 1).

[0103] To illustrate the exchange scenario, assume there is a node C, whose Second, Core. If the initial sequence is [node B(170s,2c)->node C(160s,1.5c)]. . . . . . If the condition is met, then swap node B and node C, updating the sequence to [node C -> node B]. Update the initial weights to... The value is 0.13528.

[0104] Please see Figure 1 and Figure 4 The task execution feedback module schedules the task execution engine to execute settlement tasks according to the task execution sequence, monitors and records unique identifiers, actual execution time, peak resource usage, average resource usage, completion status parameters, and resource recovery time, and compiles them into a task execution feedback table.

[0105] The task execution feedback form specifically refers to the task performance log and resource consumption record;

[0106] The specific functions of the task execution feedback module are as follows:

[0107] The task execution submodule schedules the task execution engine to execute settlement tasks according to the task execution sequence.

[0108] The process monitoring submodule monitors and records the unique identifier of the settlement task, the actual execution time consumed, the peak resource consumption, and the average resource consumption in real time during the execution of the settlement task.

[0109] The results recording submodule records the corresponding completion status parameters and resource recycling time values ​​after the settlement task is completed.

[0110] The log assembly submodule compiles the unique identifiers, actual execution time, peak resource usage, average resource usage, completion status parameters, and resource recovery time values ​​of the monitoring records into a structured format to generate a task execution feedback table.

[0111] In the specific implementation of the task execution feedback module, the task execution submodule is executed first. This submodule retrieves the task execution sequence ([node B, node A], 1) generated by the sequence dynamic rearrangement module and schedules the task execution engine to execute the settlement task according to the final node execution order [node B, node A]. Node B (unique identifier "Z20251027-002") is executed first, and after node B is completed, node A (unique identifier "Z20251027-001") is executed.

[0112] During the execution of the settlement task, an execution process monitoring submodule monitors and records various performance parameters of the settlement task in real time. For the execution process of node B (Z20251027-002): its start time was monitored as 10:30:00 on October 27, 2025, and its end time was monitored as 10:31:55 on October 27, 2025. The actual execution time consumed was calculated to be 115 seconds. During this period, its peak resource usage was monitored at 3.5 standard computing cores, and its average resource usage was 2.2 standard computing cores. For the execution process of node A (Z20251027-001): its start time was monitored as 10:31:55 on October 27, 2025, and its end time was monitored as 10:34:25 on October 27, 2025. The actual execution time consumed was calculated to be 150 seconds. During this period, the peak resource usage was monitored at 8.2 standard computing cores, and the average resource usage was 7.9 standard computing cores.

[0113] After the settlement task is completed, the execution result recording submodule records the following: For node B (Z20251027-002): its completion status parameter is recorded as 0 (indicating successful execution), and the resource reclamation time value is 2025-10-27 10:31:58 (i.e., 3 seconds after the task ended). For node A (Z20251027-001): its completion status parameter is recorded as 0 (indicating successful execution), and the resource reclamation time value is 2025-10-27 10:34:28 (i.e., 3 seconds after the task ended).

[0114] Finally, the execution log assembly submodule is executed. This submodule assembles the monitored and recorded data into a structured format to generate a task execution feedback table (i.e., task performance logs and resource consumption records).

[0115] Table 2: Task Execution Feedback Form

[0116] ;

[0117] As shown in Table 2, this table compiles the actual execution data of two settlement tasks with IDs Z20251027-002 and Z20251027-001, forming a structured task execution feedback table.

[0118] Please see Figure 1 and Figure 5 The scheduling strategy correction module iterates through the task execution feedback table, obtains the actual execution time value and unique identifier, finds the estimated execution time value, calculates the execution time deviation and deviation ratio, compares the absolute value of the deviation ratio with the adjustment threshold value, and if it is greater, reads the self-correction coefficient value, multiplies them, and updates the initial priority identifier value and resource quota value based on the product result.

[0119] The resource quota value is specifically the adjusted upper limit for resource allocation;

[0120] The specific functions of the scheduling strategy correction module are as follows:

[0121] The data extraction submodule iterates through the task execution feedback table to obtain the actual execution time and unique identifier.

[0122] The deviation calculation submodule finds the corresponding estimated execution time value based on the unique identifier, calculates the execution time deviation between the actual execution time value and the estimated execution time value, and calculates the deviation ratio of the execution time deviation to the estimated execution time value.

[0123] The correction judgment submodule obtains the preset adjustment threshold value and compares the absolute value of the deviation ratio with the adjustment threshold value.

[0124] The parameter correction submodule reads the self-correction coefficient value associated with the unique identifier if the absolute value of the deviation ratio is greater than the adjustment threshold value. It then multiplies the self-correction coefficient value by the execution time deviation to obtain the correction amount and updates the initial priority identifier value and resource quota value based on the correction amount.

[0125] When updating resource quota values, the parameter correction submodule is implemented as follows:

[0126] Obtain the deviation ratio Self-correction coefficient value and current resource quota values ;

[0127] Through formula The updated resource quota values ​​are calculated. ;

[0128] in, This represents the updated resource quota value. This represents the current resource quota value recorded in the data node created by the settlement task. Represents the self-correction coefficient value. This represents the deviation ratio.

[0129] In the specific implementation of the scheduling strategy correction module, the data extraction submodule is executed first. This submodule iterates through the task execution feedback table generated by the task execution feedback module (as shown in Table 2). The first row of data extraction: the actual execution time consumed is 115 seconds, with a unique identifier of "Z20251027-002". The second row of data extraction: the actual execution time consumed is 150 seconds, with a unique identifier of "Z20251027-001".

[0130] Next, the deviation calculation submodule is executed. For the identifier "Z20251027-002" (node ​​B): based on this unique identifier, the corresponding estimated execution time value is searched from the data nodes of the task chain initialization module. The value is found... Second;

[0131] Calculate execution time deviation Seconds. Calculate the deviation ratio. For the identifier "Z20251027-001" (Node A): Based on this unique identifier, find the corresponding estimated execution time value. Found. Seconds. Calculate the execution time deviation. Seconds. Calculate the deviation ratio. .

[0132] Next, the correction judgment submodule is executed. A preset adjustment threshold value is obtained, which is set to 0.1 (i.e., 10%). The reference standard for setting this adjustment threshold value is: this threshold is used to define whether the execution time deviation is within the range that needs correction. The verification experiment process is as follows: the deviation ratio of 10,000 historical tasks (…) Statistical analysis was performed, and the standard deviation of its distribution was 0.045. Two standard deviations (approximately 0.09) were selected and rounded up to 0.1 as the threshold for triggering adjustments. Experimental data (omitted here) show that using 0.1 as the threshold allows 8% of tasks with an absolute deviation ratio greater than 0.1 to be identified, while 92% of tasks with an absolute deviation ratio less than 0.1 are not triggered for correction. This setting meets the expected correction strategy. For identifier "Z20251027-002": compare the absolute value of the deviation ratio. (i.e., 0.3235) and adjust the threshold value to 0.1. Judgment process: Established. Regarding the identifier "Z20251027-001": compare the absolute value of the deviation ratio. (i.e., 0.4118) and adjust the threshold value to 0.1. Judgment process: Established.

[0133] Next, the parameter correction submodule is executed. Since the absolute value of the deviation ratio of "Z20251027-002" is greater than the adjustment threshold, the self-correction coefficient value associated with this unique identifier is read. . Set to 0.2. Self-calibration coefficient value. The reference standard for setting it is: the damping coefficient of the feedback loop, used to smooth the magnitude of the correction. The verification experiment process is as follows: an ARMA (Autoregressive Moving Average) model of the task execution time is established, and a feedback correction term is introduced. .right Simulation tests were conducted from 0.05 to 0.5. Experimental data show that when At this point, the estimated time is adjusted to be close to the actual time within 3-5 periods, and this convergence speed is in line with expectations. Calculate the correction amount. The initial priority flag value is updated based on the correction amount: this process is not a direct addition or subtraction, but rather an update to the historical parameters used to calculate the priority flag (average task execution time). The new average task execution time is then used. Second, This refers to the average execution time of a new task. This refers to the average execution time of older tasks. This is a correction period. These 89 seconds will be used for priority calculations for subsequent tasks of this type. Simultaneously, resource quota values ​​will be updated. The deviation ratio will be obtained. Self-correction coefficient value and current resource quota values (i.e., node B) (Core). Through the formula Calculate the updated resource quota values . The core. The formula here. middle, This represents the updated resource quota value (the adjusted resource allocation limit). Represents the current resource quota value. Represents the self-correction coefficient value. This represents the deviation ratio. The calculation logic of this formula is as follows: [Based on the current resource quota...] Based on the deviation ratio (Representing the accuracy of the prediction) and self-correction coefficient (The magnitude of the adjustment) is used to calculate an adjustment factor. .if If the value is negative (as in this example, the actual execution time is much shorter than the estimated time, indicating that the actual execution time is shorter than the estimated time), then the adjustment factor is less than 1, and the new quota... Will be lower The reduced resource quota value was calculated.

[0134] For "Z20251027-001": its absolute deviation ratio of 0.4118 is also greater than the threshold of 0.1. Read its self-correction coefficient value. Calculate the correction amount. Update its historical average task execution time. Seconds. Update resource quota values: Get , , core. core. The calculated result of 7.34112 cores indicates that node A's resource quota has been reduced from 8 cores to 7.34112 cores. This updated value ( core, The core parameters will be stored in the historical parameter library of the corresponding task type for parameter calculation when creating new tasks in the future.

[0135] The above embodiments illustrate preferred embodiments of the present invention. Any equivalent adjustments to the technical solution based on software engineering methods are within the scope of protection, including but not limited to: implementing algorithm logic using different programming languages, refactoring functional modules into services, adjusting data interaction protocols, and optimizing resource scheduling strategies. Any implementation scheme derived from reasonable modifications to the data processing flow, service call chain, or system architecture layer without departing from the core technology of the present invention should be considered within the scope of protection defined by the claims of the present invention.

Claims

1. A cloud-based purchase and sale coordination settlement system, characterized by, The system includes: The task chain initialization module obtains the settlement task creation data node, retrieves parameters to generate initial priority identifier value, estimated execution time value and resource request amount value, stores them in the settlement task creation data node, sets initial weights, and links them into an ordered task chain. The sequence dynamic reordering module starts a loop processing flow based on the ordered task chain, selects the preceding node and the following node, calculates the difference between execution time and the difference between resource request amount to obtain the scheduling adjustment driving value, determines whether the scheduling adjustment driving value is greater than the initial weight, if the scheduling adjustment driving value is greater than the initial weight, swaps the positions of the preceding node and the following node in the ordered task chain, updates the initial weight to the scheduling adjustment driving value, and generates a task execution sequence in a loop; The task execution feedback module schedules the task execution engine to execute settlement tasks according to the task execution sequence, monitors and records unique identifiers, actual execution time values, peak resource usage, average resource usage, completion status parameters, resource recovery time values, and resource quota values, and compiles them into a task execution feedback table. The scheduling strategy correction module traverses the task execution feedback table, obtains the actual execution time value and the unique identifier, finds the estimated execution time value, calculates the execution time deviation and deviation ratio, compares the absolute value of the deviation ratio with the adjustment threshold value, and if it is greater than the adjustment threshold value, reads the self-correction coefficient value, multiplies the self-correction coefficient value with the execution time deviation, and updates the initial priority identifier value and the resource quota value based on the product result. The resource quota value is specifically the adjusted upper limit of resource allocation, and the initial priority identifier value specifically refers to the initial priority order identifier of the task execution. The specific function of the sequence dynamic rearrangement module is as follows: The node selection submodule starts the loop processing flow based on the ordered task chain, and selects the previous node and the next node sequentially from the ordered task chain; The driving value calculation submodule obtains the estimated execution time value and the resource request amount value of the preceding node and the following node, calculates the difference between the execution time and the difference between the resource request amount, and performs a weighted summation of the difference between the execution time and the difference between the resource request amount to obtain the scheduling adjustment driving value. The sequence update submodule compares the scheduling adjustment driving value with the initial weight. If the scheduling adjustment driving value is greater than the initial weight, the positions of the preceding node and the following node in the ordered task chain are swapped, and the initial weight is updated to the scheduling adjustment driving value. The sequence output submodule executes in a loop until the loop processing flow ends, outputs the final node execution order, and sets the sequence stability flag, together generating the task execution sequence; The specific implementation of the drive value calculation submodule in calculating the scheduling adjustment drive value is as follows: obtaining the front node estimated execution time value of the front node obtaining the front node resource request amount value of the front node obtaining the back node estimated execution time value of the back node obtaining the back node resource request amount value of the back node ; calculating the execution time difference ; calculating the resource request amount difference ; Respective calculation of time deviation rate With resource deviation rate ; Call time influence factor With resource influence factor ; The scheduling adjustment driving value is calculated by the formula ;​ wherein, a scheduling adjustment driving value, a predicted execution time value of the predecessor node, a predicted resource request value of the predecessor node, a predicted execution time value of the successor node, a predicted resource request value of the successor node, a execution time difference value, a resource request difference value, a time deviation rate, a resource deviation rate, a preset time influence factor, a preset resource influence factor. 2.The cloud-based purchase and sale collaborative settlement system according to claim 1, wherein, The ordered task chain includes node link pointers and node data structures; the task execution sequence includes the final node execution order and sequence stability identifier; and the task execution feedback table specifically refers to task performance logs and resource consumption records.

3. The cloud-based collaborative settlement system for purchasing and selling according to claim 2, characterized in that, The specific function of the task chain initialization module is as follows: The node data acquisition submodule acquires the data node created by the settlement task and retrieves the historical settlement parameters, system load parameters and business rule parameters corresponding to the data node created by the settlement task. The node parameter calculation submodule calculates and generates the initial priority identifier value, the estimated execution time value, and the resource request quantity value based on the historical settlement parameters, the system load parameters, and the business rule parameters. The task chain linking submodule stores the initial priority identifier value, the estimated execution time value, and the resource request amount value into the settlement task creation data node, sets the initial weight, and links multiple settlement task creation data nodes to generate the ordered task chain.

4. The cloud-based collaborative settlement system for purchasing and selling according to claim 3, characterized in that, The specific functions of the task execution feedback module are as follows: The task execution submodule schedules the task execution engine to execute the settlement task according to the order of the task execution sequence; The process monitoring submodule monitors and records in real time the unique identifier of the settlement task, the actual execution time consumed, the peak resource consumption, and the average resource consumption during the execution of the settlement task. The result recording submodule records the corresponding completion status parameters and resource recovery time values ​​after the settlement task is completed. The log assembly submodule performs structured assembly of the monitored and recorded unique identifier, actual execution time, peak resource usage, average resource usage, completion status parameters, and resource recovery time to generate the task execution feedback table.

5. The cloud-based collaborative settlement system for purchasing and selling according to claim 4, characterized in that, The specific function of the scheduling strategy correction module is as follows: The data extraction submodule iterates through the task execution feedback table to obtain the actual execution time value and the unique identifier; The deviation calculation submodule finds the corresponding estimated execution time value based on the unique identifier, calculates the execution time deviation between the actual execution time value and the estimated execution time value, and calculates the deviation ratio of the execution time deviation to the estimated execution time value. The correction judgment submodule obtains the preset adjustment threshold value and compares the absolute value of the deviation ratio with the adjustment threshold value. The parameter correction submodule reads the self-correction coefficient value associated with the unique identifier if the absolute value of the deviation ratio is greater than the adjustment threshold value, multiplies the self-correction coefficient value by the execution time deviation to obtain the correction amount, and updates the initial priority identifier value and the resource quota value based on the correction amount.

6. The cloud-based collaborative settlement system for purchasing and selling according to claim 3, characterized in that, The node parameter calculation submodule calculates the initial priority identifier value as follows: Obtain the average task execution time from the historical settlement parameters, the current CPU utilization and memory usage from the system load parameters, and the business urgency level from the business rule parameters; A basic priority weight is set based on the aforementioned business urgency level; Calculate the resource sensitivity factor by combining the average execution time of the task, the current CPU utilization, and the memory usage. The initial priority identifier value is generated by weighting and summing the basic priority weight and the resource sensitivity factor.

7. The cloud-based collaborative settlement system for purchasing and selling according to claim 6, characterized in that, When updating the resource quota value, the parameter correction submodule is implemented as follows: Obtain the deviation ratio The self-correction coefficient value and current resource quota values ; Through formula The updated resource quota values ​​were calculated. ; in, This represents the updated resource quota value. This represents the current resource quota value recorded in the data node where the settlement task is created. This represents the self-correction coefficient value. This represents the deviation ratio.

Images