Task processing method and device, electronic equipment and storage medium

Abstract

The present disclosure relates to a task processing method and device, electronic equipment and storage medium. The method comprises: receiving a task recovery request, wherein the task recovery request comprises a mapping relationship between a state identifier of a task and a state type; in the case that the task recovery request comprises a preset storage path, determining a compatibility result of a task state of the task according to the state type corresponding to the state identifier in the mapping relationship and the state type corresponding to the state identifier in the locally maintained meta information; in the case that the compatibility result represents that the task states are compatible, obtaining state data corresponding to the state identifier in the mapping relationship according to the preset storage path; and sending the state data, wherein the state data is used to recover the task. The method provided by the present disclosure can improve the flexibility of task recovery.

Description

Technical Field

[0001] This disclosure relates to the field of real-time computing, and more particularly to a task processing method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the development of big data real-time computing technology, real-time computing is widely used in various fields, such as the Internet of Things and machine learning. In the field of real-time computing, real-time computing utilizes state to achieve task recovery, that is, to recover the real-time computation of a task.

[0003] In related technologies, during the task recovery process, it is necessary to compare the current state type of the task with the state type before the task recovery. If the state types are exactly the same, the task can be recovered based on historical state data.

[0004] However, if some task states are deleted, the task cannot be recovered based on historical state data, meaning task recovery can only be performed after the real-time calculation cycle ends. For example, consider a task upgrade scenario. Suppose a task includes real-time calculations of two metrics, each corresponding to a task state. After the task upgrade, one metric no longer needs calculation, so the real-time calculation corresponding to that metric needs to be deleted, i.e., the task state corresponding to that metric needs to be deleted. At this point, the state type of one task state differs from the state types of the two task states before the upgrade, making task recovery based on historical state data impossible. In other words, the inability of related technologies to properly handle scenarios involving the deletion of partial task states can significantly increase usage costs. Summary of the Invention

[0005] This disclosure provides a task processing method, apparatus, electronic device, and storage medium to at least solve the problem in related technologies of the inability to correctly handle scenarios involving the deletion of partial task states. The technical solution of this disclosure is as follows:

[0006] According to a first aspect of the present disclosure, a task processing method is provided, the method comprising:

[0007] Receive a task recovery request, wherein the task recovery request includes a mapping relationship between the task's status identifier and status type;

[0008] If the task recovery request includes a preset storage path, the compatibility result of the task state is determined based on the state type corresponding to the state identifier in the mapping relationship and the state type corresponding to the state identifier in the locally maintained metadata.

[0009] If the compatibility result indicates that the task status is compatible, the status data corresponding to the status identifier in the mapping relationship is obtained according to the preset storage path;

[0010] The status data is sent, and the status data is used to recover the task.

[0011] In one embodiment, determining the compatibility result of the task state based on the state type corresponding to the state identifier in the mapping relationship and the state type corresponding to the state identifier in the locally maintained metadata includes:

[0012] When the state type corresponding to the state identifier in the mapping relationship is consistent with the state type corresponding to the state identifier in the meta-information, a first compatibility result that ensures task state compatibility is obtained.

[0013] Alternatively, if the state type corresponding to the state identifier in the mapping relationship is inconsistent with the state type corresponding to the state identifier in the meta-information, a second compatibility result representing incompatibility of task states is obtained.

[0014] In one embodiment, obtaining the state data corresponding to the state identifier in the mapping relationship according to the preset storage path includes:

[0015] Based on the historical status data of the preset storage path;

[0016] Obtain the state data corresponding to the state identifier in the mapping relationship from the historical state data.

[0017] In one embodiment, the method further includes:

[0018] If the compatibility result indicates that the task status is incompatible, an error message is sent.

[0019] In one embodiment, the method further includes:

[0020] If the task recovery request does not include a preset storage path, create new metadata for the task, including the mapping relationship; and write new status data based on the new metadata.

[0021] In one embodiment, the task recovery request further includes an array of current task state serializers. The step of obtaining a compatibility result for the task state based on the consistency between the state type corresponding to the state identifier in the mapping relationship and the state type corresponding to the state identifier in the locally maintained metadata includes:

[0022] If the state type corresponding to the state identifier in the mapping relationship is consistent with the state type corresponding to the state identifier in the locally maintained metadata, obtain the matching result between the current state serializer array of the task and the locally maintained state serializer array;

[0023] If the matching result indicates that the current state serializer array matches the locally maintained state serializer array, a compatibility result indicating task state compatibility is obtained.

[0024] According to a second aspect of the present disclosure, a task processing method is provided, the method comprising:

[0025] Send a task recovery request, the task recovery request including the mapping relationship between the current status identifier and status type of the task;

[0026] Receive feedback information in response to the task recovery request. If the task recovery request includes a preset storage path, the feedback information includes status data corresponding to the status identifier.

[0027] The task is restored based on the status data in the feedback information.

[0028] In one embodiment, if the task recovery request does not include a preset storage path, the feedback information includes a metadata creation success indication.

[0029] According to a third aspect of the present disclosure, a task processing apparatus is provided, the apparatus comprising:

[0030] The receiving unit is configured to execute a receiving task recovery request, wherein the task recovery request includes a mapping relationship between a task status identifier and a status type.

[0031] The determining unit is configured to, when the task recovery request includes a preset storage path, determine the compatibility result of the task state based on the state type corresponding to the state identifier in the mapping relationship and the state type corresponding to the state identifier in the locally maintained metadata.

[0032] The acquisition unit is configured to, under the condition that the compatibility result characterizes the task status as compatible, acquire the status data corresponding to the status identifier in the mapping relationship according to the preset storage path;

[0033] The first sending unit is configured to send the status data, which is used to recover the task.

[0034] In one embodiment, the determining unit is further configured to perform:

[0035] When the state type corresponding to the state identifier in the mapping relationship is consistent with the state type corresponding to the state identifier in the meta-information, a first compatibility result representing the compatibility of task states is obtained.

[0036] Alternatively, if the state type corresponding to the state identifier in the mapping relationship is inconsistent with the state type corresponding to the state identifier in the meta-information, a second compatibility result representing incompatibility of task states is obtained.

