Distributed task processing method, apparatus, device, and computer-readable storage medium

Abstract

The application provides a distributed task processing method, device and equipment and a computer readable storage medium. The method comprises the following steps: receiving a second to-be-processed task of a second system sent by a first system, wherein the second to-be-processed task comprises a preset task identifier, and the preset task identifier is an identifier of all to-be-processed task information in all systems; generating task index data corresponding to the second to-be-processed task according to the second to-be-processed task, and sending the task index data to the first system; receiving the task index data sent by the first system after successfully executing a local transaction; and calling the second system to execute the second to-be-processed task according to the task index data. Thus, resource locking for a long time can be avoided, and single-point failure can be avoided.

Description

Technical Field

[0001] The present invention relates to the field of data processing, and in particular to a distributed task processing method, apparatus, device, and computer-readable storage medium. Background Art

[0002] With the rapid development of the internet, network application traffic is increasing, and business logic is becoming increasingly complex. Single systems are no longer sufficient to meet the needs of business development, and distributed systems are becoming increasingly popular. Consequently, the demand for cross-system transaction consistency is increasing.

[0003] Currently, distributed transactions are primarily implemented using a two-phase commit scheme, with the first phase being the prepare phase and the second being the commit phase. Two-phase commit typically involves two types of nodes: the coordinator, typically only one in a system; and the transaction participants (cohorts or workers), typically multiple. Specifically, the coordinator node queries all participant nodes for a commit operation (vote) and waits for responses from each participant node. The participant node executes all transaction operations up to the query initiation and writes undo and redo information to the log. Each participant node responds to the coordinator's query. If the participant node's transaction operation is successful, it returns an "approval" message; if it fails, it returns an "abort" message. If the coordinator receives a failure message or a timeout from a participant, it directly sends a rollback message to each participant; otherwise, it sends a commit message. The participants execute the commit or rollback operation according to the coordinator's instructions, releasing all locks used during the transaction.

[0004] However, when using the above commit scheme for distributed transaction processing, all participating nodes are in a transaction-blocking state during execution. When participants occupy common resources, other third-party nodes are forced to be blocked from accessing them. Furthermore, due to the importance of the coordinator, if the coordinator fails, participants will remain blocked. This is especially true during the second phase, where a coordinator failure would leave all participants locked in the transaction resources, preventing them from completing the transaction. Summary of the Invention

[0005] The present invention provides a distributed task processing method, apparatus, device and computer-readable storage medium, which are used to solve the technical problem in existing distributed transaction processing methods that third-party nodes have to be in a blocked state when accessing public resources due to participants occupying public resources.

[0006] A first aspect of the present invention is to provide a distributed task processing method, comprising:

[0007] receiving a second to-be-processed task of a second system sent by the first system, wherein the second to-be-processed task includes a preset task identifier, and the preset task identifier is an identifier of all to-be-processed task information in all current systems;

[0008] generating task index data corresponding to the second task to be processed according to the second task to be processed, and sending the task index data to the first system;

[0009] receiving the task index data sent by the first system after successfully executing a local transaction;

[0010] The second system is called according to the task index data to execute the second task to be processed.

[0011] Another aspect of the present invention is to provide a distributed task processing apparatus, comprising:

[0012] A first receiving module is configured to receive a second to-be-processed task of a second system sent by the first system, wherein the second to-be-processed task includes a preset task identifier, and the preset task identifier is an identifier of all to-be-processed task information in all current systems;

[0013] a generating module, configured to generate task index data corresponding to the second task to be processed according to the second task to be processed, and send the task index data to the first system;

[0014] A second receiving module is configured to receive the task index data sent by the first system after successfully executing a local transaction;

[0015] A calling module is used to call the second system to execute the second task to be processed according to the task index data.

[0016] Another aspect of the present invention is to provide a distributed task processing device, comprising: a memory, a processor;

[0017] Memory; a memory for storing instructions executable by the processor;

[0018] The processor is configured to execute the above-mentioned distributed task processing method.

[0019] Another aspect of the present invention is to provide a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, they are used to implement the distributed task processing method as described above.

