Exception processing method and device, computer equipment and computer readable storage medium

Abstract

The invention relates to an exception handling method and device, computer equipment and a computer readable storage medium. The method comprises the steps that after a first task is started, a task identifier bound with the first task is generated; monitoring the working state of the first task based on the task identifier to determine the real-time working state of the first task; when the real-time working state is abnormal, updating a task identifier and recording breakpoint data of the first task; wherein the breakpoint data is associated with a task identifier corresponding to the first task, and is stored in a corresponding breakpoint database; and starting the first task according to a preset de-restart strategy and the breakpoint data. Therefore, the real-time performance of anomaly detection in the business system is improved, the repeated execution risk is reduced, the operation accuracy of the business system is improved, and the stability of the business system and the continuity of the business of the bank are guaranteed based on the real-time performance of anomaly detection of the business system and the operation accuracy of the business system.

Description

Technical Field

[0001] This application relates to the field of banking business system technology, and in particular to an exception handling method, apparatus, computer equipment, and computer-readable storage medium. Background Technology

[0002] In the daily operation of banking systems, there are numerous periodic scheduled tasks that need to be completed. These tasks are often critical supports for core business operations, requiring high timeliness, large data volumes, and high data complexity. When these scheduled tasks malfunction, they can impact various aspects of the bank's operations, and in severe cases, even cause the entire banking system to crash.

[0003] In some related technologies, when anomalies occur in scheduled tasks, manual intervention is relied upon to investigate the anomalies and restart the scheduled task after the anomaly is resolved. However, relying on manual handling of anomalies in scheduled tasks is time-consuming. In addition, restarting the scheduled task after anomaly investigation carries a high risk of duplicate execution, which may lead to repeated execution of already processed data, resulting in data redundancy and affecting the stability and business continuity of banking systems. Summary of the Invention

[0004] Therefore, it is necessary to provide an anomaly handling method, apparatus, computer equipment, and computer-readable storage medium with high recovery capabilities to address the aforementioned technical problems, so as to improve the stability and business continuity of the banking business system after anomalies occur.

[0005] Firstly, this application provides an exception handling method, including:

[0006] Start the first task and generate a task identifier bound to the first task;

[0007] Based on the task identifier, the working status of the first task is monitored to determine the real-time working status of the first task.

[0008] When the real-time working status is abnormal, update the task identifier and record the breakpoint data of the first task; the breakpoint data is associated with the task identifier corresponding to the first task and stored in the corresponding breakpoint database.

[0009] According to the preset deduplication and restart strategy, the first task is started based on the breakpoint data.

[0010] In one embodiment, before starting the first task according to the breakpoint data based on the preset deduplication and restart strategy, the exception handling method further includes:

[0011] Record the number of times the first task was rerun;

[0012] If the number of times the first task is rerun exceeds a preset threshold, the task identifier will be updated to "startup failed" and a prompt message will be output; the prompt message is used to remind the user to check the first task.

[0013] According to the preset deduplication and restart strategy, based on the breakpoint data, the steps to start the first task include:

[0014] If the number of reruns of the first task does not exceed the preset threshold, then the first task will be started according to the preset deduplication and restart strategy and the breakpoint data.

[0015] In one embodiment, after starting the first task according to the breakpoint data based on the preset deduplication and restart strategy, the exception handling method further includes:

[0016] If the first task fails to start, update the number of reruns and diagnose the first task based on the task identifier and breakpoint data to determine the cause of the first task's abnormality.

[0017] If the diagnosis is successful, then the first task will be repaired according to the cause of the anomaly.

[0018] If the repair is successful, the second task is determined, and the repaired second task is started according to the preset deduplication and restart strategy and the breakpoint data.

[0019] In one embodiment, after the step of diagnosing the first task based on the task identifier and breakpoint data to determine the cause of the anomaly in the first task, the anomaly handling method further includes:

[0020] If the diagnosis fails, the first task will be added to the waiting list as the third task, and the number of reruns and the corresponding task identifier of the third task will be updated.

[0021] While waiting for the list to start, the third task is started according to the preset deduplication strategy and the breakpoint data.

[0022] In one embodiment, the step of diagnosing the first task based on the task identifier and breakpoint data to determine the cause of the anomaly in the first task includes:

[0023] Based on the task identifier and breakpoint data, determine the anomaly information corresponding to the first task;

[0024] Based on the anomaly information, obtain the runtime logs and system metrics of the first task;

[0025] Based on the operation logs and system metrics, analyze the cause of the anomaly in the first task; the cause of the anomaly is used to determine the target strategy for repairing the abnormal state of the first task at the time of diagnosis.

[0026] In one embodiment, the step of starting the first task based on breakpoint data according to a preset deduplication and restart strategy includes:

[0027] Based on the breakpoint data, query the breakpoint database for the data range or task node that the first task has completed, and determine the target position to be run in the first task; where the target position is the position in the first task where the completed data range or task node is skipped.

[0028] At the target location, initiate the first task.

[0029] In one embodiment, the first task includes a data processing task or a process processing task, and the processing of data processing tasks and process processing tasks have different forms of expression.

[0030] The steps for recording breakpoint data for the first task include:

[0031] Obtain the range of completed data in the data processing tasks and determine the target data to be completed in the first task; or

[0032] Retrieve completed task nodes in the process processing tasks and determine the target nodes to be completed in the first task;

