Asynchronous task two-stage confirmation and resource cooperative release method and device
By introducing a two-stage confirmation mechanism for asynchronous tasks in the context of domestic IT innovation, generating a unique ID and pre-registering resources, and ensuring that resources are released only after the task is completed, the problem of fragmented resource management in asynchronous task processing is solved, improving system reliability and operational efficiency, and adapting to domestic middleware environments.
Patent Information
- Application Number
- CN202610565923.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-04-27
- Publication Date
- 2026-07-10
AI Technical Summary
In high-reliability business systems such as finance and securities, asynchronous task processing solutions lack transaction support, leading to a disconnect between resource management and task execution. This can easily result in the formation of zombie resources, significant overhead from ineffective computation, and high system reliability and maintenance difficulty. In particular, domestic middleware support is weak in the context of information technology innovation.
A two-phase confirmation mechanism for asynchronous tasks is introduced. A unique ID is generated through the domestic IT middleware, task resources are pre-registered and associated, and resources are released after the task is completed, ensuring safe resource reclamation and avoiding resource leakage and inconsistency in state.
Significantly improves system reliability and resource utilization, enhances adaptability to the domestic IT innovation environment, improves operation and maintenance efficiency, ensures centralized management of task status and resource usage information, and facilitates the location and cleanup of zombie tasks.
Smart Images
Figure CN122372630A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of computer technology, and in particular to a method and apparatus for asynchronous task two-stage confirmation and resource collaborative release. Background Technology
[0002] In high-reliability business systems such as finance and securities, asynchronous tasks (such as strategy backtesting and batch valuation) widely rely on message middleware for decoupling and scheduling. Especially in the context of domestic IT innovation, systems are gradually migrating to domestic middleware platforms, such as TongMQ and BESMQ. However, these middleware generally lack transaction support or advanced confirmation mechanisms, making it difficult to directly reuse traditional asynchronous task processing solutions. Existing systems mostly adopt a "single-phase confirmation + manual resource release" model: after the front-end publishes the task message, the consumer pulls the message and executes it immediately. After execution, it sends an ACK and manually releases the occupied database connection, GPU memory, and other resources. The entire process lacks state synchronization and exception handling capabilities.
[0003] Because existing technologies separate task execution and resource management into two independent stages, and rely on developers to ensure resource release in the code, resources are easily left unreclaimed due to process crashes, network interruptions, or abnormal exits, forming "zombie resources" that can lead to problems such as connection pool exhaustion, memory leaks, and cache conflicts. At the same time, there is no pre-allocation or verification mechanism before tasks are consumed, so even if the parameters are invalid or the permissions are insufficient, the engine will still be started to load resources, resulting in invalid computing overhead. In addition, the resource lifecycle is scattered across various modules, without centralized registration and monitoring, making it impossible for operations and maintenance to track the "task-resource" relationship and achieve automated cleanup. Furthermore, the weak support for transaction messages in domestic middleware further exacerbates the reliability risks of the system in the context of domestic IT innovation. Summary of the Invention
[0004] To address the aforementioned technical problems, embodiments of the present invention provide a method for asynchronous task two-phase confirmation and resource collaborative release, comprising: In the context of information technology innovation, the task requests initiated by the front end through the information technology innovation middleware are initially verified for basic messages, and a unique ID is generated. The unique ID is fed back to the front end through the information technology innovation middleware, so that the front end adds the corresponding task to the task queue; Register the task resources required to execute the task, and associate the task resources with the unique ID; Start the task engine, call the task resources to execute the task, and obtain the task execution result; When the task execution ends, a resource release process is triggered to release the task resources corresponding to the unique ID; The aforementioned IT innovation middleware sends a response signal to the front end indicating the completion of task execution.
[0005] In one embodiment, the task request initiated by the front end through the domestic IT innovation middleware undergoes preliminary verification of basic messages to generate a unique ID, including: Perform preliminary verification of permissions, quotas, and parameter validity for task requests initiated by the front end through the domestic IT innovation middleware; If the verification passes, a unique ID for the task is generated.
[0006] In one embodiment, the step of feeding back the unique ID to the front end through the domestic IT innovation middleware, so that the front end adds the corresponding task to the task queue, includes: The unique ID is fed back to the front end through the information technology innovation middleware, so that the front end uses the unique ID as a valid credential to submit the unique ID to the task execution topic, thereby adding the task to the task queue.
[0007] In one embodiment, the task resources required to register and execute the task include: After monitoring the task execution topic and confirming the addition of the unique ID, register the task resources required to execute the task before starting the task engine.
[0008] In one embodiment, associating the task resource with the unique ID includes: Write the resource list of the task resources into a separately configured resource control table; Associate the resource control table with the unique ID, and update the status of the task resource to be occupied.
[0009] In one embodiment, the method further includes: During task execution, obtain task execution progress, task execution log, and exception information; The task middleware pushes the task execution progress, task execution logs, and exception information to the front end.
[0010] In one embodiment, triggering a resource release process to release the task resource corresponding to the unique ID upon completion of the task execution includes: Query the resource control table to determine the task resources; The task resources are released one by one based on a preset strategy; After all the task resources are released, update the status of the task resources to idle and the task status to released.
[0011] In one embodiment, the method further includes: If the release fails, the corresponding alarm event will be recorded; Initiate a compensation retry process to release the unreleased task resources again, while keeping the corresponding task resources in the occupied state until they are released, at which point the status of the task resources is updated to idle.
[0012] In one embodiment, the method further includes: When the front-end or scheduled task detects that a deletion instruction for the task is sent to the task execution Topic, the task process is forcibly terminated and the task resources are immediately released.
[0013] Another embodiment of the present invention provides an asynchronous task two-phase confirmation and resource collaborative release device, comprising: The verification module is used to perform preliminary verification of basic messages in task requests initiated by the front end through the domestic IT innovation middleware in the domestic IT innovation environment, and generate a unique ID; The first feedback module is used to feed back the unique ID to the front end through the information technology innovation middleware, so that the front end can add the corresponding task to the task queue; The registration module is used to register the task resources required to execute the task and associate the task resources with the unique ID; The startup module is used to start the task engine, call the task resources to execute the task, and obtain the task execution result; The release module is used to trigger a resource release process when the task execution ends, so as to release the task resource corresponding to the unique ID; The second feedback module is used to send a response signal indicating the completion of task execution to the front end through the domestic IT innovation middleware.
[0014] Based on the above, it can be seen that the beneficial effects of the solution provided in the embodiments of the present invention include: 1. Significantly improve system reliability: Through a two-stage confirmation mechanism, the system ensures that message confirmation is only completed after the associated resources are successfully released, effectively avoiding message loss, duplicate consumption, or inconsistent state issues caused by process crashes, network interruptions, or middleware anomalies.
[0015] 2. Enhanced adaptability to the domestic IT innovation environment: It does not rely on advanced features such as transactional messaging and delayed ACK of domestic message middleware, and can run based solely on basic message sending and receiving and local persistence.
[0016] 3. Improve resource utilization efficiency: By pre-empting and verifying tasks and allocating resources on demand, we avoid invalid tasks occupying computing resources; 4. Enhance system observability and maintainability: Task status and resource usage information are centrally stored in the task information table and resource control table, supporting real-time query of "which task is using which resources", facilitating quick location of zombie tasks and ghost resources, simplifying operation and improving maintenance efficiency.
[0017] Other features and advantages of this application will be set forth in the following description. The objectives and other advantages of this application can be realized and obtained through the structures particularly pointed out in the written description and drawings.
[0018] The technical solution of this application will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description
[0019] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0020] Figure 1 This is a flowchart illustrating the asynchronous task two-stage confirmation and resource collaborative release method in an embodiment of the present invention.
[0021] Figure 2 This is a flowchart illustrating the asynchronous task two-stage confirmation and resource collaborative release method in an application embodiment of the present invention.
[0022] Figure 3 This is a schematic diagram illustrating the interaction between the asynchronous task two-stage confirmation and resource collaborative release method in an embodiment of the present invention.
[0023] Figure 4 This is a structural block diagram of the asynchronous task two-stage confirmation and resource collaborative release device in an embodiment of the present invention. Detailed Implementation
[0024] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings, but these are not intended to limit the scope of the invention.
[0025] It should be understood that various modifications can be made to the embodiments disclosed herein. Therefore, the following description should not be considered as limiting, but merely as an example of embodiments. Other modifications within the scope of this disclosure will be apparent to those skilled in the art.
[0026] The accompanying drawings, which are included in and form part of this specification, illustrate embodiments of the present disclosure and, together with the general description of the disclosure given above and the detailed description of the embodiments given below, serve to explain the principles of the disclosure.
[0027] These and other features of the invention will become apparent from the following description of preferred forms of embodiments given as non-limiting examples, with reference to the accompanying drawings.
[0028] It should also be understood that although the invention has been described with reference to some specific examples, those skilled in the art can certainly implement many other equivalent forms of the invention, which have the features described in the claims and are therefore all within the scope of protection defined herein.
[0029] The above and other aspects, features and advantages of this disclosure will become more apparent when taken in conjunction with the accompanying drawings and in view of the following detailed description.
[0030] Specific embodiments of the present disclosure are described thereafter with reference to the accompanying drawings; however, it should be understood that the disclosed embodiments are merely examples of the present disclosure and can be implemented in various ways. Well-known and / or repeated functions and structures are not described in detail to avoid unnecessary or redundant details that could obscure the present disclosure. Therefore, the specific structural and functional details disclosed herein are not intended to be limiting, but merely to serve as the basis and representative basis for the claims to teach those skilled in the art to use the present disclosure in a variety of substantially any suitable detailed structures.
[0031] This specification may use the phrases “in one embodiment,” “in another embodiment,” “in yet another embodiment,” or “in still another embodiment,” all of which may refer to one or more of the same or different embodiments according to this disclosure.
[0032] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.
[0033] like Figure 1 As shown, this embodiment of the invention provides a method for asynchronous task two-phase confirmation and resource collaborative release, including: S1: In the context of information technology innovation, perform preliminary verification of basic messages on task requests initiated by the front end through information technology innovation middleware, and generate a unique ID; S2: The unique ID is fed back to the front end through the information technology innovation middleware, so that the front end adds the corresponding task to the task queue; S3: Register the task resources required to execute the task, and associate the task resources with the unique ID; S4: Start the task engine, call the task resources to execute the task, and obtain the task execution result; S5: When the task execution ends, trigger the resource release process to release the task resources corresponding to the unique ID; S6: Feedback a response signal indicating the completion of task execution to the front end through the aforementioned IT innovation middleware.
[0034] Based on the above, this embodiment provides an asynchronous task processing method suitable for domestically developed message middleware, which solves problems such as resource leakage, inconsistent states, and duplicate execution caused by asynchronous task execution and resource release. The method described in this embodiment introduces a two-phase confirmation mechanism and resource collaborative management to ensure that tasks are only confirmed after the associated resources are safely released, thus improving system reliability, resource utilization, and operational observability, and is particularly suitable for domestically developed middleware environments.
[0035] The method in this embodiment is applied to a system consisting of a front-end, a domestically developed middleware, and a common module. The following description focuses on the common module and elaborates on the specific solution.
[0036] In one embodiment, the task request initiated by the front end through the domestic IT innovation middleware undergoes preliminary verification of basic messages to generate a unique ID, including: S101: Perform preliminary verification of the permissions, quotas, and parameter validity of task requests initiated by the front end through the domestic IT innovation middleware; S102: If the verification passes, a unique ID for the task is generated.
[0037] like Figure 2 and Figure 3 As shown, in this embodiment, when the front-end initiates a task through the domestic IT innovation middleware, it only sends the basic request parameters of the task to the public module through the middleware. After receiving the task request, the public module performs preliminary verification of permissions, quotas, and parameter validity based on the obtained basic request parameters. After the verification is passed, it generates a unique ID for the task, such as a unique taskId.
[0038] Furthermore, the step of feeding back the unique ID to the front end through the domestic IT innovation middleware, so that the front end adds the corresponding task to the task queue, includes: S201: The unique ID is fed back to the front end through the information technology innovation middleware, so that the front end uses the unique ID as a valid credential to submit the unique ID to the task execution Topic, thereby adding the task to the task queue.
[0039] For example, the public module persists the generated unique taskId to the task information table and configures the initial state of the task to "inactive," while returning this unique taskId to the frontend. At this point, the public module does not allocate any computing resources to the task, nor does it submit the task to the task execution queue in the system; it only performs "logical locking" to prevent the duplicate creation of task information. After obtaining the unique taskId through the domestic middleware, the frontend submits it as a valid credential to the task execution Topic to trigger the next stage of the process. This process essentially constitutes the first stage of task confirmation, ensuring that only legitimate tasks enter the execution process.
[0040] Continue to combine Figure 2 As shown, the task resources required for registering and executing the task include: S301: Listen to the task execution Topic, and after determining that the unique ID has been added, register the task resources required to execute the task before starting the task engine.
[0041] In this embodiment, the public module continuously listens to the task execution topic. After determining that the task execution topic has received a unique taskId, it registers all the task resources required for the task before starting the task engine to execute the task. That is, it first determines all the task resources required to execute the task, and then registers the task resources to generate a resource list.
[0042] Furthermore, associating the task resource with the unique ID includes: S302: Write the resource list of the task resources into the independently configured resource control table; S303: Associate the resource control table with the unique ID, and update the status of the task resource to occupied.
[0043] In other words, the public module writes the resource list of the task into a separate "resource control table" and strongly associates this resource control table with a unique taskId. After the association is completed, the public module marks the status of the task resources associated with the task as "occupied". This resource control table can be an independently set parameter table that matches the task, meaning each task has its own corresponding resource control table, or multiple tasks can share a single resource control table, or different resources can have different resource control tables; the specific configuration is not unique.
[0044] Based on the above steps, an explicit mapping of "task-resource" was established, laying the data foundation for subsequent collaborative release of task resources.
[0045] In one embodiment, the method further includes: S7: During task execution, obtain task execution progress, task execution log, and exception information; S8: Push the task execution progress, task execution log and exception information to the front end through the task middleware.
[0046] Specifically, after resource registration is complete, the public module will launch the background task engine to execute tasks, i.e., perform actual business logic, such as strategy backtesting and model inference. Different tasks correspond to different business logic. During execution, the public module will obtain task execution progress, task execution logs, and exception information in real time, as well as other data information, which is not unique. After obtaining this data, the public module will push it to the front end through the domestic IT innovation middleware, and the front end will display it to the user for viewing.
[0047] Furthermore, the step of triggering a resource release process upon completion of the task execution to release the task resources corresponding to the unique ID includes: S501: Query the resource control table to determine the task resources; S502: Release the task resources one by one based on a preset strategy; S503: After all the task resources are released, update the status of the task resources to idle and the task status to released.
[0048] For example, by monitoring, the public module determines that after the task is completed, regardless of whether the task is successful or not, the public module will generate a notification message containing a unique taskId and the completion of the task, such as a notification message containing a unique taskId and success / fail. Then, the notification message is pushed to the front end through the domestic middleware and the task status in the task information table is updated to "completed".
[0049] Afterwards, the public module does not immediately send an ACK message to the front end, indicating the end of the task. Instead, it triggers a resource release process. This process includes querying the "resource control table" corresponding to the task, such as by searching based on a unique taskId, and determining all task resources corresponding to that task based on the information recorded in the resource control table. At this point, the public module will release the task resources item by item according to a predefined strategy, such as closing connections, returning the GPU, and cleaning up temporary files. The specific release operations performed are not unique and can be flexibly varied depending on the actual task content.
[0050] After all task resources are successfully released, the public module will update the task's resource-free status to "idle," and the corresponding task status to "released." Only after completing this process will the public module send a final ACK to the IT innovation middleware, so that the middleware can feed back the ACK information to the front end and notify the user.
[0051] Furthermore, the method also includes: S504: If the release fails, record the corresponding alarm event; S505: Initiate a compensation retry process to release the unreleased task resources again, while keeping the corresponding task resources in the occupied state until they are released, and then updating the task resources to be idle.
[0052] In other words, if not all task resources are successfully released, a corresponding alarm event is generated, and the alarm event information is pushed to the front end through the domestic IT middleware to notify the user. At the same time, the public module can automatically start compensation retry, that is, re-release all unreleased task resources without sending an ACK message to ensure reentrant processing, until all tasks are successfully released, and then an ACK message is sent.
[0053] By using the above method and process, the ACK action can be delayed until after the resource is released, thus forming a second-stage confirmation, and truly realizing the task processing flow of "task completion + resource reclamation = message termination".
[0054] In one embodiment, the public module is also configured with a fallback mechanism; for example, the method further includes: S9: When it is detected that the front-end or scheduled task sends a deletion instruction about the task to the task execution Topic, the task process of the task is forcibly terminated and the task resources are released immediately.
[0055] Specifically, the public module supports the frontend or scheduled tasks sending a "delete" command to the task execution topic. This command must include a unique taskId to identify the task. Upon receiving the deletion command, the public module responds by forcibly terminating the corresponding task process and immediately executing a resource release procedure, even if the task has not yet finished naturally. Simultaneously, the public module sets a TTL (Time To Live) for both the task resource pre-emption phase and the task execution phase, for example, but not limited to 30 seconds. If no progress is made within these 30 seconds, task resources are automatically released to prevent prolonged resource locking due to frontend disconnection.
[0056] Based on the disclosed content of the above embodiments, the implementation idea of this application is to construct an asynchronous task two-stage confirmation and resource collaborative release mechanism suitable for domestic IT message middleware. First, after the frontend initiates a task request, the public module performs a validity check and generates a unique task ID (taskId), but does not allocate resources immediately, only returning the taskId as the first-stage confirmation; only after receiving it does the frontend submit the taskId to the execution queue, ensuring that only valid tasks enter the execution process. Subsequently, before starting the task, the public module pre-registers all resources required by the task and writes them into the resource control table, establishing a strong binding relationship between the task and resources. After the task is completed, the system does not immediately send an ACK to the message middleware, but first triggers the resource collaborative release process. Only after all associated resources are safely reclaimed is the final ACK completed, constituting the second-stage confirmation. Simultaneously, the system supports active deregistration and timeout circuit breaker mechanisms, which can forcibly terminate abnormal tasks and release resources. The entire solution does not rely on middleware transaction features, achieving a highly reliable closed loop only through local persistence, state machines, and message callbacks, significantly improving resource utilization and system stability.
[0057] Based on the above, it can be seen that the asynchronous task two-phase confirmation and resource collaborative release method provided in this embodiment has the following beneficial effects: Significantly improves system reliability: Through a two-stage confirmation mechanism, it ensures that the message confirmation is completed only after the associated resources are successfully released, effectively avoiding message loss, duplicate consumption or inconsistent state caused by process crashes, network interruptions or middleware anomalies.
[0058] Enhanced adaptability to the domestic IT innovation environment: It does not rely on advanced features such as transactional messaging and delayed ACK of domestic message middleware, and can run based solely on basic message sending and receiving and local persistence.
[0059] Improve resource utilization efficiency: Avoid invalid tasks occupying computing resources by checking task pre-occupancy and allocating resources on demand; Enhanced system observability and maintainability: Task status and resource usage information are centrally stored in the task information table and resource control table, supporting real-time query of "which task is using which resources", facilitating quick location of zombie tasks and ghost resources, simple operation, and high maintenance efficiency.
[0060] like Figure 4 As shown, another embodiment of the present invention simultaneously provides an asynchronous task two-stage confirmation and resource collaborative release device, comprising: The verification module is used to perform preliminary verification of basic messages in task requests initiated by the front end through the domestic IT innovation middleware in the domestic IT innovation environment, and generate a unique ID; The first feedback module is used to feed back the unique ID to the front end through the information technology innovation middleware, so that the front end can add the corresponding task to the task queue; The registration module is used to register the task resources required to execute the task and associate the task resources with the unique ID; The first startup module is used to start the task engine, call the task resources to execute the task, and obtain the task execution result; The release module is used to trigger a resource release process when the task execution ends, so as to release the task resource corresponding to the unique ID; The second feedback module is used to send a response signal indicating the completion of task execution to the front end through the domestic IT innovation middleware.
[0061] In one embodiment, the task request initiated by the front end through the domestic IT innovation middleware undergoes preliminary verification of basic messages to generate a unique ID, including: Perform preliminary verification of permissions, quotas, and parameter validity for task requests initiated by the front end through the domestic IT innovation middleware; If the verification passes, a unique ID for the task is generated.
[0062] In one embodiment, the step of feeding back the unique ID to the front end through the domestic IT innovation middleware, so that the front end adds the corresponding task to the task queue, includes: The unique ID is fed back to the front end through the information technology innovation middleware, so that the front end uses the unique ID as a valid credential to submit the unique ID to the task execution topic, thereby adding the task to the task queue.
[0063] In one embodiment, the task resources required to register and execute the task include: After monitoring the task execution topic and confirming the addition of the unique ID, register the task resources required to execute the task before starting the task engine.
[0064] In one embodiment, associating the task resource with the unique ID includes: Write the resource list of the task resources into a separately configured resource control table; Associate the resource control table with the unique ID, and update the status of the task resource to be occupied.
[0065] In one embodiment, the device further includes: The acquisition module is used to obtain task execution progress, task execution logs, and exception information during task execution. The push module is used to push the task execution progress, task execution logs and exception information to the front end through the task middleware.
[0066] In one embodiment, triggering a resource release process to release the task resource corresponding to the unique ID upon completion of the task execution includes: Query the resource control table to determine the task resources; The task resources are released one by one based on a preset strategy; After all the task resources are released, update the status of the task resources to idle and the task status to released.
[0067] In one embodiment, the device further includes: The logging module is used to record the corresponding alarm event when the release fails; The second startup module is used to initiate a compensation retry process to release the unreleased task resources again, while keeping the corresponding task resources in the occupied state until they are released, at which point the status of the task resources is updated to be idle.
[0068] In one embodiment, the device further includes: The termination module is used to forcibly terminate the task process and immediately release the task resources when it detects that the front-end or scheduled task sends a deletion instruction about the task to the task execution Topic.
[0069] Another embodiment of the present invention also provides an electronic device, comprising: One or more processors; Memory, configured to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the asynchronous task two-phase confirmation and resource collaborative release method as described above.
[0070] Furthermore, one embodiment of the present invention also provides a storage medium storing a computer program, which, when executed by a processor, implements the asynchronous task two-phase confirmation and resource collaborative release method described above. It should be understood that the various solutions in this embodiment have the corresponding technical effects in the above-described method embodiments, and will not be repeated here.
[0071] Furthermore, embodiments of the present invention also provide a computer program product, which is tangibly stored on a computer-readable medium and includes computer-readable instructions, which, when executed, cause at least one processor to perform an asynchronous task two-phase confirmation and resource cooperative release method such as the embodiment described above.
[0072] It should be noted that the computer storage medium of the present invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, system, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access storage medium (RAM), a read-only storage medium (ROM), an erasable programmable read-only storage medium (EPROM or flash memory), an optical fiber, a portable compact disk read-only storage medium (CD-ROM), an optical storage medium, a magnetic storage medium, or any suitable combination thereof. In the present invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. In the present invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program configured for use by or in connection with an instruction execution system, system, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, antenna, optical fiber, RF, etc., or any suitable combination thereof.
[0073] Furthermore, those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.
[0074] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1One or more processes and / or boxes Figure 1 A system that specifies functions in one or more boxes.
[0075] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including an instruction set implemented in a process. Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0076] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of protection of this application is limited to these examples; within the framework of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of one or more embodiments of this application as described above, which are not provided in detail for the sake of brevity.
Claims
1. A method for asynchronous task two-phase confirmation and resource collaborative release, characterized in that, include: In the context of information technology innovation, the task requests initiated by the front end through the information technology innovation middleware are initially verified for basic messages, and a unique ID is generated. The unique ID is fed back to the front end through the information technology innovation middleware, so that the front end adds the corresponding task to the task queue; Register the task resources required to execute the task, and associate the task resources with the unique ID; Start the task engine, call the task resources to execute the task, and obtain the task execution result; When the task execution ends, a resource release process is triggered to release the task resources corresponding to the unique ID; The aforementioned IT innovation middleware sends a response signal to the front end indicating the completion of task execution.
2. The asynchronous task two-phase confirmation and resource collaborative release method according to claim 1, characterized in that, Perform preliminary verification of basic messages on task requests initiated by the frontend through the domestic IT innovation middleware, and generate a unique ID, including: Perform preliminary verification of permissions, quotas, and parameter validity for task requests initiated by the front end through the domestic IT innovation middleware; If the verification passes, a unique ID for the task is generated.
3. The asynchronous task two-phase confirmation and resource collaborative release method according to claim 1, characterized in that, The step of feeding back the unique ID to the front end through the domestic IT innovation middleware, so that the front end adds the corresponding task to the task queue, includes: The unique ID is fed back to the front end through the information technology innovation middleware, so that the front end uses the unique ID as a valid credential to submit the unique ID to the task execution topic, thereby adding the task to the task queue.
4. The asynchronous task two-phase confirmation and resource collaborative release method according to claim 3, characterized in that, The task resources required to perform the task are registered, including: After monitoring the task execution topic and confirming the addition of the unique ID, register the task resources required to execute the task before starting the task engine.
5. The asynchronous task two-phase confirmation and resource collaborative release method according to claim 3, characterized in that, Associating the task resource with the unique ID includes: Write the resource list of the task resources into a separately configured resource control table; Associate the resource control table with the unique ID, and update the status of the task resource to be occupied.
6. The asynchronous task two-phase confirmation and resource collaborative release method according to claim 1, characterized in that, The method further includes: During task execution, obtain task execution progress, task execution log, and exception information; The task middleware pushes the task execution progress, task execution logs, and exception information to the front end.
7. The asynchronous task two-phase confirmation and resource collaborative release method according to claim 5, characterized in that, When the task execution ends, a resource release process is triggered to release the task resources corresponding to the unique ID, including: Query the resource control table to determine the task resources; The task resources are released one by one based on a preset strategy; After all the task resources are released, update the status of the task resources to idle and the task status to released.
8. The asynchronous task two-phase confirmation and resource collaborative release method according to claim 7, characterized in that, The method further includes: If the release fails, the corresponding alarm event will be recorded; Initiate a compensation retry process to release the unreleased task resources again, while keeping the corresponding task resources in the occupied state until they are released, at which point the status of the task resources is updated to idle.
9. The asynchronous task two-phase confirmation and resource collaborative release method according to claim 3, characterized in that, The method further includes: When the front-end or scheduled task detects that a deletion instruction for the task is sent to the task execution Topic, the task process is forcibly terminated and the task resources are immediately released.
10. An asynchronous task two-stage confirmation and resource collaborative release device, characterized in that, include: The verification module is used to perform preliminary verification of basic messages in task requests initiated by the front end through the domestic IT innovation middleware in the domestic IT innovation environment, and generate a unique ID; The first feedback module is used to feed back the unique ID to the front end through the information technology innovation middleware, so that the front end can add the corresponding task to the task queue; The registration module is used to register the task resources required to execute the task and associate the task resources with the unique ID; The first startup module is used to start the task engine, call the task resources to execute the task, and obtain the task execution result; The release module is used to trigger a resource release process when the task execution ends, so as to release the task resource corresponding to the unique ID; The second feedback module is used to send a response signal indicating the completion of task execution to the front end through the domestic IT innovation middleware.