[0020] The distributed task processing method, apparatus, device, and computer-readable storage medium provided by the present invention receive a second pending task from a second system sent by a first system, the second pending task including a preset task identifier, which identifies all pending task information in all current systems; generate task index data corresponding to the second pending task based on the second pending task, and send the task index data to the first system; receive the task index data sent by the first system after successfully executing a local transaction; and invoke the second system to execute the second pending task based on the task index data. This avoids locking resources for extended periods and single points of failure. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0022] Figure 1 A schematic diagram of the network architecture based on which the present invention is based;

[0023] Figure 2 A schematic diagram of the process of a distributed task processing method provided in the first embodiment of the present invention;

[0024] Figure 3 A schematic diagram of the process of a distributed task processing method provided in the second embodiment of the present invention;

[0025] Figure 4 A schematic diagram of the process flow of a distributed task processing method provided in the third embodiment of the present invention;

[0026] Figure 5 A schematic diagram of the process flow of a distributed task processing method provided in the fourth embodiment of the present invention;

[0027] Figure 6 A flowchart of a distributed task processing method according to a fifth embodiment of the present invention;

[0028] Figure 7 A flowchart of a distributed task processing method according to a sixth embodiment of the present invention;

[0029] Figure 8 A schematic diagram of the structure of a distributed task processing device provided in Example 7 of the present invention;

[0030] Figure 9 This is a structural diagram of a distributed task processing device provided in Example 8 of the present invention. DETAILED DESCRIPTION

[0031] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions of the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained based on the embodiments of the present invention fall within the scope of protection of the present invention.

[0032] Currently, distributed transactions are primarily implemented using a two-phase commit scheme, with the first phase being the prepare phase and the second being the commit phase. Two-phase commit typically involves two types of nodes: the coordinator, typically only one in a system; and the transaction participants (cohorts or workers), typically multiple. Specifically, the coordinator node queries all participant nodes for a commit operation (vote) and waits for responses from each participant node. The participant node executes all transaction operations up to the query initiation and writes undo and redo information to the log. Each participant node responds to the coordinator's query. If the participant node's transaction operation is successful, it returns an "approval" message; if it fails, it returns an "abort" message. If the coordinator receives a failure message or a timeout from a participant, it directly sends a rollback message to each participant; otherwise, it sends a commit message. The participants execute the commit or rollback operation according to the coordinator's instructions, releasing all locks used during the transaction. However, when using the above commit scheme for distributed transaction processing, all participating nodes are in a transaction-blocking state during execution. When participants occupy common resources, other third-party nodes are forced to be blocked from accessing them. Furthermore, due to the importance of the coordinator, if the coordinator fails, participants will remain blocked. This is especially true during the second phase, where a coordinator failure would leave all participants locked in the transaction resources, preventing them from completing the transaction.

[0033] To address the above technical issues, the present invention provides a distributed task processing method, apparatus, device, and computer-readable storage medium. The distributed task processing method, apparatus, device, and computer-readable storage medium provided by the present invention can be applied to any distributed database task processing scenario to avoid long-term resource locking and single point failure.

[0034] Figure 1 This is a schematic diagram of the network architecture based on which the present invention is based. Figure 1As shown, the network architecture based on the present invention includes at least: an asynchronous task processing system 1, a first system 2, and a second system 3. The asynchronous task system 1 can be implemented in software and / or hardware. The asynchronous task system 1 communicates and exchanges information with the first system 2 and the second system 3 respectively via wired or wireless means. The first system 2 and the second system 2 can exchange information through the asynchronous task system. It should be noted that the distributed system includes but is not limited to two systems.

[0035] Figure 2 A flow chart of a distributed task processing method provided in the first embodiment of the present invention is shown as follows: Figure 2 As shown, the method includes:

[0036] Step 101: Receive a second to-be-processed task of a second system sent by a first system, wherein the second to-be-processed task includes a preset task identifier, which is an identifier of all to-be-processed task information in all current systems.