[0033] Record the target data or target node to the breakpoint database to obtain the breakpoint data of the first task; in the breakpoint database, the breakpoint data is mapped one-to-one with the task identifier.

[0034] Secondly, this application also provides an anomaly handling apparatus, comprising:

[0035] The startup module is used to start the first task and generate a task identifier bound to the first task;

[0036] The monitoring module is used to monitor the working status of the first task based on the task identifier in order to determine the real-time working status of the first task.

[0037] The first processing module is used to update the task identifier and record the breakpoint data of the first task when the real-time working status is abnormal; wherein, the breakpoint data is associated with the task identifier corresponding to the first task and stored in the corresponding breakpoint database.

[0038] The second processing module is used to start the first task according to the preset deduplication and restart strategy and the breakpoint data.

[0039] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0040] Start the first task and generate a task identifier bound to the first task;

[0041] Based on the task identifier, the working status of the first task is monitored to determine the real-time working status of the first task.

[0042] When the real-time working status is abnormal, update the task identifier and record the breakpoint data of the first task; the breakpoint data is associated with the task identifier corresponding to the first task and stored in the corresponding breakpoint database.

[0043] According to the preset deduplication and restart strategy, the first task is started based on the breakpoint data.

[0044] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0045] Start the first task and generate a task identifier bound to the first task;

[0046] Based on the task identifier, the working status of the first task is monitored to determine the real-time working status of the first task.

[0047] When the real-time working status is abnormal, update the task identifier and record the breakpoint data of the first task; the breakpoint data is associated with the task identifier corresponding to the first task and stored in the corresponding breakpoint database.

[0048] According to the preset deduplication and restart strategy, the first task is started based on the breakpoint data.

[0049] The above-mentioned anomaly handling method, apparatus, computer equipment, and computer-readable storage medium, after starting the first task, generate a task identifier bound to the first task; based on the task identifier, monitor the working status of the first task to determine the real-time working status of the first task; when the real-time working status is abnormal, update the task identifier and record the breakpoint data of the first task; wherein the breakpoint data is associated with the task identifier corresponding to the first task and stored in the corresponding breakpoint database; and according to a preset deduplication and restart strategy, start the first task based on the breakpoint data.

[0050] Compared to existing technologies that rely on manual inspection or waiting for business alarms to discover anomalies in business systems, this new technology involves manually reviewing and analyzing complex logs to diagnose the cause of the anomaly. After diagnosing the cause, manual judgment is required on how to fix it, and manual commands are needed to trigger a rerun of the business system. However, in situations where manual detection is impossible, the business system cannot process abnormal tasks in a timely manner, resulting in low real-time performance. Furthermore, when a manual rerun command is issued, it may incorrectly rerun abnormal tasks, potentially increasing redundant data, causing business inconsistencies, and reducing accuracy.

[0051] After the business system starts the first task, this application can generate a task identifier bound to the first task. Based on the task identifier, the real-time working status of the first task is monitored. If the first task is abnormal, the task identifier is updated and the breakpoint data corresponding to the abnormality is recorded. In this way, through the automatic monitoring of the first task in the business system, the task anomaly monitoring of the business system at all times is realized, and the real-time performance of anomaly detection in the business system is improved.

[0052] On the other hand, in addition to real-time monitoring of anomalies in the business system based on task identifiers and corresponding breakpoint data, tasks that have anomalies in the business system can also be rerun according to the recorded breakpoint data and the deduplication and restart strategy. This reduces the risk of repeated execution of tasks that have anomalies in the business system, reduces the generation of redundant data and the occurrence of business logic errors, and improves the accuracy of the business system operation.

[0053] Thus, based on the real-time nature of anomaly detection in the business system and the accuracy of business system operation, the stability of the bank's business system and the continuity of its business are ensured. Attached Figure Description

[0054] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0055] Figure 1 This is a diagram illustrating the application environment of an exception handling method in one embodiment.

[0056] Figure 2 This is a flowchart illustrating an exception handling method in one embodiment;

[0057] Figure 3This is a flowchart illustrating an exception handling method according to another embodiment;

[0058] Figure 4 This is a flowchart illustrating an exception handling method for yet another embodiment.

[0059] Figure 5 Here is a flowchart illustrating an example of an exception handling method;

[0060] Figure 6 This is a structural block diagram of an exception handling device in one embodiment;

[0061] Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0062] 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.

[0063] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0064] The exception handling method provided in this application embodiment can be applied to, for example, Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. Server 104 can initiate the first task in the business system and generate a task identifier corresponding to the first task. Based on this task identifier, server 104 can monitor the working status of the first task. If it determines that the real-time working status of the first task is abnormal, it updates the task identifier and records the breakpoint data where the first task encountered the abnormality. The updated task identifier and the breakpoint data with the corresponding record number are stored in the data storage system. Server 104 can also call the task identifier and breakpoint data in the data storage system and start the first task in the business system according to the deduplication restart strategy to achieve task rerun. The data storage system can store the data that server 104 needs to process. The data storage system can be integrated on server 104 or placed in the cloud or other network servers.

[0065] The terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, and projection equipment. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses.

[0066] Server 104 can be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides cloud computing services.

[0067] In one exemplary embodiment, such as Figure 2 As shown, an exception handling method is provided, which can be applied to... Figure 1 Taking server 104 as an example, the explanation includes steps 21 to 24. Wherein:

[0068] Step 21: Start the first task and generate a task identifier bound to the first task.