[0037] In one embodiment, the acquiring unit is further configured to perform:

[0038] Historical status data is obtained according to the preset storage path;

[0039] Obtain the state data corresponding to the state identifier in the mapping relationship from the historical state data.

[0040] In one embodiment, the apparatus further includes:

[0041] The second sending unit is configured to send an error message if the compatibility result indicates that the task state is incompatible.

[0042] In one embodiment, the apparatus further includes:

[0043] The creation unit is configured to create new metadata for the task if the task recovery request does not include a preset storage path, and the new metadata includes the mapping relationship;

[0044] The writing unit is configured to perform the writing of new state data based on the new metadata.

[0045] In one embodiment, the task recovery request further includes an array of current task state serializers, and the determining unit is further configured to execute:

[0046] If the state type corresponding to the state identifier in the mapping relationship is consistent with the state type corresponding to the state identifier in the locally maintained metadata, obtain the matching result between the current state serializer array of the task and the locally maintained state serializer array;

[0047] If the matching result indicates that the current state serializer array matches the locally maintained state serializer array, a compatibility result indicating task state compatibility is obtained.

[0048] According to a fourth aspect of the present disclosure, a task processing apparatus is provided, the apparatus comprising:

[0049] The sending unit is configured to execute a sending task recovery request, wherein the task recovery request includes a mapping relationship between the current status identifier and the status type of the task.

[0050] The receiving unit is configured to receive feedback information in response to the task recovery request. If the task recovery request includes a preset storage path, the feedback information includes status data corresponding to the status identifier.

[0051] The recovery unit is configured to perform the task of recovering the status data based on the feedback information.

[0052] In one embodiment, if the task recovery request does not include a preset storage path, the feedback information includes a metadata creation success indication.

[0053] According to a fifth aspect of the present disclosure, an electronic device is provided, comprising:

[0054] processor;

[0055] Memory used to store the processor's executable instructions;

[0056] The processor is configured to execute the instructions to implement the task processing method described in either the first or second aspect.

[0057] According to a sixth aspect of the present disclosure, a computer-readable storage medium is provided, characterized in that, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is able to perform a task processing method as described in any of the first or second aspects above.

[0058] According to a seventh aspect of the present disclosure, a computer program product is provided, the computer program product including instructions, characterized in that, when the instructions are executed by a processor of an electronic device, the electronic device is able to perform the task processing method described in any one of the first or second aspects.

[0059] The technical solutions provided by the embodiments of this disclosure bring at least the following beneficial effects:

[0060] This disclosure provides a task processing method, apparatus, electronic device, and storage medium. It allows receiving task recovery requests through a layer, where the request includes a mapping between a task's status identifier and its status type. When the task recovery request includes a preset storage path, the compatibility of the task's status can be determined based on the status type corresponding to the status identifier in the mapping relationship and the status type corresponding to the status identifier in locally maintained metadata. If the compatibility indicates that the task statuses are compatible, the status data corresponding to the status identifier in the mapping relationship is obtained according to the preset storage path, and the status data is sent to recover the task. Based on the task processing method, apparatus, electronic device, and storage medium provided in this disclosure, when a task needs to be recovered from historical status data, the task recovery request includes a mapping between the task's status identifier and its status type. Therefore, the compatibility of the task status can be determined based on the mapping between the status type corresponding to the status identifier in the mapping relationship and the status type corresponding to the status identifier in the metadata. If the task statuses are compatible, the status data corresponding to the current status can be obtained from the preset storage path according to the mapping relationship. This allows the task to be recovered based on the status data, correctly handling scenarios where some states have been deleted, enabling real-time task recovery, reducing usage costs, and improving task maintainability.

[0061] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0062] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0063] Figure 1 This is a flowchart illustrating a task processing method according to an exemplary embodiment.

[0064] Figure 2 This is a schematic diagram illustrating the application environment of a task processing method according to an exemplary embodiment.

[0065] Figure 3 This is a schematic diagram illustrating a task processing method according to an exemplary embodiment.

[0066] Figure 4a This is a schematic diagram illustrating a task processing method according to an exemplary embodiment.

[0067] Figure 4b This is a schematic diagram illustrating a task processing method according to an exemplary embodiment.

[0068] Figure 5This is a flowchart illustrating a task processing method according to an exemplary embodiment.

[0069] Figure 6 This is a flowchart illustrating a task processing method according to an exemplary embodiment.

[0070] Figure 7a This is a schematic diagram illustrating a task processing method according to an exemplary embodiment.

[0071] Figure 7b This is a schematic diagram illustrating a task processing method according to an exemplary embodiment.

[0072] Figure 8 This is a flowchart illustrating a task processing method according to an exemplary embodiment.

[0073] Figure 9 This is a flowchart illustrating a task processing method according to an exemplary embodiment.

[0074] Figure 10 This is a block diagram illustrating a task processing apparatus according to an exemplary embodiment.

[0075] Figure 11 This is a block diagram illustrating a task processing apparatus according to an exemplary embodiment.

[0076] Figure 12 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation

[0077] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0078] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0079] It should also be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties.

[0080] The tasks in this embodiment are all real-time computing tasks. Therefore, if a task is interrupted due to operations such as task upgrades or task fault repair, task recovery is required, i.e., restoring the real-time computing of the task. During task execution, some task states may be deleted (for example, during task upgrades or task fault repairs, some unused task states may be deleted), resulting in inconsistencies in the task states before and after recovery. This makes it impossible to recover the task using historical state data. In other words, existing technologies cannot properly handle scenarios where some states are deleted, which incurs significant costs.

[0081] For example, taking a task upgrade scenario, suppose the task includes counting the number of orders in a day (from 0:00 to 24:00). If the task is upgraded at any time between 0:00 and 24:00 (for example, 13:00), the task has already counted the number of orders from 0:00 to 13:00. To ensure the accuracy of the number of orders counted after the task upgrade, the task needs to be restored based on the number of orders counted before that time. That is, after the task is successfully restored, the task will continue to count the number of orders based on the number of orders from 0:00 to 13:00.