[0037] The execution subject of this embodiment is an asynchronous task system, which stores task metadata, task body data, and task index data. The task index data includes the storage path of the task metadata, the task metadata records information such as the task status and the target service of the task, and the task body data includes all data required to execute the task. The first system includes a first pending task, and the second system includes a second pending task. It should be noted that the first system can independently complete the first pending task. Furthermore, the first system can also interact with the second system to obtain all currently pending tasks, name all pending tasks according to a preset naming rule, and generate a task identifier. It is understood that after the first system names all pending tasks, all currently pending tasks in all systems will include the task identifier. Furthermore, the first system can also send the second currently pending task in the second system to the asynchronous task system. Accordingly, the asynchronous task system can receive the second currently pending task in the second system sent by the first system, wherein the second pending task includes a task identifier, and the task identifier is the identifier of all currently pending tasks in all systems.

[0038] Step 102: Generate task index data corresponding to the second task to be processed according to the second task to be processed, and send the task index data to the first system.

[0039] In this embodiment, after receiving the second pending task, the asynchronous task system can generate task index data based on the second pending task, wherein the task index data includes the storage path of the task metadata for processing the second pending task. After generating the task index data, the asynchronous task system can send the task index data to the first system.

[0040] Step 103: Receive the task index data sent by the first system after successfully executing the local transaction.

[0041] In this embodiment, after the first system receives the task index data, it can start a local transaction and execute the local transaction. It is understandable that the first pending task in the first system and the second pending task in the second system need to be processed successfully at the same time or fail at the same time. Therefore, after successfully executing the local transaction, the first system can return the task index data to the asynchronous task system. Accordingly, the asynchronous task system can receive the task index data.

[0042] Step 104: Call the second system to execute the second to-be-processed task according to the task index data.

[0043] In this embodiment, after the asynchronous task system receives the task index data, it can process the second pending task by scanning the task index data. Specifically, the asynchronous task system can call the second system to process the pending task based on the task index data. It should be noted that there may be multiple task index data at the same time in the asynchronous task system. Therefore, the asynchronous task system can process the second pending task in sequence according to the upload time of the task index data.

[0044] The distributed task processing method provided in this embodiment receives a second pending task from a second system sent by a first system, the second pending task including a preset task identifier, which identifies all pending task information in all current systems; generates task index data corresponding to the second pending task based on the second pending task, and sends the task index data to the first system; receives the task index data sent by the first system after successfully executing a local transaction; and invokes the second system to execute the second pending task based on the task index data. This method avoids locking resources for extended periods and prevents single points of failure.

[0045] It should be noted that, based on any of the above embodiments, the preset transaction identifier is generated according to a preset numbering rule after the first system determines all pending tasks in all current systems.

[0046] In this embodiment, the first system can interact with the second system to obtain all currently pending tasks, and name all pending tasks according to a preset naming rule to generate a task identifier. It is understandable that after the first system names all pending tasks, all currently pending tasks in all systems include the task identifier. It is understandable that the first pending task in the first system and the second pending task in the second system need to be processed successfully or failed to be processed at the same time. Since the current first pending task and the second pending task have the same task identifier, it is possible to easily determine whether the current first pending task and the second pending task are processed successfully or failed to be processed at the same time.

[0047] The distributed task processing method provided in this embodiment is generated according to a preset numbering rule after the first system determines all pending tasks in all current systems through a preset transaction identifier, thereby facilitating the management of all pending tasks in all current systems.

[0048] Figure 3 The flowchart of the distributed task processing method provided in the second embodiment of the present invention is based on any of the above embodiments. Figure 3 As shown, the method includes:

[0049] Step 201: Receive a second pending task of a second system sent by a first system, wherein the second pending task includes a preset task identifier, which is an identifier of all pending task information in all current systems;

[0050] Step 202: Generate task index data corresponding to the second task to be processed according to the second task to be processed, and send the task index data to the first system;

[0051] Step 203: Receive the task index data sent by the first system after successfully executing the first task to be processed in the first system and writing the transaction identifier into a local database corresponding to the first system;

[0052] Step 204: Call the second system to execute the second to-be-processed task according to the task index data.

