Abnormality processing method and device, electronic equipment and computer readable medium

Abstract

The invention discloses an exception handling method and device, electronic equipment and a computer readable medium, and relates to the technical field of computers.The specific implementation mode comprises the steps that in response to a service calling exception, a corresponding upstream system identifier and a corresponding downstream system identifier are determined; judging an exception type, and determining target logic according to the exception type; executing the target logic, and generating return result information; determining the type of the returned result information, and determining a target system according to the type of the returned result information; and obtaining calculation result data corresponding to the target system, and executing the result processing logic based on the calculation result data to obtain target result data. Therefore, the consumption of computing resources is reduced, the consumption of expensive storage medium resources is reduced, and the system cost is reduced.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular, to an exception handling method, apparatus, electronic device, and computer-readable medium. Background Art

[0002] Currently, in a distributed system, the problem of service call timeout often occurs, which has a certain impact on data consistency. When solving the problem of data inconsistency caused by interface call timeout, a solution to ensure eventual consistency is usually adopted. Since the business processing logics of each system in the call chain are different and the corresponding processing is also different, in the existing solutions, each system in the call chain has to record the processing result of the current system and establish a result confirmation mechanism for this system. When a timeout occurs in calling the downstream system, the result confirmation mechanism of this system is started, and the processing result of the downstream system is obtained through reverse lookup, then the result calculation of this system is performed, and the processing result of this system is stored for providing reverse lookup of the result for the upstream when a timeout occurs in the upstream. Therefore, each system needs to save a copy of the result data of this system, and each system needs to establish a result confirmation mechanism for this system. In a distributed environment, when handling service call exceptions and ensuring the eventual consistency of system data, the system resources consumed are large and the cost of handling the generated exceptions is high. Summary of the Invention

[0003] In view of this, embodiments of this application provide an exception handling method, apparatus, electronic device, and computer-readable medium, which can solve the problems that in the existing distributed environment, when handling service call exceptions and ensuring the eventual consistency of system data, a large amount of system resources are consumed and the cost of handling the generated exceptions is high.

[0004] To achieve the above object, according to one aspect of the embodiments of this application, an exception handling method is provided, including:

[0005] In response to a service call exception, determining the corresponding upstream system identifier and downstream system identifier;

[0006] Judging the exception type, and determining the target logic according to the exception type;

[0007] Executing the target logic to generate a return result message;

[0008] Determining the type of the return result message, and determining the target system according to the type of the return result message;

[0009] Obtaining the calculation result data corresponding to the target system, and executing a result processing logic based on the calculation result data to obtain a target result data.

[0010] Optionally, before determining the corresponding upstream system identifier and downstream system identifier, the method further includes:

[0011] In response to a service call failure or a service call timeout, a service call exception is determined.

[0012] Optionally, determine the target logic, including:

[0013] In response to the exception type being a service call failure, determining that the write rollback logic is the target logic.

[0014] Optionally, determine the target logic, including:

[0015] In response to the exception type being a service call timeout, determining the unknown result output logic as the target logic.

[0016] Optionally, identify target systems, including:

[0017] In response to the type of the returned result information being unknown, it is determined that the target system is the first system that initiates the request.

[0018] Optionally, identify target systems, including:

[0019] In response to the type of the returned result information being known, it is determined that the target system is a system corresponding to the upstream system identifier.

[0020] Optionally, obtaining calculation result data corresponding to the target system includes:

[0021] In response to the target system being the system corresponding to the upstream system identifier, determining the returned result information as calculation result data corresponding to the target system and acquiring the calculation result data;

[0022] In response to the target system being the first system to initiate the request, data obtained by result processing based on the returned result information by the first system to initiate the request is determined as calculation result data and the calculation result data is acquired.

[0023] Optionally, executing result processing logic based on the calculation result data to obtain target result data includes:

[0024] In response to the calculation result data corresponding to unknown or timeout, the following result processing logic is executed:

[0025] Query the downstream calculation result data corresponding to the downstream system identifier;

[0026] Execute result processing based on downstream calculation result data, and in response to execution failure, perform write rollback until the execution is successful to obtain upstream calculation result data corresponding to the upstream system identifier;

[0027] Based on the upstream calculation result data, the corresponding result processing is performed by the first system that initiates the request until the target result data is obtained.

[0028] In addition, the present application also provides an exception handling device, including:

[0029] an anomaly detection unit, configured to determine a corresponding upstream system identifier and a downstream system identifier in response to a service call anomaly;

[0030] a target logic determination unit, configured to determine an abnormality type and determine a target logic according to the abnormality type;

[0031] An information generating unit is configured to execute target logic and generate return result information;