[0069] The first task can be a task that needs to be run periodically in different business systems of the bank.

[0070] For example, the first task can be a scheduled task that needs to be executed periodically in various business systems of the bank. For instance, the clearing business system needs to clear batch transactions across institutions every morning; the reconciliation business system needs to reconcile account balances at the top of the hour during the day; and the bill generation system needs to generate customer bills at fixed time intervals.

[0071] The task identifier can be a globally unique identifier assigned to the first task. This task identifier can be the state management anchor point of the first task during its operation in the business system, and can be used to monitor and track the running status of the first task.

[0072] It should be noted that starting the first task can be a task initiated in the business system that needs to be executed multiple times periodically. That is, the first task can be a task with multiple cycles, and it needs to be executed multiple times within those multiple cycles. Starting the first task can also be a task initiated in the business system that needs to be executed once or multiple times at preset times. That is, the first task can also be a task with one or more timed executions, and it needs to be executed once or multiple times at preset times.

[0073] Accordingly, when starting the first task, a task identifier bound to each first task can be generated. This task identifier can mark the status of the first task and report the status of the first task to determine the real-time working status of the first task.

[0074] If the first task is a task that includes multiple cycles, the corresponding task identifier can perform state management on the multiple executions within each cycle of the first task. State management can include whether it is triggered within the cycle, whether it runs normally after being triggered, and whether the task is completed within each cycle. If the first task is a timed task that includes one or more times, the corresponding task identifier can perform state management on the first task at each breakpoint that needs to be executed. State management can include whether it is executed at each target breakpoint and whether any runtime exceptions occur during execution.

[0075] Step 22: Based on the task identifier, monitor the working status of the first task to determine the real-time working status of the first task.

[0076] The real-time working status can be based on the task identifier to mark the working status of the first task in real time and report the confirmed status result.

[0077] Here, the task identifier serves as the state management anchor point for the first task during its runtime in the business system, and the task identifier can be associated with the state attributes of the first task. During the execution of the first task, the real-time working status of the first task can be reported and updated at key runtime nodes based on the task execution engine or business logic code.

[0078] For example, the task identifier may include multiple status attributes such as: pending execution, in execution, completed, interrupted and awaiting rerun, and failed rerun. For instance, after starting the first task and generating the corresponding task identifier, the task identifier of the first task can be marked as "pending execution". When the first task starts processing data services, the task identifier corresponding to the first task can be marked and reported as "in execution". When the business logic of the first task is successfully executed, the task identifier corresponding to the first task can be marked and reported as "completed".

[0079] It should be noted that, based on the task identifier, the working status of the first task is monitored by marking the working status of the first task through the task identifier. After marking the working status of the first task at each node, the working status of the first task is reported to the terminal in real time, and the task identifier of the first task is updated based on the reported working status. In this way, the working status of the first task can be monitored based on the task identifier, and the real-time working status of the first task can be determined according to the status attribute updated in real time based on the task identifier.

[0080] In another embodiment, the first task may disappear abruptly during operation due to external reasons. When it disappears abruptly, the first task cannot report its status to the terminal, and consequently, its task identifier cannot be updated, making it impossible to monitor its working status. To address this, for first tasks with long execution times, a heartbeat signal can be reported to the terminal at fixed time intervals, allowing the terminal to continuously monitor the first task based on this heartbeat signal.

[0081] For example, due to server downtime, the execution process of the first task is forcibly interrupted, and the task identifier corresponding to the first task cannot mark the working status of the first task. Similarly, the server cannot report the status of the first task. However, the first task is configured to send a heartbeat message to the status management system every 30 seconds. If the heartbeat message of the first task is not received within the preset timeout period, the status management system can determine that the first task has lost response, mark the status attribute of the first task as "abnormal" or "interrupted", and update the task identifier corresponding to the first task. Based on the task identifier, the working status of the first task is monitored.

[0082] Step 23: When the real-time working status is abnormal, update the task identifier and record the breakpoint data of the first task.

[0083] The breakpoint data is associated with the task identifier corresponding to the first task and stored in the corresponding breakpoint database.

[0084] Here, breakpoint data can refer to the data related to the breakpoint when the real-time working status of the first task is abnormal. The breakpoint data can include the breakpoint when the first task is abnormal, the range of processed content before the breakpoint, and the range of unprocessed content after the breakpoint.

[0085] This breakpoint data can be used to represent the execution process of the first task at the breakpoint where an exception occurs.

[0086] The breakpoint data is associated with the task identifier corresponding to the first task. Specifically, there is a mapping relationship between the breakpoint data and the task identifier corresponding to the first task. The breakpoint data can also be used to indicate the execution of the status attribute corresponding to the task identifier.

[0087] It should be noted that an anomaly in the real-time working status of the first task could be due to an interruption during its execution. Therefore, when the first task is interrupted, its current status attributes can be reported to the server, and the task identifier corresponding to the first task can be updated based on the reported status attributes. After updating the task identifier, the breakpoint data corresponding to the first task can be recorded.

[0088] For example, when the first task is interrupted, the status attribute of the first task can be marked as "interrupted", and the first interruption time when the first task was processing data during execution, as well as the processed data and unprocessed data before and after the interruption time, can be obtained to obtain the breakpoint data corresponding to the first task.

[0089] In some implementations, after determining the task identifier and breakpoint data corresponding to the first task whose real-time working status is abnormal, the task identifier and breakpoint data corresponding to the first task can be stored in a separate breakpoint database.