[0053] In this embodiment, after the first system receives the task index data, it can start a local transaction and execute the local transaction. Specifically, the local transaction is for the first system to process the first pending task and upload the generated task identifier to the local database of the first system. It can be understood that the first pending task in the first system and the second pending task in the second system need to be processed successfully at the same time or fail at the same time, and the local transactions in the first system also need to succeed or fail at the same time. Therefore, it is necessary to send the task index data to the asynchronous task system after the first system successfully processes the first pending task and uploads the generated task identifier to the local database of the first system. Accordingly, the asynchronous task system can receive the task index data.

[0054] It should be noted that after the asynchronous task system receives the task index data, it indicates that the first pending task in the first system has been successfully executed. Since the first pending task and the second pending task in the second system need to be processed successfully or fail at the same time, the second pending task must be processed successfully.

[0055] The distributed task processing method provided in this embodiment receives the task index data sent by the first system after successfully executing the first task to be processed in the first system and writing the transaction identifier into the local database corresponding to the first system, thereby ensuring that the first task to be processed and the second task to be processed in the second system are processed successfully or failed to be processed at the same time, ensuring the synchronization of asynchronous task system processing, and thus avoiding long-term resource locking and single point failure.

[0056] Figure 4 The flowchart of the distributed task processing method provided in the third embodiment of the present invention is based on any of the above embodiments. Figure 4 As shown, the task index data includes a storage path for processing task metadata corresponding to the second task to be processed; the method includes:

[0057] Step 301: Receive a second pending task of a second system sent by a first system, wherein the second pending task includes a preset task identifier, which is an identifier of all pending task information in all current systems;

[0058] Step 302: Generate task index data corresponding to the second task to be processed according to the second task to be processed, and send the task index data to the first system;

[0059] Step 303: Receive the task index data sent by the first system after successfully executing the local transaction;

[0060] Step 304: Scan the task index data to obtain task metadata corresponding to the processing of the second task to be processed;

[0061] Step 305: Call the second system to execute the second to-be-processed task according to the task metadata.

[0062] In this embodiment, after the asynchronous task system receives the task index data, it can process the second pending task by scanning the task index data. The asynchronous task system can call the second system to process the pending task based on the task index data. It should be noted that since the task index data includes the storage path of the task metadata, the asynchronous task system can scan the task index data, obtain the task metadata corresponding to the second pending task based on the storage path of the task metadata in the task index data, and process the second pending task based on the task metadata.

[0063] The distributed task processing method provided in this embodiment obtains the task metadata corresponding to the processing of the second task to be processed by scanning the task index data, and calls the second system to execute the second task to be processed according to the task metadata, thereby improving the efficiency of asynchronous task processing, avoiding long-term resource locking, and avoiding single point failure.

[0064] Figure 5 The flowchart of the distributed task processing method provided in the fourth embodiment of the present invention is based on any of the above embodiments. Figure 5 As shown, the method includes:

[0065] Step 401: Receive a second pending task of a second system sent by a first system, wherein the second pending task includes a preset task identifier, which is an identifier of all pending task information in all current systems;

[0066] Step 402: Generate task index data corresponding to the second task to be processed according to the second task to be processed, and send the task index data to the first system;

[0067] Step 403: Receive the task index data sent by the first system after successfully executing the local transaction;

[0068] Step 404: Call the second system to execute the second pending task according to the task index data;

[0069] Step 405: Determine whether the second pending task is successfully executed;

[0070] Step 406: If yes, then update the task status recorded in the task metadata of the second task to be processed;

[0071] Step 407: If not, re-call the second system to execute the second pending task.

[0072] In this embodiment, after the asynchronous task system receives the task index data, it indicates that the first pending task has been successfully executed in the first system. Since the first pending task and the second pending task in the second system need to be successfully processed or failed to be processed at the same time, the second pending task must be successfully processed. Specifically, after calling the second system to execute the second pending task according to the task index data, it is necessary to determine whether the second pending task is successfully processed. If it is successfully processed, the task status in the task metadata can be updated. If it fails, in order to ensure that it is successfully processed or failed to be processed at the same time as the first pending task, it is necessary to call the second system again to execute the second pending task.