[0082] However, if some unused task states are deleted during the upgrade process (for example, if the task includes click statistics, but click statistics are no longer needed after the upgrade, then the click statistics task state needs to be deleted), the existing technology cannot properly handle scenarios where partial task states are deleted. This will prevent the task from being restored in real time based on the order volume count previously collected. Consequently, after task restoration, the order volume count can only be recalculated from the current moment, leading to errors in order volume statistics. To avoid these errors, task upgrades and restorations must be performed at midnight (midnight is the end of one real-time calculation cycle and the beginning of the next). Therefore, task restoration at this time does not require restoration based on historical state data; order volume statistics start from zero, preventing errors in order volume statistics. It is evident that the existing technology's inability to properly handle scenarios where partial task states are deleted will impose significant costs on its use.

[0083] Figure 1 This is a flowchart illustrating a task processing method according to an exemplary embodiment, such as... Figure 1 As shown, the task processing method may include the following steps.

[0084] In step 102, a task recovery request is received, which includes a mapping relationship between the task's status identifier and status type.

[0085] Exemplary embodiments of this disclosure can be applied to, for example, Figure 2 The application environment shown. For example... Figure 2 As shown, engine 20 includes a state management module 210 and an application 220, which can interact with each other. The state management module 210 manages and stores the task states of tasks within the application 220. The state management module 210 locally maintains metadata created based on the task states, which may include a mapping between task state identifiers and state types. The state management module 210 can store the state data written by the application 220 based on this metadata.

[0086] In this embodiment, the task is a real-time computing task, and task recovery is required during use. For example, task recovery is necessary after task upgrades or modifications due to task failures. When task recovery is required, the application can generate a mapping relationship between a status identifier and the corresponding status type based on the current task status, and can send a corresponding task recovery request based on this mapping relationship.

[0087] For example, each real-time computation included in a task can correspond to a task state, and the data type of each real-time computation is its corresponding state type. (See reference...) Figure 3 As shown, the current task status corresponds to the status identifiers count1, sum1, and concat1, respectively, and the status types corresponding to each status identifier are long, int, and string, respectively. The mapping relationship between the status identifiers and status types generated based on the current task status information can be found in Table 1 below.

[0088] Table 1

[0089] Status indicator State type count1 Long sum1 Int concat1 String

[0090] In step 104, if the task recovery request includes a preset storage path, the compatibility result of the task state is determined based on the state type corresponding to the state identifier in the mapping relationship and the state type corresponding to the state identifier in the locally maintained metadata.

[0091] In this embodiment of the disclosure, before task recovery is required (e.g., before task upgrade or task fault repair), the user can specify a task recovery path, which is a preset storage path. This preset storage path can be used to indicate the write location of the task's status data. For example, when recovering a task based on historical status data, the preset storage path can be written in advance within the application. When the application writes status data, the status data can be stored in the area specified by the preset storage path. Furthermore, when task recovery is required, if the task needs to be recovered based on historical status data, the task recovery request issued by the application can include the preset storage path, so that task recovery can be instructed based on the historical status data stored in the preset storage path.

[0092] Upon receiving a task recovery request, if the request includes a preset storage path, it can be determined that the task needs to be recovered based on historical state data. At this point, the compatibility of the task state needs to be assessed to obtain a compatibility result. This compatibility result characterizes whether the historical state data is compatible with the current task state. If they are incompatible, the task cannot be recovered based on the historical state data.

[0093] For example, the locally maintained metadata includes a mapping relationship between the task's state identifier and state type before the task recovery operation. Upon receiving a task recovery request, the compatibility result of the task state can be determined based on the state type corresponding to the state identifier in the mapping relationship of the task recovery request and the state type corresponding to that state identifier in the locally maintained metadata. For example, if the state type corresponding to the state identifier in the mapping relationship of the task recovery request is completely consistent with the state type corresponding to that state identifier in the locally maintained metadata, a compatibility result indicating task state compatibility is obtained; otherwise, a compatibility result indicating task state incompatibility is obtained.

[0094] In step 106, if the compatibility result characterizes the task state as compatible, the state data corresponding to the state identifier in the mapping relationship is obtained according to the preset storage path.

[0095] In this embodiment of the disclosure, when the compatibility result characterizes the task state as compatible, it can be determined that the state data corresponding to the state identifier in the historical state data is compatible with the current task state. That is, the state data can be identified and processed. Therefore, the state data corresponding to the state identifier in the mapping relationship can be obtained from the historical state data to provide to the application for task recovery. For example, historical state data can be obtained according to a preset storage path, and the state data corresponding to the state identifier in the mapping relationship can be further obtained from the historical state data.

[0096] In step 108, status data is sent, which is used to resume the task.

[0097] For example, after obtaining the task's status data, this status data can be sent to the application so that the application can resume the task based on it. Alternatively, feedback information can be sent to the application based on the status data, and this feedback information may include the status data. Upon receiving the feedback information including the status data, the application can resume the task based on the status data, that is, continue to perform real-time calculations corresponding to each task status using the various status data. For instance, if a task is upgraded at 8:00 AM, and the task status includes real-time statistics of clicks within a day, then the status data obtained at this time is the cumulative click count before 8:00 AM. Furthermore, the application can continue to perform real-time click statistics based on the cumulative click count before 8:00 AM.

[0098] For example, still using Figure 2 In the example shown, application 220 deletes the target state during task upgrades or task fault repairs. After the task restarts, it sends a task recovery request to the state management module 210. The task recovery request includes a mapping relationship between the current state identifier and the state type. After receiving the task recovery request, the state management module 210 can determine the compatibility of the task state based on the locally maintained metadata and the mapping relationship to obtain a compatibility result. If the compatibility result indicates that the task state is compatible, it retrieves historical state data according to a preset storage path, obtains the state data corresponding to each state identifier in the mapping relationship from the historical state data, and sends the state data to application 220. Application 220 performs task recovery based on the received state data, that is, real-time calculation of the task recovery. In this embodiment, task recovery is not limited by time. Based on this, task upgrades and task fault repairs can be performed in real time, which can improve the flexibility of task execution operations, improve task maintainability, and greatly reduce usage costs.

