Resource state change system

Abstract

The application discloses a resource state change system, which comprises an upstream business module and a downstream resource change module; the downstream resource change module analyzes a resource change request, generates a business processing identifier and a change target of each change resource line identifier, drives a corresponding change resource line to perform state change, and generates first feedback information; the upstream business module judges whether state rollback is needed according to the first feedback information; the downstream resource change module restores the state of a corresponding rollback resource line based on a rollback target value of each rollback resource line identifier; and the upstream business module records the business processing identifier, each retry resource line identifier and the corresponding business change difference in a retry table, so that the downstream resource change module performs resource state change when the service is in an idle state. It can be seen that the application can reasonably stagger the business processing pressure, improve the resource change success rate and business processing continuity, and significantly optimize the operation stability and processing performance of the business system.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more specifically, to a resource status change system. Background Technology

[0002] In business systems, a single business operation typically requires the coordinated efforts of multiple resource management systems. Taking order processing as an example, it generally requires first invoking resource services such as inventory, account balance, and quotas to complete resource allocation or deduction operations, and then sequentially executing subsequent business processes such as payment, message notification, and logistics scheduling. If subsequent business processes fail, to ensure business data consistency and avoid interfering with other normal business operations, the completed resource operations need to be rolled back.

[0003] Current rollback solutions mostly perform global rollback at the granularity of a single business request number. However, in actual business processing, there are often cases where some resource details are successfully operated or do not require rollback. Global rollback is prone to generating redundant operations, resulting in too many invalid rollbacks, which in turn reduces the efficiency of resource change processing in the business system. Summary of the Invention

[0004] In view of this, this application provides a resource status change system to address the shortcomings of low efficiency in resource change processing in existing resource service technologies.

[0005] To achieve the above objectives, the following solution is proposed:

[0006] A resource status change system includes an upstream business module and a downstream resource change module;

[0007] The upstream business module sends a resource change request containing resource change details to the downstream resource change module.

[0008] The downstream resource change module analyzes the resource change request, generates a unique corresponding business processing identifier, and determines all change resource line identifiers and the change target of each change resource line identifier. Based on the change target of each change resource line identifier, it drives the corresponding change resource line to perform a status change, records the value before and after the change of the change resource line, and generates first feedback information containing the business processing identifier to characterize whether each change resource line has been successfully changed.

[0009] The upstream business module determines whether a state rollback is required based on the first feedback information, and when a state rollback is required, generates and sends a resource rollback request containing a rollback resource line identifier and a business processing identifier to the downstream resource change module.

[0010] When the downstream resource change module receives the resource rollback request, it determines the rollback target value of the corresponding rollback resource line identifier based on each rollback resource line identifier and the previous values ​​corresponding to the business processing identifier; and restores the state of the corresponding rollback resource line based on the rollback target value of each rollback resource line identifier.

[0011] The upstream business module uses the rollback resource line identifiers corresponding to the successful rollbacks of the business processing identifiers as the retry resource line identifiers. Based on the resource change details, it determines the business change difference for each retry resource line identifier and records the business processing identifier, each retry resource line identifier, and its corresponding business change difference in the retry table so that the downstream resource change module can perform resource status changes when the service is idle.

[0012] Optionally, the upstream business module includes a first request generation unit;

[0013] The first request generation unit receives and analyzes business processing requirements, determines all change resource lines that match the business processing requirements and the change difference of each change resource line, and generates and sends a resource change request containing resource change details to the downstream resource change module.

[0014] Optionally, the upstream business module further includes a second request generation unit;

[0015] The second request generation unit analyzes the first feedback information and uses the identifier of the changed resource line that has not been successfully changed as the rollback resource line identifier; it combines the business processing identifier and all its corresponding rollback resource line identifiers to generate a resource rollback request.

[0016] Optionally, the downstream resource change module includes a flow record unit;

[0017] The logging unit determines the change timestamp corresponding to the execution status change of each changed resource line, and writes the change timestamp, the value before the change, and the value after the change corresponding to the changed resource line into the logging table.

[0018] Optionally, the downstream resource change module further includes a status restoration unit;

[0019] Upon receiving the resource rollback request, the state restoration unit analyzes the log record table to determine whether there is a resource row concurrency conflict between the resource rollback request and other resource change requests. If not, it selects the pre-change value that matches the rollback resource row identifier from the pre-change values ​​corresponding to the business processing identifier as the rollback target value of the corresponding rollback resource row identifier.

[0020] Optionally, the state restoration unit includes a rollback target value determination subunit;

[0021] If a resource row concurrency conflict exists, the rollback target value determination subunit filters the target pre-change value and target post-change value that match the rollback resource row identifier corresponding to the concurrency conflict from the pre-change value and post-change value corresponding to the business processing identifier, calculates the target change difference between the target pre-change value and target post-change value matched by the rollback resource row identifier, and calculates the rollback target value of the rollback resource row identifier based on the transaction record table and the target change difference of the rollback resource row identifier.