[0073] The distributed task processing method provided in this embodiment determines whether the second pending task is executed successfully. If so, the task status recorded in the task metadata of the second pending task is updated. If not, the second system is re-called to execute the second pending task. This ensures that the first pending task and the second pending task in the second system are processed successfully or fail to be processed at the same time, ensuring the synchronization of asynchronous task system processing, thereby avoiding long-term resource locking and single point failure.

[0074] Furthermore, based on any of the above embodiments, the method includes:

[0075] receiving a second to-be-processed task of a second system sent by the first system, wherein the second to-be-processed task includes a preset task identifier, and the preset task identifier is an identifier of all to-be-processed task information in all current systems;

[0076] generating task index data corresponding to the second task to be processed according to the second task to be processed, and sending the task index data to the first system;

[0077] receiving the task index data sent by the first system after successfully executing a local transaction;

[0078] calling the second system to execute the second to-be-processed task according to the task index data;

[0079] Determining whether the second pending task is executed successfully;

[0080] If yes, then updating the task status recorded in the task metadata of the second task to be processed;

[0081] If not, re-calling the second system to execute the second pending task;

[0082] Determining whether the number of execution failures of the second pending task exceeds a preset threshold;

[0083] If yes, prompt the user to manually process the second pending task;

[0084] If not, return to the step of re-calling the second system to execute the second task to be processed.

[0085] In this embodiment, after the asynchronous task system receives the task index data, it indicates that the first pending task has been successfully executed in the first system. Since the first pending task and the second pending task in the second system need to be processed successfully or failed at the same time, the second pending task must be processed successfully. Specifically, after calling the second system to execute the second pending task according to the task index data, it is necessary to determine whether the second pending task is processed successfully. If it is processed successfully, the task status in the task metadata can be updated. If it fails, in order to ensure that it is processed successfully or failed at the same time as the first pending task, it is necessary to call the second system again to execute the second pending task. Accordingly, if the second system processes successfully multiple times, in order to improve the efficiency of task processing and avoid occupying public resources for a long time, it is necessary to prompt the user to perform manual processing. Specifically, it can be determined whether the number of times the second pending task fails to execute exceeds a preset threshold. If so, the user is prompted to perform manual processing. If not, the second system can continue to be called for processing. Among them, the preset threshold can be set by the user or by the system default, and the present invention is not limited here.

[0086] The distributed task processing method provided in this embodiment determines whether the number of execution failures of the second pending task exceeds a preset threshold. If so, the method prompts the user to manually process the second pending task. If not, the method returns to the step of re-invoking the second system to execute the second pending task. This ensures that the first pending task and the second pending task in the second system are simultaneously processed successfully or simultaneously failed, ensuring synchronization of asynchronous task system processing, thereby avoiding prolonged resource locking and single points of failure.

[0087] Figure 6 The flowchart of the distributed task processing method provided in the fifth embodiment of the present invention is based on any of the above embodiments. Figure 6 As shown, the method includes:

[0088] Step 501: Scan according to a preset time period to see whether there is any second pending task that has not been processed for a preset time threshold;

[0089] Step 502: If yes, determine whether the transaction identifier is pre-stored in the local database corresponding to the first system according to the transaction identifier in the second task to be processed;

[0090] Step 503: If yes, call the second system to execute the second pending task;

[0091] Step 504: If not, discard the second task to be processed.

