A multi-source stop request processing method, device, equipment and medium

Abstract

The application relates to the field of bare metal resources, in particular to a multi-source stop request processing method and device, equipment and a medium, the method comprising: receiving multiple stop requests from at least two types of sources for the same target resource object; determining arbitration attributes corresponding to the multiple stop requests; establishing a unique execution context associated with the target resource object and obtaining an arbitration lock; comprehensively judging by relying on the arbitration attributes to filter out a winning stop request from the multiple requests and binding the winning stop request to the unique execution context; and performing idempotent merging processing on all other non-winning requests after the resource recycling process is executed or ends, so that the final execution result of the context can be directly reused, and the same target resource object is prevented from being repeatedly executed in the recycling process, and the consistency and reliability of the resource recycling process in the multi-source stop scene are significantly improved.

Description

Technical Field

[0001] This application relates to the field of bare metal resources, and in particular to a method, apparatus, device, and medium for processing multi-source stop requests. Background Technology

[0002] In scenarios such as cloud gaming, edge computing desktops, PXE bare metal scheduling, remote streaming delivery, and resource inspection and compensation, the stopping action for the same target resource object often does not originate from a single entry point, but may simultaneously come from multiple sources, including inspection tasks, external active release requests, box restart events, host shutdown events, anomaly compensation processes, or manual stopping operations. Stop requests from different sources typically differ in triggering timing, business urgency, execution basis, and subsequent reclamation actions, but they all ultimately point to the stopping and reclamation of the same target resource object.

[0003] A common approach is to immediately execute a reclamation process on the target resource upon receiving a stop request, or simply use locking to avoid full concurrent execution. However, when stop requests arrive simultaneously from multiple sources, multiple stop requests concurrently advance the reclamation process for the same target resource, leading to duplicate releases, duplicate remote calls, or duplicate state write-backs. This results in repeated execution of the reclamation process, which not only affects system stability but also easily leads to inconsistencies. Therefore, how to solve the above-mentioned technical problems is an urgent technical issue to be addressed in this field. Summary of the Invention

[0004] The purpose of this application is to provide a method, apparatus, device, and medium for processing multi-source stop requests, which can prevent the same target resource object from being repeatedly executed in the recycling process, and significantly improve the consistency and reliability of the resource recycling process in multi-source stop scenarios.

[0005] In a first aspect, embodiments of the present invention provide a multi-source stop request processing method, including: Receive multiple stop requests for the same target resource object, wherein the multiple stop requests originate from at least two types of stop sources; Determine the arbitration attributes corresponding to each of the multiple stop requests; Establish a unique execution context associated with the target resource object; and after successfully acquiring the arbitration lock associated with the target resource object, determine the winning stop request from the plurality of stop requests based on the arbitration attribute; Bind the winning stop request to the unique execution context; execute the resource reclamation process for the target resource object corresponding to the winning stop request; During or after the resource recycling process is executed, other stop requests are subjected to idempotent merging, enabling them to reuse the execution results of the unique execution context.

[0006] In one possible implementation, before establishing a unique execution context associated with the target resource object, the following is also included: Check whether a unique execution context already exists that is bound to the target resource object; If the detection result indicates that the request already exists, then the multiple stop requests are directly associated with the existing unique execution context and marked as pending merging. If the detection result is that it does not exist, then the step of establishing a unique execution context associated with the target resource object is executed.

[0007] In one possible implementation, determining the arbitration attributes corresponding to the plurality of stop requests includes: For each received stop request, perform parameter validation, extract the target resource identifier, request source field and request timestamp from the request, and encapsulate them into a unified arbitration object; Based on the source of the request in the unified arbitration object, a corresponding source level is generated for each stop request; a corresponding idempotency identifier is generated for each stop request, and the target resource identifier, request source, request timestamp, source level, and idempotency identifier are used as the arbitration attributes of each unified arbitration object.

[0008] In one possible implementation, determining the winning stop request from the plurality of stop requests based on arbitration attributes includes: Iterate through all currently generated unified arbitration objects and extract the source level from each unified arbitration object; Sort the source level of each arbitration object and filter out all candidate arbitration objects with the highest source level value; If the number of candidate arbitration objects obtained through screening is 1, then the stop request corresponding to the candidate arbitration object will be determined as the winning stop request; If the number of candidate arbitration objects obtained through screening is greater than 1, then the stop request corresponding to the candidate arbitration object with the earliest timestamp will be determined as the winning stop request.

[0009] In one possible implementation, binding the winning stop request to the unique execution context includes: writing the idempotency identifier of the winning stop request into the main execution field of the unique execution context to complete the binding operation; and associating other stop requests with the unique execution context includes: uniformly storing the idempotency identifiers of other stop requests into a merge set within the unique execution context to complete the association binding of all requests.

[0010] In one possible implementation, during the execution of the resource reclamation process for the target resource object corresponding to the winning stop request, the method further includes: when the resource reclamation process starts, writing a winning request confirmation event to the unique execution context to record the start time of the current reclamation operation; after each key node of the resource reclamation process is completed, writing the corresponding node's execution event to the unique execution context to synchronously update the real-time state of the unique execution context; if an abnormal interruption occurs during the execution of the resource reclamation process, immediately triggering an abnormal compensation event, writing the abnormal type and breakpoint location to the unique execution context, and starting a preset retry rollback mechanism.

[0011] In one possible implementation, during or after the execution of the resource reclamation process, idempotent merging is performed on other stop requests to enable them to reuse the execution results of the unique execution context. This includes: determining the stop request category of the other stop requests, where the stop request category includes any one of merge requests, result reuse requests, and deferred execution requests; and performing corresponding idempotent merging based on the stop request category.