[0022] Optionally, the upstream service module includes a retry unit;

[0023] When the downstream resource change module is in a service idle state, the retry unit combines the business processing identifier in the retry table and all its corresponding retry resource row identifiers, as well as the business change difference corresponding to each retry resource row identifier, to generate a change retry request, and sends it to the downstream resource change module so that the downstream resource change module can change the resource row status.

[0024] Optionally, the downstream resource change module includes a status retry unit;

[0025] Upon receiving the change retry request, the status retry unit sequentially drives the corresponding retry resource line to perform a status change based on the business change difference corresponding to each retry resource line identifier. It also records the pre-retry value and post-retry value of the retry resource line and generates a second feedback information containing the business processing identifier to indicate whether each retry resource line has been successfully changed. This allows the upstream business module to delete the successfully changed retry resource line identifiers and business change differences from the retry table and execute business processing after all retry resource lines corresponding to the business processing identifier have been successfully changed.

[0026] Optionally, the upstream business module may further include a periodic identification unit;

[0027] The periodic identification unit periodically monitors the service status of the downstream resource change module and identifies whether the downstream resource change module is in an idle state; if so, it calls the retry unit.

[0028] Optionally, the downstream resource change module includes a change execution unit;

[0029] The change execution unit determines the business scenario type based on the resource change request, sorts each change resource line identifier according to the business scenario type, and obtains a sorting result; according to the sorting result, it drives the corresponding change resource line execution status change in turn according to the change target of each change resource line identifier.

[0030] As can be seen from the above technical solution, this application provides a resource status change system. This system can include a upstream business module and a downstream resource change module. When the downstream resource change module receives a resource change request from the upstream business module, it performs a status change using a single resource behavior as the smallest processing unit. Simultaneously, it records the pre-change and post-change values ​​of each resource line and generates a unique business processing identifier. This allows the first feedback information to characterize whether each changed resource line has been successfully changed, facilitating the upstream business module's accurate location of the resource lines requiring rollback after determining that a rollback is necessary. During rollback, the downstream resource change module can accurately restore the resource lines to be rolled back based on the pre-change value corresponding to the unique business processing identifier, achieving atomic-level restoration and rollback of resource details. This makes the resource change and rollback process traceable and verifiable, effectively ensuring data consistency and business reliability of the business system. After receiving change feedback, the upstream business module can decide whether to continue the business process or initiate a rollback without waiting for a long time for the final status of all resource lines. Successfully rolled-back resource rows are automatically marked as retry rows, and the business change difference is calculated and stored in a retry table. Downstream processes asynchronously compensate for this difference during idle periods, thus avoiding blocking the upstream main process, significantly improving system throughput and user experience, and ensuring business continuity. The retry table in this application stores the business change difference for each retry row, rather than the complete original change details. This approach reduces data transmission and processing overhead during retries, and the difference is calculated based on the resource change details, improving retry success rate and flexibility. Therefore, this application constitutes a closed-loop process for change, feedback, on-demand rollback, difference recording, and idle retries, avoiding business interruptions due to momentary business anomalies, reasonably mitigating peak business processing pressure, improving the overall system resource change success rate and business continuity, and significantly optimizing the operational stability and processing performance of the business system. Attached Figure Description

[0031] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0032] Figure 1 This is a system architecture diagram of a resource status change system disclosed in an embodiment of this application;

[0033] Figure 2 This is an optional signaling flow for a resource status change system disclosed in an embodiment of this application. Detailed Implementation

[0034] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0035] Figure 1 This is a system architecture diagram of a resource status change system disclosed in an embodiment of this application, such as... Figure 1 As shown, the resource status change system of this application may include an upstream business module 10 and a downstream resource change module 20.

[0036] The upstream business module 10 can determine the resource lines that need to be changed based on business needs and feedback information, and notify the downstream resource change module 20 by issuing a request.

[0037] The downstream resource change module 20 is responsible for coordinating various resource management systems, executing resource status change operations, and recording the entire change process in a traceable manner.

[0038] The upstream business module 10 can perform business processing after confirming that the downstream resource change module 20 has successfully changed the status of each resource row.

[0039] The upstream business module 10 and the downstream resource change module 20 can be devices such as mobile phones, computers, and servers.

[0040] The upstream business module 10 and the downstream resource change module 20 can be deployed in the same device or in different devices. Therefore, the upstream business module 10 and the downstream resource change module 20 can interact with each other through inter-process communication, network or data bus.

[0041] Next, combine Figure 2 The processing procedure of the resource status change system in this application is described in detail, including the following steps:

[0042] Step S1: The upstream business module 10 sends a resource change request containing resource change details to the downstream resource change module.

