Springbatch-based task fault-tolerant processing method and related device

Abstract

The application relates to the technical field of data processing, in particular to a task fault-tolerant processing method based on springbatch and related equipment, which comprises the following steps: obtaining a batch task to be re-executed, sending the number of the batch task to a user end, receiving feedback information of the user end, determining the operation mode of the batch task according to the feedback information, operating the batch task according to the operation mode, recording the operation start time and operation termination time of the batch task, obtaining the data offset generated from the operation start time to the operation termination time, outputting the operation result if the data offset is equal to the number of rows of the batch task, determining the breakpoint position if the data offset is less than the number of rows of the batch task, determining the un-operated task batch according to the breakpoint position, operating the un-operated task batch, and outputting the operation result. The method effectively solves the problem that the fault-tolerant mechanism of the batch processing of SpringBatch mainly processes the code level and is not flexible enough.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a task fault tolerance processing method and related equipment based on Spring Batch. Background Technology

[0002] SpringBatch is a batch processing framework. As a Spring component, it provides the means to handle batch processing using Spring's dependency injection. Spring Batch uses a three-tier architecture: application, core, and basic services. The application layer contains user-written batch processing tasks. The core layer contains the essential classes for executing and controlling tasks, such as the implementations of JobLauncher, Job, and Step. The application and core layers are based on a common layer of basic services. These basic services include common classes like Reader, Writers, and RetryTemplate.

[0003] Currently, SpringBatch's batch processing fault tolerance mechanism is mainly handled at the code level, which is not flexible enough. Adding certain fault tolerance scenarios requires code modification, increasing the risk of system errors. When running batch processing programs on multiple physical nodes, errors cannot be well located and handled, and the degree of data batch processing is not transparent enough. Summary of the Invention

[0004] Based on this, this paper addresses the problem that the current fault tolerance mechanism of SpringBatch batch processing mainly handles issues at the code level, which is not flexible enough. Adding certain fault tolerance scenarios requires code modification, increasing the risk of system errors. This paper provides a task fault tolerance processing method and related equipment based on SpringBatch.

[0005] A task fault tolerance handling method based on Spring Batch includes the following steps:

[0006] Obtain the batch tasks to be re-executed, send the batch tasks to the user terminal, receive feedback information from the user terminal, and determine the running mode of the batch tasks based on the feedback information.

[0007] According to the operating mode, run the batch task and record the start time and end time of the batch task.

[0008] Obtain the data offset generated during the period from the start time of the operation to the end time of the operation;

[0009] If the data offset is equal to the number of rows in the batch task, then output the running result;

[0010] If the data offset is less than the number of rows in the batch task, then the breakpoint position is determined based on the data offset, the unrunn task batch is determined based on the breakpoint position, and the unrunn task batch is rerun and the running result is output.

[0011] In one possible embodiment, the steps of obtaining the batch tasks to be re-executed, sending the batch tasks to the user terminal, receiving feedback information from the user terminal, and determining the running mode of the batch tasks based on the feedback information include:

[0012] Receive abnormal alarm signals from the user terminal and mark the task corresponding to the time node in which the abnormal alarm signal was generated as a batch task to be re-executed;

[0013] Send the batch tasks to the user terminal, receive feedback information from the user terminal, and extract keywords from the feedback information;

[0014] If the keyword is "single machine", then the operating mode is determined to be single machine mode and the batch task is run using the user terminal. If the keyword is "multi-point", then the operating mode is determined to be multi-point mode, and the configuration parameters of each node in the network are obtained. Based on the configuration parameters, the operating parameters for each node to run the batch task are determined.

[0015] In one possible embodiment, the step of running the batch task according to the operating mode and recording the start and end times of the batch task includes:

[0016] If the running mode is single-machine mode, then obtain the data type of the batch task, determine the running thread of the batch task according to the data type, run the batch task, and record the running start time and running end time of the batch task.

[0017] If the operation mode is multi-point mode, the IP address of each node is obtained, and the running node of each batch task in the batch task is determined according to the IP address of each node. The batch tasks are run in sequence, and the start time and end time of each batch task are recorded.

[0018] In one possible embodiment, obtaining the IP addresses of each node and determining the running node for each batch of the batch tasks based on the IP addresses of each node includes:

[0019] Obtain the IP address of each node, determine the connection method based on the IP address of each node, and connect the nodes according to the connection method;

[0020] Obtain the thread ID, determine the number of threads on each node based on the thread ID, and determine the load on each node based on the number of threads;

[0021] Based on the load of each node, determine the running node for each batch of tasks in the batch task.

[0022] In one possible embodiment, obtaining the data offset generated during the period from the start time of the operation to the end time of the operation includes:

[0023] Obtain the number of data in the batch task, and mark the data at the end of the batch task as feature data;

[0024] Record the initial position of the feature data at the start time of the operation and the termination position at the start time of the operation, respectively.

[0025] Calculate the position difference between the termination position and the initial position, and determine the data offset based on the position difference.

[0026] In one possible embodiment, before obtaining the batch tasks to be re-executed, sending the batch tasks to the user terminal, receiving feedback information from the user terminal, and determining the running mode of the batch tasks based on the feedback information, the method further includes:

[0027] Obtain the abnormal signal and determine the task number of the abnormal task based on the generation time of the abnormal signal;

[0028] Based on the processing method of the task number in the preset abnormal task processing table, determine whether the abnormal task is one of the batch tasks to be re-executed.

[0029] In one possible embodiment, before obtaining the batch tasks to be re-executed, sending the batch tasks to the user terminal, receiving feedback information from the user terminal, and determining the running mode of the batch tasks based on the feedback information, the method further includes:

[0030] Obtain the task processing parameters, and determine the task execution method based on the task processing parameters;

[0031] The task operation status is monitored, and when the task triggers the re-execution instruction in the task execution mode, the re-execution instruction is sent to the user terminal.

[0032] A task fault tolerance processing device based on Spring Batch includes the following modules:

[0033] The mode determination module is configured to acquire batch tasks to be re-executed, send the batch tasks to the user terminal, receive feedback information from the user terminal, and determine the running mode of the batch tasks based on the feedback information.

[0034] The time confirmation module is configured to run the batch task according to the running mode and record the start time and end time of the batch task.

[0035] The result output module is configured to obtain the data offset generated during the time period from the start time of the run to the end time of the run; if the data offset is equal to the number of rows of the batch task, the run result is output; if the data offset is less than the number of rows of the batch task, the breakpoint position is determined according to the data offset, the unrun task batch is determined according to the breakpoint position, the unrun task batch is rerun, and the run result is output.

[0036] A computer device includes a memory and a processor, wherein the memory stores computer-readable instructions, which, when executed by the processor, cause the processor to perform the steps of the above-described task fault-tolerant processing method based on SpringBatch.

[0037] A storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the above-described SpringBatch-based task fault-tolerant processing method.

[0038] Compared to existing mechanisms, this application obtains batch tasks to be re-executed, sends the batch tasks to the user terminal, receives feedback information from the user terminal, determines the running mode of the batch tasks based on the feedback information, runs the batch tasks according to the running mode, and records the start and end times of the batch tasks; obtains the data offset generated during the time period from the start time to the end time; if the data offset is equal to the number of rows in the batch tasks, the running result is output; if the data offset is less than the number of rows in the batch tasks, the breakpoint position is determined based on the data offset, the unrunn task batch is identified based on the breakpoint position, and the unrunn task batch is re-run, and the running result is output. This effectively solves the problems that the current SpringBatch batch processing fault tolerance mechanism mainly handles issues at the code level, which is not flexible enough; when running batch processing programs on multiple physical nodes, errors cannot be well located and handled, and the degree of data batch processing is not transparent enough. Attached Figure Description

[0039] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application.

[0040] Figure 1 This is an overall flowchart of a task fault tolerance processing method based on Spring Batch in one embodiment of this application;

[0041] Figure 2 This is a schematic diagram illustrating the process of determining the running mode in a SpringBatch-based task fault-tolerant processing method in one embodiment of this application;

[0042] Figure 3 This is a structural diagram of a task fault-tolerant processing device based on SpringBatch in one embodiment of this application. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0044] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the word “comprising” as used in the specification of this application means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0045] Figure 1 This is an overall flowchart of a Spring Batch-based task fault tolerance processing method in one embodiment of this application. The Spring Batch-based task fault tolerance processing method includes the following steps:

[0046] S1. Obtain the batch tasks to be re-executed, send the batch tasks to the user terminal, receive feedback information from the user terminal, and determine the running mode of the batch tasks based on the feedback information.

[0047] Specifically, tasks awaiting re-execution typically fall into two categories: first, the task is not fully executed; for example, task A has 100 lines, and an exception occurs when executing line 50, causing the task execution to be interrupted; second, the result obtained after task execution exceeds the normal value range. Each task requires a number from the client during execution, and the order of these numbers can be the order in which the tasks were executed.

[0048] User feedback can be received through the fault-tolerant handling interface on the user's end, a web interface written in Vue. This interface allows users to choose to skip error handling after a batch task fails. This is often when a batch of tasks experiences an interruption due to minor data discrepancies. With this setting, the entire batch will continue running, ignoring the error record and not affecting the overall task execution. Users can also choose to roll back after a failed task. This means that if abnormal data occurs halfway through the task and execution cannot continue, all data in the batch can be rolled back, effectively preventing execution. The task will then fetch data again and execute business logic the next time it runs. Alternatively, users can choose to re-execute after failure: this is equivalent to the automatic handling of point 2, where the task is interrupted halfway, and the system will simply re-execute the batch task when it encounters the same parameter. Another option is automatic switching after a failed task, used in multi-machine mode. If the current machine fails, the system can dynamically switch to another running machine to continue execution. Finally, a quick interruption after a failed task is allowed: this is when the user chooses to interrupt, meaning the task is stopped immediately. The system will first find the cause of the interruption, process the abnormal data, and then continue execution. Parallel task calls to multiple servers: This is also a scenario used on multiple machines. A batch of tasks can be set to execute on multiple machines, or it can be set to execute on a specific machine IP.

[0049] After the user selects the operation for the problem task on the fault tolerance processing interface, the user's client will send the selection result to the backend server for processing in the corresponding mode.

[0050] S2. According to the operating mode, run the batch task and record the start time and end time of the batch task.

[0051] Specifically, there are two main operating modes: single-machine mode and multi-point mode. In single-machine mode, the batch task runs on a single machine, fully utilizing its performance. A batchlog is used to record the execution of each record within the batch task. For example, when reading customer data from database A to database B, the task is executed in batches of 100 records (this parameter is configurable). Each time a batch is executed, a corresponding log record is written to the batchlog file. An example is: `insert B database.B1 table values(1,1,1); start record 1,1,1 end record 2,2,2; number of rows 100; offset 100; commit after every 100 rows`. The log file records information such as the source database, target database, specific data record, start data record, end data record, number of rows, and offset, which is useful in case of subsequent batch task anomalies. By consulting the log file, the start and end times of the problematic task can be obtained.

[0052] For a distributed, multi-node operating mode: This method is an extension of the single-node principle. In multi-node mode, it is also necessary to record the node status information of each physical node in the batchlog, such as IP address, machine CPU, memory, number of threads, number of tasks, thread ID, and current batch processing result status. By obtaining and summarizing the log files of each node, the start and end times of the task can be obtained.

[0053] S3. Obtain the data offset generated during the time period from the start time of the operation to the end time of the operation;

[0054] If the data offset is equal to the number of rows in the batch task, then output the running result;

[0055] If the data offset is less than the number of rows in the batch task, then the breakpoint position is determined based on the data offset, the unrunn task batch is determined based on the breakpoint position, and the unrunn task batch is rerun and the running result is output.

[0056] Specifically, if a batch task is interrupted after running to line 100, and you want to restore the entire batch, you can directly execute it according to the current batch's historical log, since the current batch's historical log is complete and it just happened to end at line 100, so you can commit directly.

[0057] When a batch task is interrupted halfway through execution, for example, at line 50, the batchlog records half of the records, along with the data offset and the offset of the previous interrupted batch at line 50. To recover the entire batch, it is necessary to first find the offset of the previous small batch segment, i.e., the line where the previous commit point of the current batch is recorded. Once this line is found and the corresponding offset is located, the data with the complete commit segment is executed first, thus supplementing a portion of the data in the current batch. Then, the commit segment with half of the data recorded is discarded. Since the offset, the start and end points of the data are recorded at this point, the start and end markers and offset of the discarded segment can be found using these parameters. Based on this record, the execution continues from the previous commit segment, thus reconnecting the data.