[0092] It should be noted that the operation of the first system writing the task index data to the asynchronous task system may succeed or fail. For example, if there is a fault in the current network, the first system may fail to write the task index data to the asynchronous task system. In addition, if there is insufficient storage space in the current asynchronous task system, the first system may fail to write the task index data to the asynchronous task system. When the first system successfully writes the task index data to the asynchronous task system, the processing of the second pending task can be achieved by scanning the task index data. When the first system fails to write the task index data to the asynchronous task system, the processing of the second pending task cannot be achieved by scanning the task index data. At this time, in order to achieve timely processing of the asynchronous task, it is necessary to scan according to a preset time period whether there is any second pending task that has not been processed for more than a preset time threshold. It is understandable that since the second pending task does not have corresponding task index data, it is not known whether the corresponding first pending task is successfully processed. In order to ensure that the first pending task and the second pending task in the second system are successfully processed or failed to be processed at the same time, it is necessary to determine whether the local database corresponding to the first system has the transaction identifier pre-stored according to the transaction identifier in the second pending task. Since the first system's execution of the first pending task and uploading the transaction identifier to the local database simultaneously succeed and fail, if the transaction identifier can be found in the local database, it indicates that the first pending task has been successfully processed. At this point, the second pending task also needs to be successfully processed, and the second system needs to be called to execute the second pending task. Correspondingly, if the transaction identifier is not found in the local database, it indicates that the first pending task has not been successfully processed. At this point, to ensure that the first pending task and the second pending task in the second system are simultaneously successfully processed or failed, the second pending task can be discarded.

[0093] The distributed task processing method provided in this embodiment scans for any pending tasks that have been unprocessed for longer than a preset time threshold, based on a preset time period. If so, the method determines whether the transaction identifier is pre-stored in the local database corresponding to the first system based on the transaction identifier in the second pending task. If so, the method calls the second system to execute the second pending task; if not, the method discards the second pending task. This ensures that the first pending task and the second pending task in the second system are processed successfully or failed simultaneously, ensuring synchronization of asynchronous task system processing, thereby avoiding prolonged resource locking and single points of failure.

[0094] Figure 7 The flowchart of the distributed task processing method provided in the sixth embodiment of the present invention is based on any of the above embodiments. Figure 7 As shown, the method includes:

[0095] Step 601: The first system generates a transaction identifier.

[0096] Step 602: The first system sends the second to-be-processed task in the second system to the asynchronous task system.

[0097] Step 603: The asynchronous task system feeds back task index data to the first system according to the second task to be processed;

[0098] Step 604: The first system processes the first pending task and writes the transaction identifier into the local database.

[0099] Step 605: After successfully executing the first pending task in the first system and writing the transaction identifier into the local database corresponding to the first system, the first system sends task index data to the asynchronous task system.

[0100] Step 606: The asynchronous task system obtains task index data;

[0101] Step 607: The asynchronous task system obtains task metadata according to the task index data.

[0102] Step 608: The asynchronous task system calls the second system to process the second pending task;

[0103] Step 609: When the second pending task is successfully processed, the asynchronous task system updates the status of the second pending task.

[0104] Step 610: The asynchronous task system periodically queries whether there is any task metadata of the second pending task that has not been processed for more than a preset time threshold.

[0105] Step 611: The asynchronous task system determines, based on the transaction identifier in the second pending task, whether the transaction identifier is pre-stored in the local database corresponding to the first system.

[0106] Step 612: If it exists, the asynchronous task system calls the second system to execute the second task to be processed;

[0107] Step 613: If the second task to be processed does not exist, the task system discards the second task to be processed.

[0108] Among them, the execution subject of steps 601-602 and steps 604-605 is the first system; the execution subject of steps 603 and steps 606-613 is the asynchronous task system.

[0109] The distributed task processing method provided in this embodiment can ensure that the first task to be processed and the second task to be processed in the second system are processed successfully or fail to be processed at the same time, thereby ensuring the synchronization of asynchronous task system processing, thereby avoiding long-term resource locking and single point failure.

[0110] Figure 8 This is a structural diagram of a distributed task processing device provided in Example 7 of the present invention, as shown in FIG. Figure 8 As shown, the device includes:

[0111] The first receiving module 71 is configured to receive a second to-be-processed task of a second system sent by the first system, wherein the second to-be-processed task includes a preset task identifier, which is an identifier of all to-be-processed task information in all current systems;

[0112] A generating module 72 is configured to generate task index data corresponding to the second task to be processed based on the second task to be processed, and send the task index data to the first system;