[0043] Specifically, the upstream business module 10 can receive a business processing request, determine the resource change details based on the business processing request, and generate a resource change request containing the resource change details.

[0044] The resource change details may include the identifier of the resource line that needs to be changed and the change difference.

[0045] The resource row modification function can be used to modify various resource details that are broken down into "rows".

[0046] For example, different SKUs in the inventory system correspond to different inventory detail lines, different users' balances in the account system correspond to different balance detail lines, and different tenants' quota usage in the calculation resource quota corresponds to different calculation resource quota detail lines. Any independent resource detail unit that needs to be modified in a single business process can be used as a change resource line in this application.

[0047] A single business process may require modification of one or more change resource lines.

[0048] Step S2: Downstream resource change module 20 analyzes the resource change request, generates a unique corresponding business processing identifier, and determines all change resource line identifiers and the change target of each change resource line identifier; based on the change target of each change resource line identifier, it drives the corresponding change resource line to perform a status change, records the value before and after the change of the change resource line, and generates first feedback information containing the business processing identifier to characterize whether each change resource line has been successfully changed.

[0049] Specifically, the downstream resource change module 20 can generate a unique business processing identifier for the resource change request based on the collection timestamp combined with a random number.

[0050] To ensure the uniqueness of the business processing identifier, a table containing the correspondence between historical business processing identifiers and historical resource change requests can be consulted to check if there is an identifier with a similarity exceeding a preset similarity threshold. If not, the business processing identifier can be directly determined as the unique identifier corresponding to the resource change request. If it is, the business processing identifier is regenerated, and the uniqueness check is repeated until a unique and non-duplicate business processing identifier is obtained.

[0051] The downstream resource change module 20 can analyze the resource change details in the resource change request to determine the identifier of each changed resource line, and use the change difference corresponding to each changed resource line identifier as the change target.

[0052] After determining the change target corresponding to each changed resource line identifier, the downstream resource change module 20 can sort each changed resource line according to the preset business sorting rules, and drive each changed resource line to complete the status change based on the change target in sequence. During the process of performing the change on each changed resource line, the value of each changed resource line before the change is recorded as the value before the change, and the value after the change is recorded as the value after the change. It can compare whether the difference between the value before the change and the change difference of each changed resource line is equal to the corresponding change target. If so, it is determined that the change of the corresponding changed resource line is successful; if not, it is determined that the change of the corresponding changed resource line is unsuccessful. The change results of each changed resource line involved in the same resource change request are summarized, and the summarized results are combined with the business processing identifier of the resource change request to form the first feedback information.

[0053] In this case, the various changed resource lines involved in the same resource change request can be recorded in different resource management systems. Therefore, the downstream resource change module 20 can coordinate the various resource management systems according to the order of the various changed resource lines to complete the resource status change.

[0054] In the same resource change request, the values ​​before and after the change of each changed resource line correspond to the values ​​before and after the change operation, respectively. Due to abnormal situations such as service overload, distributed transaction conflicts, temporary resource locking, network timeout, and service unavailability, the change operation may be invalid or interrupted. Therefore, the actual value after the change may be inconsistent with the expected change target, or even the actual value after the change may be the same as before the change. Therefore, by comparing the values ​​before and after the change, the actual change result of each resource line can be accurately identified, and the result will not be misjudged due to abnormal service return information.

[0055] The downstream resource change module 20 can upload the first feedback information to the upstream business module 10.

[0056] Step S3: The upstream business module 10 determines whether a state rollback is needed based on the first feedback information.

[0057] Specifically, the upstream business module 10 can analyze whether all changed resource lines in the first feedback information have been successfully changed. If so, it is determined that no status rollback is required, and the upstream business module 10 can perform business processing. If not, it is determined that a status rollback is required, and step S4 can be executed.

[0058] Step S4: If yes, the upstream business module 10 generates and issues a resource rollback request containing a rollback resource line identifier and a business processing identifier.

[0059] Specifically, when it is determined that a state rollback is required, the upstream business module 10 can identify all the change resource lines that failed to change in the first feedback information as rollback resource lines that need to be rolled back, extract the identifier of each rollback resource line and the business processing identifier of the first feedback information to generate a resource rollback request, and send the resource rollback request to the downstream resource change module 20; if the subsequent overall business process fails, all the change resource lines that have been successfully changed can also be identified as rollback resource lines and a unified rollback can be initiated.

[0060] Step S5: Downstream resource change module 20 determines the rollback target value of the corresponding rollback resource line identifier based on each rollback resource line identifier and the previous values ​​corresponding to the business processing identifier; and restores the state of the corresponding rollback resource line based on the rollback target value of each rollback resource line identifier.