[0012] Secondly, a multi-source stop request processing apparatus is provided, comprising: The receiving module is configured to receive multiple stop requests for the same target resource object, wherein the multiple stop requests originate from at least two types of stop sources; The first determining module is used to determine the arbitration attributes corresponding to the plurality of stop requests respectively; The second determining module is used to establish a unique execution context associated with the target resource object; and after successfully acquiring the arbitration lock associated with the target resource object, to determine the winning stop request from the plurality of stop requests based on the arbitration attribute; The recycling module is used to bind the winning stop request to the unique execution context; and to execute the resource recycling process for the target resource object corresponding to the winning stop request. The idempotent merge module is used to perform idempotent merge processing on other stop requests during or after the execution of the resource reclamation process, so that the other stop requests can reuse the execution results of the unique execution context.

[0013] Thirdly, an electronic device is provided, the electronic device including a memory and a processor, the memory storing a computer program, the processor executing the method of any one of the first aspects when running the computer program.

[0014] Fourthly, a computer-readable storage medium is provided, wherein at least one piece of program code is stored therein, the program code being loaded and executed by a processor to implement the method as described in any of the first aspects.

[0015] Fifthly, a computer program product is provided, including a computer program or instructions that, when executed by a processor, implement the method as described in any of the first aspects.

[0016] In summary, the multi-source stop request processing method provided in this application has the following beneficial technical effects: receiving multiple stop requests from at least two types of sources targeting the same target resource object; determining the arbitration attributes corresponding to each of the multiple stop requests. Instead of immediately executing the recycling operation for each stop request sequentially, a unique execution context associated with the target resource object is established and an arbitration lock is acquired; a comprehensive judgment is made based on the arbitration attributes to select the winning stop request from among the numerous requests and bind it to the unique execution context. During or after the resource recycling process driven by the winning request, idempotent merging processing is performed on all other non-winning requests, allowing them to directly reuse the final execution result of the context, avoiding repeated recycling processes for the same target resource object, and significantly improving the consistency and reliability of the resource recycling process in multi-source stop scenarios.

[0017] In addition, this application also provides a multi-source stop request processing apparatus, device and medium, all of which have the above-mentioned beneficial technical effects. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of 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 some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of a multi-source stop request processing method provided in an embodiment of this application; Figure 2 This is a schematic diagram illustrating the process of acquiring an arbitration lock, stopping context establishment, and merging unsuccessful requests, as provided in an embodiment of the present invention. Figure 3 This is a schematic diagram illustrating a process for unifying the source of a stop request, generating arbitration attributes, and determining the winner, as provided in an embodiment of the present invention. Figure 4 This is a schematic diagram of a process for winning a stop request execution recovery, process event recording, and final idempotent termination, provided as an embodiment of the present invention; Figure 5 This is a schematic diagram of a multi-source stop request concurrent arbitration overall architecture provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of a multi-source stop request processing device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] This specific embodiment is merely an explanation of this application and is not intended to limit it. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they are within the scope of this application.

[0021] It should be noted that, in the optional embodiments of this application, the data related to object information, when applied to specific products or technologies, requires the permission or consent of the object. Furthermore, the collection, use, and processing of this data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. In other words, if the embodiments of this application involve data related to an object, it must be obtained with the permission and consent of the object, the permission and consent of relevant departments, and in accordance with the relevant laws, regulations, and standards of the country and region. If the embodiments involve personal information, the acquisition of all personal information requires the consent of the individual. If sensitive information is involved, the separate consent of the information subject is required. The embodiments also need to be implemented with the permission and consent of the object.

[0022] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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, 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.

[0023] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article, unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0024] In existing technologies, a common approach is to immediately execute a recycling process on the target resource upon receiving a stop request, or simply avoid full concurrent execution through simple locking. However, when stop requests arrive simultaneously from multiple sources, existing solutions are prone to the following problems: multiple stop requests simultaneously advance the recycling process of the same target resource, leading to duplicate releases, duplicate remote calls, or duplicate state write-backs; earlier but lower-priority stop requests occupy execution opportunities, while higher-priority requests fail to take over in time, resulting in inconsistencies between the stop results and business requirements; the lack of a unified merging mechanism for unsuccessful stop requests easily leads to repeated retries, duplicate logging, or continuous triggering of downstream interfaces; different processes write states separately during the recycling process, easily causing overwrite conflicts where some resources are released while other processes continue to execute; and the lack of a unified stop context makes it difficult to trace which stop source actually executed this round of recycling during subsequent auditing, compensation, or asynchronous callback confirmation.

[0025] Existing solutions focus more on shutdown control, resource release timing, or post-release status confirmation under a single stop source, but lack specific technical solutions for "how to unify the sources of stop requests, determine the unique winner, idempotently merge the non-winner requests, and unify the final status when multiple stop sources arrive concurrently".

[0026] Therefore, a new technical solution is needed to establish a unified arbitration attribute for each stop request when multiple stop sources concurrently arrive at the same target resource object, determine the unique winning stop request to advance the actual recycling process, and perform idempotent merging on the non-winning stop requests, thereby improving the consistency, controllability, and audit certainty of the resource recycling chain in multi-source stop scenarios. This solution focuses on how to maintain unique execution and idempotent convergence when multiple stop sources simultaneously trigger stop actions on the same target resource object, and proposes a concurrent arbitration and idempotent recycling method for multi-source stop requests. Its core is: first, a unified arbitration object corresponding to multiple stop requests is formed around the same target resource object; then, a unique execution context is established based on the target resource identifier; and the winning stop request is determined according to the unified arbitration object. Only the winning stop request is allowed to advance the actual recycling process as the unique execution request corresponding to the unique execution context; for the remaining non-winning requests, idempotent merging processing such as execution result reuse, merging mark, or delayed confirmation is performed, and finally, the recycling result and the set of merged requests are written back around the same unique execution context. This solution is suitable for concurrent recycling control, anomaly compensation, and audit tracing in scenarios involving bare metal resources, PXE scheduling resources, streaming session binding resources, and other multi-entry stop scenarios.

[0027] The multi-source stop request processing method provided in this embodiment of the invention can be executed by an electronic device, and can at least solve one of the above-mentioned technical problems. The embodiments of the invention will be described in detail below with reference to the accompanying drawings.

[0028] refer to Figure 1 The present invention provides a multi-source stop request processing method, including the following steps S101 to S105.