[0099] This disclosure provides a task processing method that receives a task recovery request, which includes a mapping relationship between the task's status identifier and its status type. When the task recovery request includes a preset storage path, the compatibility result of the task's status can be determined based on the status type corresponding to the status identifier in the mapping relationship and the status type corresponding to the status identifier in locally maintained metadata. If the compatibility result indicates that the task statuses are compatible, the status data corresponding to the status identifier in the mapping relationship is retrieved according to the preset storage path, and the status data is sent to restore the task. Based on the task processing method provided by this disclosure, when a task needs to be restored from historical status data, since the task recovery request includes a mapping relationship between the task's status identifier and its status type, the compatibility of the task status can be determined based on the status type corresponding to the status identifier in the mapping relationship and the status type corresponding to the status identifier in the metadata. If the task statuses are compatible, the status data corresponding to the current status can be retrieved from the preset storage path according to the mapping relationship. This allows the task to be restored based on the status data, correctly handles scenarios where some states have been deleted, enables real-time task restoration, reduces usage costs, and improves task maintainability.

[0100] In one embodiment, in step 104 above, the compatibility result of the task state is determined based on the state type corresponding to the state identifier in the mapping relationship and the state type corresponding to the state identifier in the locally maintained metadata. This can be achieved through the following steps:

[0101] When the state type corresponding to the state identifier in the mapping relationship is consistent with the state type corresponding to the state identifier in the meta-information, the first compatibility result representing the compatibility of task states is obtained.

[0102] Alternatively, if the state type corresponding to a state identifier in the mapping relationship is inconsistent with the state type corresponding to a state identifier in the metadata, a second compatibility result representing task state incompatibility is obtained. In this embodiment of the present disclosure, when the task recovery request includes a preset storage path, the state identifier in the mapping relationship carried in the task recovery request can be obtained, and the state type corresponding to the state identifier can be determined from the locally maintained metadata. If the state type corresponding to each state identifier in the metadata is consistent with the state type corresponding to each state identifier in the mapping relationship, a first compatibility result can be obtained, which can be used to represent state-task compatibility; or, if there is a state type corresponding to a state identifier in the metadata that is inconsistent with the state type corresponding to that state identifier in the mapping relationship, a second compatibility result can be obtained, which can be used to represent state-task incompatibility.

[0103] For example, taking a task upgrade scenario, assuming that the status identifiers corresponding to the task state before the upgrade are count1, sum1, avg1, and concat1, and the status types corresponding to each status identifier are long, int, (long, long), and string, then the metadata can include the mapping relationship between status identifiers and status types generated based on the status information before the task upgrade, as shown in Table 2 below. As shown in Table 2, it should be understood that in some embodiments, the status identifier corresponds to two or more status types.

[0104] Table 2

[0105]

[0106] In one embodiment, during task upgrade, if task state avg1 is deleted, the task recovery request sent by the application carries a mapping relationship between the current task's state identifier and state type. This mapping relationship can be referenced in Table 1 (which represents the deleted task state mentioned in this embodiment). Upon receiving the task recovery request, the preset storage path determines whether the task needs to be recovered from historical state data. Therefore, it can be determined whether the state type corresponding to each state identifier in Table 1 in Table 2 is consistent with the state type corresponding to each state identifier in Table 1. (Refer to...) Figure 4a As shown, at this point, the state type corresponding to each state identifier in Table 1 in Table 2 is determined to be consistent with the state type corresponding to each state identifier in Table 1. Therefore, the first compatibility result representing the compatibility of task states can be obtained.

[0107] In another embodiment, during the task upgrade process, an erroneous operation occurred when deleting task state avg1, meaning only a portion of the state types in task state avg1 were deleted. avg1 includes two calculations, i.e., two state types. These two state types may be related, and they must be deleted together as related. If only one calculation (i.e., one state type) is deleted when deleting avg1, the correctness of the task state will be compromised. This embodiment represents a special case of partial task state deletion as described in the embodiments of this application. After deleting one state type (i.e., deleting a portion of the state), the task recovery request sent by the application carries the mapping relationship between the current task's state identifiers and state types. This mapping relationship can be referred to in Table 3 below. It should be understood that deleting a portion of the task state's state types will compromise the correctness of the task state.

[0108] Table 3

[0109] Status indicator State type count1 Long sum1 Int avg1 long concat1 String

[0110] Upon receiving a task recovery request, the preset storage path indicates that the task needs to be recovered from historical state data. This allows us to determine whether the first state type corresponding to each state identifier in Table 3 in Table 2 is consistent with the state type corresponding to each state identifier in Table 1. At this point, it is determined that the state type of task state avg1 is inconsistent with the state type corresponding to task state avg1 in Table 3. (Refer to...) Figure 4b As shown, a second compatible result representing the incompatibility of task states can be obtained.

[0111] Based on the task processing method provided in the public embodiments, when a task needs to be restored from historical state data, the task restoration request includes a mapping relationship between the state identifier and the state type in the task. Then, based on the state type corresponding to the state identifier in the mapping relationship and the state type corresponding to the state identifier in the locally maintained metadata, it can be determined whether the task state is compatible and obtain a compatibility result. This allows the task to still obtain state data based on the compatibility result even after some task states are deleted, thus enabling the task to be restored based on the state data. This allows for real-time task restoration, improves the flexibility of task restoration, enhances the maintainability of the task, and greatly reduces the cost of use.

[0112] In one embodiment, refer to Figure 5 In step 106, obtaining the state data corresponding to the state identifier in the mapping relationship according to the preset storage path can be achieved through the following steps:

[0113] In step 502, historical status data is obtained according to the preset storage path;

[0114] In step 504, the state data corresponding to the state identifier in the mapping relationship is obtained from the historical state data.

[0115] In this embodiment of the disclosure, when the application has state data to write, the data can be written to the area specified by the preset storage path according to the data structure described by the metadata. During the task recovery process, if the task state is confirmed to be compatible, historical state data can be obtained from the specified area according to the preset storage path, and the state identifier in the mapping relationship can be determined. The state data corresponding to each state identifier can be obtained from the historical state data, and the corresponding feedback information can be sent to the application according to the state data, so that the application can resume the real-time calculation of the task based on the state data, that is, to realize task recovery.