[0061] Specifically, the downstream resource change module 20 can use the value before the change of the corresponding rollback resource line as the rollback target value when there is no corresponding concurrent conflict in each rollback resource line. If there is a corresponding concurrent conflict, the rollback target value of the corresponding rollback resource line can be determined according to the log record table, the value before the change and the value after the change.

[0062] After determining the rollback target value, the value of each rollback resource line can be rolled back to the rollback target value to complete the state restoration.

[0063] The downstream resource change module 20 can restore the status of rollback resource lines that have failed to roll back until the preset number of restorations is reached. If there are still rollback resource lines that have failed to roll back, a reminder message containing the identifier of the rollback resource lines that have failed to roll back will be generated so that maintenance personnel can handle it.

[0064] Downstream resource change module 20 can be rolled back line by line, as shown in the following code:

[0065] {"changeStreamId": "RSC_20260612_001_PRE_OCCUPY",

[0066] "resourceKeys": [

[0067] "WAREHOUSE_A_ITEM_001"

[0068] ], / / Only roll back this line, do not roll back WAREHOUSE_B_ITEM_001

[0069] "rollbackReason": "PAYMENT_TIMEOUT"};

[0070] Step S6: The upstream business module 10 uses the rollback resource line identifiers corresponding to the successful rollback of the business processing identifier as the retry resource line identifiers. Based on the resource change details, it determines the business change difference of each retry resource line identifier and records the business processing identifier, each retry resource line identifier and its corresponding business change difference in the retry table so that the downstream resource change module 20 can perform resource status changes when the service is idle.

[0071] Specifically, after the state rollback is completed, the upstream business module 10 can identify each successfully rolled-back resource line as a retry resource line and identify each successfully rolled-back resource line as a retry resource line identifier.

[0072] The upstream business module 10 can determine the change difference corresponding to each retry resource line identifier as the business change difference based on the resource change details, and write the business processing identifier, business change difference and corresponding retry resource line identifier into the retry table so that when the downstream resource change module 20 is in a service idle state, it can issue a change retry request. After all the retry resource lines corresponding to the business processing identifier have been successfully changed, the upstream business module 10 deletes the relevant data of the business processing identifier in the retry table and executes the business operation corresponding to the business processing identifier.

[0073] As can be seen from the above technical solution, this application provides a resource status change system. This system can include a upstream business module and a downstream resource change module. When the downstream resource change module receives a resource change request from the upstream business module, it performs a status change using a single resource behavior as the smallest processing unit. Simultaneously, it records the pre-change and post-change values ​​of each resource line and generates a unique business processing identifier. This allows the first feedback information to characterize whether each changed resource line has been successfully changed, facilitating the upstream business module's accurate location of the resource lines requiring rollback after determining that a rollback is necessary. During rollback, the downstream resource change module can accurately restore the resource lines to be rolled back based on the pre-change value corresponding to the unique business processing identifier, achieving atomic-level restoration and rollback of resource details. This makes the resource change and rollback process traceable and verifiable, effectively ensuring data consistency and business reliability of the business system. After receiving change feedback, the upstream business module can decide whether to continue the business process or initiate a rollback without waiting for a long time for the final status of all resource lines. Successfully rolled-back resource rows are automatically marked as retry rows, and the business change difference is calculated and stored in a retry table. Downstream processes asynchronously compensate for this difference during idle periods, thus avoiding blocking the upstream main process, significantly improving system throughput and user experience, and ensuring business continuity. The retry table in this application stores the business change difference for each retry row, rather than the complete original change details. This approach reduces data transmission and processing overhead during retries, and the difference is calculated based on the resource change details, improving retry success rate and flexibility. Therefore, this application constitutes a closed-loop process for change, feedback, on-demand rollback, difference recording, and idle retries, avoiding business interruptions due to momentary business anomalies, reasonably mitigating peak business processing pressure, improving the overall system resource change success rate and business continuity, and significantly optimizing the operational stability and processing performance of the business system.

[0074] In some embodiments of this application, the upstream business module 10 may include a first request generation unit.

[0075] The first request generation unit receives and analyzes the business processing requirements, determines all change resource lines that match the business processing requirements and the change difference of each change resource line, and generates and sends a resource change request containing resource change details to the downstream resource change module 20.

[0076] Specifically, business processing requirements can include information such as business scenario type and business parameters used to characterize the specific requirements of business processing.

[0077] The first request generation unit can determine all the changed resource lines that need to be changed in status from the resource catalog according to the preset resource line matching rules and the business scenario type. Then, based on the business parameters, it calculates the corresponding change difference for each changed resource line, organizes the identifier of each changed resource line and the corresponding change difference into resource change details, and then generates a resource change request.

[0078] Business scenario types can include order payment, inventory transfer, credit limit adjustment, and other business scenarios.

[0079] Business parameters can include payment amount, quantity of goods, and credit limit adjustment value.