[0058] In this embodiment, the specific location of the problematic batch task is determined by the offset, thus solving the problem that SpringBatch requires code modifications for batch task fault tolerance processing.

[0059] Figure 2 This is a schematic diagram illustrating the process of determining the running mode in a Spring Batch-based task fault tolerance method in one embodiment of this application. As shown in the figure, step S1 involves obtaining the batch tasks to be re-executed, sending the batch tasks to the user terminal, receiving feedback information from the user terminal, and determining the running mode of the batch tasks based on the feedback information, including:

[0060] S11. Receive the abnormal alarm signal from the user terminal and mark the task corresponding to the time node where the abnormal alarm signal was generated as a batch task to be re-executed.

[0061] Specifically, if an interruption occurs during task processing on the user's end, a data breakpoint will appear in the user's system log. Upon the occurrence of the breakpoint, the user's end will send an alarm signal to the backend server at the time the breakpoint occurred. Simultaneously, a notification will be displayed on the fault-tolerant interface, such as a red alarm message.

[0062] S12. Send the batch task to the user terminal, receive feedback information from the user terminal, and extract keywords from the feedback information;

[0063] Specifically, since multiple tasks may be executed in parallel on the user's end, and these parallel tasks are interconnected, the user typically runs a single task package without assigning numbers to each task within it. In this step, the task numbers for the problematic tasks correspond to different task attributes; for example, if the first character of the number is "A," then the task is a premium amount calculation task, etc.

[0064] S13. If the keyword is "single machine", then the operating mode is determined to be single machine mode and the batch task is run using the user terminal. If the keyword is "multi-point", then the operating mode is determined to be multi-point mode, and the configuration parameters of each node in the network are obtained. Based on the configuration parameters, the operating parameters for each node to run the batch task are determined.

[0065] Specifically, since multiple tasks may be executed in parallel on the user's end, and these parallel tasks are interconnected, the user typically runs a single task package without assigning numbers to each task within it. In this step, the task numbers for the problematic tasks correspond to different task attributes; for example, if the first character of the number is "A," then the task is a premium amount calculation task, etc.

[0066] In this embodiment, by selecting an appropriate running mode for the problem task, code modification is avoided, thus saving time for fault tolerance processing.

[0067] In one embodiment, the step of running the batch task according to the running mode and recording the start and end times of the batch task includes:

[0068] If the running mode is single-machine mode, then obtain the data type of the batch task, determine the running thread of the batch task according to the data type, run the batch task, and record the running start time and running end time of the batch task.

[0069] The data types include byte and int, etc. Different data types determine the number of threads required to run the task, and the load of different threads determines the execution termination time.

[0070] If the operation mode is multi-point mode, the IP address of each node is obtained, and the running node of each batch task in the batch task is determined according to the IP address of each node. The batch tasks are run in sequence, and the start time and end time of each batch task are recorded.

[0071] Specifically, the following steps can be used to determine the running nodes: obtain the IP address of each node, determine the connection method based on the IP address of each node, and connect each node according to the connection method;

[0072] Obtain the thread ID, determine the number of threads on each node based on the thread ID, and determine the load on each node based on the number of threads;

[0073] Based on the load of each node, determine the running node for each batch of tasks in the batch task.

[0074] In this embodiment, different operating modes are selected to make exception handling more convenient and flexible.

[0075] In one embodiment, obtaining the data offset generated during the period from the start time of the operation to the end time of the operation includes:

[0076] Obtain the number of data in the batch task, and mark the data at the end of the batch task as feature data;

[0077] Among them, the marker end data can record the row number of the problem task. When the problem task is executed, the end data will move forward to accurately obtain the offset.

[0078] Record the initial position of the feature data at the start time of the operation and the termination position at the start time of the operation, respectively.

[0079] Calculate the position difference between the termination position and the initial position, and determine the data offset based on the position difference.

[0080] In this embodiment, the offset can accurately identify the batch of problematic tasks, thereby enabling effective continuation of operations and achieving fault tolerance.