[0032] The target system determination unit is configured to determine the type of the returned result information, and determine the target system according to the type of the returned result information;

[0033] The result processing unit is configured to obtain calculation result data corresponding to the target system, and execute result processing logic based on the calculation result data to obtain target result data.

[0034] Optionally, the anomaly detection unit is further configured to:

[0035] In response to a service call failure or a service call timeout, a service call exception is determined.

[0036] Optionally, the target logic determination unit is further configured to:

[0037] In response to the exception type being a service call failure, determining that the write rollback logic is the target logic.

[0038] Optionally, the target logic determination unit is further configured to:

[0039] In response to the exception type being a service call timeout, determining the unknown result output logic as the target logic.

[0040] Optionally, the target system determination unit is further configured to:

[0041] In response to the type of the returned result information being unknown, it is determined that the target system is the first system that initiates the request.

[0042] Optionally, the target system determination unit is further configured to:

[0043] In response to the type of the returned result information being known, it is determined that the target system is a system corresponding to the upstream system identifier.

[0044] Optionally, the result processing unit is further configured to:

[0045] In response to the target system being the system corresponding to the upstream system identifier, determining the returned result information as calculation result data corresponding to the target system and acquiring the calculation result data;

[0046] In response to the target system being the first system to initiate a request, determine the data obtained by the first system to initiate the request through result processing based on the return result information as the calculation result data and obtain the calculation result data.

[0047] Optionally, the result processing unit is further configured to:

[0048] In response to the calculation result data corresponding to unknown or timeout, execute the following result processing logic:

[0049] Query the downstream calculation result data corresponding to the downstream system identifier;

[0050] Perform result processing based on the downstream calculation result data. In response to the execution failure, perform a write rollback until the upstream calculation result data corresponding to the upstream system identifier is obtained successfully;

[0051] Perform corresponding result processing through the first system to initiate the request based on the upstream calculation result data until the target result data is obtained.

[0052] In addition, the present application also provides an exception handling electronic device, including: one or more processors; a storage device for storing one or more programs, when the one or more programs are executed by the one or more processors, enabling the one or more processors to implement the exception handling method as described above.

[0053] In addition, the present application also provides a computer-readable medium, on which a computer program is stored, and when the program is executed by a processor, it implements the exception handling method as described above.

[0054] One embodiment of the above invention has the following advantages or beneficial effects: In response to a service call exception, the present application determines the corresponding upstream system identifier and downstream system identifier; judges the exception type, and determines the target logic according to the exception type; executes the target logic to generate return result information; determines the type of the return result information, and determines the target system according to the type of the return result information; obtains the calculation result data corresponding to the target system, and performs result processing logic based on the calculation result data to obtain the target result data. By performing result processing logic based on the calculation result data of the target system after determining the target system, it is possible to avoid performing result processing logic on each system in the call chain, thereby saving the computing resources and storage resources of the system, and omitting the storage step of the processing results of each system in the call chain, reducing the demand for storage media, and further reducing the system cost for handling the generated exceptions.

[0055] The further effects of the above non-conventional optional methods will be described in combination with specific embodiments below. Description of the Drawings

[0056] The accompanying drawings are used to better understand the present application and do not constitute an undue limitation to the present application. Among them:

[0057] Figure 1 is a schematic diagram of the main process of the exception handling method provided according to an embodiment of the present application;

[0058] Figure 2 is a schematic diagram of the main process of the exception handling method provided according to an embodiment of the present application;

[0059] Figure 3 is a schematic diagram of the application scenario of the exception handling method provided according to an embodiment of the present application;

[0060] Figure 4 is a schematic diagram of the main units of the exception handling device according to an embodiment of the present application;

[0061] Figure 5 is an exemplary system architecture diagram to which the embodiments of the present application can be applied;

[0062] Figure 6 is a schematic diagram of the structure of a computer system of a terminal device or a server suitable for implementing the embodiments of the present application. Detailed implementation manners

[0063] The following describes exemplary embodiments of the present application with reference to the accompanying drawings. Various details of the embodiments of the present application are included to facilitate understanding, and they should be considered merely exemplary. Therefore, those of ordinary skill in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present application. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted below. It should be noted that in the technical solutions of the present disclosure, in terms of the collection, collection, update, analysis, processing, use, transmission, storage, etc. of user personal information, they all comply with the provisions of relevant laws and regulations, are used for legal purposes, and do not violate public order and good customs. Necessary measures are taken for user personal information to prevent illegal access to user personal information data, and to safeguard user personal information security, network security, and national security.

[0064] Figure 1 is a schematic diagram of the main process of the exception handling method provided according to an embodiment of the present application. As Figure 1 shown, the exception handling method includes:

[0065] Step S101, in response to a service call exception, determine the corresponding upstream system identifier and downstream system identifier.

[0066] In this embodiment, the execution subject of the exception handling method (for example, it can be a server, which can be communicatively connected to each system on the call chain and thus can call each system for business processing) can detect whether a service call exception occurs through a wired connection or a wireless connection.

[0067] Specifically, before determining the corresponding upstream system identifier and downstream system identifier, the exception handling method further includes: in response to a service call failure or a service call timeout, determining a service call exception.

[0068] When it is detected that a service call fails or a service call times out, it indicates that the call between two systems on the system call chain times out. Obtain the upstream system identifier and downstream system identifier corresponding to the two systems where the timeout occurs. Query the processing result of the downstream system corresponding to the downstream system identifier and return it to the upstream system corresponding to the upstream system identifier to complete the corresponding business processing.

[0069] Step S102, determine the exception type, and determine the target logic according to the exception type.

[0070] Exemplarily, the exception type can include a service call failure or a service call timeout.

[0071] Specifically, determining the target logic includes: in response to the exception type being a service call failure, determining the write-back rollback logic as the target logic.

[0072] Exemplarily, as Figure 3 shown, when the system corresponding to the upstream system identifier is System B, the system corresponding to the downstream system identifier is System C, and the exception type is a service call failure, the target logic that can be executed is the write-back rollback of B service.

[0073] Specifically, determining the target logic includes: in response to the exception type being a service call timeout, determining the unknown result output logic as the target logic.

[0074] Exemplarily, as Figure 3 shown, when the system corresponding to the upstream system identifier is System B, the system corresponding to the downstream system identifier is System C, and the exception type is a service call timeout, the target logic that can be executed is to output an unknown result B. Here, "B" can be the number or name of the system that has a service call exception in the call chain. The meaning of "outputting an unknown result B" can be: outputting unknown result data + the number or name of the system that has a service call exception (for example, B), so that the upstream system (for example Figure 3 System A in) can clearly know which system has a service call exception, thereby accelerating the positioning speed of the system with a service call exception and improving the exception handling speed.

[0075] Step S103, execute the target logic and generate return result information.