[0080] Based on the business parameters in the business processing requirements, the first request generation unit can determine the change difference corresponding to each changed resource line. Then, it integrates all changed resource line identifiers and corresponding change differences into resource change details, encapsulates them to generate a complete resource change request for distribution.

[0081] The first request generation unit can also perform preliminary format verification on the resource change details. After confirming that the changed resource line identifier is compliant and the change difference format is correct, the completed resource change request is sent to the downstream resource change module 20. This reduces the probability of abnormal handling from the source of request generation and improves the overall process efficiency.

[0082] As can be seen from the above technical solution, this embodiment provides an optional composition of the upstream business module 10. Through this method, the first request generation unit can ensure the accuracy and completeness of the resource change request content, avoiding omissions or incorrect entries of change information that could lead to subsequent processing anomalies.

[0083] In some embodiments of this application, the upstream business module 10 may further include a second request generation unit;

[0084] The second request generation unit analyzes the first feedback information and uses the identifier of the changed resource line that has not been successfully changed as the rollback resource line identifier; it combines the business processing identifier and all its corresponding rollback resource line identifiers to generate a resource rollback request.

[0085] Specifically, the second request generation unit can filter out all failed change resource lines based on the change results of each changed resource line in the first feedback information, extract their identifiers as rollback resource line identifiers; at the same time, it reads the business processing identifier carried in the first feedback information, integrates and encapsulates the business processing identifier with all rollback resource line identifiers, generates a resource rollback request according to a preset communication protocol format, and then sends the generated resource rollback request to the downstream resource change module 20 to ensure that the rollback request can accurately carry all the core information required for rollback, and avoid errors in the rollback process due to missing information.

[0086] If the overall business process fails and a unified rollback of all changed resource lines is required, the second request generation unit can also extract the identifiers of all successfully changed resource lines from the first feedback information as rollback resource line identifiers, and uniformly integrate and generate resource rollback requests to adapt to rollback requirements in different scenarios.

[0087] As can be seen from the above technical solution, this embodiment provides another optional composition method for the upstream business module 10. In this way, the upstream business module 10 can use the first feedback information through the second request generation unit to accurately filter the resource lines that need to be rolled back, flexibly adapt to various rollback scenarios such as partial failure rollback and overall failure full rollback, ensure the integrity and accuracy of the rollback request information, provide reliable support for subsequent accurate rollback, and further improve the fault tolerance and adaptability of the rollback process.

[0088] In some embodiments of this application, the downstream resource change module 20 may include a flow record unit.

[0089] The logging unit determines the change timestamp corresponding to the execution status change of each changed resource line, and writes the change timestamp, the value before the change, and the value after the change corresponding to the changed resource line into the logging table.

[0090] Specifically, after each changed resource line completes its status change, the transaction record unit can generate a corresponding change timestamp based on the completion time, and store the changed resource line identifier, business processing identifier, change timestamp, value before change, and value after change into the transaction record table.

[0091] The transaction log table can be indexed according to the business processing identifier, which facilitates quick querying of the values ​​and execution status of the corresponding changed resource lines before and after the change when rolling back or retrying. This provides a complete and verifiable basis for full-process traceability, and also makes it easier to sort out the processing sequence of each changed resource line when troubleshooting problems, avoiding the inability to locate the cause of the anomaly due to missing information.

[0092] As can be seen from the above technical solution, this embodiment provides an optional composition of the downstream resource change module 20. The entire process change information of each changed resource line is centrally stored through the flow record unit. This can provide accurate pre-change value basis for rollback operations, and also realize full process traceability, which facilitates subsequent anomaly investigation and business auditing, and further improves the maintainability and reliability of the entire resource status change system.

[0093] In some embodiments of this application, the downstream resource change module 20 may further include a state restoration unit.

[0094] Upon receiving the resource rollback request, the state restoration unit can analyze the log record table to determine whether there is a resource row concurrency conflict between the resource rollback request and other resource change requests. If not, it can select the previous value that matches the rollback resource row identifier from the previous values ​​corresponding to the business processing identifier as the rollback target value of the corresponding rollback resource row identifier.

[0095] Specifically, concurrent conflict refers to a situation where the same rollback resource row is modified by multiple different resource rollback requests and / or resource change requests within the same time period, resulting in the resource row state being modified by multiple operations simultaneously.

[0096] The state restoration unit can first extract all rollback resource line identifiers in the resource rollback request, traverse the most recent processing record of the corresponding resource line in the pipeline record table, and verify whether the business processing identifier corresponding to the record is consistent with the business processing identifier of the current rollback request. If they are consistent, it means that there is no concurrent conflict and no other request is modifying the rollback resource line at the same time; if they are inconsistent, it means that the rollback resource line has been modified by other requests and there is a concurrent conflict.