[0090] In one specific implementation, the first task includes a data processing task or a process processing task, and the processing progress of the data processing task and the process processing task have different manifestations; the step of recording the breakpoint data of the first task includes: obtaining the range of data that has been completed in the data processing task and determining the target data to be completed in the first task; or obtaining the task nodes that have been completed in the process processing task and determining the target nodes to be completed in the first task; recording the target data or target nodes to the breakpoint database to obtain the breakpoint data of the first task; wherein, in the breakpoint database, the breakpoint data is mapped one-to-one with the task identifier.

[0091] Step 24: According to the preset deduplication and restart strategy, start the first task based on the breakpoint data.

[0092] The preset deduplication restart strategy can be a restart strategy that restarts the first task when the real-time working status of the first task is abnormal. This preset deduplication restart strategy can skip the range of content processed by the first task before the breakpoint where the abnormality occurred, and start from the range of content that the first task has not processed after the breakpoint where the abnormality occurred, restart the first task and continue running the content to be executed in the first task.

[0093] After detecting an anomaly in the first task, updating its corresponding task identifier, and recording the breakpoint data at the moment the anomaly occurred, it can be determined whether the first task can be restarted. If the first task can be restarted, its corresponding task identifier is updated, and the first task is restarted based on the breakpoint data.

[0094] It should be noted that, according to the preset deduplication restart strategy, the first task that encounters an abnormal state and restarts can be restarted based on the breakpoint time of the abnormality recorded in the breakpoint data, the range of processed content before the breakpoint time, and the range of unprocessed content after the breakpoint time. The first task is then restarted, skipping the range of processed content before the breakpoint time and continuing to execute the unprocessed content range after the breakpoint time. In this way, the purpose of rerunning the first task is achieved, thus avoiding the repeated execution of the processed content in the first task after restarting, and avoiding the generation of unnecessary redundant data.

[0095] In one specific implementation, the step of starting the first task according to the preset deduplication and restart strategy and the breakpoint data includes: querying the breakpoint database for the data range or task node that the first task has completed, and determining the target position to be run in the first task; wherein, the target position is the position in the first task where the completed data range or task node is skipped.

[0096] For example, after detecting an anomaly in the first task, marking the task identifier corresponding to the first task as "interrupted" or "abnormal," and recording the breakpoint data corresponding to the breakpoints of the first task at the "interrupted" or "abnormal" timestamps, if it is determined that the first task can be restarted, the task identifier corresponding to the first task can be updated again to "interrupted and awaiting rerun," and the process can wait for the first task to be rerun. When starting to rerun the first task, the first task can be restarted, and based on the recorded breakpoint data corresponding to the first task, the already executed content range can be skipped, and the unprocessed content range of the first task can be continued from the unexecuted content range.

[0097] In the above-described anomaly handling method, after starting the first task, a task identifier bound to the first task is generated; based on the task identifier, the working status of the first task is monitored to determine its real-time working status; when the real-time working status is abnormal, the task identifier is updated and the breakpoint data of the first task is recorded; wherein, the breakpoint data is associated with the task identifier corresponding to the first task and stored in the corresponding breakpoint database; according to a preset deduplication and restart strategy, the first task is started based on the breakpoint data. Through automatic monitoring of the first task in the business system, full-time task anomaly monitoring of the business system is achieved, improving the real-time performance of anomaly detection in the business system. Based on the recorded breakpoint data, according to the deduplication and restart strategy, the abnormal tasks in the business system are rerun, thereby reducing the risk of repeated execution of abnormal tasks in the business system, reducing the generation of redundant data and the occurrence of business logic errors, and improving the accuracy of business system operation. Thus, based on the real-time performance of business system anomaly detection and the accuracy of business system operation, the stability of the bank's business system and the continuity of business are guaranteed.

[0098] In one exemplary embodiment, such as Figure 3 As shown, an exception handling method is provided. Before step 24, the exception handling method of this application embodiment further includes steps B241 to B242. Wherein:

[0099] Step B241: Record the number of times the first task is rerun.

[0100] The rerun count is used to record the number of times the first task is rerun after it is detected to be in an abnormal state for the first time after normal operation. The rerun count can be used to represent the number of reruns performed by the first task during the abnormal handling process.

[0101] Here, there is a preset threshold for the number of times the first task can be rerun, and this preset threshold can be customized according to the importance of the first task.

[0102] In step B242, if the number of times the first task is rerun exceeds the preset threshold, the task identifier is updated to start failure, and a prompt message is output.

[0103] The prompt message is used to remind the user to check the first task.

[0104] Here, if the number of times the first task is rerun exceeds the preset threshold, it means that the first task cannot be restarted after rerunning and repair. Therefore, a prompt message can be output to prompt manual intervention for the first task.

[0105] Step 24: According to the preset deduplication and restart strategy, start the first task based on the breakpoint data.

[0106] In one specific implementation, if the number of times the first task is rerun does not exceed a preset threshold, the first task is started according to the preset deduplication and restart strategy and the breakpoint data.

[0107] Here, if the number of times the first task is rerun does not exceed the preset threshold, it means that the first task can be effectively restarted after diagnosis and repair if the real-time working status is determined to be abnormal.

[0108] Therefore, if it is determined that the number of times the first task is rerun does not exceed the preset threshold, the first task can be started according to the preset deduplication and restart strategy based on the breakpoint data.