[0029] S101: Receive multiple stop requests for the same target resource object, with the multiple stop requests originating from at least two types of stop sources.

[0030] The target resource object refers to the object that needs to be stopped and reclaimed, such as bare metal servers, cloud gaming instances, edge computing desktop sessions, or streaming delivery channels. A stop request is a stop request initiated against the target resource object. Stop sources include at least two of the following: stop triggered by inspection tasks, external active release requests, box restart events, host shutdown events, stop triggered by anomaly compensation, and manual stop operations.

[0031] Specifically, once the system receives a stop request for the same target resource object, it will process all stop requests together instead of processing them separately.

[0032] S102: Determine the arbitration attributes corresponding to each of the multiple stop requests.

[0033] In this embodiment, the original formats of requests from different sources are usually inconsistent. If common fields are not extracted first, a unified comparison and arbitration cannot be performed subsequently. After extracting the basic fields of each stop request, they are converted into a unified arbitration object. Then, based on the unified arbitration object, multiple arbitration attributes are generated. These multiple arbitration attributes include the target resource identifier, request source, request timestamp, source level, and idempotency identifier.

[0034] S103: Establish a unique execution context associated with the target resource object; and after successfully acquiring the arbitration lock associated with the target resource object, determine the winning stop request from multiple stop requests based on the arbitration attribute.

[0035] The unique execution context is an execution environment established for the target resource object, which binds all relevant information of the target resource object together, ensuring that all operations on the target resource object are executed in this environment. Once the unique execution context is established for the target resource object, no new context will be established for other requests to the target resource object. The unique execution context records all the contents of the entire process.

[0036] An arbitration lock is a locking mechanism used to ensure that only one request is allowed to enter the recycling process for the same target resource object within the same time window. A winning stop request represents the only request to execute the recycling process in the current round of concurrent stop scenarios.

[0037] Specifically, the process checks whether a unique execution context already exists for the target resource object. If it does, it indicates that a previous request has entered the execution chain, and subsequent requests will not initiate a separate recycling process but will instead be merged. If it does not exist, the process attempts to acquire the lock and establish a context. If an existing context is found before acquiring the lock, it is merged, and an attempt is made to acquire an arbitration lock associated with the target resource identifier. The arbitration lock is implemented using a combination of database lock detection and distributed lock acquisition. After successfully acquiring the arbitration lock, the winning request is determined based on the arbitration attribute.

[0038] S104: Bind the winning stop request to the unique execution context; execute the resource reclamation process for the target resource object corresponding to the winning stop request.

[0039] The operation that establishes the winning stop request as the sole legitimate executor within the unique execution context means that all subsequent actual reclamation actions, result write-back actions, and status closure actions are based on this winning request. The resource reclamation process represents a sequence of operations involving stopping, releasing, and cleaning up the target resource object.

[0040] After binding the winning stop request to a unique execution context, the actual recycling process is advanced based on that winning stop request. By allowing only the winning request to enter this stage, multiple sources are prevented from simultaneously executing stop operations on the same resource repeatedly. During the recycling process, the system can also continuously record key process events, including stop intent events, winning request confirmation events, merge events, recycling execution events, recycling completion events, and exception compensation events. The stop intent event records when a source initiates a stop request; the winning request confirmation event indicates which request becomes the sole executor; the merge event explains how the remaining requests are merged or reused; and the recycling completion event indicates when the final stop chain ends and what the result is.

[0041] The purpose of this step is to execute the actual recycling operation through the only winning request, thereby avoiding multiple requests from different sources from repeatedly executing stop and release on the same resource, thus reducing resource state overwriting conflicts and the risk of repeated calls to downstream interfaces.

[0042] S105: During or after the resource reclamation process, perform idempotent merging on other stop requests so that other stop requests can reuse the execution results of the unique execution context.

[0043] In this context, idempotent merging refers to performing a unified convergence operation on the ineligible stop requests, reusing the existing execution results of the ineligible requests instead of independently triggering the reclamation process. The final stop state associated with the target resource identifier is written back to form a concurrent arbitration and idempotent closure result for multi-source stop requests. The execution result represents the final stop state formed after the winning stop request advances the resource reclamation process, including the target resource identifier, winning request identifier, winning source type, source level, stop start time, stop completion time, reclamation result, current state, and a unified closure result of the merged request set. Other requests include at least the requests other than the winning stop request from among multiple stop requests; additionally, they may include stop requests received during the resource reclamation process targeting the same target resource object.

[0044] In some embodiments, after the recycling process is completed, the arrival time of all non-winning requests is checked, requests that arrive during the recycling process are marked as merged requests and the merging reason is recorded, requests that arrive after the recycling process is completed are marked as result reuse requests and the final stop status is returned directly, and the set of identifiers of all merged requests is written into the merged request set field of the final stop status.

[0045] The purpose of this step is to reduce repeated retries by uniformly merging unsuccessful requests into the existing execution chain and forming a final, consistent stopping result.

[0046] As can be seen, in this embodiment, multiple stop requests targeting the same resource object from at least two sources are received; the arbitration attributes corresponding to each stop request are determined. Instead of immediately executing the recycling operation for each stop request sequentially, a unique execution context associated with the target resource object is established and an arbitration lock is acquired. A comprehensive judgment is made based on the arbitration attributes, selecting the winning stop request from among the numerous requests and binding it to the unique execution context. During or after the resource recycling process driven by the winning request, idempotent merging is performed on all other non-winning requests, allowing them to directly reuse the final execution result of the context. This avoids the same target resource object being repeatedly subjected to the recycling process, significantly improving the consistency and reliability of the resource recycling process in multi-source stop scenarios.

[0047] In one feasible approach, to accurately determine whether a new execution context needs to be created and to avoid the repeated creation of existing execution chains, specifically, before establishing a unique execution context associated with the target resource object, the following steps are included: checking whether a unique execution context already exists bound to the target resource object; if the detection result is that it already exists, then multiple stop requests are directly associated with the existing unique execution context and marked as pending merging; if the detection result is that it does not exist, then the step of establishing a unique execution context associated with the target resource object is executed.