[0097] In the absence of concurrent conflicts, the state restoration unit can directly retrieve the corresponding pre-change value as the rollback target value, ensuring the accuracy of the rollback target value and avoiding erroneous rollback that overwrites other change results.

[0098] As can be seen from the above technical solution, this embodiment provides an optional composition of the downstream resource change module 20. Through this method, it is possible to detect in advance whether there are concurrent conflicts during the rollback process, and to directly and quickly locate the accurate rollback target value when there are no conflicts. This ensures the accuracy of the rollback operation, avoids errors from overwriting other change results, and improves the processing efficiency of rollback in conflict-free scenarios, further optimizing the reliability and execution speed of the rollback process.

[0099] Based on this, considering the possibility of concurrent conflicts, in order to avoid excessive rollback, the state restoration unit of this application may include a rollback target value determination subunit;

[0100] If a resource row concurrency conflict exists, the rollback target value determination subunit filters the target pre-change value and target post-change value that match the rollback resource row identifier corresponding to the concurrency conflict from the pre-change value and post-change value corresponding to the business processing identifier, calculates the target change difference between the target pre-change value and target post-change value matched by the rollback resource row identifier, and calculates the rollback target value of the rollback resource row identifier based on the transaction record table and the target change difference of the rollback resource row identifier.

[0101] Specifically, the rollback target value determination subunit can determine the identifier of the rollback resource line with concurrent conflicts, and take the pre-change value that matches the identifier among the various pre-change values ​​corresponding to the business processing identifier as the target pre-change value of the identifier, and take the post-change value that matches the identifier among the various post-change values ​​corresponding to the business processing identifier as the target post-change value of the identifier; it can calculate the difference between the target pre-change value and the target post-change value corresponding to the same rollback resource line identifier with concurrent conflicts as the target change difference value, and take the sum of the current value of the rollback resource line identifier and its corresponding target change difference value as the rollback target value of the rollback resource line identifier.

[0102] As can be seen from the above technical solution, this embodiment provides an optional composition of the state restoration unit. Through this method, this application can calculate an accurate rollback target value for rollback resource rows with concurrent conflicts by combining the difference between the original change records and the actual value of the current resource row. This avoids incorrectly overwriting legitimate changes already completed by other requests during concurrency and accurately completes the adjustments that need to be rolled back, preventing excessive or incomplete rollbacks in concurrent scenarios. This further improves the accuracy and stability of rollback operations in complex concurrent scenarios and ensures data consistency when multiple requests are processed in parallel.

[0103] In some embodiments of this application, the upstream service module 10 may also include a retry unit.

[0104] When the downstream resource change module 20 is in a service idle state, the retry unit combines the business processing identifier in the retry table and all its corresponding retry resource row identifiers, as well as the business change difference corresponding to each retry resource row identifier, to generate a change retry request, and sends it to the downstream resource change module so that the downstream resource change module can change the resource row status.

[0105] Specifically, the retry unit can organize and combine all retry resource line identifiers corresponding to the same business processing identifier to generate a corresponding change retry request, trigger batch retry processing in a unified manner, reduce the overhead of repeated communication interaction, improve the overall processing efficiency of the retry process, so that the downstream resource change module 20 can complete the status change on a single resource line and feed back the change result to the upstream business module 10. The upstream business module 10 can make process decisions again based on the retry result until all resource lines under the corresponding business processing identifier have been changed, and then execute the subsequent closing business operations.

[0106] To reduce resource waste, the retry unit can also record the number of retries corresponding to the service processing identifier. When the number of retries exceeds the preset retry threshold, an alarm containing the service processing identifier and the remaining retry resource line identifier can be generated so that maintenance personnel can handle it.

[0107] The relevant code can be seen as follows:

[0108] CREATE TABLE retry_task (

[0109] id BIGINT PRIMARY KEY AUTO_INCREMENT,

[0110] task_data JSON NOT NULL COMMENT 'Serialized rollback request',

[0111] retry_count INT DEFAULT 0 COMMENT 'Number of retries',

[0112] `next_retry_time` is the next retry time (exponential backoff) specified in the `COMMENT` property.

[0113] status VARCHAR(20) DEFAULT 'PENDING' COMMENT 'PENDING / SUCCESS / FINAL_FAILED',

[0114] create_time DATETIME,

[0115] update_time (DATETIME)

[0116] As can be seen from the above technical solution, this embodiment provides an optional composition method for the upstream business module 10. Through the above asynchronous retry processing mechanism, it ensures that the resource row that fails to be changed can get a second processing opportunity, thereby improving the overall change success rate, without blocking the main processing flow of the upstream business. It can effectively reduce the business processing pressure during peak periods and improve the overall processing capacity of the system in high-concurrency scenarios.

[0117] In some embodiments of this application, the downstream resource change module 20 may include a status retry unit.

[0118] Upon receiving the change retry request, the status retry unit sequentially drives the corresponding retry resource line to perform a status change based on the business change difference corresponding to each retry resource line identifier. It also records the pre-retry value and post-retry value of the retry resource line and generates a second feedback information containing the business processing identifier to indicate whether each retry resource line has been successfully changed. This allows the upstream business module to delete the successfully changed retry resource line identifiers and business change differences from the retry table. After all retry resource lines corresponding to the business processing identifier have been successfully changed, the business processing is executed.

[0119] Specifically, upon receiving a change retry request, the status retry unit can sequentially drive the corresponding retry resource line to perform a status change based on the business change difference corresponding to each retry resource line identifier. Simultaneously, during the change process, it records the status value of each retry resource line before the change begins and the final status value after the change is completed. After completing the status change operation for a single retry resource line, the change result of that retry resource line can be bound to the corresponding business processing identifier. After summarizing the change results of all retry resource lines, a second feedback message is generated and sent back to the upstream business module 10. Upon receiving the feedback, the upstream business module 10 deletes the identifier and business change difference of the successfully changed retry resource line from the retry table. Only after all retry resource lines under that business processing identifier show successful changes can the subsequent business closure processing be completed.

[0120] As can be seen from the above technical solution, this embodiment provides an optional composition of the downstream resource change module 20. Through this method, the status changes of the retry resource rows can be completed sequentially, the data of each step of the retry process can be fully recorded, and accurate and clear change result feedback can be generated. This allows the upstream business module 10 to accurately update the retry table and also fully retains the change data of the retry process, facilitating subsequent traceability and verification. It ensures that every step of the retry process is controllable and traceable, further improving the standardization and accuracy of the retry process.

[0121] In some embodiments of this application, the upstream business module 10 may also include a periodic identification unit.

[0122] The periodic identification unit periodically monitors the service status of the downstream resource change module and identifies whether the downstream resource change module is in an idle state; if so, it calls the retry unit.

[0123] Specifically, the periodic identification unit can periodically scan the current service load of the downstream resource change module 20 according to a preset monitoring cycle, and determine whether it meets the idle determination conditions based on a preset idle threshold; it can also issue query commands to determine whether the downstream resource change module 20 is in a service idle state based on the retry feasibility flag returned by the downstream resource change module 20. When the current load of the downstream resource change module 20 is lower than the preset threshold or the retry feasibility flag indicates that the downstream resource change module 20 is in a service idle state, the retry unit is immediately triggered to start the retry processing procedure.

[0124] If the downstream resource change module 20 is still running under high load, it will continue to monitor and wait for the next cycle to identify and judge, and will not rashly trigger retry processing to occupy core business processing resources.

[0125] The downstream resource change module 20 can provide a retry feasibility indicator based on its own service status, such as service overload, service idle, or transaction conflict, to avoid invalid retries.

[0126] As can be seen from the above technical solution, this embodiment provides an optional composition method for the upstream business module 10. Through a periodic idle state identification mechanism, it can automatically match the running rhythm of downstream services, trigger the retry process in staggered peak hours, avoid crowding out the core business's operating resources during peak business periods, and maintain the overall stability of the system while ensuring that failed resource changes have a chance to retry.

[0127] In some embodiments of this application, the downstream resource change module 20 may include a change execution unit.

[0128] The change execution unit determines the business scenario type based on the resource change request, sorts each change resource line identifier according to the business scenario type, and obtains a sorting result; according to the sorting result, it drives the corresponding change resource line execution status change in turn according to the change target of each change resource line identifier.

[0129] Specifically, different business scenario types can correspond to different resource row operation sorting.

[0130] For example, in order payment scenarios, changes can be prioritized for resource lines involving fund deductions, and then the status adjustments for other subsidiary resource lines can be processed. In inventory deduction scenarios, changes can be prioritized for core inventory resource lines, and then the associated inventory detail resource lines can be updated. This adapts to the processing priority requirements of different business scenarios and avoids business logic errors caused by unreasonable execution order of resource lines.

[0131] The change execution unit can first parse the business scenario type carried in the resource change request, match the corresponding preset resource row sorting rules, sort all the resource row identifiers to be changed according to the rules, and then drive the corresponding resource row to complete the status change according to the preset change target. After each resource row status change is completed, its change result status is updated synchronously to ensure that the overall processing flow meets the sequential requirements of the business logic.

[0132] As can be seen from the above technical solution, this embodiment provides an optional composition of the downstream resource change module 20. By pre-sorting the execution order of the change resource lines according to the business scenario type, it can adapt to the logical priority requirements of different business scenarios, avoid business logic abnormalities caused by incorrect processing order of resource lines, and further improve the accuracy and business adaptability of the resource status change process.

[0133] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0134] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0135] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. The various embodiments of this application can be combined with each other. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A resource status change system, characterized in that, This includes upstream business modules and downstream resource change modules; The upstream business module sends a resource change request containing resource change details to the downstream resource change module. The downstream resource change module analyzes the resource change request, generates a unique corresponding business processing identifier, and determines all change resource line identifiers and the change target of each change resource line identifier. Based on the change target of each changed resource line identifier, drive the corresponding changed resource line to perform a status change, record the value before and after the change of the changed resource line, and generate the first feedback information containing the business processing identifier and used to characterize whether each changed resource line has been successfully changed. The upstream business module determines whether a state rollback is required based on the first feedback information, and when a state rollback is required, generates and sends a resource rollback request containing a rollback resource line identifier and a business processing identifier to the downstream resource change module. When the downstream resource change module receives the resource rollback request, it determines the rollback target value of the corresponding rollback resource line identifier based on each rollback resource line identifier and the previous values ​​corresponding to the business processing identifier. The rollback target value based on each rollback resource line identifier will be used to restore the state of the corresponding rollback resource line; The upstream business module uses the rollback resource line identifiers corresponding to the successful rollbacks of the business processing identifiers as the retry resource line identifiers. Based on the resource change details, it determines the business change difference for each retry resource line identifier and records the business processing identifier, each retry resource line identifier, and its corresponding business change difference in the retry table so that the downstream resource change module can perform resource status changes when the service is idle.