[0116] Based on the task processing method provided in the public embodiments, the status data corresponding to the current status of each task can be obtained from the historical status data based on the mapping relationship in the task recovery request. This enables the task to be recovered based on the status data, correctly handles scenarios where some states are deleted, and the task recovery is not controlled by time. It can realize task recovery in real time, improves the flexibility of task recovery, and greatly reduces the manpower cost of task upgrade.

[0117] In one embodiment, the above method may further include:

[0118] If the compatibility results represent incompatible task states, an error message will be sent.

[0119] In this embodiment of the disclosure, when the compatibility result indicates that the task status is incompatible, it can be determined that the task cannot be recovered based on historical data information. Therefore, an error message can be sent to the application. For example, corresponding feedback information can be sent to the application, which may include the error message. Upon receiving the feedback information, the application can determine that the task recovery has failed based on the error message, and then display the error message so that the user can troubleshoot the problem. For example, the error message may include an incompatibility status indicator, allowing the user to quickly locate the problem and improve troubleshooting efficiency.

[0120] Based on the task processing method provided in the publicly disclosed embodiments, error information can be sent when task states are incompatible, thereby enabling troubleshooting based on the error information and improving troubleshooting efficiency.

[0121] In one embodiment, refer to Figure 6 As shown, the above data processing method may further include:

[0122] In step 602, if the task recovery request does not include a preset storage path, new metadata is created for the task, and the new metadata includes mapping relationships.

[0123] In step 604, new status data is written based on the new metadata.

[0124] In this embodiment of the disclosure, if the task does not need to be recovered from historical state data, the task recovery request does not include a preset storage path. That is, if the received task recovery request does not include a preset storage path, it can be determined that the task does not need to be recovered from historical state data. In this case, new metadata can be created based on the mapping relationship carried in the task recovery request, and the metadata before task recovery can be deleted. For example, a new state type array can be created based on the mapping relationship, and both the new state type array and the mapping relationship can be written into the metadata.

[0125] For example, assuming the mapping relationship in the metadata before task recovery is as shown in Table 2, data can be written based on the mapping relationship shown in Table 2, referring to... Figure 7a As shown in Table 1, after receiving a task recovery request, new metadata can be created based on the mapping relationship carried in the task recovery request. That is, the mapping relationship maintained locally by the state layer at this time is shown in Table 1. New state data can be written based on the mapping relationship shown in Table 1. (Refer to...) Figure 7b As shown.

[0126] Based on the task processing method provided in the publicly disclosed embodiments, task recovery is not limited by time, which improves the flexibility of task recovery and greatly reduces the cost of use.

[0127] In one embodiment, refer to Figure 8 As shown, the task recovery request also includes an array of current task state serializers. In step 304, based on the state type corresponding to the state identifier in the mapping relationship and the state type corresponding to the state identifier in the locally maintained metadata, the compatibility result of the task state is obtained, including:

[0128] In step 802, if the state type corresponding to the state identifier in the mapping relationship is consistent with the state type corresponding to the state identifier in the locally maintained meta-information, the matching result between the current state serializer array of the task and the locally maintained state serializer array is obtained.

[0129] In step 804, if the matching result represents a match between the current state serializer array and the locally maintained state serializer array, a compatibility result representing the compatibility of the task state is obtained.

[0130] In this embodiment of the disclosure, when the application is in the task usage state, it can generate a mapping relationship between the state identifier and the state type and an array of state serializers corresponding to the state according to the program logic of the task (for example, the array of state serializers is shown in Table 4 below).

[0131] Table 4

[0132] Meta information longSerializer intSerializer longSerializer longSerializer stringSerializer

[0133] These two pieces of information can be written into the metadata. That is, the metadata includes not only the mapping relationship between the task's status identifier and status type, but also the task's status serializer array. The read and write operations of status data are all implemented through this status serializer array.

[0134] The task recovery request can include an array of current task state sequencers. If the state type corresponding to each state identifier in the state recovery request is consistent with the state type corresponding to each state identifier in the metadata, a compatibility judgment can be further performed based on the state sequencer array to improve the accuracy of compatibility judgment and the correctness of task recovery.

[0135] For example, it can be determined whether the current state serializer array of a task matches the state serializer array in the metadata. If the serializer corresponding to the current task state and the serializer corresponding to the same task state in the metadata can read and write the same type of data, the two serializers are considered to match. If each serializer in the current state serializer array matches each serializer in the state serializer array in the metadata, the current state serializer array matches the locally maintained state serializer array. Therefore, it can be determined that the task's state is compatible, meaning task recovery can be performed based on the state data. Otherwise, it is determined that the task's state is incompatible, meaning task recovery cannot be performed based on the state data, and task recovery fails.

[0136] Based on the task processing method provided in the public embodiments, the compatibility of task states can be further judged based on the task state serializer array, in addition to the judgment based on the mapping relationship. This can improve the accuracy of the task state compatibility result and ensure the correctness and reliability of task recovery.

[0137] Figure 9 This is a flowchart illustrating a task processing method according to an exemplary embodiment, exemplarily as follows: Figure 2 As shown, the data processing method used in application 220 includes the following steps.

[0138] In step 902, a task recovery request is sent, which includes a mapping relationship between the task's current status identifier and status type.

[0139] In this embodiment of the disclosure, when the application is in a task usage state, it can generate a mapping relationship between state identifiers and state types according to its own program logic (or may also include an array of state serializers corresponding to the state), write the mapping relationship into the metadata, and read and write the application's state data according to the metadata.

[0140] During task recovery, a mapping relationship between the current task status identifier and status type can be generated based on the current task status, and a task recovery request can be sent according to this mapping relationship. If the task needs to be recovered based on historical status data, the task recovery request can also include a preset storage path; if the task does not need to be recovered based on historical status data, the task recovery request does not include a preset storage path.

[0141] In step 904, feedback information for the task recovery request is received. If the task recovery request includes a preset storage path, the feedback information includes status data corresponding to the status identifier.

[0142] In step 906, the task is restored based on the status data in the feedback information.