[0081] In one embodiment, before obtaining the batch tasks to be re-executed, sending the batch tasks to the user terminal, receiving feedback information from the user terminal, and determining the running mode of the batch tasks based on the feedback information, the method further includes:

[0082] Obtain the abnormal signal and determine the task number of the abnormal task based on the generation time of the abnormal signal;

[0083] Based on the processing method of the task number in the preset abnormal task processing table, determine whether the abnormal task is one of the batch tasks to be re-executed.

[0084] In one embodiment, before obtaining the batch tasks to be re-executed, sending the batch tasks to the user terminal, receiving feedback information from the user terminal, and determining the running mode of the batch tasks based on the feedback information, the method further includes:

[0085] Obtain the task processing parameters, and determine the task execution method based on the task processing parameters;

[0086] The task operation status is monitored, and when the task triggers the re-execution instruction in the task execution mode, the re-execution instruction is sent to the user terminal.

[0087] In this embodiment, some tasks do not need to be re-executed. Even if an error occurs in the task, the error result will be used as the final output result for display.

[0088] The technical features mentioned in any of the corresponding embodiments or implementations above are also applicable to the present application. Figure 3 The corresponding implementation examples will not be repeated hereafter.

[0089] The above describes a Spring Batch-based task fault tolerance processing method in this application. The following describes the execution of the Spring Batch-based task fault tolerance processing device.

[0090] like Figure 3 The diagram illustrates a structure of a Spring Batch-based task fault tolerance processing device, which can be applied to Spring Batch-based task fault tolerance processing. The Spring Batch-based task fault tolerance processing device in this embodiment can achieve the corresponding [specific implementation details]. Figure 1 The steps of the SpringBatch-based task fault tolerance processing method executed in the corresponding embodiments are described. The functionality implemented by the SpringBatch-based task fault tolerance processing device can be achieved through hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-described functionality; these modules can be software and / or hardware.

[0091] In one embodiment, a task fault tolerance processing device based on Spring Batch is proposed, such as... Figure 3 As shown, it includes the following modules:

[0092] The mode determination module 10 is configured to acquire the batch tasks to be re-executed, send the batch tasks to the user terminal, receive feedback information from the user terminal, and determine the running mode of the batch tasks based on the feedback information.

[0093] The time confirmation module 20 is configured to run the batch task according to the running mode and record the start time and end time of the batch task.

[0094] The result output module 30 is configured to obtain the data offset generated during the time period from the start time of the operation to the end time of the operation; if the data offset is equal to the number of rows of the batch task, the operation result is output; if the data offset is less than the number of rows of the batch task, the breakpoint position is determined according to the data offset, the unrun task batch is determined according to the breakpoint position, the unrun task batch is rerun, and the operation result is output.

[0095] In one embodiment, a computer device is provided, the computer device including a memory and a processor, the memory storing computer-readable instructions, which, when executed by the processor, cause the processor to perform the steps of the task fault-tolerant processing method based on springbatch in the above embodiments.

[0096] In one embodiment, a storage medium storing computer-readable instructions is provided. When executed by one or more processors, these computer-readable instructions cause the one or more processors to perform the steps of the SpringBatch-based task fault-tolerant processing method described in the above embodiments. The storage medium can be a non-volatile storage medium or a volatile storage medium; this application does not specifically limit its choice.

[0097] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0098] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0099] The embodiments described above are merely exemplary embodiments of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the appended claims.

Claims

1. A task fault tolerance processing method based on Spring Batch, characterized in that, include: Obtain the batch tasks to be re-executed, send the batch tasks to the user terminal, receive feedback information from the user terminal, and determine the running mode of the batch tasks based on the feedback information. According to the operating mode, run the batch task and record the start time and end time of the batch task. Obtain the data offset generated during the period from the start time of the operation to the end time of the operation; If the data offset is equal to the number of rows in the batch task, then output the running result; If the data offset is less than the number of rows in the batch task, then the breakpoint position is determined based on the data offset, the unrunn task batch is determined based on the breakpoint position, and the unrunn task batch is rerun and the running result is output.