[0076] When the target logic is determined, the execution subject can execute the target logic, such as executing the logic of business write rollback of B (i.e., business write rollback of system B) or executing the logic of outputting unknown result B, to generate return result information. For example, the return result information can be calculation result B or unknown result B. "B" here can be the number or name of the calculation result data output system or the number or name of the system where the service call exception occurs in the call chain. Then, outputting "calculation result B" can mean: outputting the calculation result data obtained by executing the logic of business write rollback of B + the number or name of the data output system (for example, B). "Outputting unknown result B" can mean: outputting unknown result data + the number or name of the system where the service call exception occurs (for example, B), so that the upstream system (for example Figure 3 A system in the example (A system) specifies which system has a service call exception, speeds up the location of the system where the service call exception has occurred, and thus improves the exception handling speed.

[0077] Step S104, determining the type of the returned result information, and determining the target system according to the type of the returned result information.

[0078] The type of the returned result information may include known and unknown. Specifically, determining the target system includes: in response to the type of the returned result information being known, determining that the target system is the system corresponding to the upstream system identifier, that is, the upstream system where the service call exception occurs, for example Figure 3 The B system in.

[0079] When the type of the returned result information is known, it indicates that the returned result information is a known calculation result obtained after the write rollback is successful (for example Figure 3 When the type of the returned result information is unknown, it indicates that the returned result information is an unknown result of the output (for example Figure 3 B). When the type of the returned result information is known, the target system can identify the corresponding system for the upstream system, for example Figure 3 The B system in.

[0080] When the type of the returned result information is unknown, the target system may be the system that initiated the request for the first time (e.g. Figure 3 The system that initiates the request for the first time may be, for example, the system that initiates the service-to-service call processing using the call chain for the first time (e.g. Figure 3 A system in ).

[0081] Step S105, obtaining calculation result data corresponding to the target system, and executing result processing logic based on the calculation result data to obtain target result data.

[0082] Get the calculation result data corresponding to the target system and call the first system that initiated the request (for example Figure 3 The A system in the system executes the result processing logic based on the calculation result data to obtain the target result data. This reduces the consumption of system resources, reduces the cost of exception processing, and improves the speed of exception processing.

[0083] For example, when the target system is the system corresponding to the upstream system identifier (for example Figure 3 When the target system (e.g. Figure 3 The calculation result data corresponding to the B system in the example may be the return result information obtained after executing the write rollback logic (i.e., the corresponding target logic), for example Figure 3 The calculation result B shown in FIG. Then, the result processing logic is executed based on the calculation result data to obtain the target result data, that is, the target system (eg Figure 3 The calculation result data of the B system in Figure 3 The calculation result B shown in FIG. 1 is transmitted back to system A (i.e., the system that initiated the request for the first time), so that system A performs result processing based on the obtained calculation result B to obtain the calculation result data of system A, and executes the result processing logic based on the calculation result data of system A to obtain the target result data. Specifically, the calculation result data of system A can be success, failure, unknown, or timeout. When the calculation result data corresponding to system A is successful, the corresponding result processing logic is executed, that is, the calculation result A is obtained, the result A is stored, and the business processing is completed; when the calculation result data corresponding to system A is failed, the corresponding result processing logic is executed, that is, the A business write rollback is executed to obtain the calculation result A, the result A is stored, and the business processing is completed; when the calculation result data corresponding to system A is unknown, the corresponding result processing logic is executed, that is, system A starts the confirmation mechanism and reversely checks the result B, which can be specifically the calculation result C obtained by querying system C, calling system B to perform result processing based on the calculation result C obtained by the query, if the result processing is successful, the calculation result B is obtained, if the result processing fails, the B business write rollback is performed to obtain the calculation result B, and then system A obtains the calculation result B returned by system B and continues to process the result until system A obtains the final processing result, that is Figure 3The calculated result A therein is stored, and after storing result A, the business process is completed. When the calculated result data corresponding to System A is timed out, the corresponding result processing logic is executed, that is, after starting the confirmation mechanism in System A, result B is retrieved. Specifically, it can be the calculated result C obtained by querying System C. System B is called to perform result processing based on the retrieved calculated result C. If the result processing is successful, calculated result B is obtained. If the result processing fails, B service write-back rollback is performed to obtain calculated result B. Then, System A obtains the calculated result B transmitted back by System B and continues with the result processing until System A obtains the final processing result, that is Figure 3 The calculated result A therein is stored, and after storing result A, the business process is completed.

[0084] Exemplarily, when the target system is the system that initiates the request for the first time (such as Figure 3 System A therein), the calculated result data corresponding to the target system can be success, failure, unknown, or timeout. When the calculated result data corresponding to the target system is success, the corresponding result processing logic is executed, that is, calculated result A is obtained, result A is stored, and the business process is completed. When the calculated result data corresponding to the target system is failure, the corresponding result processing logic is executed, that is, A service write-back rollback is performed, calculated result A is obtained, result A is stored, and the business process is completed. When the calculated result data corresponding to the target system is unknown, the corresponding result processing logic is executed, that is, System A starts the confirmation mechanism to retrieve result B. Specifically, it can be the calculated result C obtained by querying System C. System B is called to perform result processing based on the retrieved calculated result C. If the result processing is successful, calculated result B is obtained. If the result processing fails, B service write-back rollback is performed to obtain calculated result B. Then, System A obtains the calculated result B transmitted back by System B and continues with the result processing until System A obtains the final processing result, that is Figure 3 The calculated result A therein is stored, and after storing result A, the business process is completed. When the calculated result data corresponding to the target system is timed out, the corresponding result processing logic is executed, that is, after starting the confirmation mechanism in System A, result B is retrieved. Specifically, it can be the calculated result C obtained by querying System C. System B is called to perform result processing based on the retrieved calculated result C. If the result processing is successful, calculated result B is obtained. If the result processing fails, B service write-back rollback is performed to obtain calculated result B. Then, System A obtains the calculated result B transmitted back by System B and continues with the result processing until System A obtains the final processing result, that is Figure 3 The calculated result A therein is stored, and after storing result A, the business process is completed.

[0085] In this embodiment, in response to a service call exception, the corresponding upstream system identifier and downstream system identifier are determined; the exception type is judged, and according to the exception type, the target logic is determined; the target logic is executed to generate return result information; the type of the return result information is determined, and according to the type of the return result information, the target system is determined; the calculation result data corresponding to the target system is obtained, and the result processing logic is executed based on the calculation result data to obtain the target result data. By executing the result processing logic based on the calculation result data of the target system after determining the target system, it is possible to avoid executing the result processing logic for each system in the call chain, thereby saving the computing resources and storage resources of the system, and omitting the storage step of the processing results of each system in the call chain, reducing the demand for the storage medium, and further reducing the system cost for processing the generated exception.

[0086] Figure 2 is a schematic diagram of the main process of the exception handling method provided by an embodiment of the present application, as Figure 2 shown, the exception handling method includes:

[0087] Step S201, in response to a service call exception, determine the corresponding upstream system identifier and downstream system identifier.

[0088] By detecting in real time or at regular intervals whether a service call fails or times out, if a service call fails or times out, the corresponding upstream system identifier and downstream system identifier of the generated service call exception are determined. The upstream system identifier can be the number or name of the upstream system, etc., and the embodiments of the present application do not make specific limitations on the upstream system identifier. The downstream system identifier can be the number or name of the downstream system, etc., and the embodiments of the present application do not make specific limitations on the downstream system identifier.

[0089] Step S202, judge the exception type, and according to the exception type, determine the target logic.

[0090] The exception type, for example, can be the type of exception generated by the system corresponding to the upstream system identifier during the service call process, for example, it can be a service call failure or a service call timeout, etc., and the embodiments of the present application do not make specific limitations on the exception type. According to the exception type, the target logic for handling the exception is determined. The target logic can be a write-back rollback logic corresponding to the exception type of service call failure or an unknown result output logic corresponding to the exception type of service call timeout. Among them, the unknown result output logic means that when a service call timeout is detected, unknown result information is output.

[0091] Step S203, execute the target logic to generate return result information.

[0092] When the target logic is determined, the execution subject can generate an asynchronous task based on the target logic and execute the asynchronous task to generate return result information. By executing asynchronous tasks, the system response speed can be improved and the system's processing efficiency for business can be improved.

[0093] Step S204, determining the type of the returned result information, and determining the target system according to the type of the returned result information.

[0094] Specifically, determining the target system includes: in response to the type of the returned result information being known, determining the target system to be a system corresponding to the upstream system identifier.

[0095] For example, Figure 3 As shown, the system corresponding to the upstream system identifier may be, for example, system B. When the type of the returned result information is known, Figure 3 The B system in is determined as the target system.

[0096] Specifically, the determining the target system includes: in response to the type of the returned result information being unknown, determining the target system to be the first system to initiate the request (eg Figure 3 A system in ).

[0097] It is understandable that the target system may be any upstream system where a service call exception occurs, and the embodiment of the present application does not specifically limit the target system. Figure 3 The A, B, and C systems are only schematic. On the one hand, there can be other systems in a distributed manner, and on the other hand, there can be more systems on the call chain.

[0098] Step S205 , in response to the target system being the system corresponding to the upstream system identifier, determining the returned result information as the calculation result data corresponding to the target system and acquiring the calculation result data.

[0099] If the target system is the system corresponding to the upstream system identifier, for example Figure 3 The B system in Figure 3 The known calculation result B can be obtained in the B system in the C system. The execution subject can use the calculation result B obtained after the B system successfully processes the result based on the calculation result C of the C system, or the calculation result B obtained after the B system fails to process the result based on the calculation result C of the C system and then executes the B business write rollback as the return result information, that is, as the calculation result data corresponding to the target system. Among them, the meaning of "calculation result C" can be: the calculation result data obtained by executing the logic of C business write rollback + the number or name of the data output system (for example, C).

[0100] Step S206: In response to the target system being the first system to initiate a request, determine the data obtained by the first system to initiate a request through result processing based on the return result information as the calculation result data and obtain the calculation result data.

[0101] If the target system is the first system to initiate a request, for example Figure 3 System A in Figure 3 it indicates that the calculation result B cannot be obtained in Figure 3 System B in

[0102] In response to the calculation result data corresponding to unknown or timeout, execute the following result processing logic:

[0103] Step S207: Query the downstream calculation result data corresponding to the downstream system identifier.

[0104] When the calculation result data obtained by the first system to initiate a request is unknown or timed out, the first system to initiate a request can start a confirmation mechanism to back-check result B, that is, obtain Figure 3 the calculation result B of Figure 3 System B in Figure 3 specifically, first query the calculation result data (for example

[0105] the calculation result C in

[0106] corresponding to the downstream system identifier (for example Figure 3 the system identifier C of Figure 3 System C in Figure 3 ). Figure 3 ).

[0107] Step S208: Perform result processing based on the downstream calculation result data. In response to the failure of the execution, perform a write rollback until the upstream calculation result data corresponding to the upstream system identifier is successfully obtained.

[0108] The upstream calculation result data corresponding to the upstream system identifier obtained by reverse query (for example Figure 3 The result of the calculation in B) is returned to the first system that initiated the request (for example Figure 3 A in the example), through the first system that initiated the request (e.g. Figure 3 System A in the example above) is based on the upstream calculation result data obtained (e.g. Figure 3 The calculation result B) is processed again until the target result data (i.e. Figure 3 The calculation results in A).

[0109] In the embodiment of the present application, for example, when a call between any two systems in the system call chain times out, the request is interrupted and an unknown result is returned to the upstream system (for example, Figure 3 The first system that initiates the request (e.g. Figure 3 A system in the process establishes a result confirmation mechanism, which requests each system (such as system B and system C) in turn. After each system queries the processing result (such as calculation result C) of the downstream (such as system C), it calculates its own processing result (such as calculation result B) and returns it to the upstream. If an exception or timeout occurs during this process, the confirmation is interrupted and the next confirmation request is initiated by the result confirmation mechanism until the first system (such as system A) obtains the final processing result (i.e., calculation result B) and the request ends. After determining the target system, the calculation result data based on the target system is sent by the first system that initiates the request (i.e., the first system that initiates the business processing request, such as Figure 3 The A system in the call chain) executes the result processing logic, which can avoid executing the result processing logic in each system on the call chain, thereby saving the system's computing resources and storage resources, and omitting the storage step of the processing results of each system on the call chain, reducing the demand for storage media, and further reducing the system cost of handling the generated exceptions.

[0110] Figure 3 1 is a schematic diagram of an application scenario of an exception handling method provided according to an embodiment of the present application. The exception handling method of the embodiment of the present application is applied to a processing scenario when an exception occurs in a service call between systems in a distributed system. Figure 3As shown, for example, when the system call chain includes system A, system B, and system C, system A first executes the A business write operation to request downstream data, that is, to request data from system B. System B executes the B business write operation to request downstream data, that is, to request data from system C. System C executes the C business write operation to obtain the calculation result C. At this time, when system B obtains the calculation result C of system C for result processing, if the result processing is successful, the corresponding calculation result B is obtained. If the result processing fails, the B business write rollback is executed until the calculation result B is obtained. If the result processing times out, the unknown result B is output, and the processing result is returned to system A. After obtaining the processing result, system A executes the corresponding processing logic according to whether the processing result is successful, failed, unknown, or timed out. When the processing result is successful, the calculation result A is directly obtained and stored; when the processing result is failed, the A business write rollback is executed until the calculation result A is obtained and stored; when the processing result is unknown, the A system starts the confirmation mechanism to reversely check the result B, and the B system queries the result C to obtain the calculation result C. The B system performs result processing based on the obtained calculation result C. When the result processing is successful, the calculation result B is directly obtained. When the result processing fails, the B business write rollback is executed until the calculation result B is obtained. Then the B system returns the obtained calculation result B to the A system, and the A system continues to process the result to obtain the final calculation result A and store the calculation result A. When the processing result is timed out, after the A system starts the confirmation mechanism, the result B is reversely checked, and the B system queries the result C to obtain the calculation result C. The B system performs result processing based on the obtained calculation result C. When the result processing is successful, the calculation result B is directly obtained. When the result processing fails, the B business write rollback is executed until the calculation result B is obtained. Then, the calculation result B is transmitted back to the A system by the B system, and the A system continues to process the result to obtain the final calculation result A and store the calculation result A. After the target system is determined, the calculation result data based on the target system is obtained by Figure 3 System A (i.e., the first system that initiates the request) executes the result processing logic, which can avoid the execution of the result processing logic by each system in the call chain, thereby saving the system's computing resources and storage resources, and omitting the step of storing the processing results of each system in the call chain, reducing the demand for storage media, and further reducing the system cost of handling the generated exceptions.

[0111] Figure 4 Schematic diagram of the main units of the exception handling device according to an embodiment of the present application. Figure 4 As shown, the exception handling device 400 includes an exception detection unit 401 , a target logic determination unit 402 , an information generation unit 403 , a target system determination unit 404 and a result processing unit 405 .

[0112] The anomaly detection unit 401 is configured to determine the corresponding upstream system identifier and downstream system identifier in response to the service call anomaly;

[0113] The target logic determination unit 402 is configured to determine the abnormality type and determine the target logic according to the abnormality type;

[0114] The information generating unit 403 is configured to execute the target logic and generate the return result information;

[0115] The target system determination unit 404 is configured to determine the type of the returned result information, and determine the target system according to the type of the returned result information;

[0116] The result processing unit 405 is configured to obtain the calculation result data corresponding to the target system, and execute the result processing logic based on the calculation result data to obtain the target result data.

[0117] In some embodiments, the anomaly detection unit 401 is further configured to: determine that the service call is abnormal in response to a service call failure or a service call timeout.

[0118] In some embodiments, the target logic determination unit 402 is further configured to: in response to the exception type being a service call failure, determine the write rollback logic as the target logic.

[0119] In some embodiments, the target logic determination unit 402 is further configured to: in response to the exception type being a service call timeout, determine the unknown result output logic as the target logic.

[0120] In some embodiments, the target system determination unit 404 is further configured to: in response to the type of the returned result information being unknown, determine that the target system is the first system that initiates the request.

[0121] In some embodiments, the target system determining unit 404 is further configured to: in response to the type of the returned result information being known, determine that the target system is a system corresponding to the upstream system identifier.

[0122] In some embodiments, the result processing unit 405 is further configured to: in response to the target system being the system corresponding to the upstream system identifier, determine the returned result information as the calculation result data corresponding to the target system and obtain the calculation result data; in response to the target system being the first system to initiate the request, determine the data obtained by the first system to initiate the request performing result processing based on the returned result information as the calculation result data and obtain the calculation result data.

[0123] In some embodiments, the result processing unit 405 is further configured to: in response to the calculation result data corresponding to unknown or timeout, execute the following result processing logic: query the downstream calculation result data corresponding to the downstream system identifier; perform result processing based on the downstream calculation result data, and in response to the failure of the execution, perform a write rollback until the upstream calculation result data corresponding to the upstream system identifier is successfully obtained; based on the upstream calculation result data, perform corresponding result processing through the system that initiated the request first until the target result data is obtained.

[0124] It should be noted that the exception handling method and the exception handling device of the present application have a corresponding relationship in terms of specific implementation content, so the repeated content will not be described again.

[0125] Figure 5 An exemplary system architecture 500 to which the exception handling method or the exception handling device of the embodiments of the present application can be applied is shown.

[0126] As Figure 5 shown, the system architecture 500 may include terminal devices 501, 502, 503, a network 504, and a server 505. The network 504 is used to provide a medium for communication links between the terminal devices 501, 502, 503 and the server 505. The network 504 may include various connection types, such as wired, wireless communication links, or fiber optic cables, etc.

[0127] Users can use the terminal devices 501, 502, 503 to interact with the server 505 through the network 504 to receive or send messages, etc. Various communication client applications may be installed on the terminal devices 501, 502, 503, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only as examples).

[0128] The terminal devices 501, 502, 503 may be various electronic devices having an exception handling screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, and desktop computers, etc.

[0129] The server 505 may be a server that provides various services, such as a background management server (merely an example) that supports service call exceptions detected by the user using the terminal devices 501, 502, and 503. The background management server may, in response to a service call exception, determine the corresponding upstream system identifier and downstream system identifier; determine the exception type, and based on the exception type, determine the target logic; execute the target logic to generate return result information; determine the type of the return result information, and based on the type of the return result information, determine the target system; obtain the calculation result data corresponding to the target system, and execute result processing logic based on the calculation result data to obtain target result data. By executing result processing logic based on the calculation result data of the target system after determining the target system, it is possible to avoid executing result processing logic on each system in the call chain, thereby saving the computing resources and storage resources of the system, and omitting the storage step of the processing results of each system in the call chain, reducing the demand for storage media, and further reducing the system cost for handling the generated exceptions.

[0130] It should be noted that the exception handling method provided by the embodiments of the present application is generally executed by the server 505. Correspondingly, the exception handling device is generally disposed in the server 505.

[0131] It should be understood that Figure 5 the numbers of the terminal devices, networks, and servers in

[0132] are merely illustrative. According to the implementation requirements, there may be any number of terminal devices, networks, and servers. Figure 6 is a schematic structural diagram of a computer system 600 of a terminal device suitable for implementing the embodiments of the present application. Figure 6 The terminal device shown is merely an example and should not impose any limitations on the functions and usage scope of the embodiments of the present application.

[0133] As Figure 6 shown, the computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 602 or the program loaded from the storage section 608 into the random access memory (RAM) 603. In the RAM 603, various programs and data required for the operation of the computer system 600 are also stored. The CPU 601, ROM 602, and RAM 603 are connected to each other through a bus 604. The input / output (I / O) interface 605 is also connected to the bus 604.

[0134] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc. and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 605 as required. A removable medium 611 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is installed on the drive 610 as required so that a computer program read therefrom is installed into the storage section 608 as required.

[0135] Specifically, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product that includes a computer program carried on a computer-readable medium, and the computer program includes program codes for performing the methods shown in the flowcharts. In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 609, and / or installed from the removable medium 611. When the computer program is executed by a central processing unit (CPU) 601, the above-described functions defined in the system of the present application are executed.

[0136] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can, for example, include but is not limited to an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of a computer-readable storage medium can include but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this application, a computer-readable storage medium can be any tangible medium that contains or stores a program, and this program can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in a baseband or as part of a carrier wave, in which computer-readable program code is carried. Such a propagated data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, and this computer-readable medium can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on a computer-readable medium can be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0137] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram can represent a module, a program segment, or a part of code, and the above-mentioned module, program segment, or part of code contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks can occur in a different order from that marked in the accompanying drawings. For example, two consecutive blocks shown can actually be executed substantially in parallel, and they can sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram or flowchart, and the combination of blocks in the block diagram or flowchart, can be implemented by a dedicated hardware-based system for performing the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0138] The units involved in the embodiments described in the present application may be implemented by software or hardware. The units described may also be set in a processor, for example, it may be described as: a processor includes an anomaly detection unit, a target logic determination unit, an information generation unit, a target system determination unit, and a result processing unit. The names of these units do not, in some cases, constitute limitations on the units themselves.

[0139] As another aspect, the present application also provides a computer-readable medium, which may be included in the device described in the above embodiment; or it may exist independently without being assembled into the device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by a device, the device responds to the service call exception, determines the corresponding upstream system identifier and downstream system identifier; determines the exception type, and determines the target logic according to the exception type; executes the target logic and generates return result information; determines the type of the return result information, and determines the target system according to the type of the return result information; obtains the calculation result data corresponding to the target system, and executes the result processing logic based on the calculation result data to obtain the target result data.

[0140] According to the technical solution of the embodiment of the present application, after determining the target system, the system that first initiates the request (i.e., the system that first initiates the business processing request, for example, Figure 3 The A system in the call chain) executes the result processing logic, which can avoid executing the result processing logic in each system on the call chain, thereby saving the system's computing resources and storage resources, and omitting the storage step of the processing results of each system on the call chain, reducing the demand for storage media, and further reducing the system cost of handling the generated exceptions.

[0141] The above specific implementations do not constitute a limitation on the protection scope of this application. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of this application should be included in the protection scope of this application.

Claims

1. An exception handling method, It is characterized in that include: In response to the service call exception, determining a corresponding upstream system identifier and a downstream system identifier; Determine the type of exception, and determine the target logic according to the type of exception; Execute the target logic and generate return result information; Determine the type of the returned result information, and determine the target system according to the type of the returned result information; The calculation result data corresponding to the target system is obtained, and the result processing logic is executed based on the calculation result data to obtain the target result data.

2. The method according to claim 1, It is characterized in that Before determining the corresponding upstream system identifier and downstream system identifier, the method further includes: In response to a service call failure or a service call timeout, the service call is determined to be abnormal.

3. The method according to claim 1, It is characterized in that The target determination logic includes: In response to the exception type being a service call failure, determining the write rollback logic as the target logic.

4. The method according to any one of claims 1 to 3, It is characterized in that The target determination logic includes: In response to the exception type being a service call timeout, the unknown result output logic is determined to be the target logic.

5. The method according to claim 1, It is characterized in that The target system is determined, comprising: In response to the type of the returned result information being unknown, it is determined that the target system is the first system to initiate the request.

6. The method according to claim 1, It is characterized in that The target system is determined, comprising: In response to the type of the returned result information being known, it is determined that the target system is the system corresponding to the upstream system identifier.

7. The method according to claim 1, It is characterized in that The obtaining of calculation result data corresponding to the target system includes: In response to the target system being the system corresponding to the upstream system identifier, determining the returned result information as calculation result data corresponding to the target system and acquiring the calculation result data; In response to the target system being the first system to initiate a request, data obtained by result processing performed by the first system to initiate a request based on the returned result information is determined as calculation result data and the calculation result data is acquired.

8. The method according to claim 7, It is characterized in that The executing result processing logic based on the calculation result data to obtain target result data includes: In response to the calculation result data corresponding to unknown or timed out, the following result processing logic is executed: Query the downstream calculation result data corresponding to the downstream system identifier; Execute result processing based on the downstream calculation result data, and in response to execution failure, perform write rollback until the execution is successful to obtain the upstream calculation result data corresponding to the upstream system identifier; Based on the upstream calculation result data, corresponding result processing is performed by the first system that initiates the request until the target result data is obtained.

9. An exception handling device, It is characterized in that include: an anomaly detection unit, configured to determine a corresponding upstream system identifier and a downstream system identifier in response to a service call anomaly; A target logic determination unit, configured to determine an exception type and determine a target logic according to the exception type; An information generation unit, configured to execute the target logic and generate return result information; A target system determination unit, configured to determine the type of the return result information and determine a target system according to the type of the return result information; A result processing unit, configured to obtain calculation result data corresponding to the target system and execute a result processing logic based on the calculation result data to obtain target result data.

10. An exception handling electronic device characterized in that it includes: one or more processors; a storage device for storing one or more programs, when the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1-8.

11. A computer-readable medium, on which a computer program is stored, characterized in that when the program is executed by a processor, the method according to any one of claims 1-8 is implemented.

Images