[0109] In the above-mentioned exception handling method, by recording the number of times the first task is rerun, it can be ensured that the first task can still be rerun if the number of reruns is within the preset threshold. If the number of reruns of the first task is outside the preset threshold, a prompt message can be output to prompt manual intervention. In this way, when the first task has a relatively complex exception, it can still be handled manually, thus improving the scenario adaptability of exception handling.

[0110] In one exemplary embodiment, such as Figure 4 As shown, after step 24, the exception handling method of this application embodiment further includes steps A241 to A243. Wherein:

[0111] In step 24, after starting the first task according to the preset deduplication and restart strategy and based on the breakpoint data, there may also be a case of restart failure. Here, if the first task first determines an abnormal running state and restarts, the first task may fail to restart.

[0112] Step A241: If starting the first task fails, update the number of reruns and diagnose the first task based on the task identifier and breakpoint data to determine the cause of the first task's abnormality.

[0113] Here, if the first task is found to be in an abnormal running state for the first time and is restarted for the first time, and the restart fails, the number of reruns for the first task can be updated, that is, the number of reruns for the first task can be increased by one.

[0114] In addition, the first task can be diagnosed to determine the cause of the anomaly. Specifically, the first task can be diagnosed based on the task identifier and breakpoint data corresponding to the first task, thereby determining the cause of the anomaly.

[0115] It should be noted that diagnosing the first task based on the task identifier and breakpoint data can be done by judging the first task based on the diagnostic logic corresponding to the cause of the anomaly, and determining the corresponding cause of the anomaly.

[0116] In one specific implementation, the step of diagnosing the first task based on the task identifier and breakpoint data to determine the cause of the anomaly in the first task includes:

[0117] (1) Determine the anomaly information corresponding to the first task based on the task identifier and the breakpoint data.

[0118] (2) Based on the anomaly information, obtain the running log and system indicators of the first task.

[0119] (3) Based on the operation log and system indicators, the cause of the abnormality of the first task.

[0120] Among them, the cause of the anomaly is used to determine the target strategy for repairing the abnormal state corresponding to the first task at the diagnosis time.

[0121] For example, the diagnostic logic for this first task and its corresponding reasons for exceptions can be found in the following:

[0122] 1. Determine the target file corresponding to the first task based on the task identifier, and check the access log in the target file based on the breakpoint data. If a "FileLockedException" exception occurs, the system file management interface can be called to confirm that the current process holding the target file is a historical residual task process. Then, it can be determined that the exception of the first task is a temporary file lock conflict.

[0123] 2. Collect real-time metrics from the database connection pool, including the number of active connections, the number of idle connections, and the maximum number of connections. If the number of active connections is equal to the maximum number of connections, and the number of idle connections is 0, and no connection is obtained within a preset time (10 seconds) after the task initiates a connection request, then the abnormal reason is determined to be that the connection pool is exhausted.

[0124] 3. Check the communication logs between the first task and the cache service. If there are 3 consecutive connection timeouts (timeout time is 5 seconds / timeout), the cache service health check interface can be called. If it returns "not running", the reason for the abnormality is that the cache service is temporarily unavailable.

[0125] 4. Read the maximum number of child processes configured for the main task and call the system process management interface to count the number of child processes associated with the current main task. If the number of child processes associated with the current main task exceeds the maximum number of child processes and there are child processes that have been running for more than the preset time (30 minutes), the cause of the abnormality is determined to be residual child task processes.

[0126] 5. Check the task startup log. If a ConfigurationException occurs and the exception points to the currently loaded configuration file version, compare it with the latest backup version on the configuration file server. If the currently loaded version has missing fields and / or format errors, then the exception is determined to be due to the temporary failure to load the configuration file.

[0127] Step A242: If the diagnosis is successful, then repair the first task according to the cause of the abnormality to obtain the second task.

[0128] After the first task is diagnosed and the diagnosis is successful, the first task can be repaired. The repair plan can be determined according to the cause of the anomaly.

[0129] For example, the cause of the anomaly in the first task and the corresponding solution can be found in the following:

[0130] 1. When the cause of the exception is a temporary file lock conflict, the system process kill interface can be called to forcibly terminate the historical residual task process. Specifically, the historical residual task can be accurately located by process ID to avoid accidentally killing other processes; clear the temporary lock mark of the target file, for example, delete the hidden ".lock" file in the file directory; generate a file lock repair log to record the residual process ID and the corresponding repair time.

[0131] After determining that the cause of the anomaly is a temporary file lock conflict and the corresponding repair solution, the repaired task can be verified. Specifically, you can try to obtain read and write permissions for the target file again. If successful, the repair is complete; if it fails, for example, if the residual process cannot be terminated, the cause is upgraded to a file lock conflict requiring manual intervention, triggering an alarm to prompt manual intervention.

[0132] 2. When the cause of the exception is that the database connection pool is exhausted, the database connection pool management interface can be called to forcibly reclaim active connections that have been idle for more than a preset time (10 minutes). Here, non-core business connections can be reclaimed first; the maximum number of connections in the current task's connection pool can be temporarily increased to ensure that the task has enough connections; the number of connections reclaimed and the temporary expansion parameters can be recorded.