[0048] The "pending merging" state indicates that the stop request has been identified as needing to be merged into an existing execution chain, but the final merging operation has not yet been completed. At this time, the stop request no longer independently triggers the recycling process, but waits for the recycling result to be determined before the result is reused or marked for merging.

[0049] Before processing a new stop request, the system first checks whether a corresponding unique execution context record already exists for the target resource identifier. If it does, it means that a previous request has entered the execution chain, and the current stop request is directly associated with that unique execution context and marked as pending merging, without attempting to acquire an arbitration lock or create a new unique execution context. If it does not exist, the system proceeds to the process of creating a new unique execution context and acquiring an arbitration lock.

[0050] As can be seen, in this embodiment, before attempting to establish a new unique execution context for a currently arriving stop request, it is determined whether the target resource already has a bound unique execution context. If the detection result is that it already exists, it indicates that the recycling process for the resource has been initiated and is being executed or has already been completed by a previous winning request. At this time, no new unique execution context is attempted to be established. Instead, all currently arriving requests are directly associated with the existing unique execution context and marked as pending merging, ensuring that the same resource has one and only one unique execution context at any given time.

[0051] In one feasible approach, see [link to relevant documentation] Figure 2 This includes: starting from the arbitration process after the stop request enters the arbitration process, firstly determining whether a unique execution context already exists. If it does, it is directly associated with the existing context, and the current request is treated as a failed request and idempotently merged to achieve merging, result reuse, and delayed confirmation. If it does not yet exist, it attempts to acquire the arbitration lock for the target resource. If the acquisition of the arbitration lock fails, the context is re-checked and merged into the existing context to avoid multiple nodes winning repeatedly. If the acquisition is successful, a unique execution context is established and a unique execution request is bound. In this way, the winning request enters the recycling execution, ultimately ensuring that the actual recycling chain is executed only once.

[0052] In one feasible approach, multiple stop requests are converted into unified arbitration objects with arbitration attributes, including: determining the arbitration attributes corresponding to each stop request, including: performing parameter validation on each received stop request, extracting the target resource identifier, request source field, and request timestamp from the request, and encapsulating them into a unified arbitration object; generating a corresponding source level for each stop request based on the request source of the unified arbitration object; generating a corresponding idempotency identifier for each stop request, and using the target resource identifier, request source, request timestamp, source level, and idempotency identifier as the arbitration attributes of each unified arbitration object.

[0053] The parameter validation section checks the completeness, format validity, and value legality of the fields in the stop request. The target resource identifier is the identification information used to uniquely determine the resource object affected by the stop request. The request source field identifies the source type of the stop request.

[0054] Specifically, each received stop request undergoes parameter validation, extracting the target resource identifier, request source field, and request timestamp, and encapsulating them into a unified arbitration object. Based on the request source field, a pre-defined source level mapping table is queried to generate a corresponding source level for each stop request. The source level is pre-configured based on the business urgency, mandatory constraints, or resource security risks of the stop source; a higher source level value indicates higher priority. A unique idempotent identifier is generated for each stop request, which can be a hash value or UUID generated based on a combination of source type, event identifier, and target resource identifier. All attributes are used as arbitration attributes for each stop request.

[0055] As can be seen, in this embodiment of the application, a unified arbitration object with a unified format is generated by verifying parameters and extracting the target resource identifier, request source, and timestamp; a source level is dynamically generated for each stop request according to pre-configured rules; a globally unique idempotent identifier is generated for each request as a fingerprint of the stop request; and all the above information is used to constitute the arbitration attribute.

[0056] In one feasible approach, determining the winning stop request from multiple stop requests based on arbitration attributes includes: sorting the source level of each arbitration object and filtering out all candidate arbitration objects with the highest source level value; if the number of candidate arbitration objects obtained is 1, then the stop request corresponding to the candidate arbitration object is determined as the winning stop request; if the number of candidate arbitration objects obtained is greater than 1, then the stop request corresponding to the candidate arbitration object with the earliest timestamp is determined as the winning stop request.

[0057] Specifically, the source level field is extracted for each arbitration object. All arbitration objects are sorted in descending order of source level value, and all candidate arbitration objects with the highest source level are selected. If there is only one request among all candidate arbitration objects with the highest source level, its corresponding stop request is directly determined as the winning stop request; if there are multiple requests among all candidate arbitration objects with the highest source level, the request timestamps are further compared, and the stop request corresponding to the candidate arbitration object with the earliest timestamp is determined as the winning stop request.

[0058] As can be seen, in this embodiment, when executing the core decision on the winning request, an initial screening is performed based on the source level. All candidate arbitration objects are sorted, and the candidate arbitration object with the highest value is selected. Since the source level is pre-configured based on hard rules such as business urgency and security, it ensures that the highest priority business requests are responded to first. When multiple requests have the same source level, a second screening is performed based on the request timestamp. Through the above methods, the winning stop request can be accurately determined.

[0059] In one feasible approach, the winning stop request is bound to the unique execution context, including: writing the idempotency flag of the winning stop request into the main execution field of the unique execution context to complete the binding operation; other stop requests are associated with the unique execution context, including: storing the idempotency flags of other stop requests into a merged set within the unique execution context to complete the association binding of all requests.

[0060] The main execution field represents the field in the unique execution context used to record the unique and legitimate executor of the current round of the stop process. The merge set represents the list in the unique execution context used to store all the identifiers of the stop requests that did not win.

[0061] Specifically, after determining the winning stop request, its idempotency flag is written to the main execution field of the unique execution context, ensuring that all subsequent actual recycling actions in this round of the stop process use this winning request as the sole legitimate executor. Simultaneously, the idempotency flags of the remaining unsuccessful stop requests are collectively stored in a merge set within the unique execution context, completing the association and binding of all requests. Subsequent requests, even if they still have the intention to stop, are no longer allowed to restart independent stop chains; they can only establish associations with the existing unique execution context.