[0143] In this embodiment of the disclosure, when the task recovery request includes a preset storage path, the compatibility of the task states can be determined. If the task states are compatible, state data can be obtained from historical state data (the specific process can be referred to the relevant description in the foregoing embodiments, and will not be repeated here). Based on the state data, corresponding feedback information is sent to the application. The application can then restore the real-time calculation of each task state based on the received state data. Alternatively, if the task recovery request does not include a preset storage path, new metadata can be created directly according to the mapping relationship in the task recovery request, so that the task can be restored based on the new metadata (the specific process can be referred to the relevant description in the foregoing embodiments, and will not be repeated here).

[0144] In one embodiment, if the task recovery request does not include a preset storage path, the feedback information includes a metadata creation success indication.

[0145] In this embodiment of the disclosure, if the task does not need to be restored based on historical state data, and the task restoration request does not include a preset storage path, then new metadata can be created directly according to the mapping relationship in the task restoration request, and feedback information including a successful metadata creation indication can be sent. In this way, the application can restore the task based on the new metadata.

[0146] This disclosure provides a task processing method that can send a task recovery request, which includes a mapping relationship between the task's current state identifier and state type. It also receives feedback information in response to the task recovery request. When the task recovery request includes a preset storage path, the feedback information includes state data corresponding to the state identifier. The task is then recovered based on the state data in the feedback information. Based on the task processing method provided in this disclosure, when a task needs to be recovered from historical state data, the task recovery request includes a mapping relationship between the task's state identifier and state type. Compatibility can then be determined based on the state type corresponding to the state identifier in the mapping relationship and the state type corresponding to the state identifier in locally maintained metadata. If the task state is compatible, the state data corresponding to the current state can be obtained from the preset storage path according to the mapping relationship. This allows the task to be recovered based on the state data, correctly handling scenarios where some states have been deleted, enabling real-time task recovery, reducing usage costs, and improving task maintainability.

[0147] To enable those skilled in the art to better understand the embodiments of this disclosure, the embodiments of this disclosure are described below through specific examples.

[0148] For example, in combination Figure 2 Taking a task upgrade scenario as an example, before determining that a task needs to be upgraded, the user can specify the storage area for status data by writing a preset storage path. At this time, the status management module 210 can write the task status data into the corresponding storage area based on the preset storage path.

[0149] During the task upgrade process, some unused states are deleted. During the task recovery process, the application 220 can send a corresponding task recovery request to the state management module 210. The task recovery instruction includes the mapping relationship between the current state identifier and the state type of the task, as well as the preset storage path.

[0150] If the status management module 210 determines that there is a preset storage path in the task recovery instruction, it will determine whether the task status is compatible based on the currently maintained local metadata and the mapping relationship in the task recovery request. If all the status identifiers in the mapping relationship exist in the metadata and the status type corresponding to the status identifier is consistent with the status type corresponding to each status identifier in the metadata, the task status can be determined to be compatible. The status data can be obtained from the preset storage path based on the status identifier in the mapping relationship, and the application can recover the task based on the status data.

[0151] The task processing method provided in this disclosure can significantly reduce the maintenance cost of applications, greatly improve maintainability, ensure the correctness of tasks more reliably, and significantly improve the robustness of applications.

[0152] It should be understood that, although Figures 1-9 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figures 1-9 At least some of the steps in the process may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but may be executed at different times. The execution order of these steps or stages is not necessarily sequential, but may be executed in turn or alternately with other steps or at least some of the steps or stages in other steps.

[0153] It is understood that the same / similar parts between the various embodiments of the methods described above in this specification can be referred to each other. Each embodiment focuses on the differences from other embodiments, and relevant parts can be referred to the description of other method embodiments.

[0154] Figure 10 This is a block diagram of a task processing apparatus according to an exemplary embodiment. (Refer to...) Figure 10 The device includes a receiving unit 1002, a determining unit 1004, an acquiring unit 1006, and a first transmitting unit 1008.

[0155] The receiving unit 1002 is configured to execute a receiving task recovery request, wherein the task recovery request includes a mapping relationship between the task's status identifier and status type;

[0156] The determining unit 1004 is configured to determine the compatibility result of the task state based on the state type corresponding to the state identifier in the mapping relationship and the state type corresponding to the state identifier in the locally maintained metadata, when the task recovery request includes a preset storage path.

[0157] The acquisition unit 1006 is configured to, under the condition that the compatibility result characterizes the task status as compatible, acquire the acquisition status data corresponding to the status identifier in the mapping relationship according to the preset storage path;

[0158] The first sending unit 1008 is configured to send the status data, which is used to recover the task.

[0159] Based on the task processing apparatus provided in the disclosed embodiments, when a task needs to be restored from historical state data, since the task restoration request includes a mapping relationship between the task's state identifier and state type, the compatibility of the task state can be determined based on the state type corresponding to the state identifier in the mapping relationship and the state type corresponding to the state identifier in the locally maintained metadata. If the task states are compatible, the state data corresponding to the current state can be obtained from a preset storage path according to the mapping relationship. This allows the task to be restored based on the state data, correctly handles scenarios where some states have been deleted, and enables real-time task restoration, reducing usage costs and improving task maintainability.

[0160] In one embodiment, the determining unit 1004 is further configured to perform:

[0161] When the state type corresponding to the state identifier in the mapping relationship is consistent with the state type corresponding to the state identifier in the meta-information, a first compatibility result representing the compatibility of task states is obtained.

[0162] Alternatively, if the state type corresponding to the state identifier in the mapping relationship is inconsistent with the state type corresponding to the state identifier in the metadata, a second compatibility result representing task state incompatibility is obtained. In one embodiment, the acquisition unit 1006 is further configured to execute:

[0163] Historical status data is obtained according to the preset storage path;

[0164] Obtain the state data corresponding to the state identifier in the mapping relationship from the historical state data.

[0165] In one embodiment, the apparatus further includes:

[0166] The second sending unit is configured to send an error message if the compatibility result indicates that the task state is incompatible.

[0167] In one embodiment, the apparatus further includes:

[0168] The creation unit is configured to create new metadata for the task if the task recovery request does not include a preset storage path. The new metadata includes the mapping relationship writing unit, which is configured to write new status data based on the new metadata.