2. The resource status change system according to claim 1, characterized in that, The upstream business module includes a first request generation unit; The first request generation unit receives and analyzes business processing requirements, determines all change resource lines that match the business processing requirements and the change difference of each change resource line, and generates and sends a resource change request containing resource change details to the downstream resource change module.

3. The resource status change system according to claim 1, characterized in that, The upstream business module also includes a second request generation unit; The second request generation unit analyzes the first feedback information and uses the identifier of the changed resource line that has not been successfully changed as the rollback resource line identifier; it combines the business processing identifier and all its corresponding rollback resource line identifiers to generate a resource rollback request.

4. The resource status change system according to claim 1, characterized in that, The downstream resource change module includes a flow record unit; The logging unit determines the change timestamp corresponding to the execution status change of each changed resource line, and writes the change timestamp, the value before the change, and the value after the change corresponding to the changed resource line into the logging table.

5. The resource status change system according to claim 4, characterized in that, The downstream resource change module also includes a status restoration unit; Upon receiving the resource rollback request, the state restoration unit analyzes the log record table to determine whether there is a resource row concurrency conflict between the resource rollback request and other resource change requests. If not, it selects the pre-change value that matches the rollback resource row identifier from the pre-change values ​​corresponding to the business processing identifier as the rollback target value of the corresponding rollback resource row identifier.

6. The resource status change system according to claim 5, characterized in that, The state restoration unit includes a rollback target value determination subunit; If a resource row concurrency conflict exists, the rollback target value determination subunit filters the target pre-change value and target post-change value that match the rollback resource row identifier corresponding to the concurrency conflict from the pre-change value and post-change value corresponding to the business processing identifier, calculates the target change difference between the target pre-change value and target post-change value matched by the rollback resource row identifier, and calculates the rollback target value of the rollback resource row identifier based on the transaction record table and the target change difference of the rollback resource row identifier.

7. The resource status change system according to claim 1, characterized in that, The upstream business module includes a retry unit; When the downstream resource change module is in a service idle state, the retry unit combines the business processing identifier in the retry table and all its corresponding retry resource row identifiers, as well as the business change difference corresponding to each retry resource row identifier, to generate a change retry request, and sends it to the downstream resource change module so that the downstream resource change module can change the resource row status.

8. The resource status change system according to claim 7, characterized in that, The downstream resource change module includes a status retry unit; Upon receiving the change retry request, the status retry unit sequentially drives the corresponding retry resource line to perform a status change based on the business change difference corresponding to each retry resource line identifier. It also records the pre-retry value and post-retry value of the retry resource line and generates a second feedback information containing the business processing identifier to indicate whether each retry resource line has been successfully changed. This allows the upstream business module to delete the successfully changed retry resource line identifiers and business change differences from the retry table and execute business processing after all retry resource lines corresponding to the business processing identifier have been successfully changed.

9. The resource status change system according to claim 7, characterized in that, The upstream business module also includes a periodic identification unit; The periodic identification unit periodically monitors the service status of the downstream resource change module and identifies whether the downstream resource change module is in an idle state; if so, it calls the retry unit.

10. The resource status change system according to claim 1, characterized in that, The downstream resource change module includes a change execution unit; The change execution unit determines the business scenario type based on the resource change request, sorts each change resource line identifier according to the business scenario type, and obtains a sorting result; according to the sorting result, it drives the corresponding change resource line execution status change in turn according to the change target of each change resource line identifier.

Images