[0062] As can be seen, in this embodiment of the application, after successfully determining the winning request, the idempotency flag of the winning request is written into the main execution field of the execution context, and the request is regarded as the only executor. The subsequent resource reclamation process will be based entirely on the request corresponding to this flag. For all other requests that do not win, their idempotency flags are uniformly stored in the merge set inside the execution context, which effectively avoids the problem of inconsistent states caused by information dispersion.

[0063] In one feasible approach, see [link to relevant documentation] Figure 3 , Figure 3This invention provides a flowchart illustrating the process of source unification, arbitration attribute generation, and winner determination for stop requests. The process includes: receiving multiple stop requests for the same target resource object; extracting the source type, source event identifier, and request time for each request; locking the target resource identifier; introducing pre-configured level rules based on business urgency and security risk; converting heterogeneous source requests into a unified comparable structure through source unification rules, i.e., mapping different entry points to the same set of fields to form a unified arbitration object; generating arbitration attributes including source level, request time, idempotency identifier, and target resource identifier; aggregating them according to the same target resource; and performing winner determination, specifically prioritizing higher source levels, sorting same levels by request time, and merging duplicate events by idempotency identifier. Finally, a unique winner stop request is output and prepared to be bound to a unique execution context. This winner stop request is then bound as a unique execution request.

[0064] In one feasible approach, to enhance the traceability and exception handling capabilities of the recycling process, the resource recycling process for the target resource object corresponding to the successful stop request also includes: writing a successful request confirmation event to the unique execution context when the resource recycling process starts, recording the start time of the current recycling operation; writing the corresponding node's execution event to the unique execution context after each key node of the resource recycling process is completed, synchronously updating the real-time state of the unique execution context; and immediately triggering an exception compensation event if an exception occurs during the execution of the resource recycling process, writing the exception type and breakpoint location to the unique execution context, and initiating a preset retry rollback mechanism.

[0065] Among them, the execution events of key nodes represent progress events recorded after the completion of each important operation step in the recycling process, such as resource occupancy release completion events, streaming task completion events, or downstream interface call completion events. Exception compensation events represent fault information events recorded when an exception occurs during the recycling process, i.e., retry criteria including the exception type and breakpoint location. The retry rollback mechanism represents a preset processing flow that rolls back from the failed node to a safe state based on the breakpoint location after an exception occurs.

[0066] Specifically, upon initiation of the recycling process, a win request confirmation event is immediately written to the unique execution context, recording the start time. After each critical node in the recycling process is completed, the corresponding node's execution event is written to the unique execution context, synchronously updating the context's real-time status fields. If an abnormal interruption occurs during the recycling process, an exception compensation event is immediately triggered, writing the exception type and breakpoint location information to the context, and initiating a preset retry and rollback mechanism.

[0067] As can be seen in this embodiment, a success request confirmation event is written immediately upon process initiation. During process execution, the real-time state of the execution context is synchronously updated and corresponding events are recorded upon completion of each key node, enabling precise determination of the recycling process's progress. When the process is unexpectedly interrupted, the system can immediately capture and trigger an exception compensation event, write the exception type and breakpoint location into the context, and initiate a preset retry or rollback mechanism. Through complete process event recording, the system can track the entire recycling process.

[0068] In one feasible approach, to achieve unified convergence of the non-winning stop requests and form a final consistent conclusion, during or after the resource reclamation process, idempotent merging is performed on other stop requests so that they can reuse the execution results of a unique execution context. This includes: determining the stop request category of other stop requests, where the stop request category includes any one of merge requests, result reuse requests, and deferred execution requests; and performing the corresponding idempotent merging process based on the stop request category.

[0069] Among them, "Merge Request" indicates a request category where the intention to stop has been included in the current unique execution chain but no longer independently triggers recycling; that is, the stopping purpose of this request has been covered by the execution of the winning request. "Result Reuse Request" indicates a request category where the current unique execution chain has produced a reusable result, and subsequent requests directly reuse this result; that is, this request reaches a final, directly referable, stopped state after the recycling process is completed. "Delayed Execution Request" indicates a request category where there is currently an execution chain in progress, and subsequent requests are temporarily suspended until the chain is completed and it is confirmed whether they still need to be processed independently.

[0070] Specifically, after the recycling process is completed, the stop requests are categorized based on their arrival time and status. Other stop requests include: requests that did not succeed, stop requests for the unified resource object that arrived during the recycling process, and stop requests for the unified resource object that arrived after the recycling process was completed.

[0071] For requests arriving during the recycling process, the system classifies them as merge requests, indicating that their intention to stop has been incorporated into the current execution chain. For requests arriving after the recycling process is completed, the system classifies them as result reuse requests, directly returning the final stop status without triggering a new recycling process. For requests arriving during the recycling process but requiring independent confirmation by business logic, the system classifies them as deferred execution requests, temporarily shelving them until the recycling process is completed and the current resource status is assessed to determine whether independent processing is still necessary. The final stop status and the set of merge requests are written back together to form a unified idempotent closing result.

[0072] As can be seen, in this embodiment of the application, each unsuccessful request is explicitly classified into a merge request, a result reuse request, or a delayed execution request according to preset rules or the attributes of the request itself. Based on the classification of the request results, the system executes the corresponding idempotent processing strategy to ensure that each request can obtain feedback that matches its business semantics.

[0073] Further, see Figure 4 This includes: after the winning stop request enters the actual recycling process, the stop intent event and the winning judgment event are written first, the execution source, execution time and unique context identifier are fixed, and then the resource recycling chain is executed, including releasing the occupancy relationship, ending the target task and triggering resource cleanup. At the same time, the merge request needs to reuse the execution result; during this process, the system will determine whether it receives an asynchronous callback or compensation confirmation. If received, the unique execution context is checked and the callback attribution to the current state is verified; if not received, the final stop state is written back to form the winning request identifier, current state, and stop completion time, etc. Then, the request set and event chain are settled and merged for reuse in auditing, playback, compensation and subsequent queries, as well as writing back the results of this round of collection and recording the results of execution completion or abnormal compensation.