[0113] A second receiving module 73 is configured to receive the task index data sent by the first system after successfully executing a local transaction;

[0114] The calling module 74 is configured to call the second system to execute the second task to be processed according to the task index data.

[0115] The distributed task processing device provided in this embodiment receives a second pending task from a second system sent by a first system, the second pending task including a preset task identifier, which identifies all pending task information in all current systems; generates task index data corresponding to the second pending task based on the second pending task, and sends the task index data to the first system; receives the task index data sent by the first system after successfully executing a local transaction; and invokes the second system to execute the second pending task based on the task index data. This avoids locking resources for extended periods and single points of failure.

[0116] Furthermore, based on any of the above embodiments, the preset transaction identifier is generated according to a preset numbering rule after the first system determines all pending tasks in all current systems.

[0117] Furthermore, based on any of the above embodiments, the second receiving module includes:

[0118] The receiving unit is configured to receive the task index data sent by the first system after the first system successfully executes the first task to be processed in the first system and writes the transaction identifier into a local database corresponding to the first system.

[0119] Further, based on any of the above embodiments, the task index data includes a storage path of task metadata corresponding to the second to-be-processed task;

[0120] Accordingly, the calling module includes:

[0121] a scanning unit, configured to scan the task index data and obtain task metadata corresponding to processing the second task to be processed;

[0122] A calling unit is used to call the second system to execute the second to-be-processed task according to the task metadata.

[0123] Furthermore, based on any of the above embodiments, the device further includes:

[0124] A first judgment module is used to judge whether the second pending task is executed successfully;

[0125] A first processing module, configured to update the task status recorded in the task metadata of the second task to be processed if yes;

[0126] The second processing module is configured to, if not, re-call the second system to execute the second task to be processed.

[0127] Furthermore, based on any of the above embodiments, the device further includes:

[0128] A second judgment module is used to judge whether the number of execution failures of the second to-be-processed task exceeds a preset threshold;

[0129] a third processing module, configured to, if yes, prompt the user to manually process the second pending task;

[0130] The fourth processing module is configured to, if not, return to the step of re-calling the second system to execute the second task to be processed.

[0131] Furthermore, based on any of the above embodiments, the device further includes:

[0132] A scanning module, configured to scan, according to a preset time period, whether there is any second pending task that has not been processed for a preset time threshold;

[0133] a query module, configured to, if yes, determine, based on the transaction identifier in the second task to be processed, whether the transaction identifier is pre-stored in a local database corresponding to the first system;

[0134] a fifth processing module, configured to, if yes, call the second system to execute the second task to be processed;

[0135] The sixth processing module is configured to discard the second task to be processed if no.

[0136] Figure 9 This is a structural diagram of a distributed task processing device provided in Example 8 of the present invention, such as Figure 9 As shown, the device includes: a memory 81, a processor 82;

[0137] Memory 81; Memory 81 for storing instructions executable by the processor 82;

[0138] The processor 82 is configured to execute the distributed task processing method as described in any of the above embodiments;

[0139] The distributed task processing device further includes a communication interface.

[0140] Yet another embodiment of the present invention provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are executed by a processor, they are used to implement the distributed task processing method as described in any of the above embodiments.

[0141] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the device described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0142] Those skilled in the art will appreciate that all or part of the steps in the above-described method embodiments can be implemented using hardware associated with program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0143] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A distributed task processing method, applied to an asynchronous task system, characterized in that: include: receiving a second pending task from a second system sent by the first system, wherein the second pending task includes a preset task identifier, which is an identifier of all pending task information in all current systems; wherein the task identifier is generated by the first system interacting with the second system to obtain all current pending tasks and naming all pending tasks according to a preset naming rule; generating task index data corresponding to the second task to be processed according to the second task to be processed, and sending the task index data to the first system; receiving the task index data sent by the first system after successfully executing the first to-be-processed task in the first system and writing the transaction identifier into a local database corresponding to the first system; The second system is called according to the task index data to execute the second task to be processed.

2. The method according to claim 1, characterized in that The preset transaction identifier is generated according to a preset numbering rule after the first system determines all pending tasks in all current systems.