[0133] After determining that the cause of the anomaly is the exhaustion of the database connection pool and the corresponding repair plan, the repaired task can be verified. Specifically, the number of idle connections in the connection pool can be checked. If the number of idle connections in the connection pool is ≥5, which meets the minimum connection requirement of the task, the repair is complete. If the number of idle connections is still 0, wait for a preset time (30 seconds) and then reclaim them again.

[0134] 3. When the cause of the anomaly is that the cache service is temporarily unavailable, it can automatically switch to the cache service backup node through the preset primary and backup node list; if the backup node is also unavailable, it will trigger cache origin fallback, directly skip the cache and read the required data from the database, and record the fallback log at the same time; continuously monitor the status of the primary node, and automatically switch back after the primary node recovers.

[0135] After determining that the cause of the anomaly is the temporary unavailability of the caching service and the corresponding repair plan, the repaired task can be verified. Specifically, after switching the standby node, try reading the cached data. If successful, the repair is complete; if the standby node is unavailable, after confirming that the database read is successful, the downgrade repair is considered complete.

[0136] 4. When the cause of the abnormality is a residual subtask process, the residual subprocess can be located by sorting the subprocesses by their runtime in descending order and using the association ID between the subprocess and the main process. The residual subprocesses that have been running for more than the preset time (30 minutes) can be forcibly terminated. The temporary log files generated by the subprocesses, such as "subtask_xxx.log", can be cleaned up to free up disk space. The maximum number of subprocesses of the main task can be temporarily increased to prevent the limit from being exceeded again in the future.

[0137] After determining that the cause of the anomaly is the residual subtask process and the corresponding repair solution, the repaired task can be verified. Specifically, the current number of subprocesses can be counted. If it is less than or equal to the original maximum number of subprocesses, the repair is complete. If the number of subprocesses still exceeds the limit, the task will be terminated again after waiting for a preset time (20 seconds).

[0138] 5. When the error is due to a temporary failure to load the configuration file, the system can automatically retrieve the latest backup version from the configuration file server to overwrite the currently loaded incorrect version; call the configuration file verification interface to verify the integrity and format correctness of the fields in the new version; and record the configuration file version switching history.

[0139] After determining that the cause of the anomaly is the failure to temporarily load the configuration file and the corresponding repair solution, the repaired task can be verified. Specifically, the configuration file can be reloaded. If no "ConfigException" occurs, the repair is complete. If the backup version also has errors, a configuration file error alarm will be triggered, prompting manual intervention.

[0140] Based on the repair strategies corresponding to the above-mentioned abnormal causes, the first task is repaired to obtain the repaired second task.

[0141] Step A243: If the repair is successful, start the second task after repair according to the preset deduplication and restart strategy and the breakpoint data.

[0142] If the second task is successfully repaired, the repaired second task will be started according to the preset deduplication and restart strategy and the breakpoint data.

[0143] Following step A242, the process of repairing the first task also includes handling cases where the repair of the first task is unsuccessful. Specifically, if the repair of the first task is unsuccessful, a prompt message can be output to request manual intervention.

[0144] In this example, by directly determining the repair plan for the anomaly of the first task based on the cause of the anomaly, the efficiency of anomaly handling can be improved.

[0145] In one exemplary embodiment, such as Figure 5 As shown, after step A242, the exception handling method of this application embodiment further includes steps A2421 to A2422. Wherein:

[0146] Step A2421: If the diagnosis fails, add the first task as the third task to the waiting list, and update the number of reruns and the corresponding task identifier for the third task.

[0147] Step A2422: When the waiting list starts, start the third task according to the preset deduplication and startup strategy and the breakpoint data.

[0148] In step A242, after diagnosing the first task to determine the cause of the anomaly, the procedure also includes a solution for unsuccessful diagnosis of the first task.

[0149] Here, if the diagnosis of the first task is unsuccessful, the first task column is added to the pending list and marked as the third task.

[0150] It should be noted that if the diagnosis of the first task fails, the number of reruns for the first task needs to be updated.

[0151] When the third task is selected to start in the waiting list, it can be started according to the preset deduplication strategy and the breakpoint data.

[0152] This application enables multiple automatic reruns of the first task when it fails to diagnose, by including the first task in the waiting list. The system can protect the task process multiple times in case of abnormal situations in the first task.

[0153] The following is a detailed implementation of this application. Specifically, taking the "daily batch transaction clearing scheduled task at 2:00 AM" in the banking system as an example, the task identifier of the "daily batch transaction clearing scheduled task at 2:00 AM" task, that is, the task instance ID, is: CLEAR_20241001_0200, and the transaction data to be processed by the task includes: ID1-10000.

[0154] I. Task Initialization and First Interrupt

[0155] Every day at 2:00 AM, a scheduled task is triggered. After the task is triggered, a task instance ID can be generated through the status marking module: CLEAR_20241001_0200, and the status can be set to "pending execution".

[0156] At 2:01, the task started, the status was updated to "Executing", and it began reading the liquidation temporary file (path: / data / clear / temp_20241001.txt).

[0157] At 2:03, the task threw a "FileLockedException", interrupting execution and updating its status to "interrupted and awaiting rerun".

[0158] The automatic rerun module triggers the failure reason diagnosis submodule to diagnose the reason for the abnormality of the task. Specifically, it can find out through log parsing that the temporary file is occupied by the "historical residual process (PID: 12345, which is the residual of yesterday's liquidation task)", and determine that the reason for the abnormality is "temporary file lock conflict".

[0159] II. First Automatic Repair and Rerun