[0074] Based on the above embodiments, the method provided by the present invention is particularly applicable to bare metal scheduling, streaming resource reclamation, anomaly compensation reclamation, and other multi-entry concurrent stop scenarios. It is understood that the types of stop sources are not limited to the inspection tasks, external active release, box restart, host shutdown, anomaly compensation, and manual stop listed above, but may also include other business entry points that need to trigger resource stop; the implementation of the arbitration lock is not limited to a combination of database locks and distributed locks, and other mutual exclusion control methods can be adopted depending on the deployment environment; the composition of the final stop state fields can also be expanded or reduced according to business needs, and no limitations are imposed here.

[0075] Based on any of the above embodiments, see Figure 5 , Figure 5 A schematic diagram of a multi-source stop request concurrent arbitration overall architecture provided in this embodiment of the invention includes: The system supports multiple request entry points and various event-triggered stop requests, including: inspection task triggers (periodic inspections / anomaly detection), external proactive releases (API / business-side proactive stop), box restart events (terminal restart / session interruption), host shutdown events (monitoring reporting / BM events), anomaly compensation processes (timeout compensation / failure recovery), and manual stop operations (console / operations handling). A source unification and unified arbitration object formation layer normalizes requests from different sources, forming a unified arbitration object. Key identifier fields include source type, source level, request time, target resource identifier, and idempotency identifier. A unique execution context and arbitration lock control layer ensures that only one winning stop request gains actual recovery execution rights for the same target resource. The winning request drives actual recovery; after gaining execution rights, the winning request drives actual resource recovery operations, including: releasing resources, ending the task, and writing back the execution result. Unsuccessful requests are idempotently merged, including merged requests, result reuse, and delayed confirmation. The unified state closing and auditing process outputs audit information including: final stop state, merge request set, and callback compensation basis.

[0076] Specific implementation methods include: 1. Receive multiple stop requests for the target resource object; the multiple stop requests come from at least two types of stop sources; the stop sources include at least: inspection task-triggered stop; external active release request; box restart event; host shutdown event; anomaly compensation-triggered stop; manual stop operation.

[0077] 2. Extract the source type, event identifier, request time, and target resource identifier corresponding to each stop request; the event identifier can be used to indicate the reason for the stop.

[0078] 3. Convert all stop requests into a unified arbitration object; Multiple stop requests are parsed uniformly to extract the source type, source event identifier, trigger time, and target resource identifier, and then converted into a consistent arbitration object. The unified arbitration includes multiple attributes, such as source type, request time, and target resource identifier. Furthermore, source level and idempotency identifiers can be generated based on step 4 and added to the arbitration attributes.

[0079] 4. Generate source level and idempotency identifiers for each arbitration object; The source level is pre-configured based on the business urgency, mandatory constraints, or resource security risks of the stopping source, and is used to determine the winning order when multiple stop requests arrive concurrently. The idempotency identifier is generated based on the target resource identifier. In this embodiment, a source level and idempotency identifier are generated for each arbitration object, so that the subsequent arbitration process no longer depends on the original request format, but performs comparisons and judgments around a unified arbitration attribute.

[0080] 5. Establish or detect the unique execution context corresponding to the target resource object; A unique execution context is established based on the target resource identifier to correspond to multiple stop requests. In another implementation, the system first detects and establishes a unique execution context corresponding to the target resource identifier before processing the arbitration object.

[0081] When a unique execution context is detected for the target resource object, subsequent stop requests will no longer repeat the actual recycling process. Instead, they will be associated with the unique execution context and marked as merged requests or result reuse requests.

[0082] 6. If the unique execution context does not yet exist, attempt to acquire the arbitration lock associated with the target resource identifier; If a unique execution context does not exist, a unique execution context can be established to acquire an arbitration lock associated with the target resource identifier; Arbitration locks employ a combination of database lock detection and distributed lock acquisition to prevent multiple execution nodes from simultaneously determining different stop requests as winning requests.

[0083] 7. After successfully acquiring the arbitration lock, determine the winning stop request from multiple stop requests based on the arbitration attribute; After successfully acquiring the arbitration lock, a unique winning stop request is determined based on the source level, request time, and idempotency identifier of each arbitration object, and the winning stop request is bound as the unique execution request of the unique execution context.

[0084] The winning decision will also be recorded as an event for reference in subsequent auditing, replay, or compensation processes.

[0085] 8. The only execution request that binds the winning stop request to the unique execution context; 9. Perform idempotent merging on the stop requests that do not succeed, so that the remaining stop requests are associated with a unique execution context and recorded as merge requests, reuse requests, or postponed requests; For the stop requests that do not succeed, perform idempotent merging processing, so that the stop requests that do not succeed reuse the execution result of the unique execution context, are marked as merged requests, or are postponed execution requests; In a further implementation, for stop requests that do not succeed, the system does not immediately treat them as failed requests, but instead performs idempotent merging processing based on the unique execution context. Idempotent merging processing may include at least one of the following: marking the failed request as a merged request; reusing the execution result of the unique execution context for the failed request; marking the failed request as a deferred execution request; and returning a status indicator such as processing, merged, or completed result reuse. Through the above methods, the system can avoid multiple stop requests continuously retrying and repeatedly advancing the recycling chain.

[0086] 10. Based on the winning stop request, execute the target resource reclamation process; It can also record stopping process events and reclamation results. During or after the target resource reclamation process, the final stopping state associated with the target resource identifier is written back to form a concurrent arbitration and idempotent closure result for multi-source stopping requests.

[0087] 11. Record the stop intention event, the win determination event, the merge event, and the recycling completion event; The stopping process events include at least the following: stopping intent event, winning request confirmation event, non-winning request merging event, recycling execution event, recycling completion event, and exception compensation event.

[0088] In one implementation, the system only allows the winning stop request to proceed with the actual cleanup process. The actual cleanup process may include at least one of the following: releasing the target resource occupancy, terminating the target task, writing the stop result, writing back the exception reason, and triggering subsequent resource cleanup.