[0169] In one embodiment, the task recovery request further includes an array of current task state serializers, and the determining unit 1004 is further configured to execute:

[0170] If the state type corresponding to the state identifier in the mapping relationship is consistent with the state type corresponding to the state identifier in the locally maintained metadata, obtain the matching result between the current state serializer array of the task and the locally maintained state serializer array;

[0171] If the matching result indicates that the current state serializer array matches the locally maintained serializer array, a compatibility result indicating task state compatibility is obtained.

[0172] Figure 11 This is a block diagram of a task processing apparatus according to an exemplary embodiment. (Refer to...) Figure 11 The device includes a transmitting unit 1102, a receiving unit 1104, and a recovery unit 1106.

[0173] Sending unit 1102 is configured to execute a sending task recovery request, wherein the task recovery request includes a mapping relationship between the current status identifier and status type of the task;

[0174] The receiving unit 1104 is configured to receive feedback information in response to the task recovery request. If the task recovery request includes a preset storage path, the feedback information includes status data corresponding to the status identifier.

[0175] Recovery unit 1106 is configured to perform a recovery task based on the status data in the feedback information.

[0176] In one embodiment, if the task recovery request does not include a preset storage path, the feedback information includes a metadata creation success indication.

[0177] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0178] Figure 12 This is a block diagram illustrating an electronic device 1200 for a task processing method according to an exemplary embodiment. For example, the electronic device 1200 may be a mobile phone, computer, digital broadcasting terminal, messaging device, game console, tablet device, medical device, fitness equipment, personal digital assistant, etc.

[0179] Reference Figure 12 The electronic device 1200 may include one or more of the following components: processing component 1202, memory 1204, power supply component 1206, multimedia component 1208, audio component 1210, input / output (I / O) interface 1212, sensor component 1214, and communication component 1216.

[0180] Processing component 1202 typically controls the overall operation of electronic device 1200, such as operations associated with display, telephone calls, data communication, camera operation, and recording operations. Processing component 1202 may include one or more processors 1220 to execute instructions to perform all or part of the steps of the methods described above. Furthermore, processing component 1202 may include one or more modules to facilitate interaction between processing component 1202 and other components. For example, processing component 1202 may include a multimedia module to facilitate interaction between multimedia component 1208 and processing component 1202.

[0181] Memory 1204 is configured to store various types of data to support the operation of electronic device 1200. Examples of such data include instructions for any application or method operating on electronic device 1200, contact data, phonebook data, messages, pictures, videos, etc. Memory 1204 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, optical disk, or graphene storage.

[0182] Power supply component 1206 provides power to various components of electronic device 1200. Power supply component 1206 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to electronic device 1200.

[0183] Multimedia component 1208 includes a screen that provides an output interface between the electronic device 1200 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of the touch or swipe action but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 1208 includes a front-facing camera and / or a rear-facing camera. When the electronic device 1200 is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or the rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0184] Audio component 1210 is configured to output and / or input audio signals. For example, audio component 1210 includes a microphone (MIC) configured to receive external audio signals when electronic device 1200 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 1204 or transmitted via communication component 1216. In some embodiments, audio component 1210 also includes a speaker for outputting audio signals.

[0185] I / O interface 1212 provides an interface between processing component 1202 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0186] Sensor assembly 1214 includes one or more sensors for providing state assessments of various aspects of electronic device 1200. For example, sensor assembly 1214 may detect the on / off state of electronic device 1200, the relative positioning of components such as the display and keypad of electronic device 1200, changes in position of electronic device 1200 or its components, the presence or absence of user contact with electronic device 1200, orientation or acceleration / deceleration of device 1200, and temperature changes of electronic device 1200. Sensor assembly 1214 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 1214 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 1214 may also include an accelerometer, gyroscope, magnetometer, pressure sensor, or temperature sensor.

[0187] Communication component 1216 is configured to facilitate wired or wireless communication between electronic device 1200 and other devices. Electronic device 1200 can access wireless networks based on communication standards, such as WiFi, carrier networks (such as 2G, 3G, 4G, or 5G), or combinations thereof. In one exemplary embodiment, communication component 1216 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 1216 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0188] In an exemplary embodiment, the electronic device 1200 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the methods described above.

[0189] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 1204 including instructions, which can be executed by a processor 1220 of an electronic device 1200 to perform the above-described method. For example, the computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0190] In an exemplary embodiment, a computer program product is also provided, the computer program product including instructions that can be executed by a processor 1220 of an electronic device 1200 to perform the above-described method.

[0191] It should be noted that the above-mentioned apparatus, electronic equipment, computer-readable storage medium, computer program product, etc., may also include other implementation methods according to the description of the method embodiments. For specific implementation methods, please refer to the description of the relevant method embodiments, which will not be elaborated here.

[0192] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the claims.

[0193] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A task processing method, characterized in that, The method includes: A task recovery request is received. The task recovery request includes a mapping relationship between the task's status identifier and status type. The task is a real-time computing task. Each real-time computing task in the task corresponds to a task status. The data type of each real-time computing task is its corresponding status type. The task recovery request is a request sent by the application according to the mapping relationship after the task is upgraded or the task is repaired. When the task recovery request includes a preset storage path, the compatibility result of the task state is determined based on the state type corresponding to the state identifier in the mapping relationship and the state type corresponding to the state identifier in the locally maintained metadata. The compatibility result of the task state is used to characterize whether the historical state data is compatible with the task state. If the compatibility result indicates that the task status is compatible, the status data corresponding to the status identifier in the mapping relationship is obtained according to the preset storage path; Send the status data, which is used to recover the task; The step of determining the compatibility result of the task state based on the state type corresponding to the state identifier in the mapping relationship and the state type corresponding to the state identifier in the locally maintained metadata includes: When the state type corresponding to the state identifier in the mapping relationship is consistent with the state type corresponding to the state identifier in the meta-information, a first compatibility result representing the compatibility of task states is obtained. Alternatively, if the state type corresponding to the state identifier in the mapping relationship is inconsistent with the state type corresponding to the state identifier in the meta-information, a second compatibility result representing incompatibility of task states is obtained.