3. The method according to claim 1, characterized in that The task index data includes a storage path for processing task metadata corresponding to the second task to be processed; Correspondingly, calling the second system to execute the second to-be-processed task according to the task index data includes: Scan the task index data to obtain task metadata corresponding to processing the second task to be processed; The second system is called according to the task metadata to execute the second to-be-processed task.

4. The method according to claim 1, wherein After calling the second system to execute the second to-be-processed task according to the task index data, the method further includes: Determining whether the second pending task is executed successfully; If yes, then updating the task status recorded in the task metadata of the second task to be processed; If not, the second system is called again to execute the second task to be processed.

5. The method according to claim 4, characterized in that If not, then after re-calling the second system to execute the second task to be processed, the method further includes: Determining whether the number of execution failures of the second pending task exceeds a preset threshold; If yes, prompt the user to manually process the second pending task; If not, return to the step of re-calling the second system to execute the second task to be processed.

6. The method according to any one of claims 1 to 5, characterized in that Also includes: Scanning according to a preset time period whether there is a second pending task that has not been processed for a preset time threshold; If yes, determining whether the transaction identifier is pre-stored in the local database corresponding to the first system according to the transaction identifier in the second task to be processed; If so, calling the second system to execute the second pending task; If not, the second to-be-processed task is discarded.

7. A distributed task processing device, characterized in that: include: A first receiving module is configured to receive a second pending task from a second system sent by the first system, wherein the second pending task includes a preset task identifier, which is an identifier of all pending task information in all current systems; wherein the task identifier is generated by the first system interacting with the second system to obtain all current pending tasks and naming all pending tasks according to a preset naming rule; a generating module, configured to generate task index data corresponding to the second task to be processed according to the second task to be processed, and send the task index data to the first system; A second receiving module is configured to receive the task index data sent by the first system after successfully executing a local transaction; A calling module, configured to call the second system to execute the second to-be-processed task according to the task index data; The second receiving module includes: The receiving unit is configured to receive the task index data sent by the first system after the first system successfully executes the first task to be processed in the first system and writes the transaction identifier into a local database corresponding to the first system.

8. The device according to claim 7, characterized in that The preset transaction identifier is generated according to a preset numbering rule after the first system determines all pending tasks in all current systems.

9. The device according to claim 7, characterized in that The task index data includes a storage path for processing task metadata corresponding to the second task to be processed; Accordingly, the calling module includes: a scanning unit, configured to scan the task index data and obtain task metadata corresponding to processing the second task to be processed; A calling unit is used to call the second system to execute the second to-be-processed task according to the task metadata.

10. The device according to claim 7, characterized in that The device further comprises: A first judgment module is used to judge whether the second pending task is executed successfully; A first processing module, configured to update the task status recorded in the task metadata of the second task to be processed if yes; The second processing module is configured to, if not, re-call the second system to execute the second task to be processed.

11. The device according to claim 10, characterized in that The device further comprises: A second judgment module is used to judge whether the number of execution failures of the second to-be-processed task exceeds a preset threshold; a third processing module, configured to, if yes, prompt the user to manually process the second pending task; The fourth processing module is configured to, if not, return to the step of re-calling the second system to execute the second task to be processed.

12. The device according to any one of claims 7 to 11, characterized in that: Also includes: A scanning module, configured to scan, according to a preset time period, whether there is any second pending task that has not been processed for a preset time threshold; a query module, configured to, if yes, determine, based on the transaction identifier in the second task to be processed, whether the transaction identifier is pre-stored in a local database corresponding to the first system; a fifth processing module, configured to, if yes, call the second system to execute the second task to be processed; The sixth processing module is configured to discard the second task to be processed if no.

13. A distributed task processing device, characterized in that: include: Memory, processor; Memory; a memory for storing instructions executable by the processor; The processor is configured to execute the distributed task processing method according to any one of claims 1 to 6.

14. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the distributed task processing method according to any one of claims 1 to 6.

15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, it is used to implement the distributed task processing method according to any one of claims 1 to 6.

Images