[0089] Preferably, before executing the actual recycling process, the system first writes a stop intent event; during execution, it sequentially records a success request confirmation event, a recycling execution event, and a recycling completion event; and in the event of an execution exception, it records an exception compensation event. Through this event chain, the system can provide complete process evidence for subsequent callback confirmation, auditing, and exception compensation.

[0090] 12. Write back the final stopping state and the merge request set to form a unified idempotent closing result.

[0091] The final stopping status includes at least: target resource identifier, winning request identifier, winning source type, source level, stopping start time, stopping completion time, recycling result, current status, and merge request set.

[0092] In another implementation, when the system receives an asynchronous callback associated with the currently stopped process, it looks up the unique execution context corresponding to the target resource object based on the callback identifier, and combines the winner request identifier, merge request set and current state in the unique execution context to determine whether to proceed with writing back the final completion status.

[0093] Preferably, the final stopping state includes at least: target resource identifier, winning request identifier, winning source type, source level, stopping start time, stopping completion time, recycling result, current state, and merge request set. Through this method, the system can generate a unified and traceable final stopping result in multi-source concurrent stopping scenarios.

[0094] Based on the above, this application proposes a source unification and arbitration attribute generation mechanism for multi-source stop requests, enabling stop actions triggered by different entry points to be converted into a unified comparable object; it proposes a unique winning request execution mechanism with the target resource object as the granularity, ensuring that the same target resource is driven by only one stop request in the same time period; it proposes an idempotent merging mechanism for unsuccessful requests, enabling subsequent requests to reuse the execution results of the unique execution context without repeating the recycling chain; it proposes a stop context and process event linkage mechanism, forming a unified traceable chain for winning determination, merging processing, recycling execution, and exception compensation; and it proposes a unified final state write-back mechanism for concurrent stop scenarios, ensuring that the recycling result, the set of merged requests, and the current state are all unified around the same context.

[0095] Compared with existing technologies, the present invention has at least the following beneficial effects: by uniformly converting multi-source stop requests into arbitration objects and generating source levels, the consistency of request processing in concurrent stop scenarios can be improved; by allowing only one stop request to win on the same target resource object and advance the actual recycling process, the risks of duplicate release and duplicate remote calls can be reduced; by performing idempotent merging on the stop requests that do not win, duplicate retries, state jitter, and log noise can be reduced; by establishing a unified stop context and continuously recording process events, the determinism of subsequent asynchronous callbacks, compensation processing, and audit trails can be improved; by uniformly writing back the final stop state and the merged request set, the conflict of multi-process state coverage can be reduced, and the final closing capability of the resource recycling chain can be enhanced.

[0096] The following describes a device provided by an embodiment of this application. The device described below can be referred to in correspondence with the method described above. The device of this embodiment is installed in an electronic device. Figure 6 , Figure 6This is a structural block diagram of an apparatus according to one embodiment of the present application, comprising: a receiving module 210, configured to receive multiple stop requests for the same target resource object, wherein the multiple stop requests originate from at least two types of stop sources; a first determining module 220, configured to determine the arbitration attributes corresponding to the multiple stop requests; a second determining module 230, configured to establish a unique execution context associated with the target resource object; and after successfully acquiring the arbitration lock associated with the target resource object, to determine the winning stop request from the multiple stop requests based on the arbitration attributes; a recycling module 240, configured to bind the winning stop request to the unique execution context; and execute a resource recycling process for the target resource object corresponding to the winning stop request; and an idempotent merging module 250, configured to perform idempotent merging processing on other stop requests during or after the execution of the resource recycling process, so that other stop requests can reuse the execution results of the unique execution context.

[0097] In one possible implementation, the method further includes: a detection module for detecting whether a unique execution context already exists and is bound to the target resource object; if the detection result indicates that the unique execution context already exists, a marking module is triggered; if the detection result indicates that the unique execution context does not exist, a second determination module 230 is triggered; and a marking module for directly associating multiple stop requests with the existing unique execution context and marking them as pending merging.

[0098] In one possible implementation, the first determining module 220 is used to: perform parameter verification on each received stop request, extract the target resource identifier, request source field and request timestamp from the request, and encapsulate them into a unified arbitration object; Based on the source of the request in the unified arbitration object, a corresponding source level is generated for each stop request; a corresponding idempotency identifier is generated for each stop request, and the target resource identifier, request source, request timestamp, source level, and idempotency identifier are used as the arbitration attributes of each unified arbitration object.

[0099] In one possible implementation, the first determining module 220 is used to: traverse all currently generated unified arbitration objects and extract the source level from each unified arbitration object; sort the source levels in each arbitration object and filter out all candidate arbitration objects with the highest source level values; if the number of selected candidate arbitration objects is 1, then the stop request corresponding to the candidate arbitration object is determined as the winning stop request; if the number of selected candidate arbitration objects is greater than 1, then the stop request corresponding to the candidate arbitration object with the earliest timestamp is determined as the winning stop request.

[0100] In one possible implementation, the first determining module 220 is used to: write the idempotency identifier of the winning stop request into the main execution field of the unique execution context to complete the binding operation; and establish an association between other stop requests and the unique execution context, including: uniformly storing the idempotency identifiers of other stop requests into a merge set within the unique execution context to complete the association binding of all requests.

[0101] In one possible implementation, the system further includes: a resource recycling process monitoring module, which writes a win request confirmation event to the unique execution context when the resource recycling process starts, and records the start time of the current recycling operation; after each key node of the resource recycling process is completed, it writes the execution event of the corresponding node to the unique execution context, and synchronously updates the real-time status of the unique execution context; if an abnormal interruption occurs during the execution of the resource recycling process, an abnormal compensation event is immediately triggered, the abnormal type and breakpoint location are written to the unique execution context, and a preset retry rollback mechanism is started.

[0102] In one possible implementation, the idempotent merging module 250 is used to: determine the stop request classification of other stop requests, the stop request classification including any one of merge requests, result reuse requests, and deferred execution requests; and perform the corresponding idempotent merging process according to the stop request classification during or after the resource reclamation process.