2. The method according to claim 1, characterized in that, The step of obtaining the state data corresponding to the state identifier in the mapping relationship according to the preset storage path includes: Historical status data is obtained according to the preset storage path; Obtain the state data corresponding to the state identifier in the mapping relationship from the historical state data.

3. The method according to claim 1, characterized in that, The method further includes: If the compatibility result indicates that the task status is incompatible, an error message is sent.

4. The method according to claim 1, characterized in that, The method further includes: If the task recovery request does not include a preset storage path, create new metadata for the task, and the new metadata includes the mapping relationship; New status data is written based on the new metadata.

5. The method according to claim 1, characterized in that, The task recovery request also includes an array of current task state serializers. The process of obtaining a compatibility result for the task state based on the state type corresponding to the state identifier in the mapping relationship and the state type corresponding to the state identifier in the locally maintained metadata includes: If the state type corresponding to the state identifier in the mapping relationship is consistent with the state type corresponding to the state identifier in the locally maintained metadata, obtain the matching result between the current state serializer array of the task and the locally maintained state serializer array; If the matching result indicates that the current state serializer array matches the locally maintained state serializer array, a compatibility result indicating task state compatibility is obtained.

6. A task processing method, characterized in that, The method includes: After a task is upgraded or a task is repaired, a task recovery request is sent. The task recovery request includes a mapping relationship between the current status identifier of the task and the status type. The task is a real-time computing task. Each real-time computing task in the task corresponds to a task status, and the data type of each real-time computing task is its corresponding status type. The system receives feedback information regarding the task recovery request. If the task recovery request includes a preset storage path, and the compatibility result determined based on the mapping relationship in the task recovery request indicates task state compatibility, then the feedback information includes state data corresponding to the state identifier. Specifically, if the state type corresponding to the state identifier in the mapping relationship is consistent with the state type corresponding to the state identifier in the metadata, a first compatibility result indicating task state compatibility is obtained; or, if the state type corresponding to the state identifier in the mapping relationship is inconsistent with the state type corresponding to the state identifier in the metadata, a second compatibility result indicating task state incompatibility is obtained. The task is restored based on the status data in the feedback information.

7. The method according to claim 6, characterized in that, If the task recovery request does not include a preset storage path, the feedback information includes a metadata creation success indication.

8. A task processing device, characterized in that, The device includes: The receiving unit is configured to execute a task recovery request. The task recovery request includes a mapping relationship between the task's status identifier and status type. The task is a real-time computing task. Each real-time computing task in the task corresponds to a task status. The data type of each real-time computing task is its corresponding status type. The task recovery request is a request sent by the application according to the mapping relationship after the task is upgraded or the task is repaired. The determining unit is configured to, when the task recovery request includes a preset storage path, determine the compatibility result of the task state based on the state type corresponding to the state identifier in the mapping relationship and the state type corresponding to the state identifier in the locally maintained metadata. The compatibility result of the task state is used to characterize whether the historical state data is compatible with the task state. The acquisition unit is configured to, under the condition that the compatibility result characterizes the task status as compatible, acquire the status data corresponding to the status identifier in the mapping relationship according to the preset storage path; The first sending unit is configured to send the status data used to recover the task. The determining unit is further configured to execute: When the state type corresponding to the state identifier in the mapping relationship is consistent with the state type corresponding to the state identifier in the meta-information, a first compatibility result representing the compatibility of task states is obtained. Alternatively, if the state type corresponding to the state identifier in the mapping relationship is inconsistent with the state type corresponding to the state identifier in the meta-information, a second compatibility result representing incompatibility of task states is obtained.

9. The apparatus according to claim 8, characterized in that, The acquisition unit is also configured to perform: Historical status data is obtained according to the preset storage path; Obtain the state data corresponding to the state identifier in the mapping relationship from the historical state data.

10. The apparatus according to claim 8, characterized in that, The device further includes: The second sending unit is configured to send an error message if the compatibility result indicates that the task state is incompatible.

11. The apparatus according to claim 8, characterized in that, The device further includes: The creation unit is configured to create new metadata for the task if the task recovery request does not include a preset storage path, and the new metadata includes the mapping relationship; The writing unit is configured to perform the writing of new state data based on the new metadata.

12. The apparatus according to claim 8, characterized in that, The task recovery request also includes an array of serializers for the current state of the task, and the determining unit is further configured to execute: If the state type corresponding to the state identifier in the mapping relationship is consistent with the state type corresponding to the state identifier in the locally maintained metadata, obtain the matching result between the current state serializer array of the task and the locally maintained state serializer array; If the matching result indicates that the current state serializer array matches the locally maintained state serializer array, a compatibility result indicating task state compatibility is obtained.

13. A task processing device, characterized in that, The device includes: The sending unit is configured to send a task recovery request after a task upgrade or task fault repair. The task recovery request includes a mapping relationship between the current status identifier of the task and the status type. The task is a real-time computing task. Each real-time computing task in the task corresponds to a task status, and the data type of each real-time computing task is its corresponding status type. The receiving unit is configured to receive feedback information in response to the task recovery request. If the task recovery request includes a preset storage path and the compatibility result determined based on the mapping relationship in the task recovery request indicates that the task state is compatible, then the feedback information includes state data corresponding to the state identifier. Specifically, if the state type corresponding to the state identifier in the mapping relationship is consistent with the state type corresponding to the state identifier in the metadata, a first compatibility result indicating task state compatibility is obtained; or, if the state type corresponding to the state identifier in the mapping relationship is inconsistent with the state type corresponding to the state identifier in the metadata, a second compatibility result indicating task state incompatibility is obtained. The recovery unit is configured to perform the task of recovering the status data based on the feedback information.

14. The apparatus according to claim 13, characterized in that, If the task recovery request does not include a preset storage path, the feedback information includes a metadata creation success indication.

15. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the task processing method as described in any one of claims 1 to 7.

16. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is able to perform the task processing method as described in any one of claims 1 to 7.

17. A computer program product, the computer program product comprising instructions, characterized in that, When the instruction is executed by the processor of the electronic device, the electronic device is able to perform the task processing method as described in any one of claims 1 to 7.

Images