2. The task fault tolerance processing method based on Spring Batch according to claim 1, characterized in that, The steps of obtaining the batch tasks to be re-executed, sending the batch tasks to the user terminal, receiving feedback information from the user terminal, and determining the running mode of the batch tasks based on the feedback information include: Receive abnormal alarm signals from the user terminal and mark the task corresponding to the time node in which the abnormal alarm signal was generated as a batch task to be re-executed; Send the batch tasks to the user terminal, receive feedback information from the user terminal, and extract keywords from the feedback information; If the keyword is "single machine", then the operating mode is determined to be single machine mode and the batch task is run using the user terminal. If the keyword is "multi-point", then the operating mode is determined to be multi-point mode, and the configuration parameters of each node in the network are obtained. Based on the configuration parameters, the operating parameters for each node to run the batch task are determined.

3. The task fault tolerance processing method based on Spring Batch according to claim 2, characterized in that, The step of running the batch tasks according to the operating mode and recording the start and end times of the batch tasks includes: If the running mode is single-machine mode, then obtain the data type of the batch task, determine the running thread of the batch task according to the data type, run the batch task, and record the running start time and running end time of the batch task. If the operation mode is multi-point mode, the IP address of each node is obtained, and the running node of each batch task in the batch task is determined according to the IP address of each node. The batch tasks are run in sequence, and the start time and end time of each batch task are recorded.

4. The task fault tolerance processing method based on Spring Batch according to claim 3, characterized in that, The step of obtaining the IP addresses of each node and determining the running node of each batch task in the batch tasks based on the IP addresses of each node includes: Obtain the IP address of each node, determine the connection method based on the IP address of each node, and connect the nodes according to the connection method; Obtain the thread ID, determine the number of threads on each node based on the thread ID, and determine the load on each node based on the number of threads; Based on the load of each node, determine the running node for each batch of tasks in the batch task.

5. The task fault tolerance processing method based on Spring Batch according to any one of claims 1 to 4, characterized in that, The step of obtaining the data offset generated during the time period from the start time of the operation to the end time of the operation includes: Obtain the number of data in the batch task, and mark the data at the end of the batch task as feature data; Record the initial position of the feature data at the start time of the operation and the termination position at the start time of the operation, respectively. Calculate the position difference between the termination position and the initial position, and determine the data offset based on the position difference.

6. The task fault tolerance processing method based on Spring Batch according to claim 5, characterized in that, Before obtaining the batch tasks to be re-executed, sending the batch tasks to the user terminal, receiving feedback information from the user terminal, and determining the running mode of the batch tasks based on the feedback information, the method further includes: Obtain the abnormal signal and determine the task number of the abnormal task based on the generation time of the abnormal signal; Based on the processing method of the task number in the preset abnormal task processing table, determine whether the abnormal task is one of the batch tasks to be re-executed.

7. The task fault tolerance processing method based on Spring Batch according to claim 5, characterized in that, Before obtaining the batch tasks to be re-executed, sending the batch tasks to the user terminal, receiving feedback information from the user terminal, and determining the running mode of the batch tasks based on the feedback information, the method further includes: Obtain the task processing parameters, and determine the task execution method based on the task processing parameters; The task execution status is monitored, and when the task triggers the re-execution instruction in the task execution mode, the re-execution instruction is sent to the user terminal.

8. A task fault-tolerant processing device based on Spring Batch, characterized in that, Includes the following modules: The mode determination module is configured to acquire batch tasks to be re-executed, send the batch tasks to the user terminal, receive feedback information from the user terminal, and determine the running mode of the batch tasks based on the feedback information. The time confirmation module is configured to run the batch task according to the running mode and record the start time and end time of the batch task. The result output module is configured to obtain the data offset generated during the period from the start time of the operation to the end time of the operation. If the data offset is equal to the number of rows in the batch task, the running result is output; if the data offset is less than the number of rows in the batch task, the breakpoint position is determined according to the data offset, the unrunn task batch is determined according to the breakpoint position, and the unrunn task batch is rerun, and the running result is output.

9. A computer device comprising a memory and a processor, wherein the memory stores computer-readable instructions, characterized in that, When the computer-readable instructions are executed by the processor, the processor performs the steps of the task fault tolerance processing method based on any one of claims 1 to 7.

10. A storage medium storing computer-readable instructions, characterized in that, When the computer-readable instructions are executed by one or more processors, the one or more processors perform the steps of the task fault tolerance processing method based on any one of claims 1 to 7.

Images