[0103] Figure 7 A structural diagram of an electronic device provided in an embodiment of the present invention, such as... Figure 7 As shown, the electronic device includes: a memory 60 for storing a computer program; and a processor 61 for executing the computer program to implement the steps of the method as described in the above embodiments.

[0104] The electronic devices provided in this embodiment may include, but are not limited to, smartphones, tablets, laptops, or desktop computers.

[0105] The processor 61 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 61 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 61 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 61 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 61 may also include an Artificial Intelligence (AI) processor, which handles computational operations related to machine learning.

[0106] The memory 60 may include one or more computer-readable storage media, which may be non-transitory. The memory 60 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 60 is used to store at least the following computer program 601, which, after being loaded and executed by the processor 61, is capable of implementing the relevant steps of the method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 60 may also include an operating system 602 and data 603, etc., and the storage method may be temporary storage or permanent storage. The operating system 602 may include Windows, Unix, Linux, etc.

[0107] In some embodiments, the electronic device may further include a display screen 62, an input / output interface 63, a communication interface 64, a power supply 65, and a communication bus 66.

[0108] Those skilled in the art will understand that Figure 7 The structures shown do not constitute a limitation on electronic devices and may include more or fewer components than those shown.

[0109] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the current technology, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods in the various embodiments of the present invention. The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, magnetic disks, or optical disks, and other media capable of storing program code.

[0110] Based on this, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the method described above.

[0111] Based on this, embodiments of the present invention also provide a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the above-described method. It should be understood that although the steps in the flowcharts of the accompanying drawings are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying drawings may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0112] The above are only some embodiments of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for processing multi-source stop requests, characterized in that, include: Receive multiple stop requests for the same target resource object, wherein the multiple stop requests originate from at least two types of stop sources; Determine the arbitration attributes corresponding to each of the multiple stop requests; Establish a unique execution context associated with the target resource object; And after successfully acquiring the arbitration lock associated with the target resource object, the winning stop request is determined from the multiple stop requests based on the arbitration attribute; Bind the winning stop request to the unique execution context; Execute the resource reclamation process for the target resource object corresponding to the winning stop request; During or after the resource recycling process is executed, other stop requests are subjected to idempotent merging, enabling them to reuse the execution results of the unique execution context.

2. The method according to claim 1, characterized in that, Before establishing a unique execution context associated with the target resource object, the process also includes: Check whether a unique execution context already exists that is bound to the target resource object; If the detection result indicates that the request already exists, then the multiple stop requests are directly associated with the existing unique execution context and marked as pending merging. If the detection result is that it does not exist, then the step of establishing a unique execution context associated with the target resource object is executed.

3. The method according to claim 1, characterized in that, Determining the arbitration attributes corresponding to the multiple stop requests includes: For each received stop request, perform parameter validation, extract the target resource identifier, request source field and request timestamp from the request, and encapsulate them into a unified arbitration object; Based on the source of the request in the unified arbitration object, a corresponding source level is generated for each stop request; a corresponding idempotency identifier is generated for each stop request, and the target resource identifier, request source, request timestamp, source level, and idempotency identifier are used as the arbitration attributes of each unified arbitration object.

4. The method according to claim 3, characterized in that, Determining the winning stop request from the plurality of stop requests based on arbitration attributes includes: Iterate through all currently generated unified arbitration objects and extract the source level from each unified arbitration object; Sort the source level of each arbitration object and filter out all candidate arbitration objects with the highest source level value; If the number of candidate arbitration objects obtained through screening is 1, then the stop request corresponding to the candidate arbitration object will be determined as the winning stop request; If the number of candidate arbitration objects obtained through screening is greater than 1, then the stop request corresponding to the candidate arbitration object with the earliest timestamp will be determined as the winning stop request.

5. The method according to claim 3, characterized in that, Binding the winning stop request to the unique execution context includes: Write the idempotency flag of the winning stop request into the main execution field of the unique execution context to complete the binding operation; Associating other stop requests with the unique execution context includes: uniformly storing the idempotency identifiers of other stop requests into a merge set within the unique execution context, thus completing the association and binding of all requests.

6. The method according to claim 1, characterized in that, The process of executing the resource reclamation procedure for the target resource object corresponding to the winning stop request also includes: When the resource recycling process starts, a win request confirmation event is written to the unique execution context to record the start time of the current recycling operation; After each key node in the resource recycling process is completed, the execution event of the corresponding node is written to the unique execution context, and the real-time status of the unique execution context is updated synchronously. If an abnormal interruption occurs during the execution of the resource recycling process, an abnormal compensation event is immediately triggered, the abnormal type and breakpoint location are written to the unique execution context, and the preset retry and rollback mechanism is started.

7. The method according to claim 1, characterized in that, During or after the resource reclamation process, idempotent merging is performed on other stop requests to enable them to reuse the execution results of the unique execution context, including: Determine the stop request category for other stop requests. Stop request categories include any one of merge requests, result reuse requests, and deferred execution requests. During or after the resource recycling process is completed, the corresponding idempotent merging process is performed according to the stop request.

8. A multi-source stop request processing apparatus, characterized in that, include: The receiving module is configured to receive multiple stop requests for the same target resource object, wherein the multiple stop requests originate from at least two types of stop sources; The first determining module is used to determine the arbitration attributes corresponding to the plurality of stop requests respectively; The second determining module is used to establish a unique execution context associated with the target resource object; And after successfully acquiring the arbitration lock associated with the target resource object, the winning stop request is determined from the multiple stop requests based on the arbitration attribute; The recycling module is used to bind the winning stop request to the unique execution context; Execute the resource reclamation process for the target resource object corresponding to the winning stop request; The idempotent merge module is used to perform idempotent merge processing on other stop requests during or after the execution of the resource reclamation process, so that the other stop requests can reuse the execution results of the unique execution context.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the method according to any one of claims 1 to 7 when running the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one piece of program code, which is loaded and executed by a processor to implement the method as described in any one of claims 1 to 7.

Images