[0160] 2:03:05: The automatic repair execution submodule was triggered, and the residual process with PID: 12345 was forcibly terminated by calling the system interface; the lock file ".temp_20241001.lock" in the temporary file directory was deleted; the attempt to regain read and write permissions for the temporary files was successful, and the repair was completed.

[0161] 2:03:10: The automatic rerun module restarts and reruns (not counted in the "3 times threshold"). The deduplication execution module queries the breakpoint through the instance ID. If there is no historical breakpoint in the first execution, the task starts execution from transaction ID1.

[0162] At 2:08 AM: When the task reached transaction ID 3000, it threw a "Connectionpool exhausted" error and was interrupted again. The status remained "interrupted and waiting to be restarted". The diagnostic submodule can collect database connection pool metrics: active connections = 50 (maximum connections = 50), idle connections = 0. The cause of the error is determined to be "database connection pool exhausted".

[0163] III. Second Automatic Repair and Rerun

[0164] 2:08:05: "Automatic Repair Execution Submodule" triggered: Call the connection pool management interface to reclaim "active connections with idle time exceeding 10 minutes" (a total of 8 connections were reclaimed, all of which were non-core reconciliation task connections); temporarily increase the maximum number of connections in the connection pool from 50 to 60 (not exceeding the system limit of 80); check the connection pool status: number of idle connections = 8, meeting the task requirements, repair completed;

[0165] 2:08:15: The automatic rerun module restarts and reruns again (still not included in the threshold). The deduplication execution module queries the breakpoint by instance ID: "Transaction ID1-3000". The task starts clearing directly from 3001.

[0166] 2:15: When the task reached transaction ID 6500, a "Redisconnectiontimeout" was thrown, marking the third interruption. The status remained "interrupted and awaiting rerun".

[0167] The diagnostic submodule detected that three consecutive connections to the Redis master node (IP: 192.168.1.100) timed out, and the health check interface returned "down", indicating that "the cache service is temporarily unavailable".

[0168] The breakpoint recording module updates "Processed Breakpoints" to "Transaction ID1-6500" and stores it in the breakpoint database in association with the instance ID.

[0169] IV. The third automatic repair and rerun is complete.

[0170] 2:15:05: The automatic repair execution submodule is triggered, automatically switching to the standby node (IP: 192.168.1.101) from the preset Redis primary / standby list; an attempt is made to read the liquidation rate cache from the standby node, the read is successful, and the repair is complete;

[0171] 2:15:10: The automatic rerun module restarts and reruns (not included in the threshold), the deduplication execution module reads the latest breakpoint "Transaction ID1-6500", and the task starts clearing from 6501;

[0172] 2:28 PM: The task successfully completed the clearing of transactions 1-10000. The status marker module updated the status to "Completed", and the automatic rerun process terminated.

[0173] The breakpoint database records the corresponding endpoint information, which includes three reasons for the interruption (file lock conflict, connection pool exhaustion, cache unavailability), corresponding repair methods, and the starting point for rerunning, for subsequent auditing and tracing.

[0174] V. Repairing Failure Scenario

[0175] If the above "temporary unavailability of cache service" repair fails, at 2:15:05: after the repair submodule switches to the backup node, it still cannot read cache data, triggering "cache back to origin downgrade", and directly reads the settlement rate from the business system database (192.168.2.100);

[0176] 2:15:10: Database read successful, "downgrade repair complete", restart normally;

[0177] If the database cannot be read either: the repair submodule determines that "manual intervention is required" and counts this failure as "3 rerun threshold" (the current cumulative number of reruns becomes 1).

[0178] The automatic rerun module will initiate a second rerun after a 5-minute interval (2:20 PM) according to the original strategy. If it still fails, it will initiate a third rerun. If all three reruns fail, the status will be updated to "rerun failed", a prompt message will be output, and an alarm will be pushed to the maintenance personnel via SMS and email to prompt manual intervention.

[0179] VI. Scenarios requiring manual intervention

[0180] The task instance ID is “CLEAR_20241002_0200”, which requires the clearing of transaction IDs 1-10000. The first interruption occurred at transaction ID 3000. The system automatically re-run 3 times, but all failed due to “the core database is temporarily unavailable”. The status was updated to “re-run failed” and the operation and maintenance personnel received an alarm.

[0181] Operations and maintenance personnel can log in to the financial system operations and maintenance platform to view the details of the task, including the processed breakpoints (transaction IDs 1-3000), the reasons for the automatic rerun failure (database connection timeout), and the clearing batch number associated with the task.

[0182] The maintenance personnel verified that the database had been restored to normal and entered the employee number "OP_001" and the reason for the operation: the automatic rerun failed due to database abnormality. Now, the manual rerun is initiated. After a second confirmation, the manual rerun request is submitted.

[0183] The system reuses the deduplication logic by default, starting the settlement from transaction ID 3001. Operations personnel can view the rerun progress in real time, such as "3001-6000 completed" and "6001-8000 in process".

[0184] If the rerun is interrupted again due to "abnormal format of some transaction data", the breakpoint will be updated to "Transaction ID1-7500". The operations and maintenance personnel can manually adjust the starting processing point to 7501, enter the reason "Data before 7500 has been verified to be correct, continue from 7501", and initiate the manual rerun again.

[0185] The rerun was successful, the task status was updated to "completed", the operation log (employee ID, time, adjustment record) was synchronized to the audit system, and a notification was pushed to the business manager that "this batch of settlement has been completed through manual rerun".

[0186] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0187] Based on the same inventive concept, this application also provides an exception handling apparatus for implementing the exception handling method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more exception handling apparatus embodiments provided below can be found in the limitations of the exception handling method described above, and will not be repeated here.

[0188] In one exemplary embodiment, such as Figure 6 As shown, an anomaly handling device is provided, comprising: a startup module, a monitoring module, a first processing module, and a second processing module, wherein:

[0189] The startup module is used to start the first task and generate a task identifier bound to the first task;

[0190] The monitoring module is used to monitor the working status of the first task based on the task identifier in order to determine the real-time working status of the first task.

[0191] The first processing module is used to update the task identifier and record the breakpoint data of the first task when the real-time working status is abnormal; wherein, the breakpoint data is associated with the task identifier corresponding to the first task and stored in the corresponding breakpoint database.

[0192] The second processing module is used to start the first task according to the preset deduplication and restart strategy and the breakpoint data.

[0193] Each module in the above-mentioned exception handling device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0194] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 7 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores task identifiers and breakpoint data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When executed by the processor, the computer program can implement an exception handling method.

[0195] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 7As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements an exception handling method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0196] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0197] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0198] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0199] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0200] It should 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 analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0201] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0202] 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 application.

[0203] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent 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 protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. An exception handling method, characterized in that, The method includes: Start the first task and generate a task identifier bound to the first task; Based on the task identifier, the working status of the first task is monitored to determine the real-time working status of the first task. When the real-time working state is abnormal, the task identifier is updated and the breakpoint data of the first task is recorded; wherein, the breakpoint data is associated with the task identifier corresponding to the first task and stored in the corresponding breakpoint database; According to the preset deduplication and restart strategy, the first task is started based on the breakpoint data.

2. The anomaly handling method according to claim 1, characterized in that, Before the step of starting the first task according to the breakpoint data based on the preset deduplication and restart strategy, the exception handling method further includes: Record the number of times the first task is rerun; If the number of retries for the first task exceeds a preset threshold, the task identifier will be updated to "startup failed," and a prompt message will be output; wherein, the prompt message is used to remind the user to check the first task. The step of starting the first task according to the preset deduplication and restart strategy and based on the breakpoint data includes: If the number of times the first task is rerun does not exceed the preset threshold, then the first task is started according to the preset deduplication and restart strategy and the breakpoint data.

3. The anomaly handling method according to claim 2, characterized in that, After the step of starting the first task according to the breakpoint data based on the preset deduplication and restart strategy, the exception handling method further includes: If starting the first task fails, the number of reruns is updated, and the first task is diagnosed based on the task identifier and the breakpoint data to determine the cause of the first task's abnormality. If the diagnosis is successful, the first task will be repaired according to the cause of the anomaly. If the repair is successful, the second task is determined, and the repaired second task is started according to the preset deduplication and restart strategy and the breakpoint data.

4. The anomaly handling method according to claim 3, characterized in that, After the step of diagnosing the first task based on the task identifier and the breakpoint data to determine the cause of the anomaly in the first task, the anomaly handling method further includes: If the diagnosis fails, the first task will be added to the waiting list as the third task, and the number of reruns and the corresponding task identifier of the third task will be updated. When the waiting list is started, the third task is started according to the preset deduplication and startup strategy and the breakpoint data.

5. The anomaly handling method according to claim 3, characterized in that, The step of diagnosing the first task based on the task identifier and the breakpoint data to determine the cause of the anomaly in the first task includes: Based on the task identifier and the breakpoint data, determine the anomaly information corresponding to the first task; Based on the anomaly information, obtain the operation log and system metrics of the first task; Based on the operation logs and system metrics, analyze the cause of the anomaly in the first task; wherein, the cause of the anomaly is used to determine the target strategy for repairing the abnormal state of the first task at the diagnostic time.

6. The anomaly handling method according to claim 1, characterized in that, The step of starting the first task according to the preset deduplication and restart strategy and based on the breakpoint data includes: Based on the breakpoint data, query the breakpoint database for the data range or task node that the first task has completed, and determine the target position to be run in the first task; wherein, the target position is the position in the first task where the completed data range or task node is skipped. At the target location, initiate the first task.

7. The anomaly handling method according to any one of claims 1 to 6, characterized in that, The first task includes data processing tasks or process processing tasks, and the processing of data processing tasks and process processing tasks takes different forms. The step of recording the breakpoint data of the first task includes: Obtain the range of completed data in the data processing tasks and determine the target data to be completed in the first task; or Obtain the completed task nodes in the process processing task and determine the target node to be completed in the first task; Record the target data or the target node to the breakpoint database to obtain the breakpoint data of the first task; wherein, in the breakpoint database, the breakpoint data is mapped one-to-one with the task identifier.

8. An anomaly handling device, characterized in that, The device includes: The startup module is used to start the first task and generate a task identifier bound to the first task; The monitoring module is used to monitor the working status of the first task based on the task identifier, so as to determine the real-time working status of the first task. The first processing module is used to update the task identifier and record the breakpoint data of the first task when the real-time working state is abnormal; wherein the breakpoint data is associated with the task identifier corresponding to the first task and stored in the corresponding breakpoint database. The second processing module is used to start the first task according to the breakpoint data based on the preset deduplication and restart strategy.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images